MySQL tc.logが初期化出来ず起動出来ない [ERROR] Can’t init tc log

ConoHa VPS の KUSANGI 上で動くWordPressサイトに「データベース接続確立エラー」が表示されサイトが表示出来ないと報告を受けました。ディスク残量不足が原因かと思い調査してみましたが別の原因でしたので、その調査内容と解決方法までを書きます。

調査内容
対処法
1. tc.log 削除
2. MySQL起動
最後に

調査内容

ディスクの空き状況確認

dfコマンドで状況確認しましたが、空き領域は多くはありませんが問題なさそうでした。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/vda2         50G   36G   12G   76% /
devtmpfs         1.9G     0  1.9G    0% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm
tmpfs            1.9G  8.6M  1.9G    1% /run
tmpfs            1.9G     0  1.9G    0% /sys/fs/cgroup
tmpfs            379M     0  379M    0% /run/user/0

接続確認

SSHで接続しMySQLにログイン出来るか確認してみたところMySQLが起動出来ていないようでした。

$ mysql -uroot -p

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such file or directory")

ステータス確認 [1]

$ service mysqld status

Redirecting to /bin/systemctl status mysqld.service
 ● mariadb.service - MariaDB 10.1.37 database server
    Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
   Drop-In: /etc/systemd/system/mariadb.service.d
            mqmigrated-from-my.cnf-settings.conf
    Active: failed (Result: exit-code) since 月 2020-01-13 23:49:19 JST; 10h ago
      Docs: man:mysqld(8)
            https://mariadb.com/kb/en/library/systemd/
   Process: 3260 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
   Process: 3096 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=/usr/bin/galera_recovery; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
   Process: 3087 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Main PID: 3260 (code=exited, status=1/FAILURE)
    Status: "MariaDB server is down"
 1月 13 23:49:15 kusanagi systemd[1]: Starting MariaDB 10.1.37 database server…
  1月 13 23:49:15 kusanagi mysqld[3260]: 2020-01-13 23:49:15 139944166979840 [Note] /usr/sbin/mysqld (mysqld 10.1.37-MariaDB) starting as process 3260 …
  1月 13 23:49:19 kusanagi systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
  1月 13 23:49:19 kusanagi systemd[1]: Failed to start MariaDB 10.1.37 database server.
  1月 13 23:49:19 kusanagi systemd[1]: Unit mariadb.service entered failed state.
  1月 13 23:49:19 kusanagi systemd[1]: mariadb.service failed.

ステータス確認 [2]

 $ service mysql status

ERROR! MariaDB is not running

MySQL停止と起動

停止

$ service mysql stop

Stopping mysql (via systemctl):                            [  OK  ]

起動

$ service mysql start

Starting mysql (via systemctl):  Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.    [失敗]

ログ確認

ログ [ /var/log/mysql/mysqld.log ] の中身を確認したところ [ERROR] Can’t init tc log とエラーが出ており “tc.log” の初期化が出来ていないようでした。

2020-01-14 11:15:22 140688196859648 [Note] InnoDB: Dumping buffer pool(s) not yet started
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: The InnoDB memory heap is disabled
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Compressed tables use zlib 1.2.7
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Using Linux native AIO
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Using SSE crc32 instructions
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Completed initialization of buffer pool
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Highest supported file format is Barracuda.
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: 128 rollback segment(s) are active.
2020-01-14 11:17:17 139926071032064 [Note] InnoDB: Waiting for purge to start
2020-01-14 11:17:17 139926071032064 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.41-84.1 started; log sequence number 34445672880
2020-01-14 11:17:17 139926071032064 [Note] Plugin 'FEEDBACK' is disabled.
2020-01-14 11:17:17 139926071032064 [Note] Recovering after a crash using tc.log
2020-01-14 11:17:17 139926071032064 [ERROR] Can't init tc log
2020-01-14 11:17:17 139926071032064 [ERROR] Aborting

tc.log 確認

[ /var/lib/mysql/ ] 内にゼロバイトの “tc.log” が存在するこを確認しました。

対処法

tc.log 削除

先ほど確認したゼロバイトの “tc.log” ファイルを削除しました。

$ rm -f  /var/lib/mysql/tc.log

MySQL起動

“tc.log” ファイル削除後、MySQLを起動させてみましたが、今度は問題なく起動することが出来ました。

$ service mysql start

Starting mysql (via systemctl):                            [  OK  ]

最後に

今回何故 “tc.log”ファイルが初期化出来なくなったのか原因がハッキリしていませんが、ネット上調べているとディスクの使用率が 100% になると破損した事例がありました。

お客様に確認したところ 100%に達したためいくつかファイルを削除して空き容量を確保されたようでしたので、ディスク使用率が100%に達したことで起きた可能性が考えられます。

確定情報ではないため今後ハッキリしましたら追記したいと思います。