2018年2月 – 王春伟的技术博客

今天莫名其妙我的博客出现Error establishing a database connection，一看应该是数据连接不上了。首先看了下wp-config.php，发现无异常。重启nginx,更换php5均没有效果。网上查了下，说是http://blog.csdn.net/mwb310/article/details/53009920，众说纷纭，有文件格式错误，mysql版本错误等等，试了均无效。

想着不如先把sql dump一份备份，所以

mysqldump -uxxx -pxxx --dataname >wordpress.log

发现：

warning : 250 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_statistics_search
warning : 156 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_statistics_useronline
warning : 252 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_statistics_visit
warning : 252 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_statistics_visitor
warning : 252 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_term_relationships
warning : 32 clients are using or haven’t closed the table properly
status : OK
wangchunwei.wp_term_taxonomy
warning : 31 clients are using or haven’t closed the table properly
status : OK

mysqldump: Got error: 145: Table ‘./xxx/wp_options’ is marked as crashed and should be repaired when using LOCK TABLES

网上参考了：

修复 MySQL 数据库数据表问题可以由 mysqlcheck 来解决，先用 mysqlcheck 查看一下：

# mysqlcheck -u root -p wordpress
Enter password:

然后添加 –auto-repair 参数自动修复，最好修复前备份一下数据库：

# mysqldump -u root -p wordpress > wordpress.sql
Enter password:

# mysqlcheck -u root -p wordpress --auto-repair
Enter password:
wordpress.wp_commentmeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_commentmeta`" or dump/reload to fix it!
wordpress.wp_comments
error    : Table upgrade required. Please do "REPAIR TABLE `wp_comments`" or dump/reload to fix it!
wordpress.wp_links
error    : Table upgrade required. Please do "REPAIR TABLE `wp_links`" or dump/reload to fix it!
wordpress.wp_options
error    : Table upgrade required. Please do "REPAIR TABLE `wp_options`" or dump/reload to fix it!
wordpress.wp_postmeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_postmeta`" or dump/reload to fix it!
wordpress.wp_posts
error    : Table upgrade required. Please do "REPAIR TABLE `wp_posts`" or dump/reload to fix it!
wordpress.wp_term_relationships                OK
wordpress.wp_term_taxonomy
error    : Table upgrade required. Please do "REPAIR TABLE `wp_term_taxonomy`" or dump/reload to fix it!
wordpress.wp_terms
error    : Table upgrade required. Please do "REPAIR TABLE `wp_terms`" or dump/reload to fix it!
wordpress.wp_usermeta
error    : Table upgrade required. Please do "REPAIR TABLE `wp_usermeta`" or dump/reload to fix it!
wordpress.wp_users
error    : Table upgrade required. Please do "REPAIR TABLE `wp_users`" or dump/reload to fix it!

Repairing tables
wordpress.wp_commentmeta                       OK
wordpress.wp_comments                          OK
wordpress.wp_links                             OK
wordpress.wp_options                           OK
wordpress.wp_postmeta                          OK
wordpress.wp_posts                             OK
wordpress.wp_term_taxonomy                     OK
wordpress.wp_terms                             OK
wordpress.wp_usermeta                          OK
wordpress.wp_users                             OK

网站恢复了！应该是链接没有释放

在使用Laravel或者Lumen时会碰到这种情况，如果php的代码中产生了Notice或者Warning，会导致Lumen跳到错误页，日志中会打印一个很长很长的stack trace，如下图：

$app->get('/test', function () use ($app) {
	$arr = [];
	print($arr['name']);
});
#请求/test 产生的日志
[2017-07-12 11:55:54] lumen.ERROR: ErrorException: Undefined index: name in /home/vagrant/Code/featurestream/routes/web.php:16
Stack trace:
#0 /home/vagrant/Code/featurestream/routes/web.php(16): Laravel\Lumen\Application->Laravel\Lumen\Concerns\{closure}(8, 'Undefined index...', '/home/vagrant/C...', 16, Array)
#1 [internal function]: Closure->{closure}()
#2 /home/vagrant/Code/featurestream/vendor/illuminate/container/BoundMethod.php(29): call_user_func_array(Object(Closure), Array)
....

上面的日志只截取了一小部分，实际运行时最简单的api请求Lumen的stack trace会有30层左右，Laravel的会有60层..
另外一个重要的问题是，这种处理机制会让一些小错误把整个请求搞挂，代码中到处加if(isset($arr['xx'])) 或者设置默认值。
对于这个问题，Laravel和Lumen设计的初衷是好的：所有的PHP错误都应该被处理，包括Notice和Warning。就是太严格了，有时候我们并不需要代码有这么严格的检查，出现Notice或者Warning时，只需要打印个模块日志或者有PHP日志就行。
先看下Lumen中的错误是如何处理的（Laravel中也差不多，不再单独讲）。

错误处理流程

错误Handler

先看Lumen的入口：bootstrap/app.php，有一段错误处理相关的代码：

$app->singleton(
    Illuminate\Contracts\Debug\ExceptionHandler::class,
    App\Exceptions\Handler::class
);

singleton是往app（Lumen的服务容器）里注入实例的方法，这里实例化了一个ExceptionHandler类，实例为Handler。后面的代码如果有从$app里取ExceptionHandler的实例的话，会返回Handler这个类的实例。
Handler类在App\Exceptions目录下，代码如下。比较简单，只包含两个方法，再去看父类(Laravel\Lumen\Exceptions\Handler)的方法逻辑会发现，report方法负责打印日志（也就是上文那个长长的trace），render方法会根据错误类型的不同构建错误页面。

public function report(Exception $e)
{
    parent::report($e);
}

public function render($request, Exception $e)
{
    return parent::render($request, $e);
}

错误的处理逻辑找到了，如何触发进入这个逻辑的呢？

错误触发

正常情况下，PHP产生Notice或者Warning是不会抛出Exception的，会产生Exception肯定是框架内部做了更改。
bootstrap/app.php中没找到设置错误处理的地方，接着往下看Lumen框架的容器类Application（Lumen的核心类和入口），目录：vendor/laravel/lumen-framework/src/Application.php。
可以看到在其构造函数中调用了一个registerErrorHandling方法，方法代码：

/**
 * Set the error handling for the application.
 *
 * @return void
 */
protected function registerErrorHandling()
{
    error_reporting(-1);

    set_error_handler(function ($level, $message, $file = '', $line = 0) {
        if (error_reporting() & $level) {
            throw new ErrorException($message, 0, $level, $file, $line);
        }
    });

    set_exception_handler(function ($e) {
        $this->handleUncaughtException($e);
    });

    register_shutdown_function(function () {
        $this->handleShutdown();
    });
}

set_error_handler是PHP设置错误处理的方法。registerErrorHandling下用error_reporting(-1)把PHP的报错开关都打开，这样所有级别的错误都会触发error_handler。在error_handler中抛出了一个ErrorException异常。
至此，我们知道ErrorException这个异常是怎么产生的了，知道异常会交由谁来处理了（上一节中的Handler类）。不过还有个疑问，ErrorException和Handler是怎么关联起来的？

ErrorException和Handler

set_error_handler设置的方法中会抛出异常，那肯定存在针对异常的try catch块。
从请求路口public/index.php往下看，
–>bootstrap/app.php –>Application.php -> run –>Application.php -> dispatch
在dispatch方法中发现了try catch的逻辑，在catch到Exception后调用了Handler的report和render方法。

public function dispatch($request = null)
{
   list($method, $pathInfo) = $this->parseIncomingRequest($request);
   try {
			...
   } catch (Exception $e) {
       return $this->prepareResponse($this->sendExceptionToHandler($e));
   } catch (Throwable $e) {
       return $this->prepareResponse($this->sendExceptionToHandler($e));
   }
}
protected function sendExceptionToHandler($e)
{
   $handler = $this->resolveExceptionHandler();

   if ($e instanceof Error) {
       $e = new FatalThrowableError($e);
   }

   $handler->report($e);

   return $handler->render($this->make('request'), $e);
}

解决

知道了错误从触发到结束的整个流程，再来看怎么解决.

方法1.屏蔽错误

简单粗暴的方法，既然框架用来error_reporting(-1)打开了所有错误开关，那我们再用error_reporting把我们不关心的错误给屏蔽了。把下面代码加在bootstrap/app.php中，注意得加在Applition实例化之后。

error_reporting(E_ALL ^ E_NOTICE ^ E_WARNING);

这种方法的弊端显而易见，我们只是不想让E_NOTICE搞挂请求，但是这类错误还是得关注和修复的。。

方法2.修改Handler

既然是Handler负责错误处理，那我们修改Handler(App\Exceptions\Handler)的逻辑就行。

public function report(Exception $e)
{
    //parent::report($e);
    Log::warning($e->getMessage(), ['file' => $e->getFile(), 'line' => $e->getLine()]);
}

public function render($request, Exception $e)
{
    //return parent::render($request, $e);
    header('Content-type: application/json');
    echo json_encode(['errmsg' => $e->getMessage()]);
    return ;
}

如上代码，将错误处理逻辑进行更改，只打印简单的日志，并且也不跳到错误页了。
不过，这种方法还是有问题：

代码产生的NOTICE和WARNING还是会中断执行流程（因为会抛出异常）。比如一个请求中执行A->B->C三个方法，如果B中产生了一个NOTICE，整个请求还是会被中断，C不会被执行。
如果一个请求原本不是返回json，是返回一个view，则上面的render方法就不适用了。

方法3.在业务逻辑顶层中catch异常

原理类似方法2，只不过把异常的处理从Handler中移到了业务逻辑里（比如Controller中）。
这个方法的问题和方法2一样，NOTICE还是会中断请求…

方法4.修改`error_handler`，不抛出异常

罪魁祸首就在于那个set_error_handler注册的处理方法遇到PHP错误就会抛出异常，那我们修改他就行。
set_error_handler所在的registerErrorHandling方法在框架的源代码中，最好不要直接修改，我们可以在它注册完之后再重新注册一个覆盖它。可以加在bootstrap/app.php中，Application实例化之后。代码如下：

set_error_handler(function ($level, $message, $file = '', $line = 0) {
    if ($level == E_NOTICE || $level == E_WARNING) {
        Log::warning("PHP NOTICE or WARNING; MSG:[$message]", ['file' => $file, 'line' => $line]);
        return;
    }
    if (error_reporting() & $level) {
        throw new ErrorException($message, 0, $level, $file, $line);
    }
});

注意，代码中因为使用了Log这个Facades，因此必须放在$app->withFacades()之后
至此，NOTICE和WARNING不会产生烦人的日志，也不会搞挂请求，并且也保留了有效的提示信息。：）

月份：2018年2月

wordpress挂站–Error establishing a database connection

[转]Lumen和Laravel错误处理机制修改

错误处理流程

错误Handler

错误触发

ErrorException和Handler

解决

方法1.屏蔽错误

方法2.修改Handler

方法3.在业务逻辑顶层中catch异常

方法4.修改`error_handler`，不抛出异常

错误处理流程

错误Handler

错误触发

ErrorException和Handler

解决

方法1.屏蔽错误

方法2.修改Handler

方法3.在业务逻辑顶层中catch异常

方法4.修改error_handler，不抛出异常

方法4.修改`error_handler`，不抛出异常