深入浅出MySQL主从复制与读写分离原理及其实践

当Slave库与Master库建立复制关系后，Slave库的I/O线程会连接到Master库，并请求从Master库的二进制日志的特定位置（如当前Slave库已知的最后一个事件的下一个位置）开始读取事件。
Master库响应Slave库的请求，将二进制日志中的事件传送给Slave库的I/O线程。
I/O线程接收到Master库发来的二进制日志事件后，将这些事件写入到Slave库本地的中继日志中。
一旦事件被写入到中继日志，Slave库的SQL线程就会从中继日志中读取这些事件，并在Slave库上执行这些事件，从而实现数据的同步。

2.影响因素

在主从复制的过程中，有些因素可能导致主从复制延迟或者失败

二进制日志配置：

binlog_format：二进制日志的格式，如STATEMENT、ROW或MIXED，不同的格式会影响复制的精确度和兼容性。

log-bin：是否启用二进制日志，这是主从复制的基础。

server_id：每个MySQL实例都需要一个唯一的server_id，用于标识主从关系。

复制用户权限：从服务器的复制用户需要有足够的权限从主服务器读取二进制日志，并在从服务器上执行这些日志中的SQL语句。

网络稳定性：主从之间的网络通信质量至关重要，网络中断或延迟可能导致主从数据不一致或复制延迟。

主从数据库版本兼容性：主从服务器的MySQL版本应当尽可能接近，跨大版本的复制可能带来未知的风险和问题。

主从数据库架构一致性：主从数据库的表结构、字符集等需要保持一致，否则可能导致复制失败。

主从数据库同步延迟：由于主从复制通常是异步或半同步模式，因此从库的数据会有一定程度的延迟。如果应用不能容忍这种延迟，则需要评估是否适合采用主从复制方案。

主库性能：主库的写入压力和性能会影响到复制的速度和稳定性，特别是在高并发写入场景下。

中继日志与事务安全：从服务器的中继日志（relay log）管理，包括中继日志的清理策略、磁盘空间充足性等都会影响复制的正常运行。

GTID（全局事务标识符）：如果启用了GTID，主从间的事务管理和故障切换会更加便捷，但同时也引入了额外的配置和管理复杂性。

复制过滤：有时可能需要对某些数据库或表设置复制过滤规则，但这可能导致主从数据不一致，需要谨慎设置和管理。

（三）实现主从复制

环境准备

MASTER服务器	192.168.83.20
SLAVE1服务器	192.168.83.40
SLAVE2服务器	192.168.83.60

1.搭建时间同步

在构建MySQL主从复制架构时，确保主从服务器之间的系统时间同步是非常重要的。这是因为MySQL在处理事务和记录二进制日志时依赖于系统时间戳，时间不一致可能会导致主从复制出现问题，如数据不一致或复制中断

##主服务器设置##
yum install ntp -y
#下载ntp服务

vim /etc/ntp.conf
--末尾添加--
server 127.127.10.0							#设置本地是时钟源，注意修改网段
fudge 127.127.10.0 stratum 8				#设置时间层级为8（限制在15内）

systemctl start ntpd
#启动服务


##从服务器设置##
yum install ntp ntpdate -y

systemctl start ntpd
#启动服务

/usr/sbin/ntpdate 192.168.83.20
#进行时间同步,192.168.83.20为master服务器ip地址

crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.83.20
#制定计划任务，每半小时进行一次时间同步

2.配置master服务器

2.1 开启二进制日志

在/etc/my.cnf文件中添加以下字段

server-id = 1
#这个参数是为MySQL服务器分配的一个唯一标识号。在主从复制环境中，无论是主服务器还
#是从服务器,都必须设置一个唯一的server-id。

log-bin=master-bin
#log-bin用于开启二进制日志，这是实现MySQL主从复制的关键特性。这里的master-bin是指定
#二进制日志的前缀名称，二进制日志文件将以master-bin.000001,master-bin.000002等格式生成。

binlog_format = MIXED
#binlog_