Mysql 实战笔记 (六) 实践（5）

十5、MySQL是怎么保证高可用的？

正常状况下，只要主库执行更新生成的全部 binlog，均可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。

主备延迟

主备切换多是一个主动运维动做，好比软件升级、主库所在机器按计划下线等，也多是被动操做，好比主库所在机器掉电。与数据同步有关的时间点主要包括如下三个：

1. 主库 A 执行完成一个事务，写入 binlog，咱们把这个时刻记为 T1;
2. 以后传给备库 B，咱们把备库 B 接收完这个 binlog 的时刻记为 T2;
3. 备库 B 执行完成这个事务，咱们把这个时刻记为 T3。

所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
能够在备库上执行show slave status 命令，它的返回结果里面会显示seconds_behind_master，用于表示当前备库延迟了多少秒。seconds_behind_master 的计算方法是这样的：

1. 每一个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
2. 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，获得seconds_behind_master。

若是主备库机器的系统时间设置不一致，会不会致使主备延迟的值不许？

不会的。由于，备库链接到主库的时候，会经过执行 SELECT UNIX_TIMESTAMP() 函数来得到当前主库的系统时间。若是这时候发现主库的系统时间与本身不一致，备库在执行seconds_behind_master 计算的时候会自动扣掉这个差值。

须要说明的是，在网络正常的时候，日志从主库传给备库所需的时间是很短的，即 T2-T1的值是很是小的。也就是说，网络正常状况下，主备延迟的主要来源是备库接收完 binlog和执行完这个事务之间的时间差。因此说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产binlog 的速度要慢。

主备延迟的来源

备库所在机器的性能要比主库所在的机器性能差

备库的压力大

通常的想法是，主库既然提供了写能力，那么备库能够提供一些读能力。或者一些运营后台须要的分析语句，不能影响正常业务，因此只能在备库上跑。
这种状况，咱们通常能够这么处理：

1. 一主多从。除了备库外，能够多接几个从库，让这些从库来分担读的压力。
2. 经过 binlog 输出到外部系统，好比 Hadoop 这类系统，让外部系统提供统计类查询的能力。

其中，一主多从的方式大都会被采用。由于做为数据库系统，还必须保证有按期全量备份的能力。而从库，就很适合用来作备份。从库和备库在概念上其实差很少。

大事务

由于主库上必须等事务执行完成才会写入 binlog，再传给备库。因此，若是一个主库上的语句执行 10 分钟，那这个事务极可能就会致使从库延迟 10分钟。不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。

好比，一些归档类的数据，平时没有注意删除历史数据，等到空间快满了，业务开发人员要一次性地删掉大量历史数据。同时，又由于要避免在高峰期操做会影响业务（至少有这个意识仍是很不错的），因此会在晚上执行这些大量数据的删除操做。

另外一种典型的大事务场景，就是大表 DDL。

备库的并行复制能力

可靠性优先策略

在图 1 的双 M 结构下，从状态 1 到状态 2 切换的详细过程是这样的：

1. 判断备库 B 如今的 seconds_behind_master，若是小于某个值（好比 5 秒）继续下一步，不然持续重试这一步；
2. 把主库 A 改为只读状态，即把 readonly 设置为 true；
3. 判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
4. 把备库 B 改为可读写状态，也就是把 readonly 设置为 false；
5. 把业务请求切到备库 B。

这个切换流程，通常是由专门的 HA 系统来完成的，咱们暂时称之为可靠性优先流程。

备注：图中的 SBM，是 seconds_behind_master 参数的简写。

能够看到，这个切换流程中是有不可用时间的。由于在步骤 2 以后，主库 A 和备库 B 都处于 readonly 状态，也就是说这时系统处于不可写状态，直到步骤 5 完成后才能恢复。在这个不可用状态中，比较耗费时间的是步骤 3，可能须要耗费好几秒的时间。这也是为何须要在步骤 1 先作判断，确保 seconds_behind_master 的值足够小。
试想若是一开始主备延迟就长达 30 分钟，而不先作判断直接切换的话，系统的不可用时间就会长达 30 分钟，这种状况通常业务都是不可接受的。固然，系统的不可用时间，是由这个数据可靠性优先的策略决定的。你也能够选择可用性优先的策略，来把这个不可用时间几乎降为 0。

可用性优先策略

若是我强行把步骤 四、5 调整到最开始执行，也就是说不等主备数据同步，直接把链接切到备库 B，而且让备库 B 能够读写，那么系统几乎就没有不可用时间了。咱们把这个切换流程，暂时称做可用性优先流程。这个切换流程的代价，就是可能出现数据不一致的状况。

insert into t(c) values(4); insert into t(c) values(5);
假设，如今主库上其余的数据表有大量的更新，致使主备延迟达到 5 秒。在插入一条 c=4的语句后，发起了主备切换。
下图是可用性优先策略，且binlog_format=mixed时的切换流程和数据结果。

如今，咱们一块儿分析下这个切换流程：

1. 步骤 2 中，主库 A 执行完 insert 语句，插入了一行数据（4,4），以后开始进行主备切换。
2. 步骤 3 中，因为主备之间有 5 秒的延迟，因此备库 B 还没来得及应用“插入 c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。3. 步骤 4 中，备库 B 插入了一行数据（4,5），而且把这个 binlog 发给主库 A。
3. 步骤 5 中，备库 B 执行“插入 c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库 B 执行的“插入 c=5”这个语句，传到主库 A，就插入了一行新数据（5,5）。

最后的结果就是，主库 A 和备库 B 上出现了两行不一致的数据。能够看到，这个数据不一致，是由可用性优先流程致使的。

可用性优先策略，但设置 binlog_format=row
由于 row 格式在记录 binlog 的时候，会记录新插入的行的全部字段值，因此最后只会有一行不一致。并且，两边的主备同步的应用线程会报错 duplicate key error 并中止。也就是说，这种状况下，备库 B 的 (5,4) 和主库 A 的 (5,5) 这两行数据，都不会被对方执行。
从上面的分析中，你能够看到一些结论：

1. 使用 row 格式的 binlog 时，数据不一致的问题更容易被发现。而使用 mixed 或者statement 格式的 binlog 时，数据极可能悄悄地就不一致了。若是你过了好久才发现数据不一致的问题，极可能这时的数据不一致已经不可查，或者连带形成了更多的数据逻辑不一致。
2. 主备切换的可用性优先策略会致使数据不一致。所以，大多数状况下，我都建议你使用可靠性优先策略。毕竟对数据服务来讲的话，数据的可靠性通常仍是要优于可用性的。

可用性优先级更高的场景

有一个库的做用是记录操做日志。这时候，若是数据不一致能够经过 binlog 来修补，而这个短暂的不一致也不会引起业务问题。同时，业务系统依赖于这个日志写入逻辑，若是这个库不可写，会致使线上的业务操做没法执行。

这时候，你可能就须要选择先强行切换，过后再补数据的策略。固然，过后复盘的时候，咱们想到了一个改进措施就是，让业务逻辑不要依赖于这类日志的写入。也就是说，日志写入这个逻辑模块应该能够降级，好比写到本地文件，或者写到另一个临时库里面。

按照可靠性优先的思路，异常切换会是什么效果？

假设，主库 A 和备库 B 间的主备延迟是 30 分钟，这时候主库 A 掉电了，HA 系统要切换B 做为主库。咱们在主动切换的时候，能够等到主备延迟小于 5 秒的时候再启动切换，但这时候已经别无选择了。

采用可靠性优先策略的话，你就必须得等到备库 B 的 seconds_behind_master=0 以后，才能切换。但如今的状况比刚刚更严重，并非系统只读、不可写的问题了，而是系统处于彻底不可用的状态。由于，主库 A 掉电后，咱们的链接尚未切到备库 B。

能不能直接切换到备库 B，可是保持 B 只读呢？这样也不行。由于，这段时间内，中转日志尚未应用完成，若是直接发起主备切换，客户端查询看不到以前执行完成的事务，会认为有“数据丢失”。虽然随着中转日志的继续应用，这些数据会恢复回来，可是对于一些业务来讲，查询到“暂时丢失数据的状态”也是不能被接受的。

在知足数据可靠性的前提下，MySQL 高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，在主库故障的时候，服务恢复须要的时间就越短，可用性就越高。

十6、备库为何会延迟好几个小时？

谈到主备的并行复制能力，咱们要关注的是图中黑色的两个箭头。一个箭头表明了客户端写入主库，另外一箭头表明的是备库上 sql_threa 执行中转日志（relay log）。若是用箭头的粗细来表明并行度的话，那么真实状况就如图 1 所示，第一个箭头要明显粗于第二个箭头。

在主库上，影响并发度的缘由就是各类锁了。因为 InnoDB 引擎支持行锁，除了全部并发事务都在更新同一行（热点行）这种极端场景外，它对业务并发度的支持仍是很友好的。因此，你在性能测试的时候会发现，并发压测线程 32 就比单线程时，整体吞吐量高。

而日志在备库上的执行，就是图中备库上 sql_thread 更新数据 (DATA) 的逻辑。若是是用单线程的话，就会致使备库应用日志不够快，形成主备延迟。

MySQL 多线程复制

coordinator 就是原来的 sql_thread, 不过如今它再也不直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，变成了 worker 线程。而 work 线程的个数，就是由参数 slave_parallel_workers 决定的。根据个人经验，把这个值设置为 8~16 之间最好（32 核物理机的状况），毕竟备库还有可能要提供读查询，不能把 CPU 都吃光了。

事务能不能按照轮询的方式分发给各个 worker，也就是第一个事务分给 worker_1，第二个事务发给 worker_2 呢？
实际上是不行的。由于，事务被分发给 worker 之后，不一样的 worker 就独立执行了。可是，因为 CPU 的调度策略，极可能第二个事务最终比第一个事务先执行。而若是这时候恰好这两个事务更新的是同一行，也就意味着，同一行上的两个事务，在主库和备库上的执行顺序相反，会致使主备不一致的问题。

同一个事务的多个更新语句，能不能分给不一样的worker 来执行呢？
也不行。举个例子，一个事务更新了表 t1 和表 t2 中的各一行，若是这两条更新语句被分到不一样 worker 的话，虽然最终的结果是主备一致的，但若是表 t1 执行完成的瞬间，备库上有一个查询，就会看到这个事务“更新了一半的结果”，破坏了事务逻辑的隔离性。

因此，coordinator 在分发的时候，须要知足如下这两个基本要求：

1. 不能形成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个 worker中。
2. 同一个事务不能被拆开，必须放到同一个 worker 中。

MySQL 5.6 版本的并行复制策略

官方 MySQL5.6 版本，支持了并行复制，只是支持的粒度是按库并行。理解了上面介绍的按表分发策略和按行分发策略，你就理解了，用于决定分发策略的 hash 表里，key 就是数据库名。

这个策略的并行效果，取决于压力模型。若是在主库上有多个 DB，而且各个 DB 的压力均衡，使用这个策略的效果会很好。相比于按表和按行分发，这个策略有两个优点：

1. 构造 hash 值的时候很快，只须要库名；并且一个实例上 DB 数也不会不少，不会出现须要构造 100 万个项这种状况。
2. 不要求 binlog 的格式。由于 statement 格式的 binlog 也能够很容易拿到库名。

可是，若是你的主库上的表都放在同一个 DB 里面，这个策略就没有效果了；或者若是不一样DB 的热点不一样，好比一个是业务逻辑库，一个是系统配置库，那也起不到并行的效果。理论上你能够建立不一样的 DB，把相同热度的表均匀分到这些不一样的 DB 中，强行使用这个策略。不过据我所知，因为须要特意移动数据，这个策略用得并很少。

MySQL 5.7 的并行复制策略

由参数slave-parallel-type 来控制并行复制策略：

1. 配置为 DATABASE，表示使用 MySQL 5.6 版本的按库并行策略；
2. 配置为 LOGICAL_CLOCK，表示的就是相似 MariaDB 的策略。不过，MySQL 5.7 这个策略，针对并行度作了优化。这个优化的思路也颇有趣儿。

同时处于“执行状态”的全部事务，是否是能够并行？不能。由于，这里面可能有因为锁冲突而处于锁等待状态的事务。若是这些事务在备库上被分配到不一样的 worker，就会出现备库跟主库不一致的状况。

两阶段提交细化过程图。

其实，不用等到 commit 阶段，只要可以到达 redo log prepare 阶段，就表示事务已经经过锁冲突的检验了。所以，MySQL 5.7 并行复制策略的思想是：

1. 同时处于 prepare 状态的事务，在备库执行时是能够并行的；
2. 处于 prepare 状态的事务，与处于 commit 状态的事务之间，在备库执行时也是能够并行的。

binlog 的组提交，有两个参数：

1. binlog_group_commit_sync_delay 参数，表示延迟多少微秒后才调用 fsync;
2. binlog_group_commit_sync_no_delay_count 参数，表示累积多少次之后才调用fsync。

这两个参数是用于故意拉长 binlog 从 write 到 fsync 的时间，以此减小 binlog 的写盘次数。在 MySQL 5.7 的并行复制策略里，它们能够用来制造更多的“同时处于 prepare 阶段的事务”。这样就增长了备库复制的并行度。也就是说，这两个参数，既能够“故意”让主库提交得慢些，又可让备库执行得快些。在MySQL 5.7 处理备库延迟的时候，能够考虑调整这两个参数值，来达到提高备库复制并发度的目的。

MySQL 5.7.22 的并行复制策略

MySQL 增长了一个新的并行复制策略，基于 WRITESET 的并行复制。
相应地，新增了一个参数 binlog-transaction-dependency-tracking，用来控制是否启用这个新策略。这个参数的可选值有如下三种。

1. COMMIT_ORDER，表示的就是前面介绍的，根据同时进入 prepare 和 commit 来判断是否能够并行的策略。
2. WRITESET，表示的是对于事务涉及更新的每一行，计算出这一行的 hash 值，组成集合writeset。若是两个事务没有操做相同的行，也就是说它们的 writeset 没有交集，就能够并行。
3. WRITESET_SESSION，是在 WRITESET 的基础上多了一个约束，即在主库上同一个线程前后执行的两个事务，在备库执行的时候，要保证相同的前后顺序。

固然为了惟一标识，这个 hash 值是经过“库名 + 表名 + 索引名 + 值”计算出来的。若是一个表上除了有主键索引外，还有其余惟一索引，那么对于每一个惟一索引，insert 语句对应的 writeset 就要多增长一个 hash 值。你可能看出来了，这跟咱们前面介绍的基于 MySQL 5.5 版本的按行分发的策略是差很少的。不过，MySQL 官方的这个实现仍是有很大的优点：

1. writeset 是在主库生成后直接写入到 binlog 里面的，这样在备库执行的时候，不须要解析 binlog 内容（event 里的行数据），节省了不少计算量；
2. 不须要把整个事务的 binlog 都扫一遍才能决定分发到哪一个 worker，更省内存；
3. 因为备库的分发策略不依赖于 binlog 内容，因此 binlog 是 statement 格式也是能够的。

所以，MySQL 5.7.22 的并行复制策略在通用性上仍是有保证的。固然，对于“表上没主键”和“外键约束”的场景，WRITESET 策略也是无法并行的，也会暂时退化为单线程模型。

十7、主库出问题了，从库怎么办？

以下图所示，就是一个基本的一主多从结构。

图中，虚线箭头表示的是主备关系，也就是 A 和 A’互为主备， 从库 B、C、D 指向的是主库 A。一主多从的设置，通常用于读写分离，主库负责全部的写入和一部分读，其余的读请求则由从库分担。

以下图所示，就是主库发生故障，主备切换后的结果。

相比于一主一备的切换流程，一主多从结构在切换完成后，A’会成为新的主库，从库 B、C、D 也要改接到 A’。正是因为多了从库 B、C、D 从新指向的这个过程，因此主备切换的复杂性也相应增长了。

基于位点的主备切换

当咱们把节点 B 设置成节点 A’的从库的时候，须要执行一条 change master 命令：

CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$por
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
MASTER_LOG_FILE=$master_log_name 
MASTER_LOG_POS=$master_log_po

MASTER_HOST、MASTER_PORT、MASTER_USER 和 MASTER_PASSWORD 四个参数，分别表明了主库 A’的 IP、端口、用户名和密码。最后两个参数 MASTER_LOG_FILE 和 MASTER_LOG_POS 表示，要从主库的master_log_name 文件的 master_log_pos 这个位置的日志继续同步。而这个位置就是咱们所说的同步位点，也就是主库对应的文件名和日志偏移量。

节点 B 要设置成 A’的从库，就要执行 change master 命令，就不可避免地要设置位点的这两个参数，可是这两个参数到底应该怎么设置呢？

原来节点 B 是 A 的从库，本地记录的也是 A 的位点。可是相同的日志，A 的位点和 A’的位点是不一样的。所以，从库 B 要切换的时候，就须要先通过“找同步位点”这个逻辑。这个位点很难精确取到，只能取一个大概位置。为何这么说呢？考虑到切换过程当中不能丢数据，因此咱们找位点的时候，老是要找一个“稍微往前”的，而后再经过判断跳过那些在从库 B 上已经执行过的事务。一种取同步位点的方法是这样的：

1. 等待新主库 A’把中转日志（relay log）所有同步完成；
2. 在 A’上执行 show master status 命令，获得当前 A’上最新的 File 和 Position；
3. 取原主库 A 故障的时刻 T；
4. 用 mysqlbinlog 工具解析 A’的 File，获得 T 时刻的位点。

mysqlbinlog File --stop-datetime=T --start-datetime=T

图中，end_log_pos 后面的值“123”，表示的就是 A’这个实例，在 T 时刻写入新的binlog 的位置。而后，咱们就能够把 123 这个值做为 $master_log_pos ，用在节点 B 的change master 命令里。

固然这个值并不精确。为何呢？你能够设想有这么一种状况，假设在 T 这个时刻，主库 A 已经执行完成了一个 insert 语句插入了一行数据 R，而且已经将 binlog 传给了 A’和 B，而后在传完的瞬间主库 A 的主机就掉电了。那么，这时候系统的状态是这样的：

1. 在从库 B 上，因为同步了 binlog， R 这一行已经存在；
2. 在新主库 A’上， R 这一行也已经存在，日志是写在 123 这个位置以后的；
3. 咱们在从库 B 上执行 change master 命令，指向 A’的 File 文件的 123 位置，就会把插入 R 这一行数据的 binlog 又同步到从库 B 去执行。

这时候，从库 B 的同步线程就会报告 Duplicate entry ‘id_of_R’ for key ‘PRIMARY’错误，提示出现了主键冲突，而后中止同步。因此，一般状况下，咱们在切换任务的时候，要先主动跳过这些错误，有两种经常使用的方法。
一种作法是，主动跳过一个事务。跳过命令的写法是：
set global sql_slave_skip_counter=1; start slave;
由于切换过程当中，可能会不止重复执行一个事务，因此咱们须要在从库 B 刚开始接到新主库 A’时，持续观察，每次碰到这些错误就停下来，执行一次跳过命令，直到再也不出现停下来的状况，以此来跳过可能涉及的全部事务。

另一种方式是，经过设置 slave_skip_errors 参数，直接设置跳过指定的错误。在执行主备切换时，有这么两类错误，是常常会遇到的：1062 错误是插入数据时惟一键冲突；1032 错误是删除数据时找不到行。

所以，咱们能够把 slave_skip_errors 设置为 “1032,1062”，这样中间碰到这两个错误时就直接跳过。这里须要注意的是，这种直接跳过指定错误的方法，针对的是主备切换时，因为找不到精确的同步位点，因此只能采用这种方法来建立从库和新主库的主备关系。这个背景是，咱们很清楚在主备切换过程当中，直接跳过 1032 和 1062 这两类错误是无损的，因此才能够这么设置 slave_skip_errors 参数。等到主备间的同步关系创建完成，并稳定执行一段时间以后，咱们还须要把这个参数设置为空，以避免以后真的出现了主从数据不一致，也跳过了。

GTID

经过 sql_slave_skip_counter 跳过事务和经过 slave_skip_errors 忽略错误的方法，虽然都最终能够创建从库 B 和新主库 A’的主备关系，但这两种操做都很复杂，并且容易出错。因此，MySQL 5.6 版本引入了 GTID，完全解决了这个困难。

GTID 的全称是 Global Transaction Identifier，也就是全局事务 ID，是一个事务在提交的时候生成的，是这个事务的惟一标识。它由两部分组成，格式是：GTID=server_uuid:gno
server_uuid 是一个实例第一次启动时自动生成的，是一个全局惟一的值；gno 是一个整数，初始值是 1，每次提交事务的时候分配给这个事务，并加 1。

在 MySQL 的官方文档里，GTID 格式是这么定义的：
GTID=source_id:transaction_id
这里的 source_id 就是 server_uuid；然后面的这个 transaction_id，我以为容易形成误导，因此我改为了 gno。为何说使用 transaction_id 容易形成误解呢？由于，在 MySQL 里面咱们说 transaction_id 就是指事务 id，事务 id 是在事务执行过程当中分配的，若是这个事务回滚了，事务 id 也会递增，而 gno 是在事务提交的时候才会分配。从效果上看，GTID 每每是连续的，所以咱们用 gno 来表示更容易理解。

TID 模式的启动也很简单，咱们只须要在启动一个 MySQL 实例的时候，加上参数gtid_mode=on 和 enforce_gtid_consistency=on 就能够了。在 GTID 模式下，每一个事务都会跟一个 GTID 一一对应。这个 GTID 有两种生成方式，而使用哪一种方式取决于 session 变量 gtid_next 的值。

1. 若是 gtid_next=automatic，表明使用默认值。这时，MySQL 就会把server_uuid:gno 分配给这个事务。a. 记录 binlog 的时候，先记录一行 SET@@SESSION.GTID_NEXT=‘server_uuid:gno’;b. 把这个 GTID 加入本实例的 GTID 集合。1GTID=server_uuid:gno复制代码server_uuid 是一个实例第一次启动时自动生成的，是一个全局惟一的值；gno 是一个整数，初始值是 1，每次提交事务的时候分配给这个事务，并加 1。1GTID=source_id:transaction_id复制代码
2. 若是 gtid_next 是一个指定的 GTID 的值，好比经过 set gtid_next='current_gtid’指定为 current_gtid，那么就有两种可能：a. 若是 current_gtid 已经存在于实例的 GTID 集合中，接下来执行的这个事务会直接被系统忽略；b. 若是 current_gtid 没有存在于实例的 GTID 集合中，就将这个 current_gtid 分配给接下来要执行的事务，也就是说系统不须要给这个事务生成新的 GTID，所以 gno 也不用加 1。

注意，一个 current_gtid 只能给一个事务使用。这个事务提交后，若是要执行下一个事务，就要执行 set 命令，把 gtid_next 设置成另一个 gtid 或者 automatic。这样，每一个 MySQL 实例都维护了一个 GTID 集合，用来对应“这个实例执行过的全部事务”。

接下来我就用一个简单的例子，来和你说明 GTID 的基本用法。咱们在实例 X 中建立一个表 t。

CREATE TABLE `t` (  
    `id` int(11) NOT NULL,  
    `c` int(11) DEFAULT NULL,  
    PRIMARY KEY (`id`)
    ) ENGINE=InnoDB;
insert into t values(1,1);

能够看到，事务的 BEGIN 以前有一条 SET @@SESSION.GTID_NEXT 命令。这时，若是实例 X 有从库，那么将 CREATE TABLE 和 insert 语句的 binlog 同步过去执行的话，执行事务以前就会先执行这两个 SET 命令， 这样被加入从库的 GTID 集合的，就是图中的这两个 GTID。假设，如今这个实例 X 是另一个实例 Y 的从库，而且此时在实例 Y 上执行了下面这条插入语句：
insert into t values(1,1);

而且，这条语句在实例 Y 上的 GTID 是 “aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”。那么，实例 X 做为 Y 的从库，就要同步这个事务过来执行，显然会出现主键冲突，致使实例 X 的同步线程中止。这时，咱们应该怎么处理呢？处理方法就是，你能够执行下面的这个语句序列：

set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';
begin;
commit;
set gtid_next=automatic;
start slave;

其中，前三条语句的做用，是经过提交一个空事务，把这个 GTID 加到实例 X 的 GTID 集合中。如图 5 所示，就是执行完这个空事务以后的 show master status 的结果。

能够看到实例 X 的 Executed_Gtid_set 里面，已经加入了这个 GTID。

这样，我再执行 start slave 命令让同步线程执行起来的时候，虽然实例 X 上仍是会继续执行实例 Y 传过来的事务，可是因为“aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”已经存在于实例 X 的 GTID 集合中了，因此实例 X 就会直接跳过这个事务，也就不会再出现主键冲突的错误。在上面的这个语句序列中，start slave 命令以前还有一句 set gtid_next=automatic。这句话的做用是“恢复 GTID 的默认分配行为”，也就是说若是以后有新的事务再执行，就仍是按照原来的分配方式，继续分配 gno=3。

基于 GTID 的主备切换

在 GTID 模式下，备库 B 要设置为新主库 A’的从库的语法以下：

CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
master_auto_position=1

其中，master_auto_position=1 就表示这个主备关系使用的是 GTID 协议。能够看到，前面让咱们头疼不已的 MASTER_LOG_FILE 和 MASTER_LOG_POS 参数，已经不须要指定了。咱们把如今这个时刻，实例 A’的 GTID 集合记为 set_a，实例 B 的 GTID 集合记为set_b。接下来，咱们就看看如今的主备切换逻辑。

咱们在实例 B 上执行 start slave 命令，取 binlog 的逻辑是这样的：

1. 实例 B 指定主库 A’，基于主备协议创建链接。
2. 实例 B 把 set_b 发给主库 A’。
3. 实例 A’算出 set_a 与 set_b 的差集，也就是全部存在于 set_a，可是不存在于 set_b的 GTID 的集合，判断 A’本地是否包含了这个差集须要的全部 binlog 事务。a. 若是不包含，表示 A’已经把实例 B 须要的 binlog 给删掉了，直接返回错误；b. 若是确认所有包含，A’从本身的 binlog 文件里面，找出第一个不在 set_b 的事务，发给 B；
4. 以后就从这个事务开始，日后读文件，按顺序取 binlog 发给 B 去执行。

其实，这个逻辑里面包含了一个设计思想：在基于 GTID 的主备关系里，系统认为只要创建主备关系，就必须保证主库发给备库的日志是完整的。所以，若是实例 B 须要的日志已经不存在，A’就拒绝把日志发给 B。

这跟基于位点的主备协议不一样。基于位点的协议，是由备库决定的，备库指定哪一个位点，主库就发哪一个位点，不作日志的完整性判断。基于上面的介绍，咱们再来看看引入 GTID 后，一主多从的切换场景下，主备切换是如何实现的。因为不须要找位点了，因此从库 B、C、D 只须要分别执行 change master 命令指向实例A’便可。

其实，严谨地说，主备切换不是不须要找位点了，而是找位点这个工做，在实例 A’内部就已经自动完成了。但因为这个工做是自动的，因此对 HA 系统的开发人员来讲，很是友好。
以后这个系统就由新主库 A’写入，主库 A’的本身生成的 binlog 中的 GTID 集合格式是：server_uuid_of_A’:1-M。若是以前从库 B 的 GTID 集合格式是 server_uuid_of_A:1-N， 那么切换以后 GTID 集合的格式就变成了 server_uuid_of_A:1-N, server_uuid_of_A’:1-M。固然，主库 A’以前也是 A 的备库，所以主库 A’和从库 B 的 GTID 集合是同样的。这就达到了咱们预期。

GTID 和在线 DDL

业务高峰期的慢查询性能问题时，分析到若是是因为索引缺失引发的性能问题，咱们能够经过在线加索引来解决。可是，考虑到要避免新增索引对主库性能形成的影响，咱们能够先在备库加索引，而后再切换。

在双 M 结构下，备库执行的 DDL 语句也会传给主库，为了不传回后对主库形成影响，要经过 set sql_log_bin=off 关掉 binlog。
一个问题：这样操做的话，数据库里面是加了索引，可是 binlog 并无记录下这一个更新，是否是会致使数据和日志不一致？

假设，这两个互为主备关系的库仍是实例 X 和实例 Y，且当前主库是 X，而且都打开了GTID 模式。这时的主备切换流程能够变成下面这样：在实例 X 上执行 stop slave。
在实例 Y 上执行 DDL 语句。
执行完成后，查出这个 DDL 语句对应的 GTID，并记为 server_uuid_of_Y:gno。到实例 X 上执行如下语句序列：

set GTID_NEXT="server_uuid_of_Y:gno";
begin;
commit;
set gtid_next=automatic;
start slave;

这样作的目的在于，既可让实例 Y 的更新有 binlog 记录，同时也能够确保不会在实例 X上执行这条更新。接下来，执行完主备切换，而后照着上述流程再执行一遍便可。