ほとんどのクエリで問題なく機能するTokuDBテーブルがありますが、他のクエリではsegfaultが発生します。テーブルにエラーがあることを示すCHECK TABLEを実行しました。ただし、TokuDBはREPAIR TABLEをサポートしていません。破損したTokuDBテーブルを修正するにはどうすればよいですか?
mysql> check table XXX;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 1
Current database: XXX
+------------------------------------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------------------------------------------+-------+----------+----------+
| XXX.XXX | check | error | Corrupt |
+------------------------------------------------+-------+----------+----------+
1 row in set (14 hours 17 min 55.05 sec)
mysql> repair table XXX;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 2
Current database: XXX
+------------------------------------------------+--------+----------+---------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+------------------------------------------------+--------+----------+---------------------------------------------------------+
| XXX.XXX | repair | note | The storage engine for the table doesn't support repair |
+------------------------------------------------+--------+----------+---------------------------------------------------------+
1 row in set (0.84 sec)
TokuDBはInnoDBと同様に、repair tableコマンドをサポートしていないため、問題のテーブルを修復できません。バックアップまたはスレーブがない場合、可能な限り最善の方法は、テーブル自体の読み取り可能な部分から行を選択することです。 「select * from table_name where table_pk <?into;」を使用することをお勧めします。および「select * from table_name where table_pk>?into;」。を試す必要がありますか?ファイルの破損した部分を読み取るとサーバーがクラッシュするため、ステートメントごとに。
ほとんどのクエリは機能するので、最善の方法はテーブルをmysqldumpすることです。
DB=mydb
TB=mytable
DUMPSCHM=${DB}_${TB}_schema.sql
DUMPDATA=${DB}_${TB}_data.sql
mysqldump --no-data --skip-disable-keys --skip-lock-tables ${DB} ${TB} > ${DUMPSCHM}
mysqldump --no-create-info --skip-disable-keys --skip-lock-tables ${DB} ${TB} > ${DUMPDATA}
次に、使用してテーブルの名前を変更します
mysql> ALTER TABLE mydb.mytable RENAME mydb.myoldtable;
次に、使用してテーブルをリロードします
mysql> source mydb_mytable_schema.sql
mysql> source mydb_mytable_data.sql
試してみてください(うまくいくことを願っています)!!!
警告:うまくいけば、 Tokutekサイトで参照できるTokuDB Docがいくつかあります 。
ドキュメントの1つ によると、それは言う:
トランザクションセーフデータベースを使用する場合、ハードウェアの書き込みキャッシュ特性を理解することが不可欠です。 TokuDBは、MySQLにトランザクションセーフ(ACID準拠)のデータストレージを提供します。ただし、基盤となるオペレーティングシステムまたはハードウェアが実際にディスクにデータを書き込んでいない場合は、マシンがクラッシュしたときにシステムがデータベースを破壊する可能性があります。たとえば、NFSボリュームにマウントされている場合、TokuDBは適切なリカバリを保証できません。書き込みキャッシュを無効にすることは常に安全ですが、パフォーマンスをあきらめる可能性があります
システムクラッシュまたはディスクへの書き込みが成功したことによる誤検知が原因でこの破損した状態が発生した場合は、Tokutekに直接問い合わせる必要があります Tokutekは私の操舵室から少し離れています 。
そして、それが完全に破損している場合。これが、生ファイルからデータを取得する方法を説明する私の投稿です。
Gistでは、メインのtokuファイルからファイルを復元できました。
Toku-ftリポジトリには、tokuftdumpと呼ばれる内部デバッグツールがあります。
ツリーを解析した後、解凍されたリーフエントリにバイトストリームをダンプします。変換された16進ストリームでいくつかの16進編集を行うと構造が明らかになるため、元のユーティリティを変更して、構造によって明らかにされた解析後にexact値をダンプできます。 。
Tokuのノードにはメッセージバッファーがあるため、追加のメッセージ処理も必要になる場合があります。私の場合、インサートしかなかったのでこれは簡単でした...
更新:詳細はこちら
http://kshitij.learnercafe.com/TokuDB-Recovery-From-Files/
(免責事項:これはファイルのリバースエンジニアリングです。データを回復した後、データの健全性チェックを行うことをお勧めします)。