web-dev-qa-db-ja.com

サーバーがクラッシュした後、MariaDBが起動しません。エラーログなし

CentOS 7サーバーは、実行中にハードドライブを取り外すとクラッシュし、MariaDBが起動せず、エラーログが表示されません。

サーバー上の他のすべてが正常に動作しているようで、ディスク上でxfs_repair(xfsのfsckと同様)を実行しても効果がありませんでした。具体的には、次のようなエラーが発生します。

$ Sudo systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.

$ Sudo systemctl -l status mariadb
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2018-07-29 19:34:03 MDT; 1min 22s ago
  Process: 21579 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE)
  Process: 21577 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS)
  Process: 27150 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=1/FAILURE)
 Main PID: 21577 (code=exited, status=0/SUCCESS)

Jul 29 19:34:03 giivaserver systemd[1]: Starting MariaDB database server...
Jul 29 19:34:03 giivaserver mariadb-prepare-db-dir[27150]: Database MariaDB is not initialized, but the directory /var/lib/mysql is not empty, so initialization cannot be done.
Jul 29 19:34:03 giivaserver mariadb-prepare-db-dir[27150]: Make sure the /var/lib/mysql is empty before running mariadb-prepare-db-dir.
Jul 29 19:34:03 giivaserver systemd[1]: mariadb.service: control process exited, code=exited status=1
Jul 29 19:34:03 giivaserver systemd[1]: Failed to start MariaDB database server.
Jul 29 19:34:03 giivaserver systemd[1]: Unit mariadb.service entered failed state.
Jul 29 19:34:03 giivaserver systemd[1]: mariadb.service failed.

私の知る限り、何が起こっているのか、またはなぜ開始できないのかに関する情報は得られません。エラーログファイルもどこにもありません。

これが私のmy.cnfです。

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

/var/log/mariadb/または/var/run/mariadb/フォルダにファイルがまったくありません。また、公式に説明されているように、/var/log/または/var/log/mysqlHost-name。err(私の場合はgiivaserver.err)がありません。記事 MariaDBが起動しない場合の対処

innodb_force_recovery = 1[mysqld]の下にmy.cnfを1から5に増やしてみましたが、何の影響もありませんでした。

また、/var/lib/mysqlフォルダをバックアップして名前を変更し、mysql_install_dbを再実行してみました。オンラインで削除すると効果があるとのことですが、違いはありませんでした。

私はこれまでに考えられるすべてのことを試みましたが、MariaDBが起動しない理由に関する私のシステムからのフィードバックを見つけることができません。

編集:

オリジナルの名前を変更した後の/ var/lib/mysqlフォルダーの内容:

drwx------.  6 mysql mysql   122 Jul 29 19:03 .
drwxr-xr-x. 61 root  root   4096 Jul 29 19:03 ..
-rw-rw----.  1 mysql mysql 16384 Jul 29 19:02 aria_log.00000001
-rw-rw----.  1 mysql mysql    52 Jul 29 19:02 aria_log_control
drwx------.  2 mysql mysql  4096 Jul 29 19:02 mysql
drwxr-xr-x.  8 mysql mysql   232 Jul 29 18:58 mysqlBAK
drwx------.  2 mysql mysql  4096 Jul 29 19:02 performance_schema
drwx------.  2 mysql mysql     6 Jul 29 19:02 test
2
Isvvc

数日後、データを失うことなく修正することができました。私が疑ったように、停止によるデータ損失はありませんでした。私は問題を解決するために多くのことをしましたが、これは私がそれを修正したと私が信じるものです:

/var/lib/mysqlフォルダの名前を変更して、バックアップがあることを確認してから、/etc/my.cnfファイルを削除しました。 mariadbとmariadb-serverを再インストールして起動しました。そこから、バックアップした/var/lib/mysqlフォルダーをコピーし、/etc/my.cnfに次の行を追加しました( here から取得):

port = 8881
innodb_force_recovery=3
innodb_purge_threads=0

(私は実際に回復モード4を使用したと思いますが、3も私にとってはうまくいったでしょう)

そこから、すべてのデータベースでMariaDBを起動できました。次に、mysqlcheck --all-databases -pを実行して、データベースが破損していないことを確認しました。ここから、MariaDBを正常に停止することができず、それを再び起動するときに問題が発生したため、/var/lib/mysql/フォルダーを削除してデータベースインストールを実行するプロセスを繰り返し、バックアップをコピーして戻しました。に。

そこから、MariaDBをInnoDB強制リカバリで起動し、実行中にコマンドmysqldump -u root -p --all-databases > alldb.sqlを使用してすべてをダンプしました。その後、MariaDBが適切に停止しないため強制停止し、再起動しました。 MariaDBをアンインストールして/var/lib/mysql/を削除し、/etc/my.cnfに名前を変更してから、MariaDBを再インストールしました。新しい状態で実行したら、mysql -u root -p < alldb.sqlを使用してダンプしたデータベースをインポートし、FLUSH PRIVILEGES;を使用してMySQLシェルで特権をフラッシュしました。すべてが正常に機能し、データが失われることはありません。

私はCentOSを実行しているため、途中でSELinuxに関する作業を行う必要がありました。ほとんどの場合、ポップアップ診断ダイアログの指示に従って、最初にNextcloudサーバーをインストールするときに最初に実行したSELinuxコマンドを再実行して、すべての権限を正しく取得しました。

1
Isvvc

データベースストレージが破損したようです。バックアップから復元し、ハードドライブに大きな兆候を示します。「実行中はプラグを抜かないでください」。

1
womble