MYSQL：主从复制原理及简单实现

概述

概念

主从复制：指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中

• 基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新

主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。

主从复制，主要涉及三个线程: binlog 线程、I/O 线程和 SQL 线程。

• binlog 线程 : 负责将主服务器上的数据更改写入二进制日志中。
• I/O 线程 : 负责从主服务器上读取二进制日志，并写入从服务器的中继日志中。
• SQL 线程 : 负责读取中继日志并重放其中的 SQL 语句。

主从复制类型

基于语句的复制：主服务器上面执行的语句在从服务器上面再执行一遍，在MySQL-3.23版本以后支持

问题：时间上可能不完全同步造成偏差，执行语句的用户也可能是不同一个用户

基于行的复制：把主服务器上面改变后的内容直接复制过去，而不关心到底改变该内容是由哪条语句引发的，在MySQL-5.0版本以后引入。

问题：如果修改的行数过多，造成的开销比较大。

• MySQL默认使用基于语句的复制，当基于语句的复制会引发问题的时候就会使用基于行的复制，MySQL会自动进行选择。
• MySQL主从复制架构中，读操作可以在所有的服务器上面进行，而写操作只能在主服务器上面进行

原理

基本原理

主服务器上面的任何修改都会保存在二进制日志Binary log

从服务器上面启动一个I/O thread（实际上就是一个主服务器的客户端进程），连接到主服务器上面请求读取二进制日志，然后把读取到的二进制日志写到本地的一个Relay log

• 从服务器上面开启一个SQL thread定时检查Relay log，如果发现有更改立即把更改的内容在本机上面执行一遍。

  如果一主多从的话，这时主库既要负责写又要负责为几个从库提供二进制日志，可以做一下调整，将二进制日志只给某一从A，从A再开启二进制日志并将自己的二进制日志再发给其它从，或者从不记录只负责将二进制日志转发给其它从
  

操作步骤如下

操作步骤如下：

1. Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容

2. Master接收到来自Slave的IO进程的请求后，Master负责复制的IO进程会根据请求信息读取日志指定位置之后的日志信息，返回给Slave的IO进程、

   1. 返回信息中除了日志所包含的信息之外，
   2. 还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置

3. Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master从何处开始读取日志。

4. Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

注意：

1. 过程中 binlog 和 relay log 都是 顺序读写。
2. 主从同步的数据内容其实是二进制日志（Binlog），存储的是一个又一个的事件（Event），这些事件分别对应着数据库的相关操作，比如 INSERT、UPDATE、DELETE 等。
3. 二进制日志，它是一个文件，在进行网络传输的过程中就一定会存在一些延迟，比如200ms，这样就可能造成用户在从库上读取的数据不是最新的数据，也就会造成主从同步中的数据不一致的情况发生。

   1. 比如我们对一条记录进行更新，这个操作是在主库上完成的，而在很短的时间内，比如100ms，又对同一个记录进行读取，这时候从库还没有完成数据的同步，
   2. 那么，我们通过从库读取到的数据就是一条旧的数据。

数据复制方式

MySQL 主从复制，默认采用的复制策略就是异步复制。

全同步复制

全同步复制：当主库执行完一个事务之后，要求所有的从库也都必须执行完该事务，才可以返回处理结果给客户端。

• 全同步复制数据一致性得到保证了，
• 但是主库完成一个事务需要等待所有从库也完成，性能会比较低。
  

异步复制

异步复制：当主库提交事务后，会通知 binlog dump 线程发送 binlog 日志给从库，一旦 binlog dump 线程将 binlog 日志发送给从库之后，不需要等到从库也同步完成事务，主库就会将处理结果返回给客户端。

注意：

• 可能导致短暂的主从数据不一致的问题
• 当主库提交事务后，如果宕机挂掉了，此时可能 binlog 还没来得及同步给从库，这时候如果为了恢复故障切换主从结点的话，就会出现数据丢失的问题
  • 异步复制虽然性能高，但数据一致性上是最弱的。

半同步复制

MySQL 5.5版本之后开始支持半同步复制的方式
半同步复制：客户端提交事务之后不直接将结果返回给客户端，而是等待至少有一个从库收到了 Binlog，并且写入到中继日志中，再返回给客户端。

• 相比于异步复制，提高了数据的一致性

  至少多增加了一个网络连接的延迟，降低了主库写的效率。
  

增强半同步复制

增强半同步复制，是 MySQL 5.7.2后的版本对半同步复制做的一个改进

主要是解决幻读的问题。

主库配置了参数 rpl_semi_sync_master_wait_point = AFTER_SYNC 后，主库在存储引擎提交事务前，必须先收到从库数据同步完成的确认信息后，才能提交事务，以此来解决幻读问题。

半同步复制优化

半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。
但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。

该方案同样使用双结点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。
优点：

1. 双结点，需求资源少，部署简单；
2. 架构简单，没有选主的问题，直接切换即可;
3. 相比于原生复制，优化后的半同步复制更能保证数据的一致性。

缺点：

1. 需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。
2. 依旧依赖于半同步复制，没有从根本上解决数据一致性问题。

双通道复制

半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，

• 其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。
• 另外一条异步复制通道开始追补从机落后的数据。
• 当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。
  

binlog文件服务器

搭建两条半同步复制通道，

• 其中连接文件服务器的半同步通道正常情况下不启用，
• 当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。
• 当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。

读写分离能提高性能的原因

读写分离能提高性能的原因：

1. 负载分流：

   • 写操作集中处理：主节点（Master）专注于处理写操作（INSERT/UPDATE/DELETE），避免读写混合导致的锁竞争。
   • 读操作分散到从节点：从节点（Slave）处理读操作（SELECT），通过增加从节点数量横向扩展读能力。

2. 硬件资源优化

   • 主库资源释放：主库无需承担读压力，可集中资源处理写操作（如磁盘IO、CPU用于binlog写入和事务提交）。

3. 锁竞争减少

   • 写锁影响隔离：主库上的写操作（如行锁、表锁）不会阻塞从库的读操作。

4. 缓存利用率提升：

   • 从库独立缓存：每个从库维护独立的缓冲池（Buffer Pool），可缓存不同维度的热点数据。

5. 容灾与备份

   • 热备节点：从库实时同步数据，故障时可快速切换为主库。
   • 备份隔离：在从库执行mysqldump或物理备份，避免影响主库性能。

代理方式实现读写分离

mysql实现主从

在这里就不描述mysql的安装内容，直接说比较核心的步骤，其他是已经安装了两台数据库，mstaer和slave

只说明大致逻辑，不详细叙述实现过程

问题注意：数据延迟：异步复制下从库可能有秒级延迟，需业务容忍。

如果应用对数据不一致的接受程度程度较低，可能的优化措施包括：

1. 优化主从节点之间的网络环境（如在同机房部署）；
2. 监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据；
3. 使用集群同时扩展写负载和读负载等。

master配置

1. 修改my.cof配置文件：配置文件默认在/etc/my.cnf下，开启bin-log 日志
2. 修改配置后需要重启才能生效：service mysql restart

   # 同一局域网内注意要唯一
   server-id=100  # 开启二进制日志功能，可以随便取（关键）
   log-bin=mysql-bin
   

3. 创建复制账号：在主服务器上授权，从服务器保存授权的信息，登录数据库后，直接在命令窗口执行下面的语句

   grant replication slave on *.* to 'root'@'%' identified by '123456';
   --刷新权限
   flush privileges;
   

4. 查看binlog状态：

   #登录mysql数据库
   mysql -uroot -p
   #查看master的状态
   show master status
   

slave配置

1. 从my.cnf配置中新增后并重启：

   # 设置server_id,注意要唯一
   server-id=101  
   # 开启二进制日志功能，以备Slave作为其它Slave的Master时使用
   log-bin=mysql-slave-bin   
   # relay_log配置中继日志
   relay_log=edu-mysql-relay-bin 
   

2. 重启slave并进行相关配置

3. 连接主服务器的配置

   master_host ：Master的地址
   master_port：Master的端口号
   master_user：用于数据同步的用户
   master_password：用于同步的用户的密码
   master_log_file：指定 Slave 从哪个日志文件开始复制数据，即上文中提到的 File 字段的值
   master_log_pos：从哪个 Position 开始读，即上文中提到的 Position 字段的值
   master_connect_retry：如果连接失败，重试的时间间隔，单位是秒，默认是60秒

   #重启mysql服务
   service mysqld restart
   #登录mysql
   mysql -uroot -p
   #连接主服务器
   change master to master_host='xxx',master_user='root',master_password='123456',master_port=3306,master_log_file='master-bin.000001',master_log_pos=154;
   #开启主从复制
   start slave
   

4. 查看slave的状态:

   SlaveIORunning 和 SlaveSQLRunning 都是Yes说明主从复制已经开启

   show slave status\G
   

5. 如果需要指定想要主从同步哪个数据库，

   1. 可以在master的my.cnf添加配置

      binlog-do-db：指定mysql的binlog日志记录哪个db
      

   2. 或者在slave的my.cnf添加配置：

      replicate-do-db=需要复制的数据库名，如果复制多个数据库，重复设置这个选项即可
      

6. 如果想要同步所有库和表，在从mysql执行：

   STOP SLAVE SQL_THREAD; CHANGE REPLICATION FILTER REPLICATE_DO_DB = (); start SLAVE SQL_THREAD;