mysqlデータベースのTMDテーブルを使用して「is marked as crashed and last(automatic?)repair failedのエラーDatabase query error
7006 ワード
========================================================
1、ページにエラーが発生した:Database query errorデータベース表をクリックして現れた:Table'%s'is marked as crashed and last(automatic)repair failed
ssh Secure shellでサーバーにログインします:それからコマンドを実行します:mysqlcheck-r--all-databases-p後mysqlパスワードを入力します
=============================================================
mysqlcheck
mysqlcheck-a-c-o-r-all-databases-uroot-p//このコマンドは、すべてのdbデータベースを最適化します.
パラメータの意味は次のとおりです.-a=Analyse given tables.-c = Check table for errors -o = Optimise table -r = Can fix almost anything except unique keys that aren’t unique
winホストの下で指定したテーブルを修復する場合は、mysqlcheck-o-rデータベース名-u root-pを使用します.パスワードの入力を求めるボックスにmysqlのroot管理パスワードを入力すると、mysqlcheckがデータベースの検出修復を行います.
=================================================================
MYSQLデータテーブルに問題が発生しました.ヒント:Error:Table'./db_name/table_name' is marked as crashed and last (automatic?) repair failed
データテーブルの修復操作:
1、service mysqld stop;
2、cd/var/lib/mysql/db_name/
3、myisamchk -r tablename.MYI(修復データシート)
myisamchk -r *.MYI(すべてのデータテーブルを修復)
===========================================================
一、表破損の原因分析
次の理由はmysqlテーブルの破損の一般的な原因です.
1、サーバーの突然の停電でデータファイルが破損した.
2、強制的にシャットダウンし、mysqlサービスを先にシャットダウンしなかった.
3、mysqldプロセスは表を書く時に殺される.
4、myisamchkを使用すると同時に、mysqldもテーブルを操作しています.
5、ディスク障害.
6、サーバーがハングアップした.
7、mysql自体のバグ.
詳細出典参考:http://www.jb51.net/article/25873.htm
二.表の破損の症状破損した表の典型的な症状は以下の通りです.
1.テーブルからデータを選択すると、次のエラーが発生します.Try to repair it
2.クエリは、テーブルにローを見つけたり、不完全なデータを返したりすることはできません.
3 、Error: Table 'p' is marked as crashed and should be repaired .
4、テーブルを開けませんでした:Can't open file:'×××.MYI' (errno: 145) .
5 、
三.MySQLテーブルの破損を予防するには、mysqlテーブルの破損を予防するには、次の方法を使用します.
1、myisamchkを定期的に使用してMyISAMテーブルをチェックし(mysqldを閉じることに注意)、check tableを使用してテーブルをチェックすることをお勧めします(mysqldを閉じる必要はありません).
2、大量の更新や削除操作を行った後、OPTIMIZE TABLEを使用してテーブルを最適化することをお勧めします.これにより、ファイルの破片が減少し、テーブルが破損する確率が減少します.3、サーバーをシャットダウンする前に、mysqldをシャットダウンします(正常にサービスをシャットダウンし、kill-9を使用してプロセスを殺さないでください).
4、ups電源を使用して、突然電源が切れることを避ける.
5、最新の安定版mysqlを使用して、mysql自体のバグを減らしてテーブルの破損を招く.
6、InnoDBエンジンの場合、innodb_を使用できます.tablespace_monitorを使用して、表領域ファイル内のファイル領域管理の完全性を確認します.
7、ディスクに対してraidを行い、ディスクエラーを減らし、性能を向上させる.
8、データベース・サーバはmysqldと必要な他のサービスだけを走ったほうがいい.他の業務サービスを走ってはいけない.これにより、デッドラインによるテーブルの破損の可能性を減らす.
9、万一を恐れず、事故を恐れず、普段からバックアップをとることが時計の破損を予防する有効な手段である.
詳細出典参考:http://www.jb51.net/article/25873.htm
四.MySQLテーブルの破損した修復MyISAMテーブルは、1、reapair tableまたはmyisamchkを使用して修復することができます.2、上記の方法の修復が無効な場合は、バックアップ・リカバリ・テーブルを使用します.具体的には、フェーズ1:テーブルをチェックする時間がたくさんある場合はmyisamchk*を実行します.MYIまたはmyisamchk-e*.MYI .-s(沈黙)オプションを使用して、不要な情報を禁止します.mysqldサーバがダウンタイムしている場合は、--update-stateオプションを使用してmyisamchkにテーブルを「チェック済み」とマークするように伝えます.myisamchkがエラーを報告したテーブルだけを修復する必要があります.このようなテーブルに対しては、フェーズ2に進みます.チェック中に、out of memoryエラーなどの奇妙なエラーが発生した場合、またはmyisamchkがクラッシュした場合、フェーズ3に進みます.フェーズ2:単純で安全な修復コメント:より迅速に修復したい場合はmyisamchkを実行するときにsort_buffer_sizeとKey_buffer_size変数の値は、使用可能なメモリの約25%に設定されます.まず、myisamchk-r-q tbl_を試してみましょう.name(-r-qは「高速リカバリモード」を意味する).これにより、インデックスファイルを修復するためにデータファイルに接触しないようにします.データ・ファイルに必要なすべての内容と、データ・ファイル内の正しい場所への削除接続が含まれている場合は、テーブルを管理し、修復できます.次のテーブルの修復を開始します.そうでない場合は、続行する前にデータファイルをバックアップする手順を実行します.myisamchk-r tbl_の使用name(-rは「リカバリモード」を意味する).これにより、データファイルから不正なレコードと削除されたレコードが削除され、インデックスファイルが再構築されます.前の手順が失敗した場合はmyisamchk--safe-recover tbl_を使用します.name .セキュア・リカバリ・モードは、従来のリカバリ・モードではできない少数の状況(ただし、より遅い)を処理する古いリカバリ・メソッドを使用します.修復時に、out of memoryエラーなどの奇妙なエラーが発生した場合、またはmyisamchkがクラッシュした場合、フェーズ3に進みます.フェーズ3:難しい修復は、インデックスファイルの最初の16 Kブロックが破壊されたり、不正な情報が含まれたり、インデックスファイルが失われたりした場合にのみ、このフェーズに進む必要があります.この場合、新しいインデックスファイルを作成する必要があります.データファイルを安全な場所に移動するには、次の手順に従います.テーブル記述ファイルを使用して、新しい(空)データファイルとインデックスファイルを作成します.
コードは次のとおりです.
MySQLバージョンにTRUNCATE TABLEがない場合は、DELETE FROM tbl_を使用します.name . 古いデータファイルを新しく作成したデータファイルにコピーします.(古いファイルを新しいファイルに戻すだけでなく、何かが間違っていないようにコピーを残してください.)ステージ2に戻ります.今はmyisamchk-r-qが働いているはずです.(これは無限のサイクルではない).REPAIR TABLE tblも使えますname USE_FRMは、プログラム全体を自動的に実行します.フェーズ4:非常に困難な修復のみ.frm記述ファイルも破壊されたので、あなたはこの段階に着くべきです.テーブルが作成されると、記述ファイルは変更されないため、これは一度も起こったことがないはずです.1つのバックアップから記述ファイルをリカバリし、フェーズ3に戻ります.インデックスファイルを復元してフェーズ2に戻ることもできます.後者にはmyisamchk-rで起動する必要があります.バックアップを行っていないが、テーブルがどのように作成されているかを正確に知っている場合は、別のデータベースでテーブルのコピーを作成します.新しいデータファイルを削除し、他のデータベースから記述ファイルとインデックスファイルを破壊されたデータベースに移動します.これにより、新しい説明とインデックスファイルが提供されるが、MYDデータファイルは独自に残されています.ステージ2に戻り、インデックスファイルの再構築を試みます.InnoDBテーブルは、データベースページが破壊された場合、SELECT INTO OUTFILEでデータベースからテーブルをダンプしたい場合があります.通常、この方法で取得されるデータの多くは完璧です.それでも破損はSELECT*FROM tbl_を引き起こす可能性がありますnameまたはInnoDBバックグラウンド操作がクラッシュまたは断言したり、InnoDBフロントロールがクラッシュを回復したりします.それでも、InnoDBストレージエンジンの起動を強制し、バックグラウンド操作の実行を阻止し、テーブルをダンプできるようにすることができます.たとえば、サーバを再起動する前に、オプションファイルの[mysqld]セクションに[mysqld]innodb_の行を追加できます.force_recovery = 4innodb_force_recoveryで許可されているゼロ以外の値は次のとおりです.より大きな数字には、より小さな数字をすべて含む予防措置が含まれています.多くの4のオプション値でテーブルをダンプできる場合は、破損した個別のページのデータだけが失われます.6の値は、データベース・ページが古い状態に残されているため、Bツリーや他のデータベース構造の破壊を引き起こす可能性があります.1(SRV_FORCE_IGNORE_CORRUPT)サーバが破損したページを検出しても、サーバを動作させる.SELECT*FROM tbl_nameは破損したインデックスレコードとページをスキップし、テーブルのダンプに役立ちます.2(SRV_FORCE_NO_BACKGROUND)はメインスレッドの動作をブロックし、クラッシュが浄化操作中に発生する可能性がある場合はブロックします.3(SRV_FORCE_NO_TRX_UNDO)リカバリ後、トランザクションロールバックは実行されません.4(SRV_FORCE_NO_IBUF_MERGE)もバッファマージの挿入を阻止します.もしあなたが崩壊を招く可能性があるなら.これらの操作は行わないほうがいいです.テーブル統計表を計算しないほうがいいです.5(SRV_FORCE_NO_UNDO_LOG_SCAN)データベースの起動時に未完了ログは表示されません:InnoDBは未完了トランザクションをコミット済みと見なします.6(SRV_FORCE_NO_LOG_REDO)リカバリ接続でログをロールバックしないでください.データベースは、これらのオプションで許可されているオプションを別途持って使用することはできません.セキュリティ対策としてinnodb_force_recoveryが0より大きい値に設定場合、InnoDBは、INSERT、UPDATE、DELETEの実行をユーザに阻止する.強制リカバリが使用されても、DROPテーブルやCREATEテーブルが使用できます.指定したテーブルがロールバッククラッシュを引き起こしていることを知っている場合は、削除できます.これを使用して、失敗した大口インポートや失敗したALTER TABLEによる暴走ロールバックを停止することもできます.mysqldプロセスを殺してinnodbを設定できますforce_recoveryは3であり、データベースがロールバックを必要とせずに一時停止され、暴走ロールバックの原因となるテーブルが破棄されます.詳細出典参考:http://www.jb51.net/article/25873.htm
1、ページにエラーが発生した:Database query errorデータベース表をクリックして現れた:Table'%s'is marked as crashed and last(automatic)repair failed
ssh Secure shellでサーバーにログインします:それからコマンドを実行します:mysqlcheck-r--all-databases-p後mysqlパスワードを入力します
=============================================================
mysqlcheck
mysqlcheck-a-c-o-r-all-databases-uroot-p//このコマンドは、すべてのdbデータベースを最適化します.
パラメータの意味は次のとおりです.-a=Analyse given tables.-c = Check table for errors -o = Optimise table -r = Can fix almost anything except unique keys that aren’t unique
winホストの下で指定したテーブルを修復する場合は、mysqlcheck-o-rデータベース名-u root-pを使用します.パスワードの入力を求めるボックスにmysqlのroot管理パスワードを入力すると、mysqlcheckがデータベースの検出修復を行います.
=================================================================
Errorの解決:Table'./db_name/table_name' is marked as crashed and last (automatic?) repair
MYSQLデータテーブルに問題が発生しました.ヒント:Error:Table'./db_name/table_name' is marked as crashed and last (automatic?) repair failed
データテーブルの修復操作:
1、service mysqld stop;
2、cd/var/lib/mysql/db_name/
3、myisamchk -r tablename.MYI(修復データシート)
myisamchk -r *.MYI(すべてのデータテーブルを修復)
===========================================================
一、表破損の原因分析
次の理由はmysqlテーブルの破損の一般的な原因です.
1、サーバーの突然の停電でデータファイルが破損した.
2、強制的にシャットダウンし、mysqlサービスを先にシャットダウンしなかった.
3、mysqldプロセスは表を書く時に殺される.
4、myisamchkを使用すると同時に、mysqldもテーブルを操作しています.
5、ディスク障害.
6、サーバーがハングアップした.
7、mysql自体のバグ.
詳細出典参考:http://www.jb51.net/article/25873.htm
二.表の破損の症状破損した表の典型的な症状は以下の通りです.
1.テーブルからデータを選択すると、次のエラーが発生します.Try to repair it
2.クエリは、テーブルにローを見つけたり、不完全なデータを返したりすることはできません.
3 、Error: Table 'p' is marked as crashed and should be repaired .
4、テーブルを開けませんでした:Can't open file:'×××.MYI' (errno: 145) .
5 、
三.MySQLテーブルの破損を予防するには、mysqlテーブルの破損を予防するには、次の方法を使用します.
1、myisamchkを定期的に使用してMyISAMテーブルをチェックし(mysqldを閉じることに注意)、check tableを使用してテーブルをチェックすることをお勧めします(mysqldを閉じる必要はありません).
2、大量の更新や削除操作を行った後、OPTIMIZE TABLEを使用してテーブルを最適化することをお勧めします.これにより、ファイルの破片が減少し、テーブルが破損する確率が減少します.3、サーバーをシャットダウンする前に、mysqldをシャットダウンします(正常にサービスをシャットダウンし、kill-9を使用してプロセスを殺さないでください).
4、ups電源を使用して、突然電源が切れることを避ける.
5、最新の安定版mysqlを使用して、mysql自体のバグを減らしてテーブルの破損を招く.
6、InnoDBエンジンの場合、innodb_を使用できます.tablespace_monitorを使用して、表領域ファイル内のファイル領域管理の完全性を確認します.
7、ディスクに対してraidを行い、ディスクエラーを減らし、性能を向上させる.
8、データベース・サーバはmysqldと必要な他のサービスだけを走ったほうがいい.他の業務サービスを走ってはいけない.これにより、デッドラインによるテーブルの破損の可能性を減らす.
9、万一を恐れず、事故を恐れず、普段からバックアップをとることが時計の破損を予防する有効な手段である.
詳細出典参考:http://www.jb51.net/article/25873.htm
四.MySQLテーブルの破損した修復MyISAMテーブルは、1、reapair tableまたはmyisamchkを使用して修復することができます.2、上記の方法の修復が無効な場合は、バックアップ・リカバリ・テーブルを使用します.具体的には、フェーズ1:テーブルをチェックする時間がたくさんある場合はmyisamchk*を実行します.MYIまたはmyisamchk-e*.MYI .-s(沈黙)オプションを使用して、不要な情報を禁止します.mysqldサーバがダウンタイムしている場合は、--update-stateオプションを使用してmyisamchkにテーブルを「チェック済み」とマークするように伝えます.myisamchkがエラーを報告したテーブルだけを修復する必要があります.このようなテーブルに対しては、フェーズ2に進みます.チェック中に、out of memoryエラーなどの奇妙なエラーが発生した場合、またはmyisamchkがクラッシュした場合、フェーズ3に進みます.フェーズ2:単純で安全な修復コメント:より迅速に修復したい場合はmyisamchkを実行するときにsort_buffer_sizeとKey_buffer_size変数の値は、使用可能なメモリの約25%に設定されます.まず、myisamchk-r-q tbl_を試してみましょう.name(-r-qは「高速リカバリモード」を意味する).これにより、インデックスファイルを修復するためにデータファイルに接触しないようにします.データ・ファイルに必要なすべての内容と、データ・ファイル内の正しい場所への削除接続が含まれている場合は、テーブルを管理し、修復できます.次のテーブルの修復を開始します.そうでない場合は、続行する前にデータファイルをバックアップする手順を実行します.myisamchk-r tbl_の使用name(-rは「リカバリモード」を意味する).これにより、データファイルから不正なレコードと削除されたレコードが削除され、インデックスファイルが再構築されます.前の手順が失敗した場合はmyisamchk--safe-recover tbl_を使用します.name .セキュア・リカバリ・モードは、従来のリカバリ・モードではできない少数の状況(ただし、より遅い)を処理する古いリカバリ・メソッドを使用します.修復時に、out of memoryエラーなどの奇妙なエラーが発生した場合、またはmyisamchkがクラッシュした場合、フェーズ3に進みます.フェーズ3:難しい修復は、インデックスファイルの最初の16 Kブロックが破壊されたり、不正な情報が含まれたり、インデックスファイルが失われたりした場合にのみ、このフェーズに進む必要があります.この場合、新しいインデックスファイルを作成する必要があります.データファイルを安全な場所に移動するには、次の手順に従います.テーブル記述ファイルを使用して、新しい(空)データファイルとインデックスファイルを作成します.
コードは次のとおりです.
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit MySQLバージョンにTRUNCATE TABLEがない場合は、DELETE FROM tbl_を使用します.name . 古いデータファイルを新しく作成したデータファイルにコピーします.(古いファイルを新しいファイルに戻すだけでなく、何かが間違っていないようにコピーを残してください.)ステージ2に戻ります.今はmyisamchk-r-qが働いているはずです.(これは無限のサイクルではない).REPAIR TABLE tblも使えますname USE_FRMは、プログラム全体を自動的に実行します.フェーズ4:非常に困難な修復のみ.frm記述ファイルも破壊されたので、あなたはこの段階に着くべきです.テーブルが作成されると、記述ファイルは変更されないため、これは一度も起こったことがないはずです.1つのバックアップから記述ファイルをリカバリし、フェーズ3に戻ります.インデックスファイルを復元してフェーズ2に戻ることもできます.後者にはmyisamchk-rで起動する必要があります.バックアップを行っていないが、テーブルがどのように作成されているかを正確に知っている場合は、別のデータベースでテーブルのコピーを作成します.新しいデータファイルを削除し、他のデータベースから記述ファイルとインデックスファイルを破壊されたデータベースに移動します.これにより、新しい説明とインデックスファイルが提供されるが、MYDデータファイルは独自に残されています.ステージ2に戻り、インデックスファイルの再構築を試みます.InnoDBテーブルは、データベースページが破壊された場合、SELECT INTO OUTFILEでデータベースからテーブルをダンプしたい場合があります.通常、この方法で取得されるデータの多くは完璧です.それでも破損はSELECT*FROM tbl_を引き起こす可能性がありますnameまたはInnoDBバックグラウンド操作がクラッシュまたは断言したり、InnoDBフロントロールがクラッシュを回復したりします.それでも、InnoDBストレージエンジンの起動を強制し、バックグラウンド操作の実行を阻止し、テーブルをダンプできるようにすることができます.たとえば、サーバを再起動する前に、オプションファイルの[mysqld]セクションに[mysqld]innodb_の行を追加できます.force_recovery = 4innodb_force_recoveryで許可されているゼロ以外の値は次のとおりです.より大きな数字には、より小さな数字をすべて含む予防措置が含まれています.多くの4のオプション値でテーブルをダンプできる場合は、破損した個別のページのデータだけが失われます.6の値は、データベース・ページが古い状態に残されているため、Bツリーや他のデータベース構造の破壊を引き起こす可能性があります.1(SRV_FORCE_IGNORE_CORRUPT)サーバが破損したページを検出しても、サーバを動作させる.SELECT*FROM tbl_nameは破損したインデックスレコードとページをスキップし、テーブルのダンプに役立ちます.2(SRV_FORCE_NO_BACKGROUND)はメインスレッドの動作をブロックし、クラッシュが浄化操作中に発生する可能性がある場合はブロックします.3(SRV_FORCE_NO_TRX_UNDO)リカバリ後、トランザクションロールバックは実行されません.4(SRV_FORCE_NO_IBUF_MERGE)もバッファマージの挿入を阻止します.もしあなたが崩壊を招く可能性があるなら.これらの操作は行わないほうがいいです.テーブル統計表を計算しないほうがいいです.5(SRV_FORCE_NO_UNDO_LOG_SCAN)データベースの起動時に未完了ログは表示されません:InnoDBは未完了トランザクションをコミット済みと見なします.6(SRV_FORCE_NO_LOG_REDO)リカバリ接続でログをロールバックしないでください.データベースは、これらのオプションで許可されているオプションを別途持って使用することはできません.セキュリティ対策としてinnodb_force_recoveryが0より大きい値に設定場合、InnoDBは、INSERT、UPDATE、DELETEの実行をユーザに阻止する.強制リカバリが使用されても、DROPテーブルやCREATEテーブルが使用できます.指定したテーブルがロールバッククラッシュを引き起こしていることを知っている場合は、削除できます.これを使用して、失敗した大口インポートや失敗したALTER TABLEによる暴走ロールバックを停止することもできます.mysqldプロセスを殺してinnodbを設定できますforce_recoveryは3であり、データベースがロールバックを必要とせずに一時停止され、暴走ロールバックの原因となるテーブルが破棄されます.詳細出典参考:http://www.jb51.net/article/25873.htm