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功能。

  • 2
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值