GreatSQL通过伪装从库回放Binlog文件

GreatSQL通过伪装从库回放Binlog文件

一、适用场景说明

1、主库误操作恢复
利用 Binlog 在其他实例解析、回放，根据gtid只回放到指定位点。
2、网络隔离环境同步
备份恢复后可以拉去主库Binlog文件至新实例同步增量数据。
3、备份恢复遇到Binlog文件过大处理
恢复实例时有可能主库的 Binlog 超过限定大小，无法用mysqlbinlog工具恢复。

以上只是列举部分场景，而且恢复的方式也并非一种，本文讲解通过伪装从库的方式去回放所需的binlog。

二、测试环境实例信息

实例1192.168.138.239:3301实例2192.168.135.196:3302三、实例1生成测试数据

在实例1创建4个新库，用sysbench生成测试数据，每执行一次sysbench就刷新一下Binlog，生成多个Binlog文件。

1. 192.168.138.239:3301
2. create database wl_greatsql1;
3. create database wl_greatsql2;
4. create database wl_greatsql3;
5. create database wl_greatsql4;
7. sysbench ./src/lua/oltp_read_write.lua
8. --mysql-db=wl_greatsql1-4
9. --mysql-host=192.168.138.239
10. --mysql-port=3301
11. --mysql-user=greatsql
12. --mysql-password='QW12er#$'
13. --mysql-ignore-errors=all
14. --tables=5
15. --table_size=10000
16. --threads=10
17. --report-interval=2
18. --time=1800
19. prepare

复制代码

通过flush logs;命令生成多个Binlog文件。

1. -rw-r-----. 1 greatsql greatsql    9545477 Jun  4 17:53 binlog.000001
2. -rw-r-----. 1 greatsql greatsql    9544713 Jun  4 17:54 binlog.000002
3. -rw-r-----. 1 greatsql greatsql    9544713 Jun  4 17:54 binlog.000003
4. -rw-r-----. 1 greatsql greatsql    9544713 Jun  4 17:54 binlog.000004

复制代码

四、查看实例2状态

实例2的状态确保没有重复数据记录，做了reset master以及slave。

1. greatsql> SHOW MASTER STATUS\G
2. *************************** 1. row ***************************
3.              File: binlog.000001
4.          Position: 153
5.      Binlog_Do_DB:
6. Binlog_Ignore_DB:
7. Executed_Gtid_Set:
8. 1 row in set (0.00 sec)
10. greatsql> SHOW SLAVE STATUS\G
11. Empty set, 1 warning (0.00 sec)

复制代码

五、实例2伪装从库应用实例1binlog数据

1、处理实例2的slave信息

1. # reset slave;之后relaylog就被全清了变成以下样子
2. -rw-r----- 1 greatsql greatsql 177 Apr  4 02:32 relaylog.000001
3. -rw-r----- 1 greatsql greatsql  51 Apr  4 02:32 relaylog.index

复制代码

关于 RESET SLAVE  [ALL] 的操作说明：

1. RESET SLAVE
2. 会移除当前从库的复制状态信息。
3. 会删除所有和该从库关联的 relay log（中继日志）文件。
4. 会将与复制位点（例如 Master_Log_File、Read_Master_Log_Pos 等）相关的信息重置为空。
5. 不会清除通过 CHANGE MASTER TO 设置的复制连接参数（如主库地址、用户、密码等），在较新的 GreatSQL 版本中这些连接参数会保留。
7. RESET SLAVE ALL
8. 会执行与 RESET SLAVE 相同的操作（删除 relay log、重置复制状态）。
9. 此外，还会清空通过 CHANGE MASTER TO 配置的所有主库连接信息（主库地址、端口、用户、密码等），相当于是把复制相关的所有设置都恢复到初始默认状态。

复制代码

2、将实例1生成的binlog文件传输到实例2主机并修改名称

1. #拷贝到实例2。
2. binlog.000001  
3. binlog.000002  
4. binlog.000003  
5. binlog.000004  
7. #修改名称
8. mv binlog.000001 relaylog.000002
9. mv binlog.000002 relaylog.000003
10. mv binlog.000003 relaylog.000004
11. mv binlog.000004 relaylog.000005
14. #修改权限
15. chown -R greatsql:greatsql /greatsql/dbdata/log/

复制代码

3、修改实例2 relay-bin.index文件

1. # 修改实例2 index文件内容同上。
2. vi relaylog.index
4. # 新增
5. /greatsql/dbdata/log/relaylog.000002  
6. /greatsql/dbdata/log/relaylog.000003  
7. /greatsql/dbdata/log/relaylog.000004  
8. /greatsql/dbdata/log/relaylog.000005  

复制代码

4、实例2建立复制通道
说明：
只需要sql_thread即可应用relay log，io_thread并不用配置实际的信息。关键是在执行 CHANGE MASTER TO 操作时要指定 RELAY_LOG_FILE 和 RELAY_LOG_POS 的详细信息。

1. # 建立slave通道
2. 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

1. # 只启动sql线程
2. START SLAVE sql_thread;
4. # 如果想指定位点恢复可执行下面的命令，加上 SQL_AFTER_GTIDS 参数
5. START SLAVE sql_thread UNTIL SQL_AFTER_GTIDS = 'AAAAAAAA-0000-0000-0000-000000000000:XXX';

复制代码

6、查看实例2的复制通道

1. # 查看master信息
2. greatsql> SHOW MASTER STATUS\G
3. *************************** 1. row ***************************
4.              File: binlog.000001
5.          Position: 38179345
6.      Binlog_Do_DB:
7. Binlog_Ignore_DB:
8. Executed_Gtid_Set: 32ab2502-3492-11f0-891f-00163e7e5561:1-124
9. 1 row in set (0.00 sec)
11. # 查看slave信息
12. greatsql> SHOW SLAVE STATUS\G
13. *************************** 1. row ***************************
14.                Slave_IO_State:
15.                   Master_Host: source2.example.com
16.                   Master_User: repl
17.                   Master_Port: 3301
18.                 Connect_Retry: 60
19.               Master_Log_File:
20.           Read_Master_Log_Pos: 4
21.                Relay_Log_File: relaylog.000006
22.                 Relay_Log_Pos: 4
23.         Relay_Master_Log_File: binlog.000005
24.              Slave_IO_Running: No
25.             Slave_SQL_Running: Yes
26.               Replicate_Do_DB:
27.           Replicate_Ignore_DB:
28.            Replicate_Do_Table:
29.        Replicate_Ignore_Table:
30.       Replicate_Wild_Do_Table:
31.   Replicate_Wild_Ignore_Table:
32.                    Last_Errno: 0
33.                    Last_Error:
34.                  Skip_Counter: 0
35.           Exec_Master_Log_Pos: 4
36.               Relay_Log_Space: 153
37.               Until_Condition: None
38.                Until_Log_File:
39.                 Until_Log_Pos: 0
40.            Master_SSL_Allowed: No
41.            Master_SSL_CA_File:
42.            Master_SSL_CA_Path:
43.               Master_SSL_Cert:
44.             Master_SSL_Cipher:
45.                Master_SSL_Key:
46.         Seconds_Behind_Master: 0
47. Master_SSL_Verify_Server_Cert: No
48.                 Last_IO_Errno: 0
49.                 Last_IO_Error:
50.                Last_SQL_Errno: 0
51.                Last_SQL_Error:
52.   Replicate_Ignore_Server_Ids:
53.              Master_Server_Id: 0
54.                   Master_UUID:
55.              Master_Info_File: /greatsql/dbdata/data/master.info
56.                     SQL_Delay: 0
57.           SQL_Remaining_Delay: NULL
58.       Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
59.            Master_Retry_Count: 86400
60.                   Master_Bind:
61.       Last_IO_Error_Timestamp:
62.      Last_SQL_Error_Timestamp:
63.                Master_SSL_Crl:
64.            Master_SSL_Crlpath:
65.            Retrieved_Gtid_Set:
66.             Executed_Gtid_Set: 32ab2502-3492-11f0-891f-00163e7e5561:1-124
67.                 Auto_Position: 0
68.          Replicate_Rewrite_DB:
69.                  Channel_Name:
70.            Master_TLS_Version:
71.        Master_public_key_path:
72.         Get_master_public_key: 0
73.             Network_Namespace:
74. 1 row in set, 1 warning (0.00 sec)

复制代码

6、数据验证

1. greatsql> SHOW DATABASES;
2. +--------------------+
3. | Database           |
4. +--------------------+
5. | information_schema |
6. | mysql              |
7. | performance_schema |
8. | sys                |
9. | wl_greatsql1       |
10. | wl_greatsql2       |
11. | wl_greatsql3       |
12. | wl_greatsql4       |
13. +--------------------+
14. 8 rows in set (0.01 sec)
16. greatsql> USE wl_greatsql1
17. Reading table information for completion of table and column names
18. You can turn off this feature to get a quicker startup with -A
20. Database changed
21. greatsql> SHOW TABLES;
22. +------------------------+
23. | Tables_in_wl_greatsql1 |
24. +------------------------+
25. | sbtest1                |
26. | sbtest2                |
27. | sbtest3                |
28. | sbtest4                |
29. | sbtest5                |
30. +------------------------+
31. 5 rows in set (0.00 sec)
33. greatsql> SELECT COUNT(*) FROM sbtest1;
34. +----------+
35. | count(*) |
36. +----------+
37. |    10000 |
38. +----------+
39. 1 row in set (0.01 sec)

复制代码

六、操作风险

1、确认伪从库已有数据是否安全兼容回放操作

• 如果伪从库中本身已存在部分数据，必须提前核实与 Binlog 中即将回放的数据是否存在冲突，避免出现主键冲突、重复插入、逻辑错误等情况。
  
• 建议在回放前执行一次结构与关键数据校验，确保数据状态与预期一致。
  

2、主库误操作场景需精准识别回放的事务范围

• 若回放 Binlog 是为了修复主库误操作（如误删、误更新等），必须提前通过 mysqlbinlog 工具明确要回放的具体事务，避免出现“多执行”或“漏执行”。
  
• 回放应尽量以事务为单位分批控制，必要时使用 START SLAVE UNTIL 或 mysqlbinlog --stop-position 等方式精准切点。
  

3、严控伪从库的主从配置，避免误接入真实主库

• 伪装从库的核心在于模拟中继日志环境，不应真实接入主库。
  
• 配置 CHANGE MASTER TO 时，务必使用虚假地址或，防止误连主库造成非预期的主从同步或写入操作。
  

Enjoy GreatSQL
来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除