读写分离
原理
主从复制的原理是:binlog
日志产生量
ROW模式会记录每一条删除语句,所以日志会很大。这也说明将格式设置成ROW,对于磁盘空间的要求增加了,而复制采用传输二进制日志方式实现的,所以复制的网络开销也有增加。所以最后的结果是:ROW>STATEMENT=MIXED
对复制产生的影响
对于更新单条的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格式记录二进制日志。
数据一致性
对于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是什么了