GTID
MySQL 5.6的新特性，其全称是Global Transaction Identifier，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找点儿，而无需像之前那样通过File_name和File_position找点儿了。使用server_uuid和transaction_id两个共同组成一个GTID。即：GTID = server_uuid:transaction_id；server_uuid是MySQL Server的只读变量，保存在数据目录下的auto.cnf中，可直接通过cat命令查看。MySQL第一次启动时候创建auto.cnf文件，并生成server_uuid，之后MySQL再启动时不会重复生成uuid，而是使用auto.cnf中的uuid，在同一个集群内，每个MySQL实例的server_uuid必须唯一，否则同步时，会造成IO线程不停的中断，重连。在通过备份恢复数据时，一定要将var目录中的auto.cnf删掉，让MySQL启动时自己生成uuid。GTID中还有一部分是transaction_id，同一个server_uuid下的transaction_id一般是递增的。如果一个事务是通过用户线程执行，那么MySQL在生成的GTID时，会使用它自己的server_uuid，然后再递增一个transaction_id作为该事务的GTID
log-slave-updates:从库做为其他从库的主库时 log-slave-updates参数是必须要添加的从库开启log-bin参数，如果直接往从库写数据，是可以记录log-bin日志的，但是从库通过I0线程读取主库二进制日志文件，然后通过SQL线程写入的数据，是不会记录binlog日志的。也就是说从库从主库上复制的数据，是不写入从库的binlog日志的。所以从库做为其他从库的主库时需要在配置文件中添加log-slave-updates参数。
MySQL 主从复制模式1、异步复制：MySQL默认的复制方式，主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程，但是一旦主库宕机，就有可能出现丢失数据的情况2、半同步模式：这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长3、全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。4、 GTID复制：主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中从节点的I/O线程将变更的bin log，写入到本地的relay log中。SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（MySQL从节点必须要开启binary log）如果有记录，说明该GTID的事务已经执行，从节点会忽略。如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。
