由于MariaDB服务器出了问题，我讲述了解决方法的故事

8 月 ago
韵, 科
3 minutes

环境

    • MacBook Pro, macOS: Ventura 13.3.1 (a)

 

    • zsh のバージョン: 5.9

 

    • Bundler のバージョン: 2.4.13

 

    データベース: MariaDB (ver 10.6.13)

发生的问题的内容

    MariaDB のサーバーを stop することができない. しかも, status で PID ファイルの存在が言及されているのに, stop では PID ファイルが見つからないと言われている.
% mysql.server start
Starting MySQL
 SUCCESS!
% mysql.server stop
 ERROR! MySQL server PID file could not be found!
% mysql.server status
 ERROR! MariaDB is not running, but PID file exists
    その状態で一度再起動をしてしまうと, 今度は立ち上がりすらしなくなってしまう.
% mysql.server start 
Starting MariaDB
.230522 18:25:18 mysqld_safe Logging to '/usr/local/var/mysql/(comp name).local.err'.
230522 18:25:18 mysqld_safe Starting mariadbd daemon with databases from /usr/local/var/mysql
/usr/local/opt/mariadb@10.6/bin/mysql.server: line 264: kill: (1005) - No such process
 ERROR!

为了解决问题所采取的行动。

选项 1：卸载，重新安装

首先，我用 rm 命令删除了与 MariaDB 相关的文件 /usr/local/var/mysql 和以 /usr/local/etc/my.cnf 开头的文件，并通过 brew 安装程序卸载了 MariaDB。

% rm -rf /usr/local/var/mysql
% rm -rf /usr/local/etc/my.cnf*
% brew uninstall mariadb@10.6
Uninstalling /usr/local/Cellar/mariadb@10.6/10.6.13... (917 files, 186.3MB)

然后，我通过brew再次安装了版本为10.6的MariaDB。

% brew install mariadb@10.6
==> Downloading https://formulae.brew.sh/api/formula.jws.json
########################################################################################### 100.0%
==> Fetching mariadb@10.6
(略)
==> Summary
?  /usr/local/Cellar/mariadb@10.6/10.6.13: 917 files, 186.3MB
==> Running `brew cleanup mariadb@10.6`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

在重新安装之后，我尝试启动 MySQL 服务器。

% mysql.server start
Starting MariaDB
230522 16:40:45 mysqld_safe Logging to '/usr/local/var/mysql/(comp name).local.err'.
230522 16:40:46 mysqld_safe A mysqld process already exists
 SUCCESS! 
% mysql.server status  
 ERROR! MariaDB is not running

然后，在开始时虽然能够启动，但在检查状态时却返回了未启动的提示。

选项一：拒绝自动启动

对于“存在PID文件但找不到”的问题，可以通过使用ps命令查找正在运行的MariaDB相关程序来解决。结果如下所示：

 % ps aux | grep mysql                                     
(name) 9163   0.0  0.4 34647908  69868   ??  S     4:38PM   0:00.67 /usr/local/opt/mariadb@10.6/bin/mariadbd --basedir=/usr/local/opt/mariadb@10.6 --datadir=/usr/local/var/mysql --plugin-dir=/usr/local/opt/mariadb@10.6/lib/plugin --log-error=/usr/local/var/mysql/(comp name).local.err --pid-file=(comp name).local.pid
(name) 9092   0.0  0.0 34134040   1224   ??  S     4:37PM   0:00.02 /bin/sh /usr/local/opt/mariadb@10.6/bin/mysqld_safe --datadir=/usr/local/var/mysql
(name) 9783   0.0  0.0 34121332    628 s001  R+    5:26PM   0:00.00 grep mysql

因此，实际上服务器已经启动了，但是发现MySQL那边无法检测到它。

而且，当停止了正在运行的进程时，服务器立即重新启动了。

% kill -9 9163

% ps aux | grep mysql 
(name) 9903   0.0  0.0 34121332    628 s001  R+    5:30PM   0:00.00 grep mysql
(name) 9894   0.0  0.4 34646932  67156   ??  S     5:29PM   0:00.09 /usr/local/opt/mariadb@10.6/bin/mariadbd --basedir=/usr/local/opt/mariadb@10.6 --datadir=/usr/local/var/mysql --plugin-dir=/usr/local/opt/mariadb@10.6/lib/plugin --log-error=/usr/local/var/mysql/(comp name).local.err --pid-file=(comp name).local.pid
(name) 9824   0.0  0.0 34124824   1348   ??  S     5:29PM   0:00.02 /bin/sh /usr/local/opt/mariadb@10.6/bin/mysqld_safe --datadir=/usr/local/var/mysql

导致服务器重新启动的原因是因为它自动启动了作为包管理器使用的brew。

% brew services list
Name         Status  User             File
mariadb@10.6 started (name) ~/Library/LaunchAgents/homebrew.mxcl.mariadb@10.6.plist

我已经禁止了从brew自动启动的功能。

% brew services stop mariadb@10.6
Stopping `mariadb@10.6`... (might take a while)
==> Successfully stopped `mariadb@10.6` (label: homebrew.mxcl.mariadb@10.6)
% brew services list             
Name         Status User File
mariadb@10.6 none

有了这个改变, MariaDB 将不再自动启动.

% mysql.server status
 ERROR! MariaDB is not running
% ps aux | grep mysql
(name)   903   0.0  0.0 34130548    684 s001  S+    6:23PM   0:00.00 grep mysql

重新查看关于该日志周围的部分。

查看错误日志后，发现有如下记录。

[Note] InnoDB: Starting crash recovery from checkpoint LSN=42628,42628
[ERROR] InnoDB: Missing FILE_CHECKPOINT at 42628 between the checkpoint 42628 and the end 42640.

从中文的角度来解释一下MariaDB的崩溃恢复。当服务器无法启动时，我研究了一下MariaDB的崩溃恢复机制，发现在/usr/local/etc/my.cnf文件中可能存在某种原因。

[mysqld]
innodb_force_recovery = 0 # 0 の部分には 0 以上 6 以下の整数が入る.

通过添加这个选项，我们发现MariaDB可以在恢复模式下启动，并且可以启动到与其级别相对应的恢复模式。

此外，需要注意的是，随着恢复模式的等级提高，虽然变得更为强大，但数据库可能会出现损坏的情况（具体而言，从第5级开始），因此，建议您从第11级开始逐级提升进行操作。

我使用这个选项尝试在恢复模式下运行，结果服务器只在级别 6 启动，直到级别 5 为止没有启动。

因此，我决定从恢复模式的官方参考资料中了解在每个级别上所做的事情，并进行原因调查。

大致来看，公式参考资料中每个级别的内容如下所示（高级别的内容包含低级别的内容）。

レベル内容0(通常の起動)1ページに破壊があったとしても, サーバーの実行を継続する.2マスタースレッドの実行を停止する.3クラッシュリカバリ後に DML トランザクションのロールバックを行わないようにする.4クラッシュリカバリ後にトランザクションのロールバックを行わないようにする.5不完全なトランザクションをコミットされたものと見なし, 起動時, undo ログを見ないようにする.6redo ログを見ないようにする.

但是，在成功启动后，当我将 innodb_force_recovery 设置回级别0并检查状态时，MariaDB并没有运行，但被告知PID文件仍然存在。为了尝试，我删除了PID文件并再次检查状态，这次发现MariaDB正在运行，但却被告知PID文件不存在的情况。

相关联的是，在重新安装时我没有将my.cnf恢复到正确的设置，这就是为什么。

[mysqld]
user = (name) # 追加

通过添加，现在可以返回正确的PID PS号码了。

考虑到无法在级别5下启动服务器，以及在级别6下启动服务器的情况，并且怀疑原因可能出现在重做日志中。

根据redo日志的官方参考资料，发现记录了ib_logfile0的存在。因此，尝试删除ib_logfile0并执行了一次实验。

% mysql.server start 
Starting MariaDB
.230526 14:26:56 mysqld_safe Logging to '/usr/local/var/mysql/(comp name).local.err'.
230526 14:26:56 mysqld_safe Starting mariadbd daemon with databases from /usr/local/var/mysql
 SUCCESS! 
% mysql.server status
 SUCCESS! MariaDB running (19754)
% mysql.server stop  
Shutting down MariaDB
. SUCCESS!

我已成功启动、停止和检查服务器的状态。

最后

这是我的第一篇文章，非常感谢您的阅读。

我希望未来除了故障排除，还能写很多其他的文章。

如果是以Level 0进行正常启动的话，那么就不需要这篇文章了。↩关于这一点的反应是正确的。↩