web-dev-qa-db-ja.com

mysqlデータベースのinnodbログファイルが失われた場合はどうなりますか？

私がしたことは

/etc/init.d/mysql stop

次にファイルを削除しました：ib_logfile0, ib_logfile1

次にmy.cnfファイルを変更し、変数：innodb_log_file_size

その後：

/etc/init.d/mysql start

ファイルの再作成を許可しました

私は後でグローバル変数innodb_fast_shutdownは「1」に設定されます

問題は、どれだけのデータが失われたかです。

注：古いファイルib_logfile0、ib_logfile1はまだ削除されていません

また、データベースに依存するWebサイトは機能しているようです。

mysqlinnodbbackuprecovery
3
sharp12345

まず最初に：ファイルを実際に削除しないことに対する称賛-ファイルを移動することは、単にそれらを削除するよりも常に良いアイデアです-しかし 古いログファイルを元に戻そうとしないでください。。

ログシーケンス番号（LSN）が原因で、それらを分析することはできても、このサーバーでサービスに戻すことはできない可能性がありますログファイルのibdataに保存されているファイルと一致しません。

InnoDB:                          WARNING!
InnoDB: The log sequence number in ibdata files is higher
InnoDB: than the log sequence number in the ib_logfiles! Are you sure
InnoDB: you are using the right ib_logfiles to start up the database?

クラッシュリカバリを開始する可能性が最も高く、壊れていないものを「修復」する可能性があります...したがって、私は絶対にこれを試みません。

問題は、どれだけのデータが失われたかです。

データが失われた場合、それは最近の変更（挿入/更新/削除）でした。ただし、これまで考えてきたこととは正反対に、innodb_fast_shutdownを1に設定してmayを実行しても安全です2ではありません）。

http://dev.mysql.com/doc/refman/5.5/en/innodb-data-log-reconfiguration.html

これらの指示は、「2」に設定されていない限り問題ないことを意味し、「2」に設定されている場合、「1」に設定するように指示します。期待していたので、あなたが行ってもいいように見えるか、ドキュメントにかなり深刻な欠陥があるようです。

3
Michael - sqlbot