電源障害によるサーバーのシャットダウン。
Mysqlは現在起動しません。
ディスクがいっぱいではありません。 Syslogは以下です
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
ファイルは破損していません。これらのエラーの原因は、「perror」で確認できます。つまり.
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDBには破損検出(ページチェックサム)があり、それが問題かどうかを喜んで知らせてくれます。
ディレクトリのアクセス許可が変更されたか、my.cnfファイルがホースされ、データファイルを別の場所に再作成しようとしています。
Ubuntuまたはapparmorを使用している場合、apparmorでこの変更を許可する必要があります。
編集/etc/apparmor.d/usr.sbin.mysqld
および変更/var/lib/mysql
と新しいDATADIR
。
動作するはずです。
エラー:
101130 14:42:51 pidファイル/var/run/mysqld/mysqld.pidからmysqld_safe mysqldが終了しました 101130 18:07:58 mysqld_safe/var/lib /からのデータベースでmysqldデーモンを開始mysql 101130 18:07:58 InnoDB:ファイル操作のオペレーティングシステムエラー番号13。 InnoDB:エラーは、mysqldが InnoDBへのアクセス権を持っていないことを意味します。 directory。 InnoDB:ファイル名./ibdata1 InnoDB:ファイル操作呼び出し: 'open'。 InnoDB:操作を続行できません。
ソリューションSeLinux SeLinuxセキュリティ:
[root @ localhost〜]#service mysqld restart Deteniendo mysqld:[OK] Iniciando mysqld:[FALLÓ] [root @ localhost〜]#restorecon -R /var/lib/mysql/ [root@localhost〜]#service mysqld restart Deteniendo mysqld:[OK] Iniciando mysqld:[OK] [root @ localhost〜]#
私にとっては、セキュリティコンテキスト(selinux)を復元するとうまくいきました
restorecon -R /var/lib/mysql/
これを確認してください:
chown -R mysql:mysql /var/lib/mysql
getenforce
Enforcing
で応答する場合、SELinuxが稼働しています。 setenforce 0
で一時的に無効にし、MariaDBがすぐに起動するかどうかを確認してください!特にRHEL/CentOS/Fedoraではかなり一般的です。
この公式の記事 のようにも、このさらに下の詳細があります。
ただ、ユーザーのアクセス権よりも、ファイルへのアクセスを妨げる可能性があるUNIX環境ではより多くのものがあります。
さらに、次のような他の予期しない要因がある可能性があります...
datadir
は、mysqlに権限がない場所に設定されています(/etc/my.cnf
を参照)ちょうど私の頭の上から見る事は言うまでもあり(ところで、この答えに追加/編集するにはお気軽に)。
恒久的な解決策として、適切なセキュリティコンテキストの復元を試みることができます。
restorecon -R /var/lib/mysql/
...あるいは単にSELinuxを無効にする(しかし、そうする前に、この1少し考える)(/etc/selinux/config
に一般的に)設定を編集し、記事を以下に示唆されているようにSELINUX=disabled
を設定することにより、。
明らかに、これらは同じ方法でMySQLに適用できます。
CentOSボックスでもまったく同じ問題がありました。周りのMySQLデータディレクトリを移動した後、私は同じ所有者とアクセス権を持つファイルをコピーしていたたとしても、もはやサービスを開始できませんでした。
SELinuxセキュリティコンテキストに問題がありました。あなたはCentOSの株式を実行した場合、それを有効にするための良い機会を持って、あなたは、MySQLでやりたいことはできません。これを修正するには:
最初に古いディレクトリと新しいディレクトリを比較します
ls -Z /var/lib/mysql
そして
ls -Z /new/mysql/dir
違いが見られる場合は、問題である可能性があります。これを変更するには:
chcon -R --type=mysql_db_t /new/mysql/dir
-Rスイッチは再帰用です。 1つのファイルのみを変更する必要がある場合は、そのファイルを省略できます。コンテキストが私のコンテキストと異なる場合(異なるディストリビューションである可能性があります)、最初の出力(SELinuxスタッフの3番目のフィールドである必要があります)で示されているものを使用します
ls -Z /var/lib/mysql
私はステップ以下で同じ問題と修正を持っていました
作業ディレクトリは/ var/libに/ mysqlの
以前の/ var/lib/mysqlは不明なユーザーによって所有されていました
mysqlのにそれを変更
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
魔法のように動作します
これは私のためにポップアップするとき、私は/etc/mysql/my.cnf
設定ファイルに答えを見つけました。 datadir
ラインは/var/lib/mysql
ディレクトリ(データベースがある)を指していませんでした。私はこのパスを入れたら、サーバーは問題を再起動しません。
yum whatprovides /usr/sbin/semanage
を取得policycoreutils-python-2.5-22.el7.x86_64
インストールyum install policycoreutils-python
の後、mysqldのさまざまなセキュリティコンテキストを確認できます。
semanage fcontext -l | grep mysqld
/etc/mysql(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.* regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)? all file system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)? regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.* regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.* regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.* regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf regular file unconfined_u:object_r:mysqld_home_t:s0
ここでは説明してmysqldの短いリストは、すべてのコンテキストを見ます
したがって、ファイルのセキュリティコンテキストが間違っていると、アクセス許可が拒否されます(エラー13)
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
しかし、あまりにも、「通常」の権限を確認してください。私はこの問題centos
を持っていました。変更するにはsystemctl restart mysql
する必要があります。
CentOSボックスでもまったく同じ問題がありました。 mysqlデータディレクトリを移動した後、同じ所有者とアクセス許可でファイルをコピーしたとしても、サービスを開始できなくなりました。
SELinuxセキュリティコンテキストに問題がありました。 CentOSストックを実行すると、有効化される可能性が高くなり、MySQLで必要な処理を実行できなくなります。これを修正するには:
最初に古いディレクトリと新しいディレクトリを比較します
ls -Z /var/lib/mysql
そして
ls -Z /new/mysql/dir
違いが見られる場合は、問題である可能性があります。これを変更するには:
chcon -R --type=mysql_db_t /new/mysql/dir
-Rスイッチは再帰用です。 1つのファイルのみを変更する必要がある場合は、そのファイルを省略できます。
Synologyでこの問題がある場合NAS Synologyサポートチームのアドバイスに従うことで修正できます。
ユーザーの皆様、
これは既知の問題として確認されており、今後のMariaDBリリースでこの問題の修正を試みます。ご迷惑をお掛けします。
回避策は次のとおりです。
- 「=」アカウントとパスワード(管理者と同じ)でDSにtelnetしてみてください
- コマンド「echo 1>/var/services/mysql/VERSION」を実行します
- dSMからMariaDBパッケージを開くと、更新が再度トリガーされます
- dBパスワードを入力し、[更新]をクリックしてこの問題を修正します
詳細: Synologyフォーラム
私の推測では、Selinuxの問題です。そしてそのchcon -R --type=mysql_db_t /new/mysql/dir
エラーが発生します:chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument
。
だから私はコマンドを使用します:chcon -R root:object_r:mysqld_db_t /new/mysql/dir
。