• 欢迎访问DBA的辛酸事儿,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站
  • 欢迎大家关注博主公众号:DBA的辛酸事儿
  • 博文中若有错误的地方,请大家指正,大家的指正是我前进的动力

深入理解MySQL多源复制(一)

MySQL SEian.G 2个月前 (02-28) 153次浏览 已收录 0个评论
文章目录[隐藏]

本文主要讲解MySQL多源复制相关内容,包括搭建一个简单的多源复制环境;

一、概述

MySQL多源复制使副本能够并行接收来自多个数据源的事务。在多源复制拓扑中,副本应该为每个数据源创建一个复制通道。多源复制拓扑中的一个从服务器上最多可以创建256个通道。每个复制通道必须具有唯一的(非空)名称;

多源复制可以满足的场景:

(1)将多个服务器备份到单个服务器。

(2)合并表碎片。

(3)将数据从多个服务器整合到单个服务器。

在应用事务时,多源复制不会实现任何冲突检测或解决方案,并且如果需要,这些任务将留给应用程序。

注意

多源复制的从库上的每个通道必须从不同的源复制。不能设置从单个Master到单个Slave源的多个复制通道。这是因为server_id在复制拓扑中必须唯一。源仅通过server_id来区分Master,而不通过复制通道的名称来区分,因此它无法识别来自同一Master的不同复制通道

通过将slave_parallel_workers系统变量设置为大于0的值,也可以将多源副本设置为多线程副本。在多源副本上执行此操作时,副本上的每个通道均具有指定数量的应用程序线程,再加上一个协调器线程来管理它们。不能为单个通道配置应用程序线程数。

从MySQL 8.0开始,可以在特定的复制通道上使用复制过滤器配置多源副本。当多个源上存在相同的数据库或表时,可以使用通道特定的复制筛选器。对于基于GTID的复制,如果同一事务可能来自多个源,则必须确保所有通道上的过滤设置都相同。

测试环境:

主库:

10.30.124.187:6306 Master1

10.30.124.187:6307 Master2

从库:

10.30.124.187:6308 Slave

二、配置多源复制

多源复制拓扑至少需要配置两个源和一个副本。我们假设有两个源source1和source2,以及一个复制主机。复制副本从每个源复制一个数据库,从source1复制db1,从source2复制db2。

多源复制拓扑中的源可以配置为使用基于GTID的复制或基于二进制日志和偏移量的复制。推荐使用基于GTID的复制方式方式

多源复制拓扑中的副本需要用于副本的连接元数据存储库和applier元数据存储库的表存储库,这是MySQL 8.0中的默认值。多源复制与不推荐使用的备用文件存储库不兼容。

首先备份Master1 和Master2上的数据库,备份的时候,仅仅只备份了需要进行数据同步的数据库,并未进行全部备份,而做多源复制中,也需要这样做,否则做第一个复制还好,配置后面的复制的时候,会出现复制失败的情况;

mysqldump -udba_admin -p -h127.0.0.1 -P6306  --single-transaction --master-data=2 --set-gtid-purged=OFF --triggers  --routines --events  --databases datax_conf_db metdb >  /tmp/datax_conf_db_metdb.sql

mysqldump -udba_admin -p -h127.0.0.1 -P6307  --single-transaction --master-data=2 --set-gtid-purged=OFF --triggers  --routines --events  --databases jjlive_spider ads_schedular >  /tmp/ads_schedular_jjlive_spider.sql

在Slave上恢复恢复相关的数据库

mysql -u dba_admin -p -h 127.0.0.1 -P6308 <  /tmp/datax_conf_db_metdb.sql
mysql -u dba_admin -p -h 127.0.0.1 -P6308 <  /tmp/ads_schedular_jjlive_spider.sql

三、基于GTID的复制配置多源副本

如果多源复制拓扑中的源具有现有数据,则可以节省时间在开始复制之前为副本提供相关数据。在多源复制拓扑中,无法使用数据目录的克隆或复制为副本提供来自所有源的数据,并且可能还希望仅复制来自每个源的特定数据库。因此,提供这种副本的最佳策略是使用mysqldump在每个源上创建一个转储文件,然后使用mysql客户端在副本上导入转储文件。

如果使用基于GTID的复制,则需要注意mysqldump放在转储输出中的SET @@GLOBAL.gtid_purged声明。该语句将在源上执行的事务的GTID传输到副本,副本则需要此信息。但是,对于比从一个源配置一个新的空副本更为复杂的情况,需要检查该语句在该副本使用的MySQL版本中具有什么作用,并相应地处理该语句。

与MySQL 5.6和5.7相比SET @@GLOBAL.gtid_purged,mysqldump编写的语句的行为在MySQL 8.0版本中有所不同。在MySQL 5.6和5.7中,该语句替换gtid_purged副本上的值,并且在发行版中,仅当副本中具有GTID(gtid_executed集合)的事务记录为空时,才能更改该值。因此,在多源复制拓扑中,必须删除SET @@GLOBAL.gtid_purged在导入转储文件之前,否则不能应用包含此语句的第二个或后续转储文件。还要注意,对于MySQL 5.6和5.7,此限制意味着来自源的所有转储文件必须在具有空gtid_executed集的副本上一次操作中应用。可以通过RESET MASTER在副本上发布副本来清除副本的GTID执行历史记录。

对于MySQL 8.0.17以上开始,作为删除该SET @@GLOBAL.gtid_purged语句的替代方法,可以将mysqldump的–set-gtid-purged选项设置COMMENTED为包括该语句但被注释掉,以便在加载转储文件时不起作用。如果使用来自同一源的两个部分转储来配置副本,并且在第二个转储中设置的GTID与第一个相同,则可以设置mysqldump输出第二个转储文件时的–set-gtid-purged选项OFF,以忽略该语句。

ads_schedular_jjlive_spider.sql文件中的GTID相关信息

--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
6b7f2891-5c90-11eb-b9a5-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393066,
e308e300-a63c-11ea-ae39-005056b71124:1-2';

datax_conf_db_metdb.sql文件中的GTID相关信息

--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
b012f5ec-5c8f-11eb-94e2-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393036,
e308e300-a63c-11ea-ae39-005056b71124:1-2';

副本中需要执行的GTID集合如下:

SET @@GLOBAL.GTID_PURGED='0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
6b7f2891-5c90-11eb-b9a5-005056b7a90a:1-38,
b012f5ec-5c8f-11eb-94e2-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393066,
e308e300-a63c-11ea-ae39-005056b71124:1-2';

下面我们来建立与两台MYSQL的主从复制

在Master1和Master2上创建repl账户:

CREATE USER 'repl'@'10.30.124.%' IDENTIFIED WITH  'mysql_native_password' BY 'XXXXXX';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO  'repl'@'10.30.124.%' ;

在Slave上配置主从复制关系

mysql> RESET MASTER;
mysql>
SET @@GLOBAL.GTID_PURGED='0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
6b7f2891-5c90-11eb-b9a5-005056b7a90a:1-38,
b012f5ec-5c8f-11eb-94e2-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393066,
e308e300-a63c-11ea-ae39-005056b71124:1-2';

配置复制关系

mysql> CHANGE MASTER TO MASTER_HOST='10.30.124.187',  MASTER_USER='repl', MASTER_PORT=6306,  MASTER_PASSWORD='XXXXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL  'M_10.30.124.187_6306';

mysql> CHANGE MASTER TO MASTER_HOST='10.30.124.187',  MASTER_USER='repl', MASTER_PORT=6307,  MASTER_PASSWORD='XXXXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL  'M_10.30.124.187_6307';

也可以配置复制通道过滤,本文测试中没有配置复制过滤,配置过滤内容放到下面一篇文章中进行讲解

mysql> CHANGE REPLICATION FILTER  REPLICATE_DO_DB=(datax_conf_db,metdb) for channel  'm_10.30.124.187_6306';
mysql> CHANGE REPLICATION FILTER  REPLICATE_DO_DB=(ads_schedular,jjlive_spider) for channel  'm_10.30.124.187_6307';  

四、启动多源副本

为所有复制源添加通道后,发出一条START REPLICA | SLAVE语句以开始复制。在副本上启用多个通道后,可以选择启动所有通道,也可以选择一个特定的通道来启动。例如,要分别启动两个通道,使用mysql客户端发出以下语句:

mysql> START SLAVE FOR CHANNEL "M_10.30.124.187_6306";
mysql> START SLAVE FOR CHANNEL "M_10.30.124.187_6307";
Or from MySQL 8.0.22:
mysql> START REPLICA FOR CHANNEL "M_10.30.124.187_6306";
mysql> START REPLICA FOR CHANNEL "M_10.30.124.187_6307";

要验证两个通道均已启动并正常运行,可以SHOW REPLICA | SLAVE STATUS在副本上发出 语句,例如:

mysql> SHOW SLAVE STATUS FOR CHANNEL "M_10.30.124.187_6306"\G
mysql> SHOW SLAVE STATUS FOR CHANNEL "M_10.30.124.187_6307"\G
Or from MySQL 8.0.22:
mysql> SHOW REPLICA STATUS FOR CHANNEL "M_10.30.124.187_6306"\G
mysql> SHOW REPLICA STATUS FOR CHANNEL "M_10.30.124.187_6307"\G

查看复制状态

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.187
                  Master_User: datax_repl
                  Master_Port: 6306
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000003
          Read_Master_Log_Pos: 765
               Relay_Log_File:  slave-relay-bin-m_10@002e30@002e124@002e187_6306.000002
                Relay_Log_Pos: 413
        Relay_Master_Log_File: mysqlbin.000003
             Slave_IO_Running: Yes
            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: 765
              Relay_Log_Space: 654
              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: 311
                  Master_UUID: b012f5ec-5c8f-11eb-94e2-005056b7a90a
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave 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:  0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
6b7f2891-5c90-11eb-b9a5-005056b7a90a:1-38,
b012f5ec-5c8f-11eb-94e2-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393066,
e308e300-a63c-11ea-ae39-005056b71124:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name: m_10.30.124.187_6306
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
*************************** 2. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.124.187
                  Master_User: datax_repl
                  Master_Port: 6307
                Connect_Retry: 60
              Master_Log_File: mysqlbin.000003
          Read_Master_Log_Pos: 765
               Relay_Log_File:  slave-relay-bin-m_10@002e30@002e124@002e187_6307.000002
                Relay_Log_Pos: 413
        Relay_Master_Log_File: mysqlbin.000003
             Slave_IO_Running: Yes
            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: 765
              Relay_Log_Space: 654
              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: 311
                  Master_UUID: 6b7f2891-5c90-11eb-b9a5-005056b7a90a
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave 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:  0008c013-afb2-11ea-9fa9-005056b7a90a:1-4,
1f7133df-aa0b-11e9-af7d-005056b7a90a:1-8158244:8158247-8199883,
6b7f2891-5c90-11eb-b9a5-005056b7a90a:1-38,
b012f5ec-5c8f-11eb-94e2-005056b7a90a:1-38,
bca9ac2e-aa0a-11e9-ac0c-005056b71124:1-11393066,
e308e300-a63c-11ea-ae39-005056b71124:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name: m_10.30.124.187_6307
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
2 rows in set (0.00 sec)

五、停止多源副本

该STOP REPLICA | SLAVE语句可用于停止多源副本。默认情况下,如果STOP REPLICA | SLAVE在多源副本上使用该语句,则所有通道都将停止。(可选)使用该子句仅停止特定的频道。

要停止所有当前配置的复制通道:

mysql> STOP SLAVE;
Or from MySQL 8.0.22:
mysql> STOP REPLICA;

要仅停止命名通道,请使用子句:FOR CHANNEL channel

mysql> STOP SLAVE FOR CHANNEL "M_10.30.124.187_6306";
Or from MySQL 8.0.22:
mysql> STOP REPLICA FOR CHANNEL "M_10.30.124.187_6306";

六、重置多源副本

该RESET REPLICA | SLAVE语句可用于重置多源副本。默认情况下,如果RESET REPLICA | SLAVE在多源副本上使用该语句,则会重置所有通道。(可选)使用该子句仅重置特定通道。

重置所有当前配置的复制通道:

mysql> RESET SLAVE;
Or from MySQL 8.0.22:
mysql> RESET REPLICA;

要仅重命名频道,请使用子句:FOR CHANNEL channel

mysql> RESET SLAVE FOR CHANNEL "M_10.30.124.187_6306";
Or from MySQL 8.0.22:
mysql> RESET REPLICA FOR CHANNEL "M_10.30.124.187_6306";

对于基于GTID的复制,请注意,RESET REPLICA | SLAVE不会影响副本的GTID执行历史记录。如果要清除此问题RESET MASTER,请在副本上发出 。

RESET REPLICA | SLAVE使副本忘记其复制位置,并清除中继日志,但它不会更改任何复制连接参数(例如源主机名)或复制过滤器。如果要删除这些频道,请发出RESET REPLICA | SLAVE ALL。

七、监视多源复制

要监视复制通道的状态,存在以下选项:
使用复制性能架构表。这些表的第一列是Channel_Name。可以根据Channel_Name键编写复杂的查询。

SHOW REPLICA | SLAVE STATUS FOR CHANNELchannel

在 performance_schema 库中,提供了复制相关的一些视图,可供查看复制相关的信息。

USE performance_schema;
select * from replication_applier_configuration;
select * from replication_applier_status;
select * from replication_applier_status_by_coordinator;
select * from replication_applier_status_by_worker;
select * from replication_connection_configuration;
select * from replication_connection_status;

参考链接

https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html

深入理解MySQL多源复制(一)


如果您觉得本站对你有帮助,那么可以收藏和推荐本站,帮助本站更好地发展,在此谢过各位网友的支持。
转载请注明原文链接:深入理解MySQL多源复制(一)
喜欢 (1)
SEian.G
关于作者:
用心去记录工作,用心去感受生活,用心去学着成长;座右铭:苦练七十二变,笑对八十一难
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址