パーティション分割されたテーブルがいくつかあり、複製されたスレーブにいくつかのインデックスがあります。スナップショット(検証済みの安全)を新しいスレーブにコピーし、mysqldを5.1.42から5.5.15にアップグレードしてレプリケーションを再開した後、エラーメッセージ "Invalid pointer ..."でInnoDBがクラッシュします。
これらのエラーは、ハードウェアとO/Sが異なる2つのサーバー間で発生しました。実行後:
ALTER TABLE .... COALESCE PARTION n;
問題はそのテーブルではなくなります。
しかし、私の質問の範囲は大きく、それは「InnoDBテーブルの破損をどのように特定するのですか?」または「InnoDBテーブルの状態をどのように評価しますか?」と言い換えます。 "CHECK TABLE"プリクラッシュの問題を特定するために利用できる唯一のツールはありますか?
問題かどうかはわかりませんが、クラッシュが発生しました:バージョン: '5.5.15-55-log'ソケット: '/opt/mysql.sock'ポート:3306 Percona Server(GPL)、リリースrel21.0、リビジョン158
Morgan は、InnoDBが読み取ったページに対してチェックサムを実行することにより、破損したページを常にチェックしているというコメントを示しています。 InnoDBがチェックサムの不一致を検出すると、 クラッシュ サーバーを停止します。
そのプロセスを高速化したい場合は(InnoDBが破損したページを読み取るのを待つ代わりに)、 innochecksum
を使用できます。
チェックサムの不一致により、InnoDBは実行中のサーバーを意図的にシャットダウンするため、本番環境でサーバーが破損したページに遭遇するのを待つよりも、このツールを使用する方が望ましい場合があります。
興味深い警告:
innochecksumは、サーバーがすでに開いているテーブルスペースファイルでは使用できません。このようなファイルについては、CHECK TABLEを使用してテーブルスペース内のテーブルをチェックする必要があります。
つまり、オンラインテーブルの場合はCHECK TABLE
はおそらくツールです(または、指摘したように 別の回答でmysqlcheck
一度に複数のデータベースを実行する場合。)
データベースをシャットダウンできる場合は、innochecksum
を使用してチェックサムを強制できます。
事例:29GBのinnodbテーブルスペース(innodb_file_per_table=1
)、このスクリプトには約2分かかりました
#!/bin/bash
for i in $(ls /var/lib/mysql/*/*.ibd)
do
innochecksum -v $i
done
ただし、ボーナスとして、Perconaを実行しているため、 fast innodb checksum の新しいメソッドが実装されました。私はそれを使用したことがありませんが、プロセスをスピードアップするかもしれません。
警告:これらの手順を試す前に、万が一に備えてデータベースの正常なバックアップが手元にあることを確認することを強くお勧めします。 (警告のために@Nickに感謝)
mysqlcheck
コマンドを使用してみてください。端末上:
mysqlcheck -u username -p --databases database1 database2
このコマンドは、すべてのテーブルのリストと、何らかの破損があったかどうかを示すステータスを出力します。
table1 OK
table2 OK
table3 OK
tableN OK
これで、どのテーブルを修復する必要があるかがわかります。すべてを一度に修復したい場合に備えて:
mysqlcheck -u username -p --auto-repair --databases database1 database2
mysqlcheck
の詳細: http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html
注:あなたの質問に percona のタグを付けました。それが何なのか見当がつかなかったのでググった。 MySQLのフォークのようですが、コマンドに互換性がないと信じる理由はありません(フィンガークロス)。
データベース全体が起動しないより重要な状況でのInnoDBデータベースのリカバリに関するより具体的な手順が記載されているこのガイドを誰かが指摘した: http://www.softwareprojects.com/resources/programming/t-how-to -fix-mysql-database-myisam-innodb-1634.html
MySQL 5.0 Certification Study Guide、Page 443,444 Section 30.4 によると:
InnoDBテーブルをチェックするには、CHECK TABLEコマンドを使用するか、クライアントプログラムを使用してステートメントを発行します。ただし、InnoDBテーブルに問題がある場合、そのステートメントはMyISAMにのみ適用されるため、REPAIR TABLEを使用してそれを修正することはできません。
テーブルチェックがInnoDBテーブルに問題があることを示している場合は、mysqldumpでテーブルをダンプし、ドロップして、そのダンプからテーブルを再作成することにより、テーブルを一貫した状態に復元できるはずです。
MySQLサーバーまたはそれが実行されているホストでクラッシュが発生した場合、一部のInnoDBテーブルを修復する必要があります。 InnoDBストレージエンジンは起動シーケンスの一部として自動リカバリを実行するため、通常はサーバーを再起動するだけで十分です。まれに、InnoDB自動回復の失敗によりサーバーが起動しない場合があります。その場合は、次の手順に従ってください。
--innodb_force_recoveryオプションを1〜6の範囲の値に設定してサーバーを再起動します。これらの値は、クラッシュを回避するための警告のレベルの増加と、リカバリされたテーブルでの不整合の可能性に対する許容レベルの増加を示します。最初は4が適切です。
--innodb_force_recoveryをゼロ以外の値に設定してサーバーを起動すると、InnoDBはテーブルスペースを読み取り専用として扱います。したがって、mysqldumpを使用してInnoDBテーブルをダンプし、オプションが有効な間はそれらをドロップする必要があります。次に、-innodb_force_recoveryオプションを指定せずにサーバーを再起動します。サーバーが起動したら、ダンプファイルからInnoDBテーブルをリカバリします。
上記の手順が失敗した場合は、以前のバックアップからInnoDBテーブルを復元する必要があります。
MySQLドキュメントを InnoDB Forced Recovery でお読みください
InnoDBプラグインで作成されたInnoDBデータを誰かが使用してから、別のバージョンのInnoDBに切り替えるとどうなるのでしょうか。 mysqldの目には、ページが破損する可能性があります。
MySQLのInnoDBファイル形式に関するドキュメント がこの可能性について述べていることに注意してください:
一般に、新しいバージョンのInnoDBは、クラッシュ、ハング、誤った結果、または破損のリスクなしに、以前のバージョンのInnoDBで安全に読み書きできないテーブルまたはインデックスを作成する可能性があります。 InnoDBプラグインは、これらの条件から保護し、データベースファイルとInnoDBのバージョン間の互換性を維持するのに役立つ新しいメカニズムを導入します。
私はスレーブのデータをスクラップします。実際、私はデータの論理ダンプ(mysqldump)を取得することにより、ブルートフォースを使用します。
私が投稿した元のアンサーは「古い学校」と見なされます。しかし、この場合は、.ibdやibdata1で使用されているファイル形式を確認します。