GreatSQL借助模拟从库来重放Binlog文件

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.000001
             Position: 153
         Binlog_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. 传输并修改binlog文件名称

#拷贝到实例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. 修改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. 建立复制通道

# 建立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. 查看复制通道状态

# 查看master信息
greatsql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
                 File: binlog.000001
             Position: 38179345
         Binlog_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.com
                      Master_User: repl
                      Master_Port: 3301
                    Connect_Retry: 60
                  Master_Log_File:
              Read_Master_Log_Pos: 4
                   Relay_Log_File: relaylog.000006
                    Relay_Log_Pos: 4
            Relay_Master_Log_File: binlog.000005
                 Slave_IO_Running: No
                Slave_SQL_Running: Yes
                  Replicate_Do_DB:
              Replicate_Ignore_DB:
               Replicate_Do_Table:
           Replicate_Ignore_Table:
          Replicate_Wild_Do_Table:
      Replicate_Wild_Ignore_Table:
                       Last_Errno: 0
                       Last_Error:
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 4
                  Relay_Log_Space: 153
                  Until_Condition: None
                   Until_Log_File:
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_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: No
                    Last_IO_Errno: 0
                    Last_IO_Error:
                   Last_SQL_Errno: 0
                   Last_SQL_Error:
      Replicate_Ignore_Server_Ids:
                 Master_Server_Id: 0
                      Master_UUID:
                 Master_Info_File: /greatsql/dbdata/data/master.info
                        SQL_Delay: 0
              SQL_Remaining_Delay: NULL
          Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates
               Master_Retry_Count: 86400
                      Master_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-124
                    Auto_Position: 0
             Replicate_Rewrite_DB:
                     Channel_Name:
               Master_TLS_Version:
           Master_public_key_path:
            Get_master_public_key: 0
                Network_Namespace:
    1 row in set, 1 warning (0.00 sec)

7. 数据验证

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 -A

Database 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 UNTILmysqlbinlog --stop-position 等方式精准切点。

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

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

Enjoy GreatSQL 😃

关于 GreatSQL

GreatSQL是面向金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可作为MySQL或Percona Server的可选替代,应用于线上生产环境,且完全免费并兼容MySQL或Percona Server。

相关链接: GreatSQL社区
Gitee
GitHub
Bilibili

GreatSQL社区

社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html

技术交流群

微信:扫码添加GreatSQL社区助手微信好友,发送验证信息加群

版权声明:程序员胖胖胖虎阿 发表于 2025年8月6日 上午2:24。
转载请注明:GreatSQL借助模拟从库来重放Binlog文件 | 胖虎的工具箱-编程导航

相关文章

暂无评论

暂无评论...