Mysql主从复制

---

一、主从复制原理和作用

主从复制的作用

MySQL 主从复制是一种数据复制机制，它可以将主服务器(Master)上的数据自动同步到一个或多个从服务器(Slave)上，从而实现数据备份和负载均衡等功能。
主要有以下几个作用：

1. 数据备份和灾难恢复

• 主服务器发生故障时,可以将从服务器升级为新的主服务器,实现快速恢复。
• 从服务器上的备份数据也可用于恢复主服务器。

2. 负载均衡和高可用

• 通过部署多个从服务器,可以将读请求分散到从服务器上,减轻主服务器的负载。
• 当主服务器宕机时,可以快速切换到从服务器上,提高系统的可用性。

主从复制的架构

• 一主一从
• 一主多从
• 从服务器还可以再有从服务器（减少主节点的性能压力，距离较远）
• 互为主
• 一从多主:适用于多个不同数据库
• 环状复制

一主一从复制架构

一主多从复制架构

主从复制的主要优点包括:

1. 数据备份和灾难恢复
2. 读写分离,提高系统的伸缩性
3. 支持多种复制拓扑
4. 支持异步和半同步复制

主从复制原理

主从复制相关线程

主服务器上会开启一个线程。
dump Thread：为每个Slave的I/O Thread启动一个dump线程，用于向其发送binary log events从节点。
从服务器上会开启两个线程。
I/O Thread：向Master请求二进制日志事件，并保存于中继日志中。
SQL Thread：从中继日志中读取日志事件，在本地完成同步。

主从复制相关日志
主服务器上需要开启二进制日志，用户完成写操作后，会修改数据库，并记录在二进制日志上。
中继日志 （relay log）只在主从服务器架构的从服务器上存在。从服务器（slave）为了与主服务器（Master）保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的数据同步。

搭建好主从服务器之后，中继日志默认会保存在从服务器的数据目录下。文件名的格式是：从服务器名 - relay-bin.序号。中继日志还有一个索引文件：从服务器名 - relay-bin.index，用来定位当前正在使用的中继日志。

跟复制功能相关的文件

• master.info：用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等。
• relay-log.info：保存在当前slave节点上已经复制的当前二进制日志和本地relay log日志的对应关系。
• mysql-relay-bin.00000#: 中继日志,保存从主节点复制过来的二进制日志,本质就是二进制日志。

复制需要考虑二进制日志事件记录格式

• STATEMENT（5.0之前）, Mariadb5.5 默认使用此格式
• ROW（5.1之后，推荐）,MySQL 8.0 默认使用此格式
• MIXED: Mariadb10.3 默认使用此格式

二、 实现主从复制配置

一主一从配置

官网参考配置

https://dev.mysql.com/doc/refman/8.0/en/replication-configuration.html
https://dev.mysql.com/doc/refman/5.7/en/replication-configuration.html
https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html
https://mariadb.com/kb/en/library/setting-up-replication/

主节点配置
1.启用二进制日志

开启二进制
vim /etc/my.cnf
server-id=10
log-bin=/data/mysql//mysql-binmkdir -p /data/mysql

select @@server_id;
查看server_id;
grant replication slave on *.* to test@'192.168.2323.%' identified by 'Admin@123';
建立复制用户，使从可以登录。

建立完成。

show master status;
确定复制节点。

从节点配置

vim  /etc/my.cnf
server_id=20
log-bin=/data/mysql/mysql-bin
read_only  只读可加

从节点的配置，需要注意server_id和主不一样，通常是以ip地址配置。read_only的含义是只可以读，不能修改数据库，主要目的是，避免出现从被修改，主的数据不能同步，造成主从复制失败。
中继日志是默认开启的，可以不用添加。

修改从节点的配置

命令较长，可以使用帮助
help change master to

CHANGE MASTER TOMASTER_HOST='192.168.232.10',MASTER_USER='test',MASTER_PASSWORD='Admin@123',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=449;注意最后分号

这边的值都是自己设置的，注意不要出错。

show slave status\G;
查看设置的状态

刚开始两个进程是未开启的。

start slave;
开启线程，开启主从复制

至此，主从复制已经完成。

如果两个线程不是yes，stop slave；reset slave all；重新配置即可。

主从复制案例

假设主节点的数据库已经运行了一段时间，产生了一定量的数据，主从复制只能复制开启后数据，那之前的数据如何处理？
环境：
7-1是主服务器，已经有了很多数据，且存入数据的时候未启用二进制文件，7-2想要和其做主从复制。
解决方法：
将7-1进行完备，将完备后的数据导入7-2；然后正常做主从复制即可。

开启7-1上的二进制日志，并进行完备。

mysqldump -uroot -p123123 -A -F --single-transaction --master-data=1> /opt/all.sql
完备完成。scp all.sql 192.168.232.20:/opt
将完备文件远程拷贝至7-2在7-2上执行source /opt/all.sql即可将完备的数据导入。

接下来执行上述一主一从配置，即可完成。

错误解决办法

在从服务器忽略几个主服务器的复制事件，此为global变量，或指定跳过事件的ID。

系统变量，指定跳过复制事件的个数
SET GLOBAL sql_slave_skip_counter = N
服务器选项，只读系统变量，指定跳过事件的ID
[mysqld]
slave_skip_errors=1007|ALL  
这是错误代码。

半同步复制

默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当主服务器或从服务器端发生故障时，有可能从服务器没有接收到主服务器发送过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢复时造成数据的丢失。

需要在mysql中安装半同步模块

mysql>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 
永久安装插件
UNINSTALL PLUGIN rpl_semi_sync_master ;
卸载半同步插件，恢复成默认的异步复制。

主节点配置

vim  /etc/my.cnf
#修改文件
[mysqld]
server_id=100
log-bin=/data/mysql/mysql-bin
rpl_semi_sync_master_enabled=ON
rpl_semi_sync_master_timeout=3000
修改此行,需要先安装semisync_master.so插件后,再重启,否则无法启动 开启半同步
设置3s内无法同步，也将返回成功信息给客户端进入客户端
grant replication slave on *.* to test@'192.168.232.%' identified by 'Admin@123';
建立复制用户

查看信息

mysql>SHOW GLOBAL VARIABLES LIKE '%semi%';
查看半同步状态show global status like '%semi%';
查看半同步客户端show  master  status;
确定复制的节点。

从节点

vim /etc/my.cnf
[mysqld]
server-id=101
rpl_semi_sync_slave_enabled=ON #修改此行,需要先安装semisync_slave.so插件后,再重启,否则无法启动

CHANGE MASTER TOMASTER_HOST='192.168.232.10',MASTER_USER='test',MASTER_PASSWORD='Admin@123',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000003',MASTER_LOG_POS=154;

show global status like '%semi%';
查看状态。

造成主从不一致的原因

• 主库binlog格式为 Statement ，同步到从库执行后可能造成主从不一致。
• 主库执行更改前有执行set sql_log_bin=0，会使主库不记录binlog，从库也无法变更这部分数据。
• 从节点未设置只读，误操作写入数据。
• 主库或从库意外宕机，宕机可能会造成binlog或者relaylog文件出现损坏，导致主从不一致。
• 主从实例版本不一致，特别是高版本是主，低版本为从的情况下，主数据库上面支持的功能，从数据库上面可能不支持该功能。
• MySQL自身bug导致。

主从不一致修复方法

• 将从库重新实现

虽然这也是一种解决方法，但是这个方案恢复时间比较慢，而且有时候从库也是承担一部分的查询操作的，不能贸然重建。

• 使用percona-toolkit工具辅助

PT工具包中包含pt-table-checksum和pt-table-sync两个工具，主要用于检测主从是否一致以及修复数据不一致情况。这种方案优点是修复速度快，不需要停止主从辅助，缺点是需要知识积累，需要时间去学习，去测试，特别是在生产环境，还是要小心使用关于使用方法，可以参考下面链接：https://www.cnblogs.com/feiren/p/7777218.html

• 手动重建不一致的表

在从库发现某几张表与主库数据不一致，而这几张表数据量也比较大，手工比对数据不现实，并且重做整个库也比较慢，这个时候可以只重做这几张表来修复主从不一致这种方案缺点是在执行导入期间需要暂时停止从库复制，不过也是可以接受的。