mysql的高可用方案架构之一(各种复制方式)

读写分离

原理

主从复制的原理是:binlog

  1. 日志产生量

ROW模式会记录每一条删除语句,所以日志会很大。这也说明将格式设置成ROW,对于磁盘空间的要求增加了,而复制采用传输二进制日志方式实现的,所以复制的网络开销也有增加。所以最后的结果是:ROW>STATEMENT=MIXED

  1. 对复制产生的影响

对于更新单条的sql语句,在STATEMENT和ROW下

(1),CPU消耗差距不大,都需要执行这么sql。消耗 R=S

(2),磁盘写和网络传输上,因为ROW记录的格式的原因。消耗 R>S

(3),SQL效率来看,合理利用索引的更新,效率差距不大,不合理利用索引的更新,效率 R>S

(4),日志文件大小上,因为都需要记录这么多SQL,但是由于R和S的记录格式不一样,大小 R>S

对于执行一个大范围的sql语句,在STATEMENT和ROW下

(1),CPU上,主上只要执行一条SQL,而从上需要执行N条,消耗 R>S

(2),磁盘写和网络传输上,因为ROW记录的格式的原因。消耗R>S,看范围条件,大的话,差距巨大。

(3),日志文件大小上,主记录一条,从记录N条,并且还由于R和S的记录格式不一样,R>S,差距巨大。

从上面的分析得出,STATEMENT要比ROW划算。要是使用STATEMENT没有任何问题的话,就推荐使用STATEMENT/MIXED格式记录二进制日志。

  1. 数据一致性

对于ROW和STATEMENT的复制,ROW在数据的一致性上面要求更好,从库要是提供服务,最好把复制模式改成ROW。

mysql复制

(1)异步复制

(2)半同步复制

(3)GTID复制

异步复制:(1)mysql默认的复制方式 (2)主节点写入binlog文件后就返回客户端,不考虑binlog是否已完整同步到从节点、是否已完整存放到从节点的relay log中去

异步复制优缺点:(1)优点:性能好,无阻塞 (2)缺点:如果主节点发生宕机,主节点上已经提交的事务尚未同步到从节点,如果此时强行将从节点晋升为主节点,会导致新主节点数据不完整

异步复制

搭建的主从复制是基于异步复制的。异步复制:主节点将事件写入到binlog之后,就提交事务。主节点的事务不会知道从节点有没有接收binlog,是否处理完整个复制的过程。

全同步复制:主节点写入binlog后就等着,直到事务在所有从库都提交后,返回客户端。优点:确保数据实时同步到了所有的从库。缺点:数据更新的效率会差很多,增删改等操作会有较大延迟

半同步复制:主库提交事务后,不立即返回,而是等待至少1个从库接收到binlog,并写入到relay log才返回,从而保证主库出问题时,至少有1个从库的数据是完整的。(当等待超时时,会降低到异步复制,保证主库的正常更新)

半同步复制的方案1:

总结:(1)GTID用来标识一个事务 (2)从库会去对比传过来的GTID是否已经在binlog里面,如果已经在就直接放弃,不在就去执行 (3)不需要知道binlog文件名和position是什么了

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值