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/mysql
にHost-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
数日後、データを失うことなく修正することができました。私が疑ったように、停止によるデータ損失はありませんでした。私は問題を解決するために多くのことをしましたが、これは私がそれを修正したと私が信じるものです:
/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コマンドを再実行して、すべての権限を正しく取得しました。
データベースストレージが破損したようです。バックアップから復元し、ハードドライブに大きな兆候を示します。「実行中はプラグを抜かないでください」。