MySQL 5.7 多主一丛同步的数据库配置（将多处数据源合并到一点）

工作需要，笔记之用。文章很长，倒一杯茶慢慢看。

数据库的应用场景颇多，如 数据库双机同步，一主多从，多主多从，多主一从等；下文记录多主一从的配置及测试。

大多数复制场景中是一主或者一主多从。这种拓扑用于高可用性场景，读写分离。主机负责写入数据，丛集负责读数据，横向扩展读取程序。但是，多主一从是写入多个数据库实例，最后合并成一个结果。

多主一从使得从机从各主机同步接收业务信息（transactions），这样可以一部服务器为多个主机服务器备份，合并数据表，联合数据。（无去重）

　　　　

MySQL 版本：5.7.10

配置机器：两主一从

1，从机配置，保证从机的仓库都存在一个表；

[mysqld]
master-info-repository=TABLE
relay-log-info-repository=TABLE

确保无误后，可以检查一下，如下显示则配置正常：

mysql> SHOW VARIABLES LIKE ‘%repository%‘;
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| master_info_repository | TABLE |
| relay_log_info_repository | TABLE |
+---------------------------+-------+
2 rows in set (0.00 sec)

接下来修改 server_id ，这里用了ip的后三位：

[mysqld]
server-id=141

输入下面代码可以捡测：

mysql> SHOW VARIABLES WHERE VARIABLE_NAME = ‘server_id‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 141 |
+---------------+-------+
1 row in set (0.00 sec)　　

注意：MySQL 5.7 安装后，请在错误日志里面去找密码，如下：

# grep root error.log
2015-12-09T05:34:01.639797Z 1 [Note] A temporary password is generated for [email protected]: T<e-hd0cgI!d　　

接下来你肯定需要用到这个密码，所以最好修改一下，示例改为了“password”：

ALTER USER ‘root‘@‘localhost‘ IDENTIFIED BY ‘password‘;</font>

　　

多主一从最关键的工作就是保证在你的两（或多）个源数据里面不要有相同的主键，特别是当你在用AUTO_INCREMENT 这一列时，如果有两个一样的主键可以想象同步到从机时数据就会紊乱。这里有一个可替代的方法作为参考。在配置时最好关掉GTID，不然在mysql initialize 初始化时会遇到一个问题，并且这些记录会被复制到从机上去。假设你最开始启动了GTID，配置完成后，然后你试图在从机上复制。当你检查主机的状态时（输入 SHOW MASTER STATUS）， 你会看到这样的结果，主机上138个执行记录，现在会被复制到从机上：

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 1286
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 73fdfd2a-9e36-11e5-8592-00a64151d129:1-138
1 row in set (0.00 sec)

而在从机上 SHOW SLAVE STATUS 你会看到一些错误：

Last_Error: Error ‘Can‘t create database ‘mysql‘; database exists‘ on query. Default database: ‘mysql‘. Query: ‘CREATE DATABASE mysql;

以及 RETRIEVED GTID SET  会显示 已取回138个记录复制到了从机：

mysql> SHOW SLAVE STATUS\G
...
Retrieved_Gtid_Set: 73fdfd2a-9e36-11e5-8592-00a64151d129:1-138
..　　

当然，如果配置完成前关掉了GTID那就不会有这些错误了。

三台机器配置完成之后，输入 SHOW MASTER STATUS 显示如下：

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000002
Position: 398
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

到此，整个架构已经创建，下面进行一些测试。如图，创建一个漫画收藏数据库：

从机

CREATE DATABASE `comicbookdb`;
use comicbookdb;
CREATE TABLE `comics` (
`comic_id` int(9) NOT NULL AUTO_INCREMENT,
`comic_title` varchar(60) NOT NULL,
`issue_number` decimal(9,0) NOT NULL,
`pub_year` varchar(60) NOT NULL,
`pub_month` varchar(60) NOT NULL,
PRIMARY KEY (`comic_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1;　　

在主机和从机上都可以运行同样的SQL 语句。（因为在主机的一些列上我们用了AUTO_INCREMENT ，你可能觉得从机上就不用AUTO_INCREMENT 了。但是因为我们不会对从机做任何写入操作，所以你仍旧可以运行同样的语句，之后再去修改主键。后文会有详述。）

当数据从多个主机复制合并到一个从机时，复制程序将会处理 AUTO_INCREMENT 的问题。

下面在从机上创建表时对于comic_id 列时，没有声明 AUTO_INCREMENT出现了错误，

mysql> SHOW SLAVE STATUS\G...
Last_SQL_Error: Error ‘Field ‘comic_id‘ doesn‘t have a default value‘ on query. Default database: ‘comicbookdb‘. Query: ‘INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘5‘,‘2014‘,‘03‘)‘
...

为了处理comic_id的主键问题，最方便的方法就是在主机中配置 auto_increment_increment ，在my.cnf  或者是my.ini 中：

[mysqld]
auto_increment_increment = 2　　

加这个变量需要重启mysql服务，但是你也可以直接在命令行操作，如下：

mysql> SET @@auto_increment_increment=2;
Query OK, 0 rows affected (0.00 sec)

验证一下：

mysql> SHOW VARIABLES WHERE VARIABLES_NAME = ‘auto_increment_increment‘;
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| auto_increment_increment | 2 |
+-----------------------------+-------+
1 row in set (0.00 sec)　　

如上 每个主键的增量就是2，只要每个主机的初始值不同就可以了。但不可以简单的设 0 或 1，因为如果是0的话，它会默认恢复到1，这样会引起冲突。所以我们设一个较大的值，最低位设置为 0 和 1，代码如下：

主机 # 1

CREATE DATABASE `comicbookdb`;
use comicbookdb;
CREATE TABLE `comics` (
`comic_id` int(9) NOT NULL AUTO_INCREMENT,
`comic_title` varchar(60) NOT NULL,
`issue_number` decimal(9,0) NOT NULL,
`pub_year` varchar(60) NOT NULL,
`pub_month` varchar(60) NOT NULL,
PRIMARY KEY (`comic_id`)
) ENGINE=InnoDB AUTO_INCREMENT=100000;

主机 # 2

CREATE DATABASE `comicbookdb`;
use comicbookdb;
CREATE TABLE `comics` (
`comic_id` int(9) NOT NULL AUTO_INCREMENT,
`comic_title` varchar(60) NOT NULL,
`issue_number` decimal(9,0) NOT NULL,
`pub_year` varchar(60) NOT NULL,
`pub_month` varchar(60) NOT NULL,
PRIMARY KEY (`comic_id`)
) ENGINE=InnoDB AUTO_INCREMENT=100001;

建表完毕，在所有主机上启动 GTID。这里从机也启动了GTID， 以防之后在这部从机之下加另一台从机。启动GTID，需要修改配置：

[mysqld]
auto_increment_increment = 2
gtid-mode = on
enforce-gtid-consistency = 1

重启每个server之后，可以检查一下每一台主机状态，状态一致：

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000005
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

接下来对所有的主从都做了一个服务器重置（reset master），非必要。重置会清空所有的binnary log ，并且新建一个二值日志。

mysql> RESET MASTER;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 154
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)　

可以见到新的 binary log（mysql-bin.000001），开始位置是154.  我们往主机插入一些数据，然后再看看主机状态。

主机 #1

mysql> INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘1‘,‘2014‘,‘01‘);
Query OK, 1 row affected (0.02 sec)

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 574
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1
1 row in set (0.00 sec)

可见 插入的 GTID 是 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1 ，冒号前面部分是主机的UUID，这个信息可以在data目录下的auto.cnf里面查到。

主机 #1

# cat auto.cnf
[auto]
server-uuid=63a7971c-b48c-11e5-87cf-f7b6a723ba3d　　

再插入一行数据：

主机 #1

mysql> INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘2‘,‘2014‘,‘02‘);
Query OK, 1 row affected (0.05 sec)

mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 994
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1-2
1 row in set (0.00 sec)

mysql> select * from comics;
+----------+-------------+--------------+----------+-----------+
| comic_id | comic_title | issue_number | pub_year | pub_month |
+----------+-------------+--------------+----------+-----------+
| 100001 | Fly Man | 1 | 2014 | 01 |
| 100003 | Fly Man | 2 | 2014 | 02 |
+----------+-------------+--------------+----------+-----------+
2 rows in set (0.00 sec)　　

会发现这个数值变成了2，那么我们再在第二号主机插入两行数据，并且查看状态：

主机 #2

mysql> INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘3‘,‘2014‘,‘03‘);
mysql> INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘4‘,‘2014‘,‘04‘);

mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000005
Position: 974
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 75e2e1dc-b48e-11e5-83bb-1438deb0d51e:1-2
1 row in set (0.00 sec)

mysql> select * from comics;
+----------+-------------+--------------+----------+-----------+
| comic_id | comic_title | issue_number | pub_year | pub_month |
+----------+-------------+--------------+----------+-----------+
| 100002 | Fly Man | 3 | 2014 | 03 |
| 100004 | Fly Man | 4 | 2014 | 04 |
+----------+-------------+--------------+----------+-----------+
2 rows in set (0.00 sec)　　

主机#2有不同的UUID, 这也是我们分辨GTID对应于哪一步主机。那我们现在已经有两组GTID的会复制到从机上。当然，从机也有自己的UUID.

主机#1 跟主机#2的GTID设置：

63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1-2
75e2e1dc-b48e-11e5-83bb-1438deb0d51e:1-2

　　

在此，通常我会确认下从机是没有运行的：

从机

mysql> show slave status\G
Empty set (0.00 sec)　　

不同于平时的复制，在多主复制中，你需要为每一台主机创建一个通道，为这个通道命名。这里称之为 “master-142”（主机-142）和 “master-143”（主机143）去匹配server_id（就像IP一样）。接下来就演示如何开启主机#1(server_id=142)的数据复制。

从机

mysql> CHANGE MASTER TO MASTER_HOST=‘192.168.1.142‘, MASTER_USER=‘replicate‘, MASTER_PASSWORD=‘password‘, MASTER_AUTO_POSITION = 1 FOR CHANNEL ‘master-142‘;
Query OK, 0 rows affected, 2 warnings (0.23 sec)

这里有两个警告，可以忽略。

mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Note
Code: 1759
Message: Sending passwords in plain text without SSL/TLS is extremely insecure.
*************************** 2. row ***************************
Level: Note
Code: 1760
Message: Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the ‘START SLAVE Syntax‘ in the MySQL Manual for more information.
2 rows in set (0.00 sec)　　

现在我们可以开启从机通道“master-142”：

mysql> START SLAVE FOR CHANNEL ‘master-142‘;
Query OK, 0 rows affected (0.03 sec)　　

这个命令同时启动了SQL_THREAD 跟 IO_THREAD。将来你会考虑停止一个或者多个线程，所以这里对应有一些语法，如何指定一个需要修改的通道：

START SLAVE SQL_THREAD FOR CHANNEL ‘master-142‘;
START SLAVE IO_THREAD FOR CHANNEL ‘master-142‘;　　

也可以发一个简单的命令“START SLAVE” 为需要执行复制操作的通道来开启这两个线程。从机启动，可以见到GTID被取出并且开始写入数据库。

mysql> SHOW SLAVE STATUS FOR CHANNEL ‘master-142‘\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.142
...
Master_UUID: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d
...
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
...
Retrieved_Gtid_Set: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1-2
Executed_Gtid_Set: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1-2
Auto_Position: 1
...
Channel_Name: master-142

检查从机，可以见到相关数据：　　

mysql> select * from comics;
+----------+-------------+--------------+----------+-----------+
| comic_id | comic_title | issue_number | pub_year | pub_month |
+----------+-------------+--------------+----------+-----------+
| 100001 | Fly Man | 1 | 2014 | 01 |
| 100003 | Fly Man | 2 | 2014 | 02 |
+----------+-------------+--------------+----------+-----------+
2 rows in set (0.00 sec)

主机#1 完成之后，我们开始配置主机#2：

CHANGE MASTER TO MASTER_HOST=‘192.168.1.143‘, MASTER_USER=‘replicate‘, MASTER_PASSWORD=‘password‘, MASTER_AUTO_POSITION = 1 FOR CHANNEL ‘master-143‘;　　

然后再次确认从机状态：

从机

mysql> SHOW SLAVE STATUS FOR CHANNEL ‘master-143‘\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.143
...
Master_UUID: 75e2e1dc-b48e-11e5-83bb-1438deb0d51e
...
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
...
Retrieved_Gtid_Set: 75e2e1dc-b48e-11e5-83bb-1438deb0d51e:1-2
Executed_Gtid_Set: 63a7971c-b48c-11e5-87cf-f7b6a723ba3d:1-2,
75e2e1dc-b48e-11e5-83bb-1438deb0d51e:1-2,
Auto_Position: 1
...
Channel_Name: master-143　　

我们可以见到从机已经获取到两个GTID，并且已经在执行。再看看数据库表的内容，也能够发现四行数据都已经合并到了从机：

mysql> select * from comics;
+----------+-------------+--------------+----------+-----------+
| comic_id | comic_title | issue_number | pub_year | pub_month |
+----------+-------------+--------------+----------+-----------+
| 100001 | Fly Man | 1 | 2014 | 01 |
| 100002 | Fly Man | 3 | 2014 | 03 |
| 100003 | Fly Man | 2 | 2014 | 02 |
| 100004 | Fly Man | 4 | 2014 | 04 |
+----------+-------------+--------------+----------+-----------+
4 rows in set (0.01 sec)　　

复制过程处理了自增 AUTO_INCREMENT 的值。如果检查一下sql语句执行复制的原话，你会有所发现：

INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘1‘,‘2014‘,‘01‘)
INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘2‘,‘2014‘,‘02‘);
INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘3‘,‘2014‘,‘03‘);
INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘4‘,‘2014‘,‘04‘);　　

在主机上生成的自增值会随着声明传递给从机。检查主机上的binary log， 来到comic_id 这一列 “SET INSERT_ID = 100001”，整段会随着sql语句一起传给从机；

从机

# mysqlbinlog mysql-bin.000001
...
# at 349
#160106 21:08:01 server id 142 end_log_pos 349 CRC32 0x48fb16a2 Intvar
SET INSERT_ID=100001/*!*/;
#160106 21:08:01 server id 142 end_log_pos 543 CRC32 0xbaf55210 Query thread_id=1exec_time=0 error_code=0
use `comicbookdb`/*!*/;
SET TIMESTAMP=1452132481/*!*/;
INSERT INTO COMICS (comic_title, issue_number, pub_year, pub_month) VALUES(‘Fly Man‘,‘1‘,‘2014‘,‘01‘)
/*!*/;
...

整个讲解完毕，请大家多多指教。

参考：

1，MySQL 5.7 Multi-Source Replication – Automatically Combining Data From Multiple Databases Into One

https://mysqlhighavailability.com/mysql-5-7-multi-source-replication-automatically-combining-data-from-multiple-databases-into-one/

2， MySQL Multi-Source Replication Overview

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

原文地址：https://www.cnblogs.com/nengka/p/SQL-MultiSource-Replication.html

时间： 2024-10-19 03:01:52

MySQL 5.7 多主一丛同步的数据库配置（将多处数据源合并到一点）的相关文章

mysql性能优化学习笔记（6）数据库配置优化&amp;硬件优化

一.操作系统配置优化:          1. 网络方面,修改/etc/sysctl.conf文件,增加tcp支持的队列数,减少断开连接时,资源的回收.          2. 打开文件数的限制.修改/etc/security/limits.conf文件,增加一下内容以修改打开文件数量的限制.          3. 关闭iptables,selinux等防火墙软件. 二.系统配置优化     innodb_buffer_pool_size——建议为总内存的75%     innodb_buff

mysql主从复制（一主一从）

MySQL之间数据复制的基础是二进制日志文件(binary log file).一台MySQL数据库一旦启用二进制日志后,其作为master,它的数据库中所有操作都会以"事件"的方式记录在二进制日志中,其他数据库作为slave通过一个I/O线程与主服务器保持通信,并监控master的二进制日志文件的变化,如果发现master二进制日志文件发生变化,则会把变化复制到自己的中继日志中,然后slave的一个SQL线程会把相关的"事件"执行到自己的数据库中,以此实现从数据库

MySQL多主一从同步

MySQL多主一从同步 实验准备:主机A和主机B作为主,其IP地址分别为192.168.131.129和192.168.131.130,主机C作为从服务器,在从服务器上面配置MySQL多实例,其IP地址为192.168.131.136,三台服务器均关闭防火墙和SELINUX,MySQL版本为5.6.26,为通用二进制包 主机A和主机B主服务器MySQL通用二进制包安装和初始化 # tar xf mysql-5.6.26-linux-glibc2.5-x86_64.tar.gz # mv mysq

MySQL主从同步(复制)的配置

1.主从复制的原理: *Master,记录数据更改操作 - 启用binlog记录模式 - 允许Slave读取binlog日志 *Slave运行2个同步线程 - Slave_IO:负责连接Master,复制其binlog日志文件到本机的relay-log文件 - Slave_SQL:执行本机relay-log文件里的SQL语句,重现Master的数据操作 2.基本构建思路: 1)初始化现有库:将主库导入从库,确保数据一致性 2)配置Master,主服务器:调整运行参数,授权一个同步用户 3)配置S

mysqld_multi实现多主一从同步

首先确保mysql为5.5左右,太旧的版本,方法可能存在差异. 1.利用mysql_install_db生成数据库 mysql_install_db --datadir=/var/lib/mysql2 --user=mysql mysql_install_db --datadir=/var/lib/mysql3 --user=mysql 2.生成配置文件 mysqld_multi --example 3.修改配置文件:my.cnf [mysqld_multi] mysqld= /usr/bin/

Mysql主从同步原理及配置-Linux

从库的io线程会实时依据master.info信息的去主库的binlog日志里面读取更新的内容,将更新的内容取回到自己的中继日志中,同时会更新master.info信息,此时sql线程实时会从中继日志中读取并执行里面的sql语句 Master :记录数据更改操作 – 启用 binlog 日志 – 设置 binlog 日志格式 – 设置 server_id Slave 运行 2 个线程 – Slave_IO :复制 master 主机 binlog 日志文件里的 SQL 到本机的 relay-lo

MySQL主从复制指定不同库表同步参数说明

replication 中通过以下参数减少binlog数据量 master端: --binlog-do-db 二进制日志记录的数据库(多数据库用逗号,隔开) --binlog-ignore-db 二进制日志中忽略数据库 (多数据库用逗号,隔开) 以下是mysql主从忽略授权表的方法案例: in master: binlog-do-db=YYY 需要同步的数据库.不添加这行表示同步所有 binlog-ignore-db = mysql   这是不记录binlog,来达到从库不同步mysql库,以确

趁一切还来得及【六】数据库MySQL读写分离与主主同步

相思相见知何日?此时此夜难为情.                                                      --[唐]李白 第一章 数据库MySQL主从复制读写分离授权 1.1 主从复制读写分离方案简单分析 ①数据库主从复制搭建之后,因为数据是单向的,因此默认规则就是所有的数据(主从相关收据)写入和更新都在主库上进行操作,避免主从同步的时候造成冲突. ②严格上来讲,从库上的非同步的库写入数据,只要和主库没有关系,也是可以写入的(或者作为主库),但是如果主从都想其中

Innobackup mysql 多实例环境搭建主从同步

Innobackup mysql 多实例环境搭建主从同步 该实验是在mysql多实例环境下做的:如果需要部署 mysql 多实例环境,则移步: mysql 多实例案例实战: http://blog.csdn.net/wanglei_storage/article/details/49305239 mysql 的主从搭建大家有很多种方式,传统的 mysqldump 方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用 Xtrabackup 可以快速轻松的构建 mysql 主从架构