GreatSQL通過偽裝從庫回放Binlog文件
一、適用場景說明
1、主庫誤操作恢復
利用 Binlog 在其他實例解析、回放，根據gtid只回放到指定位點。
2、網絡隔離環境同步
備份恢復后可以拉去主庫Binlog文件至新實例同步增量數據。
3、備份恢復遇到Binlog文件過大處理
恢復實例時有可能主庫的 Binlog 超過限定大小，無法用mysqlbinlog工具恢復。
以上只是列舉部分場景，而且恢復的方式也并非一種，本文講解通過偽裝從庫的方式去回放所需的binlog。
二、測試環境實例信息
| 實例1 | 192.168.138.239:3301 |
|---|---|
| 實例2 | 192.168.135.196:3302 |
三、實例1生成測試數據
在實例1創建4個新庫，用sysbench生成測試數據，每執行一次sysbench就刷新一下Binlog，生成多個Binlog文件。
192.168.138.239:3301
create database wl_greatsql1;
create database wl_greatsql2;
create database wl_greatsql3;
create database wl_greatsql4;sysbench ./src/lua/oltp_read_write.lua
--mysql-db=wl_greatsql1-4
--mysql-host=192.168.138.239
--mysql-port=3301
--mysql-user=greatsql
--mysql-password='QW12er#$'
--mysql-ignore-errors=all
--tables=5
--table_size=10000
--threads=10
--report-interval=2
--time=1800
prepare
通過flush logs;命令生成多個Binlog文件。
-rw-r-----. 1 greatsql greatsql 9545477 Jun 4 17:53 binlog.000001
-rw-r-----. 1 greatsql greatsql 9544713 Jun 4 17:54 binlog.000002
-rw-r-----. 1 greatsql greatsql 9544713 Jun 4 17:54 binlog.000003
-rw-r-----. 1 greatsql greatsql 9544713 Jun 4 17:54 binlog.000004
四、查看實例2狀態
實例2的狀態確保沒有重復數據記錄，做了reset master以及slave。
greatsql> SHOW MASTER STATUS\G
*************************** 1. row ***************************File: binlog.000001Position: 153Binlog_Do_DB:Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)greatsql> SHOW SLAVE STATUS\G
Empty set, 1 warning (0.00 sec)
五、實例2偽裝從庫應用實例1binlog數據
1、處理實例2的slave信息
# reset slave;之后relaylog就被全清了變成以下樣子
-rw-r----- 1 greatsql greatsql 177 Apr 4 02:32 relaylog.000001
-rw-r----- 1 greatsql greatsql 51 Apr 4 02:32 relaylog.index
關于 RESET SLAVE [ALL] 的操作說明：
RESET SLAVE
會移除當前從庫的復制狀態信息。
會刪除所有和該從庫關聯的 relay log（中繼日志）文件。
會將與復制位點（例如 Master_Log_File、Read_Master_Log_Pos 等）相關的信息重置為空。
不會清除通過 CHANGE MASTER TO 設置的復制連接參數（如主庫地址、用戶、密碼等），在較新的 GreatSQL 版本中這些連接參數會保留。RESET SLAVE ALL
會執行與 RESET SLAVE 相同的操作（刪除 relay log、重置復制狀態）。
此外，還會清空通過 CHANGE MASTER TO 配置的所有主庫連接信息（主庫地址、端口、用戶、密碼等），相當于是把復制相關的所有設置都恢復到初始默認狀態。
2、將實例1生成的binlog文件傳輸到實例2主機并修改名稱
#拷貝到實例2。
binlog.000001
binlog.000002
binlog.000003
binlog.000004 #修改名稱
mv binlog.000001 relaylog.000002
mv binlog.000002 relaylog.000003
mv binlog.000003 relaylog.000004
mv binlog.000004 relaylog.000005#修改權限
chown -R greatsql:greatsql /greatsql/dbdata/log/
3、修改實例2 relay-bin.index文件
# 修改實例2 index文件內容同上。
vi relaylog.index# 新增
/greatsql/dbdata/log/relaylog.000002
/greatsql/dbdata/log/relaylog.000003
/greatsql/dbdata/log/relaylog.000004
/greatsql/dbdata/log/relaylog.000005
4、實例2建立復制通道
說明：
只需要sql_thread即可應用relay log，io_thread并不用配置實際的信息。關鍵是在執行 CHANGE MASTER TO 操作時要指定 RELAY_LOG_FILE 和 RELAY_LOG_POS 的詳細信息。
# 建立slave通道
CHANGE MASTER TO MASTER_HOST='source2.example.com', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_PORT=3301, Relay_Log_File='relaylog.000001', Relay_Log_POS=4;
5、啟動sql_thread
# 只啟動sql線程
START SLAVE sql_thread;# 如果想指定位點恢復可執行下面的命令，加上 SQL_AFTER_GTIDS 參數
START SLAVE sql_thread UNTIL SQL_AFTER_GTIDS = 'AAAAAAAA-0000-0000-0000-000000000000:XXX';
6、查看實例2的復制通道
# 查看master信息
greatsql> SHOW MASTER STATUS\G
*************************** 1. row ***************************File: binlog.000001Position: 38179345Binlog_Do_DB:Binlog_Ignore_DB:
Executed_Gtid_Set: 32ab2502-3492-11f0-891f-00163e7e5561:1-124
1 row in set (0.00 sec)# 查看slave信息
greatsql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************Slave_IO_State:Master_Host: source2.example.comMaster_User: replMaster_Port: 3301Connect_Retry: 60Master_Log_File:Read_Master_Log_Pos: 4Relay_Log_File: relaylog.000006Relay_Log_Pos: 4Relay_Master_Log_File: binlog.000005Slave_IO_Running: NoSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 4Relay_Log_Space: 153Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 0Master_UUID:Master_Info_File: /greatsql/dbdata/data/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Replica has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set: 32ab2502-3492-11f0-891f-00163e7e5561:1-124Auto_Position: 0Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:Master_public_key_path:Get_master_public_key: 0Network_Namespace:
1 row in set, 1 warning (0.00 sec)
6、數據驗證
greatsql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| wl_greatsql1 |
| wl_greatsql2 |
| wl_greatsql3 |
| wl_greatsql4 |
+--------------------+
8 rows in set (0.01 sec)greatsql> USE wl_greatsql1
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -ADatabase changed
greatsql> SHOW TABLES;
+------------------------+
| Tables_in_wl_greatsql1 |
+------------------------+
| sbtest1 |
| sbtest2 |
| sbtest3 |
| sbtest4 |
| sbtest5 |
+------------------------+
5 rows in set (0.00 sec)greatsql> SELECT COUNT(*) FROM sbtest1;
+----------+
| count(*) |
+----------+
| 10000 |
+----------+
1 row in set (0.01 sec)
六、操作風險
1、確認偽從庫已有數據是否安全兼容回放操作
- 如果偽從庫中本身已存在部分數據，必須提前核實與 Binlog 中即將回放的數據是否存在沖突，避免出現主鍵沖突、重復插入、邏輯錯誤等情況。
- 建議在回放前執行一次結構與關鍵數據校驗，確保數據狀態與預期一致。
2、主庫誤操作場景需精準識別回放的事務范圍
- 若回放 Binlog 是為了修復主庫誤操作（如誤刪、誤更新等），必須提前通過
mysqlbinlog工具明確要回放的具體事務，避免出現“多執行”或“漏執行”。 - 回放應盡量以事務為單位分批控制，必要時使用
START SLAVE UNTIL或mysqlbinlog --stop-position等方式精準切點。
3、嚴控偽從庫的主從配置，避免誤接入真實主庫
- 偽裝從庫的核心在于模擬中繼日志環境，不應真實接入主庫。
- 配置
CHANGE MASTER TO時，務必使用虛假地址或，防止誤連主庫造成非預期的主從同步或寫入操作。
