[MySQL] SQL_Threadを介してbinlogをすばやく復元する

データベースを指定された時点または場所にバックアップするには、多くの場合、完全バックアップ+ binlog増分を使用します。
大量のデータの場合、binlogの増分リカバリは常に厄介な問題でした。

binlogの回復は非常に遅く、エラーが発生しやすいためです。

ps以下のすべてのボックスは左右にスライドできます

横に読むことをお勧めします

一般的なbinlogインクリメンタルリカバリ方法

最初にsqlファイルに解析し、次にMySQLをインポートします

1mysqlbinlog mysql-bin.000001 --start-position=n > /data/add.sql
2mysqlbinlog mysql-bin.000002 ... mysql-bin.n >> /data/add.sql
3mysql -u -p -S < /data/add.sql

MySQLに直接パイプする

1mysqlbinlog mysql-bin.000001 --start-position=n | mysql -u -p -S
2mysqlbinlog mysql-bin.000002 ... mysql-bin.n | mysql -u -p -S

パイプを直接入れる方法は必ずしも安全ではありません。マニュアルには次のようにも記載されています。

1If you have more than one binary log to execute on the MySQL server,
2the safe method is to process them all using a single connection to the server.

この方法の詳細については、https ：//dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.htmlを参照して
ください。

ただし、これら2つの方法の原則は同じであり、mysqlbinlogsqlに解析され、MySQLにインポートされます。

利点：
- 便利な操作とシンプルなロジック。
- 閉じる必要はありませんmysqld。
短所：
- ERROR位置を特定するのが難しい場合、「ブレークポイントからの回復」は困難です。
- 特殊な文字または文字セットに関する問題。
- max_allowed_packet問題。
- 回復速度が遅い。

リレーログとビンログは本質的に同じものなので、
MySQL独自のsql_threadを使用してビンログを増やすことは可能ですか？

sql_threadによる回復

アイデアの処理：
1）インスタンスを再初期化し、完全なバックアップファイルを復元します。
2）最初のbinlogファイルpositionと残りのすべてのファイルを見つけますbinlog。
3）binlogふりをしrelaylogて、sql threadインクリメンタルで復元します。

ここでは、コア部分、つまりリレーログに偽装するプロセスのみを紹介します。

①リレーログ情報のリポジトリをファイルに変更し、このファイルを生成します。（relay_log_info_repositor構成ファイルに書き込まれます）

1SET GLOBAL relay_log_info_repository='FILE';
2CHANGE MASTER TO master_host='1', master_password='1', master_user='1', master_log_file='1', master_log_pos=4;

注文変更することで、無使用のため、スレーブ・インスタンスとしてMySQL自体を指示するIO_Threadので、host、password、userなどで埋めることは自由です。
そして、このステップを通じて、relay.infoファイルが生成されます。

②インスタンスを閉じ、インクリメントする必要のあるbinlogファイルをリレーログに偽装します。

1cp mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.000007 mysql-bin.000008 mysql-bin.000009 mysql-bin.000010 $relaylogdir
2cd $relaylogdir
3rename mysql-bin. mysql-relay. mysql-bin.0000*
4chown mysql:mysql -R .

cpコマンドbinlogを使用して移動します$relaylogdir。この変数はインスタンスのオプションパラメータに依存し、デフォルトdatadirで下に配置されます。
次にbinlog、バッチの名前をに変更しrelaylog、対応する権限を付与しますOS error code 13: Permission denied。そうしないと、エラーが報告されます。

③relay.infoファイルとrelay-log.indexファイルを
変更してrelay.info、2行目と3行目を最初のbinlog（現在のrelaylog）ファイル名とposition：に変更します。

1/data/mysql57/relaylog/mysql-relay.000003
21276895

2行目Relay_log_nameと3行目は合計Relay_log_posに対応し、これは次と同等です。

1mysqlbinlog mysql-relay.000003 --start-position=1276895 | mysql -u -p -S

このファイルは、どちらから実行を開始するかを指定するように変更されてSQL_Threadいます。filepositionevents

他に何を実行する必要があるかrelay-log.indexを伝えるために、もう一度変更し、元の情報をクリアし、次の情報を追加します。SQL_Threadrelaylog

1/data/mysql57/relaylog/mysql-relay.000003
2/data/mysql57/relaylog/mysql-relay.000004
3/data/mysql57/relaylog/mysql-relay.000005
4/data/mysql57/relaylog/mysql-relay.000006
5/data/mysql57/relaylog/mysql-relay.000007
6/data/mysql57/relaylog/mysql-relay.000008
7/data/mysql57/relaylog/mysql-relay.000009
8/data/mysql57/relaylog/mysql-relay.000010

④インスタンスを起動して開きますSQL_Thread：

1START SLAVE sql_thread ;

⑤コピー状態を確認してください。

 1mysql> SHOW SLAVE STATUS\G
 2*************************** 1. row ***************************
 3Slave_IO_State:
 4Master_Host: 1
 5Master_User: 1
 6Master_Port: 3306
 7Connect_Retry: 60
 8Master_Log_File: 1
 9Read_Master_Log_Pos: 4
10Relay_Log_File: mysql-relay.000003    -- 已经执行到的日志名
11Relay_Log_Pos: 11529982        -- 已经执行到日志的位置
12Relay_Master_Log_File: 1
13Slave_IO_Running: No
14Slave_SQL_Running: Yes
15Replicate_Do_DB:
16Replicate_Ignore_DB:
17Replicate_Do_Table:
18Replicate_Ignore_Table:
19Replicate_Wild_Do_Table:
20Replicate_Wild_Ignore_Table:
21Last_Errno: 0
22Last_Error:
23Skip_Counter: 0
24Exec_Master_Log_Pos: 11529982
25Relay_Log_Space: 5347038913
26Until_Condition: None
27Until_Log_File:
28Until_Log_Pos: 0
29Master_SSL_Allowed: No
30Master_SSL_CA_File:
31Master_SSL_CA_Path:
32Master_SSL_Cert:
33Master_SSL_Cipher:
34Master_SSL_Key:
35Seconds_Behind_Master: 274354        -- 若变为0，则表示已经增量完毕
36Master_SSL_Verify_Server_Cert: No
37Last_IO_Errno: 0
38Last_IO_Error:
39Last_SQL_Errno: 0
40Last_SQL_Error:
41Replicate_Ignore_Server_Ids:
42Master_Server_Id: 0
43Master_UUID:
44Master_Info_File: /data/mysql57/master.info
45SQL_Delay: 0
46SQL_Remaining_Delay: NULL
47Slave_SQL_Running_State: Reading event from the relay log
48Master_Retry_Count: 86400
49………………………………

この時点で、sql_thread段階的に復元できますbinlog。
もちろん、上記のプロセスは指定された--start-position方法での回復のみを目的としています。たとえば、シングルポイントのMySQLインスタンスinnodb_force_recovery=6を開始できない場合は、最後に使用可能な完全バックアップと残りのbinlogを使用して回復する必要があります。

このテストに使用されるバージョンは次のとおりです。MySQL 5.7.16

効果：
指定されたポイントにすばやく復元します。つまり、ファイルbinlog全体を使用して、障害が発生する前の最後のファイルに復元しますposition。

--stop-positionの場合

たとえば、切り捨てやその他の操作など、特定の瞬間に間違ったSQLが実行された場合、この方法も使用できます。
ただし、指定された--start-position方法とは少し異なります。その後に1つ追加する
だけです。このオプションは、と同様に、実行の最終位置を制御するために使用されます。START SLAVE sql_threadUNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
SQL_Threadmysqlbinlog mysql-bin.n --stop-position=$log_pos

もちろん、この種のデータバックオフ操作では、flashback機能を備えたツールを検討することもできます。

パフォーマンスの比較

同じbinlogファイル増分のセットの場合：解析+インポート
までmysqlbinlogの時間は69minです。
そしてSQL_Thread、渡された実行時間はです41min。

また、インクリメントするbinlogファイルが大きいほど、効果が明確になります。

総括する

利点：
1）ブレークポイントで復元でき、進行状況を人為的に制御できます。たとえば、スレーブを停止したりエラーが発生したりすると、エラーの場所を知ることができます。
2）性能は比較的良好です。ビンログの数が多い場合は、リカバリ速度を上げることができます。
3）一部のバージョンでは、MTSを使用して増分速度を高速化し、回復を高速化する場合があります。
短所：
1）mysqldを閉じる必要があります。
2）手動実行プロセスは、mysqlbinlogメソッドよりも複雑です。

mysqlbinlog --start-positionこれはrelay.info、変更された3行目と同等です。
目的は、実行を開始する最初の行を指定することですposition。

mysqlbinlog --stop-position起動時SQL_Threadに指定するのとUNTIL RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos同じです。
目的は、実行を終了する最後のものを指定することですposition。

全文は終わりました。

MySQLをお楽しみください:)

QRコードをスキャンして、作成者のWeChatパブリックアカウントをフォローします

TeacherYeの「MySQLCoreOptimization」クラスがMySQL8.0にアップグレードされました。コードをスキャンして、MySQL8.0の練習の旅を始めてください。