1. Toy模板网首页
  2. > Toy博客

GreatSQL一个关于主从复制的限制描述与规避

4月前 作者：GreatSQL 分类：Toy博客 阅读(27) 违法举报

这篇具有很好参考价值的文章主要介绍了GreatSQL一个关于主从复制的限制描述与规避。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、背景

分享一个在项目运维中遇到的一个主从复制限制的一个坑，项目的架构为主集群+灾备集群，每个集群为一主两从模式。主集群到灾备集群的同步为主从复制的方式，根据业务需求灾备集群需要忽略系统库跟某些配置表，所以才会触发此限制，而这个限制如果我们之前没有遇到过，那么排查起来也是相对不易的。

二、限制描述

1、主从同步出现报错

greatsql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.xxx.xxx
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: greatsql-bin.000990
          Read_Master_Log_Pos: 92274290
               Relay_Log_File: greatsql-relay.002963     -----
                Relay_Log_Pos: 701548899
        Relay_Master_Log_File: greatsql-bin.000988
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table: A.ab,B.bc
                   Last_Errno: 1146
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 701548690
              Relay_Log_Space: 2246320360
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1146
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1943306
                  Master_UUID: 9e668a93-2618-11ee-93ee-bc16954181bb
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 230822 14:14:18
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 9e668a93-2618-11ee-93ee-bc16954181bb:2-47565802
            Executed_Gtid_Set: 30873cfe-8750-11ed-b56f-744aa4073024:1-270,
9e668a93-2618-11ee-93ee-bc16954181bb:1-47508256
                Auto_Position: 1
         Replicate_Rewrite_DB:  
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

根据slave status状态信息可以看出

  • 报错的GTID为：'9e668a93-2618-11ee-93ee-bc16954181bb:47508257'
  • 应用的主集群的binlog为：greatsql-bin.000988
  • 灾备集群的relay log为：greatsql-relay.002963

详细信息查看performance_schema.replication_applier_status_by_worker表

2、查看错误的详细信息

greatsql> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
         CHANNEL_NAME:
            WORKER_ID: 1
            THREAD_ID: NULL
        SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: 9e668a93-2618-11ee-93ee-bc16954181bb:47508257
    LAST_ERROR_NUMBER: 1146
   LAST_ERROR_MESSAGE: Worker 1 failed executing transaction
'9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988,
end_log_pos 701570116; Error executing row event: 'Table 'abs_xxx.tmp_xxx_info' doesn't exist'
LAST_ERROR_TIMESTAMP: 2023-08-22 14:14:18

上述信息说明根据performance_schema.replication_applier_status_by_worker表中的详细错误信息可以发现为灾备集群abs_xxx.tmp_xxx_info表不存在，导致同步报错

3、问题分析

3.1、确认灾备集群中目标表是否存在

greatsql> show create table abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist
greatsql> desc abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist

结论：灾备集群中目标表的确不存在

3.2、根据主从报错信息解析主集群binlog，报错的SQL

解析主集群binlog

SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47508257'/*!*/;
……
#230822 14:14:18 server id 1943306  end_log_pos 701570000         Table_map: `abs_xxx`.`tmp_xxx_info` mapped to number 1595
# at 701570000
#230822 14:14:18 server id 1943306  end_log_pos 701570116         Write_rows: table id 1595 flags: STMT_END_F
### INSERT INTO `abs_xxx`.`tmp_xxx_info`
### SET
###   @1=2
###   @2='自动化'
###   @3='2300121212120000'
###   @4='90000000'
###   @5='1'
###   @6='202001290231001'
###   @7='2021-01-31 00:00:00'
# at 701570116
#230822 14:14:18 server id 1943306  end_log_pos 701570143         Xid = 800998400
COMMIT/*!*/;
# at 701570143
#230822 14:14:18 server id 1943306  end_log_pos 701570204         GTID        last_committed=26491        sequence_number=26521        rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

结论：根据复制的报错信息得知具体的GTID号以及主集群的binlog文件，解析binlog得知此事务为一条INSERT语句，语句中的目标表与performance_schema.replication_applier_status_by_worker表中信息一致

3.3、寻找主集群目标表binlog中是否有建表语句

在同一binlog日志中寻找建表语句

SET TIMESTAMP=1692684495/*!*/;
CREATE DATABASE IF NOT EXISTS `abs_xxx` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */
/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
  `ID` int(64) NOT NULL AUTO_INCREMENT,
  `CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `END_DATE` datetime DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
  KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864451

结论：在主集群的binlog日志中找到了目标表的建表语句，说明主集群执行DDL时并没有关闭binlog日志，那么继续查看在灾备集群的中继日志中是否存在DDL语句

3.4、解析灾备集群的中继日志，确认是否拉取到灾备集群

#230822 14:08:15 server id 1943306  end_log_pos 475863662         GTID        last_committed=16341        sequence_number=16342        rbr_only=no
SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47498079'/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
  `ID` int(64) NOT NULL AUTO_INCREMENT,
  `CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `END_DATE` datetime DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
  KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864660
#230822 14:08:15 server id 1943306  end_log_pos 475864512         GTID        last_committed=16342        sequence_number=16343        rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

结论：灾备集群的中继日志中存在DDL建表语句，说明并不是IO线程出了问题

3.5、排查复制配置的忽略库表

Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
Replicate_Wild_Ignore_Table: A.ab,B.bc

结论：忽略库表中并不包含目标表，但是根据以上解析日志发现，在主集群binlog日志中建表语句之前有个use information_schema/!/; 的语句，此库为同步忽略的系统库，因此触发了GreatSQL的规范限制，在忽略库下对未忽略进行操作Statement模式下记录语句默认不起作用 （详情：https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#option_mysqld_replicate-do-db）

4、解决同步报错

在灾备集群创建目标表

greatsql> CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
  `ID` int(64) NOT NULL AUTO_INCREMENT,
  `CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
  `AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
  `END_DATE` datetime DEFAULT NULL,
  PRIMARY KEY (`ID`),
  KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
  KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC;

greatsql> stop slave;
greatsql> start slave;

结论：在灾备集群创建目标表后重启复制恢复成功

三、限制规避

1、第一种规避方式

执行DDL时进入目标库

greatsql> use abs_cust
greatsql> DDL 语句（CREATE\DROP\ALTER）

说明：在应用连接数据库时有可能默认就是information_schema库，而此环境将系统库全部忽略，所以为了规避类似的问题，请在执行SQL语句时请先use到目标表的目标库。

2、第二种规避方式

修改主从复制配置，以下步骤为测试环境

关闭灾备集群在复制同步

greatsql> stop slave;
Query OK, 0 rows affected, 1 warning (0.03 sec)

修改忽略库

greatsql> change replication filter Replicate_Ignore_DB=();

修改忽略表

greatsql> change replication filter replicate_wild_ignore_table =('mysql.%','information_schema.%','sys.%','performance_schema.%');

启动同步

greatsql> start slave;
Query OK, 0 rows affected, 1 warning (0.37 sec)

测试验证

主集群：

greatsql> use mysql
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> create table test111.test111(id int primary key);
Query OK, 0 rows affected (0.06 sec)

greatsql> show tables;
+-------------------+
| Tables_in_test111 |
+-------------------+
| test111           |
+-------------------+
1 row in set (0.00 sec)

灾备集群：

greatsql> use test111
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_test111 |
+-------------------+
| test111           |
+-------------------+
1 row in set (0.00 sec)

说明：复制配置中参数Replicate_Ignore_DB设置为空，将replicate_wild_ignore_table参数设置为shema_name.%的方式也可以规避类似的问题

四、特别说明

  • 在MySQL 5.7跟8.0版本也存在此限制

Enjoy GreatSQL 😃

关于 GreatSQL

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

相关链接： GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区：

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

GreatSQL一个关于主从复制的限制描述与规避

技术交流群：

微信：扫码添加GreatSQL社区助手微信好友，发送验证信息加群。

GreatSQL一个关于主从复制的限制描述与规避文章来源地址https://www.toymoban.com/news/detail-710167.html

到了这里，关于GreatSQL一个关于主从复制的限制描述与规避的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • Redis最新版本搭建主从环境，Redis主从复制环境搭建

    Redis最新版本搭建主从环境，Redis主从复制环境搭建

    一般网站搭建都会使用Redis做缓存，当单台Redis承受不住压力时，会考虑搭建Redis主从。在没有业务的情况下，一般不会一下子上来就去搭建Redis无中心集群 Redis主从复制环境搭建 ，前面跟部署单台Redis一致，只不过后面 是从Redis的配置上去同步主Redis即可 。 这里找三台虚拟机

    2024年01月21日
    浏览(27)

  • redis复制和分区：主从复制、哨兵模式和集群模式

    在 Redis 中，复制和分区是用于数据冗余和性能扩展的关键特性。以下是主从复制、哨兵模式和集群模式的工作原理的简要概述： 主从复制 (Replication) 基本概念 ：Redis 的主从复制功能允许多个 Redis 服务器具有相同的数据副本。这在读取操作的负载均衡、数据备份、灾难恢复等

    2024年01月20日
    浏览(33)
  • MySQL主从复制详解

    MySQL主从复制详解

    随着业务流量的增长，一台MySQL数据库服务器已经满足不了需求了，会负载过重，容易出现宕机的情况，导致数据的丢失。这个时候就需要实现数据库的负载均衡和读写分离，来减少单台MySQL数据库服务器的压力。我们可以通过使用MySQL内置的复制功能来搭建MySQL一主一从或一

    2024年02月10日
    浏览(29)
  • Redis 主从复制 哨兵 集群

    Redis 主从复制 哨兵 集群

    主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能

    2024年02月11日
    浏览(36)

  • 【Redis】Redis主从复制

    主从复制， master 以写为主， slave 以读为主。 当 master 数据变化的时候，自动将新的数据异步同步到其他 slave 数据库。 读写分类 容灾备份 数据备份 水平扩容支持高并发 环境要求 ：一个 Master ，两个 Slave ——3台虚拟机，每台都安装 redis 主机 master 配置 将redis压缩包中原装

    2024年02月01日
    浏览(28)
  • Redis主从复制部署小结

    Redis主从复制部署小结

    搭建主从架构 单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。 全量同步 主从第一次建立连接时，会执行 全量同步 ，将master节点的所有数据都拷贝给slave节点，流程： 这里有一个问题，master如何得知salve是第一次来连

    2024年02月05日
    浏览(58)
  • MySQL主从复制案例实现

    MySQL主从复制案例实现

    使用Sharding-JDBC实现读写分离： 1、导入maven坐标 2、 在配置文件中配置读写分离规则 3、在配置文件中配置允许bean定义覆盖配置项 可以看到已经实现了读写分离了。

    2024年02月03日
    浏览(50)

  • 简单搭建MySQL主从复制

    个人认为，90%的公司的数据体量和并发量压根用不上从服务器，结合Redis，一台性能强劲的云MySQL服务器，做好日常备份。足够了。 一个MySQL主（Master）服务器上的数据自动复制到至少一个的MySQL从（Slave）服务器的过程，利用bin log，主服务器上的数据更改会被自动地同步到从

    2024年03月09日
    浏览(41)
  • Docker mysql 主从复制

    Docker mysql 主从复制

    目录 介绍：为什么需要进行mysql的主从复制 主从复制原理： ✨主从环境搭建 主从一般面试问题： 介绍：为什么需要进行mysql的主从复制 在实际的生产中，为了解决Mysql的单点故障已经提高MySQL的整体服务性能，一般都会采用 「主从复制」 。 比如：在复杂的业务系统中，有

    2024年01月17日
    浏览(30)

  • MySQL主从复制环境部署

    通过将MySQL的某一台主机（master）的数据复制到其他主机（slaves）上，并重新执行一遍来执行 复制的这一过程叫做主从复制。 通过主从复制可以实现后续的读写分离，部署高可用架构等打下基础。 在进行同步前，最好使两边数据库内容保持一致、版本号尽量一致、操作系统

    2024年02月15日
    浏览(31)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包