传统复制与基于GTID复制

• 传统复制

  • 复制拓扑的初始化配置和变更、复制的高可用切换等操作都需要找到正确的二进制日志文件和位置，否则就无法正确复制
  • 每个从库都会记录当前对应主库的二进制日志文件位置、二进制日志文件名，以及在此文件中它已从主库读取和处理的位置（即SQL线程和I/O线程的位置）。每个从库独立地应用主库的二进制日志，相互之间不产生影响并各自记录自身应用到的位置，而且就算有从库与主库的连接发生断开或重连，也不会影响主库的操作

• 基于GTID的复制方式

  • 定义：GTID（Global Transaction Identifier，全局事务标识符），即基于GTID实现的复制，指的是基于事务的复制
  • 使用GTID复制在搭建新从库或者因故障转移到新主库时，会自动根据GTID来定位对应的二进制日志文件和位置，更准确地说，是自动寻找从库缺失的GTID SET对应的二进制日志记录，极大地降低了这些任务的复杂度

• GTID SET信息在主库与从库中都会保存。这意味着可以通过GTID SET信息来追踪二进制日志的来源。此外，一旦在给定Server中提交过某个GTID的事务，则该Server将忽略后续提交的相同GTID的事务。因此，主库上提交的事务在从库上只能应用一次，之后碰到重复的GTID时会自动跳过整个事务，这有助于保证主从库数据一致

  • 通过GTID可以区分事务的来源（通过GTID组成中的UUID可以区分事务是由哪个Server提交的

• 开启GTID复制模式，在my.cnf配置文件中添加 5.7+版本

  gtid_mode=on    (必选)

  enforce-gtid-consistency=1  （必选）

  log_bin=mysql-bin           （可选）    #高可用切换，最好开启该功能

  log-slave-updates=1     （可选）       #高可用切换，最好打开该功能

• GTID作用方式

  • 最开始的时候，MySQL只支持一种binlog dump方式，也就是指定binlog filename + position，向master发送COM_BINLOG_DUMP命令。在发送dump命令的时候，我们可以指定flag为BINLOG_DUMP_NON_BLOCK，这样master在没有可发送的binlog event之后，就会返回一个EOF package。不过通常对于slave来说，一直把连接挂着可能更好，这样能更及时收到新产生的binlog event
  • 在MySQL 5.6之后，支持了另一种dump方式，也就是GTID dump，通过发送COM_BINLOG_DUMP_GTID命令实现，需要带上的是相应的GTID信息.

• GTID工作原理

  • master更新数据时，会在事务前产生GTID，一同记录到binlog日志中
  • slave端的i/o 线程将变更的binlog，写入到本地的relay log中
  • sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录 2 3 4 5
  • 如果有记录，说明该GTID的事务已经执行，slave会忽略
  • 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog
  • 在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描

• GTID优势

  • 一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次;
  • GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置;
  • 减少手工干预和降低服务故障时间，当主机挂了之后通过软件从众多的备机中提升一台备机为主机;

• GTID的劣势

  • 不支持非事务引擎;
  • 不支持create table ... select 语句复制(主库直接报错);(原理: 会生成两个sql, 一个是DDL创建表SQL, 一个是insert into 插入数据的 sql; 由于DDL会导致自动提交, 所以这个sql至少需要两个GTID, 但是GTID模式下, 只能给这个sql生成一个GTID)
  • 不允许一个SQL同时更新一个事务引擎表和非事务引擎表
  • 在一个复制组中，必须要求统一开启GTID或者是关闭GTID