2

InnoDB テーブルを含むデータベースがあり、InnoDB テーブルの 1 つが破損しているとマークされています (データが欠落していることなどもわかっています)。ただし、MySQL を再起動してもクラッシュしません。

クラッシュすることを期待していましたが、そうではありません。（その前に読んだのは、innodbテーブルが壊れるとmysqlサーバーが停止するということです）

今クラッシュするべきではありませんか？

innodb は私のデフォルトの db エンジンです。

4

1 に答える 1

2

破損したテーブルが必ずしもクラッシュを引き起こすとは限りません。ただし、テーブルを修復し、可能であれば、バックアップからテーブルをリロードする必要があります。破損したテーブルでの操作はせいぜい不安定であり、とにかく、すでに発見したように、正しい結果が得られないことはありません。

システムが「爆発」していないという事実を信用しないでください。データベースにはいくつかの中間状態があります。あなたが今いるのは、「私はまだ爆発していない。破損が広がり、他のテーブルのデータを汚染するのを待っている」ということかもしれません。テーブルが破損していることがわかっている場合は、今すぐ行動してください。

InnoDBテーブルの修復については、「InnoDBテーブルを修復するにはどうすればよいですか？」を参照してください。。

InnoDBテーブルが破損しているかどうかを確認するには、https： //dba.stackexchange.com/questions/6191/how-do-you-identify-innodb-table-corruptionを参照してください。

破損の検出

これを行うには、大量のデータを調べて、クリーンな健康状態を示す受け入れテストが必要です。テーブルをSQLにエクスポートし、それが可能かどうかを確認したり、タプルのカーディナリティやリレーションのチェックを実行したりすると、私のドリフトが発生します。誰も書き込むことが期待されていないテーブルでは、変更が破損に等しいため、ディスクファイルのMD5の方が高速になる可能性があります。

物事をより効率的にするために（例えば、実動システムで）、ファイルのスナップショット、データベースの複製、さらには高可用性を考えることができます。これらのメソッドは、プログラムによる破損（たとえば、不正なUPDATE）を検出しますが、マスターでのある種のハードウェア破損を検出しない場合があります（フォールスネガティブ：スレーブのチェックがパンアウトし、データはマスターでまだ破損しています）またはスレーブで事故が発生する可能性があります（マスター上のデータは実際には汚染されていないため、失敗して誤検知が発生します）。

システムの人口動態統計を監視することは重要です（そして効率的です）。差し迫った障害の最初の症状をキャッチし（たとえばSMARTを使用）、フォレンジック調査のためのデータを提供します（「DBが障害を起こすたびに、それは常に直後でした。システム負荷の突然のピーク-その原因を突き止めたらどうなるでしょうか？」）。

そしてもちろん、完全で適切なバックアップに依存します（そして、時々テスト復元を実行します。そこに行って、それを実行して、私のお尻を私に手渡してもらいました）。

破損の原因[元の質問とは関係ありません]

破損の原因は、ソフトウェアの設定によって異なります。もちろん、一般的に、何か がチェーンに侵入し、大混乱を引き起こす必要があります。server memory representation-writer process-OS handle-journaling-IOSS-OS cache-disk-disk cache-internal file layout

不適切なシステムシャットダウンは、いくつかのレベルで混乱し、パイプラインのどの段階でもデータが書き込まれないようにする可能性があります。

ディスク上のファイルの処理は、最後の段階で混乱します（サーバーが何も知らない独自のパイプラインを使用します）。

他のより難解な可能性が存在します：

  • ハードディスク自体の微妙なファームウェア/ハードウェア障害、
    • ディスクの摩耗やファームウェアの欠陥、またはファームウェアの更新の欠陥が原因で、偶発的でおそらく回復不能です（数年前、わずかに異なるモデルに対して実行される可能性のある音響管理用の日立の更新を覚えているようです。ディスクの更新後「考えた」それは実際よりも多くのキャッシュを持っていて、キャッシュの存在しない領域への書き込みはもちろん直接ビット天国に行きました）。
    • 「意図的」でおそらく回復可能：を使用してハードディスクを薄くしすぎる可能性がある場合がありますhdparm。すべてのコンポーネントがそのレベルのパフォーマンスに適しており、それを知っているか、少なくともそうでない場合は信号を送ることができる場合、ディスクを最高のパフォーマンスに設定することはすべてうまくいきます。時々、あなたが得るすべての「警告」はシステムの誤動作です。
  • プロセススペースまたはIOSSの破損：Apacheのインストールでこれが見られました。おそらく、suid rootであるCGIのおかげで、access.logファイルがユーザーのブラウザに送信されるはずのGIF画像のストリームでいっぱいになりました。修正され、何も起こりませんでしたが、ログではなくより重要なファイルだった場合は... ？このような問題は診断が難しい場合があり、すべてのログファイルを調べて、一部のアプリケーションが不利なことに気づいたか、何かをしたかどうかを確認する必要があります。
  • ハードディスクセクターの再配置：伝説になっていますが、自分では見たことがありませんが、最近のハードディスクには「スペア」セクターがあり、欠陥セクターと交換して「欠陥ゼロ」の表面を維持します。欠陥のあるセクターがたまたま読み取り不能になり、空のセクターと交換された場合を除いて、正味の効果は、そのセクターが突然ゼロにされた場合と同じです。hddhealthこれは、SMARTレポート（または）を使用して簡単に確認できますsmartctl。

もちろん、セットアップによっては、他にも多くの可能性があります。ファイルの破損をグーグルで検索すると、無数のページが見つかります。クエリに追加するのに役立つ用語は、ファイルシステム（ext4、NTFS、brtfsなど）、ハードディスクの製造元とモデル、OS、問題のあるソフトウェア、インストールされているその他のソフトウェアです。

于 2012-11-06T19:15:43.330 に答える