基于 gtid 的延迟同步

  • 选择一个 pxc 节点作为主节点，挂上一个 replication 从节点（磁盘结构也要保持一致，避免表空间的路径问题）
    • 从节点配置延迟同步
    • 一旦发现主节点出现误删除操作，只要在延迟同步期间，从节点跳过主节点误删除sql的gtid，然后快速同步一次主节点的数据，此时从节点就是没有执行过误删除 sql 的完整数据
    • 利用从节点的数据，恢复主节点的数据即可
  • 缺点是，误删除操作发生后，没有及时的处理，导致从库同步了误删除的数据
    • 不过可以配合日志闪回方案

配置主从同步

配置文件

  • 主节点开启 binlog
  • 主从节点开启 server_id
  • 主节点配置同步账号(reload、super、replication slave 权限)
  • 从节点开启 relay_log
  • 主从节点的配置文件开启 mysql 数据库的 GTID
    1. gtid_mode=ON
    2. enforce_gtid_consistency=1

设置从库延时同步

  • 一般要设置久一点 ```sql stop slave;

— 设置复制延迟时间，单位 s change master to master_delay=300;

start slave;

— 查看状态 show slave status;

  2. ---
  4. <a name="SvxVf"></a>
  5. ## 从节点跳过误删除操作
  6. <a name="hLyCK"></a>
  7. ### 主节点查找误删除的 sql 的 gtid
  8. > 
  9. > show master logs; # 看 binlog 日志列表
  10. > 
  11. > show binlog events in  "log-bin.0000xxx";  # 看 binlog 日志
  13. - 找到误删除的 sql 的 gtid
  15. <a name="z9aKm"></a>
  16. ### 从节点跳过误删除的 sql 执行
  17. > 
  18. > 
  20. ```sql
  21. stop slave;
  23. set gtid_next="<误删除sql的gtid>";
  25. -- 跳过误删除的 sql 的gtid
  26. begin;commit;
  28. set gtid_next="automatic";
  30. -- 及时同步
  31. change master to master_delay=0;
  33. start slave;

有时间再设置回延迟同步

主节点恢复数据

  • 停止 pxc 集群的业务操作
  • 导出上面跳过误删除操作的从节点的数据，在主节点上创建临时库，导入数据
  • 把主节点上业务表重命名
  • 然后把临时库的业务表迁移到业务表中