オフラインバイナリログに基づく MySQL の高速「フラッシュバック」の詳細な紹介-mysql チュートリアル-php.cn

オフラインバイナリログに基づく MySQL の高速「フラッシュバック」の詳細な紹介

黄舟

リリース： 2017-03-18 14:37:12

オリジナル

1595 人が閲覧しました

昨日、ある顧客が突然、大量のデータを誤って削除したと言い、CTO が私を直接ディスカッショングループに引き入れ、データの回復を手伝うと言いました。自分たちで穴を掘り、業務ログを基に開発側に復元させる予定だったが、主キーの削除などの情報のみが記録されており、物理的な削除は不可能だったという。

サーバーに記録されたログを確認したところ、いくつかのサーバーが誤ってレコード出力を削除していたことがわかりました。 Alibaba RDSではインスタンスのクローンを作成して削除前に復元することができますが、数万点に散在するIDを見つけるのは難しく、複数のテーブルに関連付けられたデータも復元する必要があり面倒です。

MySQL のフラッシュバックソリューションについて考えてみましょう。以前にいくつかの関連記事を読み、python を使用してバイナリを解析し、それを逆にしてロールバック SQL を取得するところでした。本当に時間がないので、今すぐ使用する必要があります。私はすぐにオンラインで「既製のソリューション」を探しました。

本文始まり

MySQL (Alibaba RDS を含む) の高速フラッシュバックは、データベースの誤操作に対する後悔の薬と言えます。フラッシュバック機能は、データベースを誤操作前の状態に戻すことができます。ただし、Oracle データベースでも、短期間内のフラッシュバックのみがサポートされます。

インターネット上の既存のオープンソース MySQL フラッシュバック実装では、binlog を解析して逆方向 SQL を生成するという原則を使用しています: (行モードである必要があります)

削除操作の場合、挿入 (DELETE_ROWS_EVENT) を生成します
更新操作の場合, ビンログの値の順序を入れ替える(UPDATE_ROWS_EVENT)
挿入操作の場合は削除を逆生成(WRITE_ROWS_EVENT)
複数のイベントの場合はSQLを逆生成

上記2つの実装方法はどちらもpython-mysql-replication パッケージは、元のライブラリのスレーブライブラリをシミュレートし、show binary logs を実行してバイナリログを取得し、バイナリログを同期するリクエストを開始して、EVENT を解析します。ただし、Alibaba Cloud RDS のビンログがスレーブライブラリに同期された後、すぐにパージされました show binary logs 来获取binlog，发起同步binlog的请求，再解析EVENT。但是阿里云 RDS 的binlog在同步给从库之后， 很快就被 purge 掉了 。如果要恢复昨天的 部分数据 ，两种方案都是拿不到binlog的。也就是闪回的时间有限。

还有一些比较简单的实现，就是解析 binlog 物理文件，实现回滚，如 binlog-rollback.pl ，试过，但是速度太慢。

为了不影响速度，又想使用比较成熟的闪回方案，我们可以这样做：

借助一个自建的 mysqld 实例，将已purge掉的binlog拷贝到该实例的目录下
在自建实例里，提前创建好需要恢复的表（结构），因为工具需要连接上来从 information_schema.columns 获取元数据信息
拷贝的时候，可以替换掉mysql实例自己的binlog文件名，保持连续
可能要修改 mysql-bin.index，确保文件名还能被mysqld识别到
重启mysql实例，show binary logs。昨日の
データ
する場合、どちらのオプションでも binlog は取得されません。言い換えれば、フラッシュバック時間には制限があります。
binlog-rollback.pl など、binlog 物理ファイルを解析してロールバックを実装する比較的単純な実装もいくつかあります。試してみましたが、速度が遅すぎます。
速度に影響を与えず、より成熟したフラッシュバックソリューションを使用したい場合は、次のようにすることができます:

自己構築された mysqld インスタンスを使用して、パージされた binlog をインスタンスのディレクトリにコピーします

information_schema.columns

mysql-bin.index

show binary logs

要するに、別のmysqlを使用してbinlogイベントを送信することです。暖かいリマインダー:

2 つのインスタンス間のバージョンの差が大きすぎないようにします

ファイルのアクセス許可に注意してください
元のライブラリで gtid が有効になっている場合、この自己構築インスタンスも gtid を有効にする必要があります

例:

python mysqlbinlog_back.py --host="localhost" --username="ecuser" --password="ecuser" --port=3306 \
--schema=dbname --tables="t_xx1,t_xx2,t_xx3" -S "mysql-bin.000019" -E "2017-03-02 13:00:00" -N "2017-03-02 14:09:00" -I -U

===log will also  write to .//mysqlbinlog_flashback.log===
parameter={&#39;start_binlog_file&#39;: &#39;mysql-bin.000019&#39;, &#39;stream&#39;: None, &#39;keep_data&#39;: True,
 &#39;file&#39;: {&#39;data_create&#39;: None, &#39;flashback&#39;: None, &#39;data&#39;: None}, &#39;add_schema_name&#39;: False, &#39;start_time&#39;: None, 
 &#39;keep_current_data&#39;: False, &#39;start_to_timestamp&#39;: 1488430800,
 &#39;mysql_setting&#39;: {&#39;passwd&#39;: &#39;ecuser&#39;, &#39;host&#39;: &#39;localhost&#39;, &#39;charset&#39;: &#39;utf8&#39;, &#39;port&#39;: 3306, &#39;user&#39;: &#39;ecuser&#39;},
 &#39;table_name&#39;: &#39;t_xx1,t_xx2,t_xx3&#39;, &#39;skip_delete&#39;: False, &#39;schema&#39;: &#39;dbname&#39;, &#39;stat&#39;: {&#39;flash_sql&#39;: {}},
 &#39;table_name_array&#39;: [&#39;t_xx1&#39;, &#39;t_xx2&#39;, &#39;t_xx3&#39;],
 &#39;one_binlog_file&#39;: False, &#39;output_file_path&#39;: &#39;./log&#39;, &#39;start_position&#39;: 4, &#39;skip_update&#39;: True,
 &#39;dump_event&#39;: False, &#39;end_to_timestamp&#39;: 1488434940, &#39;skip_insert&#39;: True, &#39;schema_array&#39;: [&#39;dbname&#39;]
}
scan 10000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:14
scan 20000 events ....from binlogfile=mysql-bin.000019,timestamp=2017-03-02T11:42:29
...

ログイン後にコピー

ヒント:

binlog は ROW 形式であり、dml の影響を受ける各行は、Table_map と Row_log の 2 つのイベントを記録します。 table_map の table_id は、どのインスタンスに適用されるかには影響しません。この ID は、テーブル構造のバージョンを記録するための論理メカニズムと考えることができます。table_diction_cache 内にテーブル定義が見つからない場合、ID は 1 ずつ増分され、次のように割り当てられます。ターゲットをbinlogテーブルに記録します。

mysqlbinlog_back.py の使用経験
:

🎜🎜ライブラリ名、表示、開始バイナリログファイル名、開始時刻、終了時刻を必ず指定してください。スキャンを高速化できます。 🎜🎜🎜🎜回復のニーズに応じて、-I、-U、-D を選択して、ロールバックする操作の種類を指定します。 🎜🎜🎜🎜(完全なフラッシュバックではなく)部分的な表データのみがリストアされる場合、関連する表は正しくリストアできません。たとえば、削除されたデータは復元する必要がありますが、削除によって更新された他のテーブルのデータは、完全なフラッシュバックがない限り復元できません。 🎜🎜🎜🎜 t_xx3 の f_do_type フィールドなど、列挙型のテーブルフィールドはサポートされません。自己構築インスタンスの enum 定義を int に変更できます。 🎜🎜🎜

以上がオフラインバイナリログに基づく MySQL の高速「フラッシュバック」の詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。