mysql的高可用方案架构之一（各种复制方式）
读写分离
原理
主从复制的原理是：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是什么了
