MySQL 5.7的多源复制

MySQL 5.7已经开始支持了多源复制,相信小伙们都很激动,MySQL 5.7之前只能实现一主一从、一主多从或者多主多从的复制,如果想实现多主一从的复制,只好使用MariaDB,但是MariaDB又与官方的MySQL版本不兼容的,在MySQL 5.7版本已经可以实现多主一从的复制了。MySQL 5.7版本相比之前的版本,无论在功能还是性能、安全等方面都已经提升了不少,值得大家去研究和使用。

MySQL 5.7版本之前的最常见的复制方式,一主一从或者一主多从的架构:

MySQL 5.7之后就可以实现多主一从的复制:

多主一从架构带来的好处(个人总结):

一、在从服务器进行数据汇总,如果我们的主服务器进行了分库分表的操作,为了实现后期的一些数据统计功能,往往需要把数据汇总在一起再统计。

二、如果我们想在从服务器时时对主服务器的数据进行备份,在MySQL 5.7之前每一个主服务器都需要一个从服务器,这样很容易造成资源浪费,同时也加大了DBA的维护成本,但MySQL 5.7引入多源复制,可以把多个主服务器的数据同步到一个从服务器进行备份。

下面演示一下在MySQL 5.7下搭建多主一从的过程:

实验环境:

Master_1: 192.168.10.128
Master_2: 192.168.10.129

Slave_3:  192.168.10.130

MySQL 5.7的搭建过程,我在这里就不作过多的演示,详细的搭建过程可以参考我之前写的博客:http://www.cnblogs.com/xuanzhi201111/p/5148113.html

一、分别在Master_1和Master_2上导出需要同步的数据库:

在Master_1:

[[email protected]_1 mysql]# mysqldump -uroot -p123456 --master-data=2 --single-transaction --databases  --add-drop-database  xuanzhi  >xuanzhi.sql

在Master_2:

[[email protected]_2 mysql]# mysqldump -uroot -p123456 --master-data=2 --single-transaction --databases  --add-drop-database  xuanzhi_2  >xuanzhi_2.sql

把分别把备份scp到Slave上:

[[email protected]_1 mysql]# scp -P22 xuanzhi.sql 192.168.10.130:/data/service/mysql/
[[email protected]_2 mysql]# scp -P22 xuanzhi_2.sql 192.168.10.130:/data/service/mysql/

二、在Master_1和Master_2上创建复制账号,这个操作跟MySQL 5.7之前版本一样:

在Master_1:

<Master_1>[(none)]> grant replication slave on *.* to ‘repl‘@‘192.168.10.130‘ identified by ‘123456‘;
Query OK, 0 rows affected, 1 warning (0.00 sec)

在Master_2:

<Master_2> [(none)]> grant replication slave on *.* to ‘repl‘@‘192.168.10.130‘ identified by ‘123456‘;
Query OK, 0 rows affected, 1 warning (0.02 sec)

三、分别Slave上把Master_1和Master_2的数据导入Slave服务器,在导入前先修改MySQL存储master-info和relay-info的方式,即从文件存储改为表存储,在my.cnf里添加以下选择:

master_info_repository=TABLE
relay_log_info_repository=TABLE

也可以在线修改,灰常方便:

<Slave> [(none)]> stop slave;
Query OK, 0 rows affected (0.02 sec)

<Slave> [(none)]> SET GLOBAL master_info_repository = ‘TABLE‘;
Query OK, 0 rows affected (0.00 sec)

<Slave> [(none)]> SET GLOBAL relay_log_info_repository = ‘TABLE‘;
Query OK, 0 rows affected (0.00 sec)

<Slave> [(none)]> 

更多的详细解析可以参考:http://dev.mysql.com/doc/refman/5.7/en/slave-logs.html

下面进行数据导入:

[[email protected] mysql]# mysql -uroot -p  <./xuanzhi.sql 
[[email protected] mysql]# mysql -uroot -p123456  <./xuanzhi_2.sql 

分别找出Master_1和Master_2的binlog位置和Pos位置:

[[email protected] mysql]# cat xuanzhi.sql |grep " CHANGE MASTER"
-- CHANGE MASTER TO MASTER_LOG_FILE=‘Master_1-bin.000001‘, MASTER_LOG_POS=1539;
[[email protected] mysql]# cat xuanzhi_2.sql |grep " CHANGE MASTER"
-- CHANGE MASTER TO MASTER_LOG_FILE=‘Master_2-bin.000003‘, MASTER_LOG_POS=630;
[[email protected] mysql]# 

四、登录Slave进行同步操作,分别change master到两台Master服务器,后面以FOR CHANNEL ‘CHANNEL_NAME‘区分

<Slave> [(none)]> CHANGE MASTER TO MASTER_HOST=‘192.168.10.128‘,MASTER_USER=‘repl‘, MASTER_PASSWORD=‘123456‘,MASTER_LOG_FILE=‘Master_1-bin.000001‘,MASTER_LOG_POS=1539 FOR CHANNEL ‘Master_1‘;
Query OK, 0 rows affected, 2 warnings (0.05 sec)

<Slave> [(none)]> CHANGE MASTER TO MASTER_HOST=‘192.168.10.129‘,MASTER_USER=‘repl‘, MASTER_PASSWORD=‘123456‘,MASTER_LOG_FILE=‘Master_2-bin.000003‘,MASTER_LOG_POS=630 FOR CHANNEL ‘Master_2‘;
Query OK, 0 rows affected, 2 warnings (0.04 sec)

进行启动slave操作,可以通过start slave的方式去启动所有的复制,也可以通过启动单个复制源的方式,下面进行单个复制源的启动进行演示(停止也是一样):

<Slave> [(none)]> start slave for CHANNEL  ‘Master_1‘;
Query OK, 0 rows affected (0.01 sec)

<Slave> [(none)]> start slave for CHANNEL  ‘Master_2‘;
Query OK, 0 rows affected (0.02 sec)

正常启动后,可以查看同步的状态:执行SHOW SLAVE STATUS FOR CHANNEL ‘channel_name‘\G

查看复制源Master_1的同步状态:

<Slave> [(none)]> SHOW SLAVE STATUS FOR CHANNEL ‘Master_1‘\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.128
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: Master_1-bin.000001
          Read_Master_Log_Pos: 1987
               Relay_Log_File: localhost-relay-bin-master_1.000002
                Relay_Log_Pos: 771
        Relay_Master_Log_File: Master_1-bin.000001
             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: 1987
              Relay_Log_Space: 991
              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: 100128
                  Master_UUID: 44b653d4-8843-11e5-b97e-000c29dfaaf7
             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:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: master_1
           Master_TLS_Version:
1 row in set (0.00 sec)

查看复制源Master_2的同步状态:

<Slave> [(none)]> SHOW SLAVE STATUS FOR CHANNEL ‘Master_2‘\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.129
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: Master_2-bin.000003
          Read_Master_Log_Pos: 1078
               Relay_Log_File: localhost-relay-bin-master_2.000002
                Relay_Log_Pos: 771
        Relay_Master_Log_File: Master_2-bin.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: 1078
              Relay_Log_Space: 991
              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: 100129
                  Master_UUID: 583f5433-43ef-11e5-8958-000c29d5bdfa
             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:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: master_2
           Master_TLS_Version:
1 row in set (0.00 sec)

也可以通过查看performance_schema相关的表查看同步状态,执行命令:SELECT * FROM performance_schema.replication_connection_status; 监控复制状态。

+--------------+------------+--------------------------------------+-----------+---------------+---------------------------+--------------------------+--------------------------+-------------------+--------------------+----------------------+
| CHANNEL_NAME | GROUP_NAME | SOURCE_UUID                          | THREAD_ID | SERVICE_STATE | COUNT_RECEIVED_HEARTBEATS | LAST_HEARTBEAT_TIMESTAMP | RECEIVED_TRANSACTION_SET | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
+--------------+------------+--------------------------------------+-----------+---------------+---------------------------+--------------------------+--------------------------+-------------------+--------------------+----------------------+
| master_1     |            | 44b653d4-8843-11e5-b97e-000c29dfaaf7 |        34 | ON            |                       184 | 2015-08-14 08:06:10      |                          |                 0 |                    | 0000-00-00 00:00:00  |
| master_2     |            | 583f5433-43ef-11e5-8958-000c29d5bdfa |        36 | ON            |                       183 | 2015-08-14 08:06:24      |                          |                 0 |                    | 0000-00-00 00:00:00  |
+--------------+------------+--------------------------------------+-----------+---------------+---------------------------+--------------------------+--------------------------+-------------------+--------------------+----------------------+
2 rows in set (0.00 sec)

<Slave> [(none)]> 

五、验证数据是否同步

在Master_1上插入两条数据:

<Master_1>[xuanzhi]> insert into tb1(name)  values (‘user1‘),(‘user2‘);
Query OK, 2 rows affected (0.01 sec)

在Master_2上插入两条数据:

<Master_2> [xuanzhi_2]> insert into tb2(name) values (‘user3‘),(‘user4‘);
Query OK, 2 rows affected (0.04 sec)

回到Slave上查看数据是否正常把数据同步过来了:

<Slave> [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| xuanzhi            |
| xuanzhi_2          |
+--------------------+
6 rows in set (0.03 sec)

<Slave> [(none)]> select * from xuanzhi.tb1;
+----+-------+
| id | name  |
+----+-------+
|  1 | user1 |
|  2 | user2 |
+----+-------+
2 rows in set (0.00 sec)

<Slave> [(none)]> select * from xuanzhi_2.tb2;
+----+-------+
| id | name  |
+----+-------+
|  1 | user3 |
|  2 | user4 |
+----+-------+
2 rows in set (0.00 sec)

成功的实现了多主一从的环境搭建,*。*

总结:

     一、MySQL 5.7的多源复制,能有效的解决分库分表的数据统计问题,同时也可以实现在一台从服务器对多台主服务器的数据备份。

     二、MySQL 5.7的多源复制的出现,我们就不需要使用MariaDB 的多主一从的架构了,让很多小伙伴又看到了新的希望。

参考资料:

http://dev.mysql.com/doc/refman/5.7/en/change-master-to.html
http://www.longlong.asia/2015/10/21/mysql57-new-features.html


作者:陆炫志

出处:xuanzhi的博客 http://www.cnblogs.com/xuanzhi201111

您的支持是对博主最大的鼓励,感谢您的认真阅读。本文版权归作者所有,欢迎转载,但请保留该声明。

时间: 2024-11-08 20:08:03

MySQL 5.7的多源复制的相关文章

MySQL 5.7.9多源复制报错修复

版本:5.7.9 用5.7.9的版本搭建MySQL多源复制测试环境 开发说复制出现问题,上去看了一下: mysql> show slave status\G*************************** 1. row ***************************               Slave_IO_State: Waiting for master to send event                  Master_Host: 182.2.2.11     

mysql 5.7.16多源复制

转 http://www.cnblogs.com/yangliheng/p/6094151.html 演示一下在MySQL下搭建多主一从的过程. 实验环境: 192.168.24.129:3306 192.168.24.129:3307 192.168.24.129:3308 主库操作 导出数据 分别在3306和3307上导出需要的数据库. 3306: 登录数据库: [[email protected] 3306]# mysql -uroot -poldboy123 -S /tmp/mysql3

Mycat读写分离以及拆库拆表综合实验1:主从复制与多源复制

数据规划: Haproxy 集群 haproxy01 node127 192.168.31.127 haproxy02 node128 192.168.31.128 Mycat集群 mycat01 node119 192.168.31.119 mycat02 node118 192.168.31.118 MySQL主从复制集群 mysqlm1 node115 192.168.31.115 mysqlm2 node116 192.168.31.116 mysqls1 node117 192.168

基于GTID的MySQL多源复制配置

多源复制的意义 1.可以在一个从库上对多个服务器的数据库进行汇总,或者对一个数据库的分库分表进行汇总. 2.集约使用从库服务器的硬件资源,毕竟弱一个数据库业务量较小确占用整个服务器资源是不经济的. 3.更方便的对个业务库进行数据备份,优化数据库备份脚本编写逻辑 拓补图 实施步骤 1.备份主库上的数据,考虑到gtid的问题建议只采用mysqldump程序进行备份 centos:#mysqldump --login-path=3306 \ #mysql官方工具都支持login-path快速登录   

mysql 多源复制

mysql5.7新特性多源复制很实用,方便对分库环境进行汇总,集中备份和数据统计分析. 我的实验环境3台机器,mysql版本:5.7.16 10.10.203.102 从库 10.10.203.93 主库 10.10.203.94 主库 操作步骤: (1)当一个从库是多源复制结构,那么master_info和relay_log_info不能用file方式来存储,必须使用table,它不支持file. 10.10.203.102 从库上操作 在配置文件中新增: [mysqld] master_in

MySQL多源复制搭建

1.1     实验概要 1.1.1  实验假设 本实验假设已经完成操作系统和MySQL安装部署. 1.1.2  实验目的 MySQL5.7的多源复制技术搭建部署,然后简单测试. 1.1.3  环境信息 操作系统 MySQL版本 服务器地址 服务器角色 Centos7 5.7.18 192.168.102.23 source 1 Centos7 5.7.18 192.168.102.24 source 2 Centos7 5.7.18 192.168.102.25 target 1.1.4  实

mysql第四篇文章~关于mysql的多源复制

一 场景需求 多源复制版本 5.7,目标主机5.6.21 4个DB机器的某些数据库需要数据汇总进行连表查询 二 进行搭建  1 导出相应的目的库     mysqldump -uuser -ppassword --master-data=2 --single-transaction --databases --add-drop-database dbname >dbname.sql  2 将相应的目的库导入到多源复制机器上     注意 5.6版本 需要先删除第一行,否则无法导入.     my

mysql多源复制详解

大家应该知道,mysql比起其他数据库,最大的特色是就是主从复制,不过5.7之前的版本最多就只支持一主多从的复制方式,对于一些统计类的需求,就需要跨库,这是比较麻烦的事情,以往只能交由数据库中间件(mycat等)去做这种事情,还有备份操作,也只能一个个库的用脚本去轮询或并发备份,不可谓不费时费力.然后,多源复制的概念出来了. 多源复制的概念最早是mariadb社区提出的,后来mysql官方积极引入到5.7的版本中来(5.6最新版也是没有这个功能的),percona就不说了,也是随后推出.这个功能

mysql 5.7 多源复制 原创

my.cnf要加两个参数才可以在GTID多源复制 master-info-repository=TABLE relay-log-info-repository=TABLE server1 连到 slave1 mysql> change master to master_host='10.24.220.70',master_user='repl',master_password='123',master_port=3306,master_auto_position=1 for channel 's