1. 主从复制

MySQL支持的复制类型
- 基于binlog的3种模式
  - statement：基于语句的复制（5.5.6之前默认），主服务器执行的SQL语句，在从服务器执行同样的语
  - row：基于行的复制（5.5.7之后默认），把改变的内容复制到从库，而不是把SQL命令在从库重新执行一遍。mysql5.0就开始支持
  - mixed：混合类型的复制，默认是使用 statement 语句方式复制，一旦发现基于语句无法精确复制时（比如now() 因为主从有延迟导致数据不一致）就会采用基于 row 行的方式复制
- 一些设置对主从复制的影响
  - 自增锁模式innodb_autoinc_lock_mode
    - 如果复制的模式是基于语句的复制，那么自增锁模式设定innodb_autoinc_lock_mode=2 的时候，可能会出现bug，所以需要将 innodb_autoinc_lock_mode 设定为 0/1
    - 如果使用的是基于行的复制或混合格式的复制，则所有自增锁定模式都是安全的
      1.1. 异步
在5.5之前，主库只管binlog dump数据到从库，不保证主从完全一致，断电、崩溃等情况会丢失数据
- 客户端提交事务，主库执行完commit操作，在主库写入binlog日志后，就返回成功给客户端。但是如果此时这个事务未能同步到从库，而主库挂掉，且数据无法恢复。这样，这个事务就丢失了

1.2. 全同步

MySQL5.5开始推出半同步复制，相比异步复制，半同步复制提高了数据完整性
在master的dump线程通知slave后，增加了一个ack(消息确认)这一个步骤。即binlog先在引擎层提交，然后再等待slave反馈收到relay log，只有收到ack后master才将commit ok结果反馈给客户端
会出现的问题：幻读。当引擎层已经commit的时候他还需要等待slave的ACK确认，才在客户端返回commit ok，但是在写入数据后并且从库确认之前，主库的其他客户端是可以看到这一条记录的，这就造成了幻读

1.4. 增强半同步
增强半同步在MySQL日志XA提交下的问题
增强半同步会不会丢数据
MySQL5.7.4及以上才可以用的
为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端应用用户，而是等待其中一个从库也接收到Binlog事务并成功写人中继日志后，主库才返回Commit操作成功给客户端。半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的 Binlog日志上，另一份在至少一个从库的中继日志Relay Log 上，从而更进一步保证了数据的完整性。

相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用
如果从库宕机或者网络故障，导致Binlog并没有及时地传送到从库上，此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定)，如果Binlog 在这段时间内都无法成功推送到从库上，则 MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端