mysql主从复制

目录

一、什么是mysql主从复制

二、mysql支持的复制类型

STATEMENT∶基于语句的复制。

ROW∶ 基于行的复制。

MIXED∶混合类型的复制。

三、主从复制的工作过程（主写从复制）

四、mysql解决的问题

五、生产环境中主流架构

一主多从

M-S-S

 M-M​编辑

M-M-M

六、MySQL主从复制延迟原因

七、MySOL主从复制模式

异步复制（Asynchronous replication）

全同步复制（Fully synchronous replication）

半同步复制（Semisynchronous replication）

八、主从架构部署

主服务器——192.168.226.22​编辑​编辑

 从服务器1——192.168.226.21

从服务器1——192.168.226.20

验证

九、总结

一、什么是mysql主从复制

MySQL主从复制是其最重要的功能之一。主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。

二、mysql支持的复制类型

STATEMENT∶基于语句的复制。

在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。

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

ROW∶ 基于行的复制。

把改变的内容复制过去， 而不是把命令在从服务器上执行一遍。

存在的问题：把主服务器上面改编后的内容直接复制过去，而不关心到底改变该内容是由哪条语句引发的

MIXED∶混合类型的复制。

默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

在MySQL主从复制架构中，读操作可以在所有的服务器上面进行，而写操作只能在主服务器上面进行。主从复制架构虽然给读操作提供了扩展，可如果写操作也比较多的话（多台从服务器还要从主服务器上面同步数据），单主模型的复制中主服务器势必会成为性能瓶颈。

三、主从复制的工作过程（主写从复制）

1. 首先client端（tomcat）将数据写入到master节点的数据库中，master节点会通知存储引擎提交事务，同时会将数据以（基于行、基于sql、基于混合）的方式保存在二进制日志中
2. SLAVE节点会开启I/O线程，用于监听master的二进制日志的更新，一旦发生更新内容，则向master的dump线程发出同步请求
3. master的dump线程在接收到SLAVE的I/O请求后，会读取二进制文件中更新的数据，并发送给SLAVE的I/O线程
4. SLAVE的I/O线程接收到数据后，会保存在SLAVE节点的中继日志中
5. 同时，SLAVE节点钟的SQL线程，会读取中继日志钟的数据，更新在本地的mysql数据库中
6. 最终，完成slave——>复制master数据，达到主从同步的效

记住两个日志和三个线程：

两个日志：二进制日志（bin log） 、中继日志（Relay log）

三个线程：I/O线程、dump线程、SQL线程

注意：中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。

           复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行             更新操作不能在 Slave上并行操作。

          半同步复制，会多一个ack确认线程（ack collector thread），专门用于接收slave 的反馈            信息（收集slave节点返回的ack信息）。

四、mysql解决的问题

1. 数据分布 (Data distribution )
2. 负载平衡(load balancing)
3. 数据备份(Backups) ，保证数据安全
4. 高可用性和容错行(High availability and failover)
5. 实现读写分离，缓解数据库压力，在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。如果主库
6. 出现问题，可以快速切换到从库提供服务
7. 可以在从库执行查询操作，降低主库的访问压力。
8. 可以在从库进行备份，以免备份期间影响主库的服务。

五、生产环境中主流架构

一主多从

M-S-S

 M-M

M-M-M

六、MySQL主从复制延迟原因

1. master服务器高并发，形成大量事务
2. 网络延迟
3. 主从硬件设备导致
4. cpu主频、内存io、硬盘io
5. 本来就不是同步复制、而是异步复制
6. 从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完 成，减少磁盘操作。
7. 从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了i/o方面性。
8. 从库使用SSD磁盘
9. 网络优化，避免跨机房实现同步

七、MySOL主从复制模式

异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

全同步复制（Fully synchronous replication）

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

半同步复制（Semisynchronous replication）

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

八、主从架构部署

Master 服务器：192.168.10.22，mysql5.7

Slave1 服务器：192.168.10.33，mysql5.7

Slave2 服务器：192.168.10.44，mysql5.7

主服务器——192.168.226.22

 

 从服务器1——192.168.226.21

从服务器1——192.168.226.20

 

 

验证

主创数据库 

从1从2都有

九、总结

一般 "Slave_IO_Running: No" 的可能原因：网络不通、my.cnf配置有问题（server-id重复）、密码、file文件名、pos偏移量不对、防火墙没有关闭

mysql从服务器挂了 恢复后怎么保证数据同步：物理方法： rsync 磁盘文件同步。 使用文件恢复，主节点需要停服务。主从复制： 将从节点原有库删除，通过偏移量，重新做一次主从复制。

数据库主从数据不一致解决方案

方法一：忽略错误后，继续同步

该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况。

方式二：重新做主从，完全同步

该方法适用于主从库数据相差较大，或者要求数据完全统一的情况。

每个master可以有多个slave。

每个slave只能有一个master。

每个slave只能有一个唯一的服务器ID（server-id）。

master一定要开启binlog二进制日志功能；通常为了数据安全，slave也开启binlog功能。