MySQL Replication概述
MySQL Replication俗称 MySQL AB复制、主从复制、主从同步，是MySQL官方推荐的数据同步技术。数据同步基本过程为从数据库会实时去读取主数据库的二进制日志文件，按照日志中记录对从库进行同样的操作，以达到数据同步效果。
优点：
通过增加从服务器来提高数据库平台的可靠性。在主服务器上执行写入和更新,在从服务器上向外提供读功能,可以动态地调整从服务器的数量,从而调整数据库平台的高性能。
提高数据安全性.因为数据已复制到从服务器，主数据库数据异常时,可以将从服务器复制进程终止来达到保护数据完整性的特点。
在主服务器上生成实时数据.而在从服务器上分析这些数据,从而缓解主服务器的性能压力。
MySQL复制类型
异步复制
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理了事务，这样就会有一个问题，主库如果down 掉了，此时主上已经提交的事务可能并没有传到从库服务器上，如果此时，强行将从提升为主，可能会导致新主上的数据不完整。默认情况下MySQL5.5/5.6/5.7和mariaDB10.0/10.1的复制功能是异步的。
全同步复制
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响，返回客户端的响应速度也会被拖慢。
半同步复制
MySQL5.5由 Google贡献的补丁才开始支持半同步复制模式，介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到 relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP 往返的时间。所以半同步复制最好在低延时的网络中使用。当出现超时情况时,源主服务器会暂时切换到异步复制模式，直到至少有一台设置为半同步复制模式的从服务器及时收到信息为止。
半同步复制模式在主服务器和从服务器同时启用，否则主服务器默认使用异步复制模式。
半同步复制原理图:
半同步复制的潜在问题:
客户端事务在存储引擎层提交后，在得到从库同步的过程中，主库宕机了。此时可能的情况有两种：
事务还没发送到从库上
此时,客户端会收到事务提交失败的信息,客户端会重新提交该事务到新的主上,当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中,会发现,该事务在从库中被提交了两次,一次是之前作为主的时候，一次是被新主同步过来的。
事务已经发送到从库上
此时从库已经收到并应用了该事务,但是客户端仍然会收到事务提交失败的信息,重新提交该事务到新的主年。
无数据丢失的半同步复制·
针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案: Loss-Less半同步复制。针对上面这个图."Waiting Slave dump”被调整到"Storage Commit"之前。当然，之前的半同步方案同样支持,MySQL 5.7.2引入了一个新的参数进行控制rpl_semi_sync_master_wait_point。
v
rpl_semi_sync_master_wait_point有两种取值
AFTER_SYNC:这个即新的半同步方案,Waiting Slave dump 在 Storage Commit之前。
AFTER_COMMIT:老的半同步方案
MySQL支持的复制方式
基于SQL 语句的复制(SBR):在主服务器上执行的SQL语句，在从服务器上执行同样的SQL语句,效率比较高。
基于行的复制(RBR):主服务器把表的行变化作为事件写入到二进制日志中，主服务器代表了行变化的事务复制到从数据库中
混合模式复制(MBR):先采用基于语句的复制,一旦发现基于语句无法精确复制时,再采用行。
在MySQL5.1.4之前的版本都只能使用基于SQL语句的复制方式,MySQL5.6.5和往后的版本是基于GTIDs来进行事务复制。当使用GTIDs时可以大大简化复制过程，因为GTIDs完全基于事务,只要在主服务器上提交了事务那么从服务器就一定会执行该事务。
通过设置服务器的系统变量binlog_format来指定要使用的格式:
RBR的优点:
任何情况都可以被复制,这对复制数据来说是最安全可靠的更少的行级锁表
和其他大多数数据库系统的复制技术一样
多数情况下,从服务器上的表如果有主键的话,复制就会快很多
RBR的缺点
Binlog文件较大
复杂的回滚时 binlog中会包含大量的数据
主服务器上执行多个 UPDATE语句时，所有发生变化的记录都会写到 binlog 中，而且只写为一个操作事物,这会导致频繁发生binlog的并发写问题
不能通过查看日志来审计执行过的sql 语句,不过可以通过使用mysqlbinlog --base64-output=decode-rows --verbose来查看数据的变动
SBR的优点
历史悠久,技术成熟;binlog文件较小
binlog 中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
binlog 可以用于实时的还原,而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR的缺点
不是所有的 UPDATE 语句都能被复制，尤其是包含不确定操作的时候。
复制需要进行全表扫描(WHERE 语句中没有使用到索引)的UPDATE 时，需要比 RBR请求更多的行级锁
对于一些复杂的语句，在从服务器上的耗资源情况会更严重
无论选择哪种方式复制,都会影响到复制的效率以及服务器的损耗,以及数据一致性问题，目前其实没有很好的客观手段去评估一个系统更适合哪种方式的复制。
复制工作原理
记
当master 上的数据发生改变时，则将其改变写入二进制曰志 binlog日志中;
slave 服务器会在一定时间间隔内对master 二进制日志进行探测其是否发生改变.如果发生改变，从库会生成两个线程,一个I/O线程,一个SQL线程;Io线程会去请求主库的binlog.并将得到的 binlog 写到本地的relay-log(中继日志)文件中
主库会生成一个 log dump 线程,用来给从库lO线程传 binlog
SQL线程,会读取relay log文件中的日志.并解析成sql语句逐一执
最后IOThread和SQLThread将进入睡眠状态，等待下一次被唤醒。