mysql集群--双主双从

喜欢ヅ旅行 2022-06-17 12:30 340阅读 0赞

1、结构如下：

![20180211102911927][]

4台机器：

master1：192.168.66.11

slave1：   192.168.66.12

master2：192.168.66.17

slave2：    192.168.66.18

注意，如果你是虚拟机复制的，得改下mysql/data下的auto.cnf，删除该文件重启机器即可，两台机器的uuid不能相同。

安装参考上一篇文章：[点击打开链接][Link 1]

2、MySQL5.6 开始主从复制有两种方式：基于日志（binlog）、基于 GTID（全局事务标示符）。  
(1) Master将数据改变记录到二进制日志(binary log)中；  
(2) Slave 通过 I/O 线程读取 Master 中的 binary log events 并写入到它的中继日志(relay log)；

(3) Slave 重做中继日志中的事件，把中继日志中的事件信息一条一条的在本地执行一次，完成数据在本地的存储，从而实现将改变反映到它自己的数据(数据重放)。

3、原理介绍完了，实现起来也特别简单，这里用slave1同步master1举例

（slave2复制master2，两个master互备都是一样的）

3.1   修改配置文件，让slave1使用此用户同步master1

master1:

vi  /etc/my.cnf

\#\# 设置 server\_id，一般设置为 IP  
server\_id=11  
\#\# 复制过滤：不需要备份的数据库，不输出（mysql 库一般不同步）  
binlog-ignore-db=mysql  
\#\# 开启二进制日志功能，可以随便取，最好有含义  
log-bin=master1-bin  
\#\# 为每个 session 分配的内存，在事务过程中用来存储二进制日志的缓存  
binlog\_cache\_size=1M  
\#\# 主从复制的格式（mixed,statement,row，默认格式是 statement）  
binlog\_format=mixed  
\#\# 二进制日志自动删除/过期的天数。默认值为 0，表示不自动删除。  
expire\_logs\_days=7  
\#\# 跳过主从复制中遇到的所有错误或指定类型的错误，避免 slave 端复制中断。  
\#\# 如：1062 错误是指一些主键重复，1032 错误是因为主从数据库数据不一致  
slave\_skip\_errors=1062

重启： service mysql restart

slave1:

vi  /etc/my.cnf

\#\# 设置 server\_id，一般设置为 IP  
server\_id=12  
\#\#复制过滤：不需要备份的数据库，不输出（mysql 库一般不同步）  
binlog-ignore-db=mysql  
\#\# 为每个 session 分配的内存，在事务过程中用来存储二进制日志的缓存  
binlog\_cache\_size = 1M  
\#\# 主从复制的格式（mixed,statement,row，默认格式是 statement）  
binlog\_format=mixed  
\#\# 二进制日志自动删除/过期的天数。默认值为 0，表示不自动删除。  
expire\_logs\_days=7  
\#\# 跳过主从复制中遇到的所有错误或指定类型的错误，避免 slave 端复制中断。  
\#\# 如：1062 错误是指一些主键重复，1032 错误是因为主从数据库数据不一致  
slave\_skip\_errors=1062  
\#\# relay\_log 配置中继日志  
relay\_log=cpmaster1-bin  
\#\# log\_slave\_updates 表示 slave 将复制事件写进自己的二进制日志  
log\_slave\_updates=1  
\#\# 防止改变数据(除了特殊的线程)

read\_only=1

重启： service mysql restart

3.2   master1为slave1创建代理用户

\#\#  mysql -uroot -p  
 \#\#创建数据同步用户，并授予相应的权限  
mysql> grant replication slave, replication client on \*.\* to 'cpmaster1'@'192.168.66.12' identified by '123456';  
Query OK, 0 rows affected (0.00 sec)  
\#\# 刷新授权表信息  
mysql> flush privileges;  
Query OK, 0 rows affected (0.00 sec)  
\#\# 查看 position 号，记下 position 号（从机上需要用到这个 position 号和现在的日志文件)  
mysql> show master status;

3.3   slave1使用此代理用户同步master1开启同步

\#\#  mysql -uroot -p  
mysql> change master to master\_host='192.168.66.11', master\_user='cpmaster1', master\_password='123456', master\_port=3306, master\_log\_file='master1-bin.000001', master\_log\_pos=1389, master\_connect\_retry=30;  
Query OK, 0 rows affected, 2 warnings (0.01 sec)  
上面执行的命令的解释：  
master\_host='192.168.66.11' \#\# Master1 的 IP 地址  
master\_user='cpmaster1' \#\# 用于同步数据的用户（在 Master 中授权的用户）  
master\_password='123456' \#\# 同步数据用户的密码  
master\_port=3306 \#\# Master 数据库服务的端口  
master\_log\_file='cpmaster1.000001' \#\#指定 Slave 从哪个日志文件开始读复制数据（可  
在 Master 上使用 show master status 查看到日志文件名）  
master\_log\_pos=429 \#\# 从哪个 POSITION 号开始读  
master\_connect\_retry=30 \#\#当重新建立主从连接时，如果连接建立失败，间隔多久后重试。  
单位为秒，默认设置为 60 秒，同步延迟调优参数。  
\#\# 查看主从同步状态  
mysql> show slave status\\G;  
可看到 Slave\_IO\_State 为空， Slave\_IO\_Running 和 Slave\_SQL\_Running 是 No，表明 Slave 还没有开始复制过程。  
\#\# 开启主从同步  
mysql> start slave;  
Query OK, 0 rows affected (0.00 sec)  
\#\# 再查看主从同步状态  
mysql> show slave status\\G;

主要看以下两个参数，这两个参数如果是 Yes 就表示主从同步正常  
Slave\_IO\_Running: Yes  
Slave\_SQL\_Running: Yes  
由截图中的主从同步状态信息可以看出，我们配置的主从同步是正常的。  
可查看 master 和 slave 上线程的状态。在 master 上，可以看到 slave 的 I/O 线程创建的连接：  
Master : mysql> show processlist\\G;

1.row 为处理 slave 的 I/O 线程的连接。  
2.row 为处理 MySQL 客户端连接线程。  
3.row 为处理本地命令行的线程。

ok  !!!  大功告成，在master1插入一条数据查看slave1是否同步即可。

slave2复制master2，两个master互备操作都是一样的。

如果遇到同步出错，可在 Slave 上重置主从复制设置（选操作）：

mysql> reset slave;  
重新执行即可  
mysql> change master to master\_host='192.168.66.11', master\_user='cpmaster1', master\_password='123456', master\_port=3306, master\_log\_file='master1-bin.000001', master\_log\_pos=1389, master\_connect\_retry=30;  
Query OK, 0 rows affected, 2 warnings (0.01 sec)

[20180211102911927]: /images/20220617/41d5901e4f3c4f7ebbb8eff4ea7614c0.png
[Link 1]: http://blog.csdn.net/kang5789/article/details/79308660