web-dev-qa-db-ja.com

MySQLが起動しない-ibdata1が破損していますか？ -オペレーティングシステムエラー番号13-権限の問題

電源障害によるサーバーのシャットダウン。
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.
mysqlfilepermissionsinnodb
30
eat_a_lemon

ファイルは破損していません。これらのエラーの原因は、「perror」で確認できます。つまり.

toaster:~ morgo$ perror 13
OS error code  13:  Permission denied

InnoDBには破損検出（ページチェックサム）があり、それが問題かどうかを喜んで知らせてくれます。

ディレクトリのアクセス許可が変更されたか、my.cnfファイルがホースされ、データファイルを別の場所に再作成しようとしています。

16
Morgan Tocker

Ubuntuまたはapparmorを使用している場合、apparmorでこの変更を許可する必要があります。

編集/etc/apparmor.d/usr.sbin.mysqldおよび変更/var/lib/mysqlと新しいDATADIR。

動作するはずです。

94
Dan

エラー：

 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〜]＃
18
Carlos Omar Briseño Gutierrez

私にとっては、セキュリティコンテキスト（selinux）を復元するとうまくいきました

restorecon -R /var/lib/mysql/

13
dordal

これを確認してください：

chown -R mysql:mysql /var/lib/mysql
10
IndikatorDesign

要するに、（特にRHEL/CentOS/Fedoraで）試してください

getenforce

Enforcingで応答する場合、SELinuxが稼働しています。 setenforce 0で一時的に無効にし、MariaDBがすぐに起動するかどうかを確認してください！特にRHEL/CentOS/Fedoraではかなり一般的です。

この公式の記事 のようにも、このさらに下の詳細があります。

一般に

ただ、ユーザーのアクセス権よりも、ファイルへのアクセスを妨げる可能性があるUNIX環境ではより多くのものがあります。

  • SELinuxの（上記参照）またはAppArmorのようなセキュリティ・モジュール（ダンが述べたように）、それを許可しない可能性があり
  • アクセス制御リスト（ACL）は、特に必要なファイル/ディレクトリの、設定することができ
  • 親フォルダのいずれかが別のユーザーが所有する、とのNO x（=「ディレクトリアクセス」）を持っていない他の人のためにセットすることができ

さらに、次のような他の予期しない要因がある可能性があります...

  • Mysql datadirは、mysqlに権限がない場所に設定されています（/etc/my.cnfを参照）
  • MySQLは（妙に）別のユーザーとして実行することができ、またはファイルが単に他の誰かが所有することができ

ちょうど私の頭の上から見る事は言うまでもあり（ところで、この答えに追加/編集するにはお気軽に）。

この場合、SELinuxは「問題」です

恒久的な解決策として、適切なセキュリティコンテキストの復元を試みることができます。

restorecon -R /var/lib/mysql/

...あるいは単にSELinuxを無効にする（しかし、そうする前に、この1少し考える）（/etc/selinux/configに一般的に）設定を編集し、記事を以下に示唆されているようにSELINUX=disabledを設定することにより、。

明らかに、これらは同じ方法でMySQLに適用できます。

5
Levit

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
5
A Nun Famous

私はステップ以下で同じ問題と修正を持っていました

作業ディレクトリは/ var/libに/ mysqlの

以前の/ var/lib/mysqlは不明なユーザーによって所有されていました

mysqlのにそれを変更

mysql]# chown -R mysql:mysql *

mysql]# service mariadb start

Redirecting to /bin/systemctl start mariadb.service

魔法のように動作します

4
Rohit Gupta

これは私のためにポップアップするとき、私は/etc/mysql/my.cnf設定ファイルに答えを見つけました。 datadirラインは/var/lib/mysqlディレクトリ（データベースがある）を指していませんでした。私はこのパスを入れたら、サーバーは問題を再起動しません。

2
John Creamer

あなたは、SELのLinuxを使用している場合

Intall semanage

yum whatprovides /usr/sbin/semanageを取得policycoreutils-python-2.5-22.el7.x86_64

Mysqldのセキュリティコンテキストを参照してください。

インストール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の短いリストは、すべてのコンテキストを見ます

  1. mysqld_etc_t - 設定ファイル
  2. mysqld_db_t - データDBファイル
  3. mysqld_log_t - ログファイル
  4. mysqld_exec_t - 実行ファイル

したがって、ファイルのセキュリティコンテキストが間違っていると、アクセス許可が拒否されます（エラー13）

解決

chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

しかし、あまりにも、「通常」の権限を確認してください。私はこの問題centosを持っていました。変更するにはsystemctl restart mysqlする必要があります。

1
Kordi

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つのファイルのみを変更する必要がある場合は、そのファイルを省略できます。

1
A Nun Famous

Synologyでこの問題がある場合NAS Synologyサポートチームのアドバイスに従うことで修正できます。

ユーザーの皆様、

これは既知の問題として確認されており、今後のMariaDBリリースでこの問題の修正を試みます。ご迷惑をお掛けします。

回避策は次のとおりです。

  • 「=」アカウントとパスワード（管理者と同じ）でDSにtelnetしてみてください
  • コマンド「echo 1>/var/services/mysql/VERSION」を実行します
  • dSMからMariaDBパッケージを開くと、更新が再度トリガーされます
  • dBパスワードを入力し、[更新]をクリックしてこの問題を修正します

詳細： Synologyフォーラム

0
DarkLite1

私の推測では、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。

0
zjhui