だから私は最近出てきたこのような状況の後、私はこれについての投稿をしていないことに気づいた。
シナリオは次のとおりです。バックアップは真夜中に行われ、データベースごとにMySQLダンプを使用しました。 それから翌日の午前10時にデータベースがクラッシュしました。 電話をかける前に一連のイベントが発生しましたが、MyISAMテーブルとIBDファイルがテーブルスペースにないデータベースのバージョンに到達しました。
そのため、オプション1、バックアップから復元すると深夜になり、何時間ものデータを失うことになります。 オプション2、私たちは何千ものibdファイルを再インポートしてすべてを保存します。 それから、オプション3、バックアップからの復元、そして最近の変更にbinlogを適用しました。
それをもっと面白くするために、彼らは私が言われたibdファイルの全てを持っていませんでした、そして私はいくらかの欠けているのを見ました。 それでそれがどのように可能であったかについてよくわからないが、選択肢2は無効な選択肢になった。 彼らは、もちろん、可能な限り少ないデータ損失を望んでいたので、私たちはオプション3を使いました。
これを安全に行うために、ポート3307でMySQLの別のインスタンスを起動しました。これにより、トラフィックがポート3306インスタンスのMyISAMデータへの読み取りアクセスを行っている間も、安全に作業できます。
すべてのバックアップダンプファイルを圧縮解除して3307インスタンスにインポートすると、binlogファイルに集中することができました。
最初は、この概念は実際よりもはるかに危険に思えます。 それは実際にはかなり単純明快です。
だから最初にあなたはあなたの後のデータを見つけなければなりません。 binlogファイルを見直すことで、どのファイルが関連しているのかをすぐに知ることができます。 私の場合、どういうわけか彼らはbinlogをリセットすることができたので117ファイルはその中に2つの日付範囲を持っていました。
最初にbinlogを確認するために、次のコマンドはデータを人間が読める形式で出力します。
*注意...上記のコマンドを実行するときは注意してください。 binlogと同じ場所に直接ファイルをダンプしていることに注意してください。 ファイル名が有効であることを確認してください。 このmysql-bin.000117.sqlは、このmysql-bin.000117 .sqlとは異なります。 あなたは2番目のオプションと.sqlの前のスペースであなたのbinlogを失うでしょう。
適用できるようにデータを保存します。 私はいくつかのbinlogを持っていたので、私はファイルを作成し、とにかく時間範囲を再確認したいと思いました。
今、私は与えられた時間範囲についてそれらのbinlogからのすべてのデータを適用しました。 クライアントはすべてのデータをダブルチェックし、すべて元に戻すことができてとても嬉しかったです。
この状況にはいくつかの異なる選択肢がありましたが、これはたまたまクライアントと一緒にトレーニングすることでした。
検証されたすべてが復元されたバージョンで大丈夫だったとすれば、両方のデータベースを停止し、データディレクトリを移動し（datadirのデフォルトをそのままにしておきたい）、ディレクトリを安全にしてMySQLを起動します。 復元されたインスタンスはポート3306で起動しました。
シナリオは次のとおりです。バックアップは真夜中に行われ、データベースごとにMySQLダンプを使用しました。 それから翌日の午前10時にデータベースがクラッシュしました。 電話をかける前に一連のイベントが発生しましたが、MyISAMテーブルとIBDファイルがテーブルスペースにないデータベースのバージョンに到達しました。
そのため、オプション1、バックアップから復元すると深夜になり、何時間ものデータを失うことになります。 オプション2、私たちは何千ものibdファイルを再インポートしてすべてを保存します。 それから、オプション3、バックアップからの復元、そして最近の変更にbinlogを適用しました。
それをもっと面白くするために、彼らは私が言われたibdファイルの全てを持っていませんでした、そして私はいくらかの欠けているのを見ました。 それでそれがどのように可能であったかについてよくわからないが、選択肢2は無効な選択肢になった。 彼らは、もちろん、可能な限り少ないデータ損失を望んでいたので、私たちはオプション3を使いました。
これを安全に行うために、ポート3307でMySQLの別のインスタンスを起動しました。これにより、トラフィックがポート3306インスタンスのMyISAMデータへの読み取りアクセスを行っている間も、安全に作業できます。
すべてのバックアップダンプファイルを圧縮解除して3307インスタンスにインポートすると、binlogファイルに集中することができました。
最初は、この概念は実際よりもはるかに危険に思えます。 それは実際にはかなり単純明快です。
だから最初にあなたはあなたの後のデータを見つけなければなりません。 binlogファイルを見直すことで、どのファイルが関連しているのかをすぐに知ることができます。 私の場合、どういうわけか彼らはbinlogをリセットすることができたので117ファイルはその中に2つの日付範囲を持っていました。
最初にbinlogを確認するために、次のコマンドはデータを人間が読める形式で出力します。
mysqlbinlog
--defaults-file=/root/.my.cnf --base64-output=DECODE-ROWS --verbose
mysql-bin.000117 > review_mysql-bin.000117.sql *注意...上記のコマンドを実行するときは注意してください。 binlogと同じ場所に直接ファイルをダンプしていることに注意してください。 ファイル名が有効であることを確認してください。 このmysql-bin.000117.sqlは、このmysql-bin.000117 .sqlとは異なります。 あなたは2番目のオプションと.sqlの前のスペースであなたのbinlogを失うでしょう。
適用できるようにデータを保存します。 私はいくつかのbinlogを持っていたので、私はファイルを作成し、とにかく時間範囲を再確認したいと思いました。
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-09
00:00:00" --stop-datetime="2019-07-10 00:00:00" mysql-bin.000117 >
binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000118 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf mysql-bin.000119 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --start-datetime="2019-07-10
00:00:00" --stop-datetime="2019-07-10 10:00:00" mysql-bin.000117
>> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000120 >> binlog_restore.sql
mysqlbinlog --defaults-file=/root/.my.cnf --stop-datetime="2019-07-10 10:00:00" mysql-bin.000121 >> binlog_restore.sql
mysql --socket=/var/lib/mysql_restore/mysql.sock -e "source /var/lib/mysql/binlog_restore.sql"
今、私は与えられた時間範囲についてそれらのbinlogからのすべてのデータを適用しました。 クライアントはすべてのデータをダブルチェックし、すべて元に戻すことができてとても嬉しかったです。
この状況にはいくつかの異なる選択肢がありましたが、これはたまたまクライアントと一緒にトレーニングすることでした。
検証されたすべてが復元されたバージョンで大丈夫だったとすれば、両方のデータベースを停止し、データディレクトリを移動し（datadirのデフォルトをそのままにしておきたい）、ディレクトリを安全にしてMySQLを起動します。 復元されたインスタンスはポート3306で起動しました。
