关于mysql:Mysql-实战笔记-六-实践5

失常状况下，只有主库执行更新生成的所有 binlog，都能够传到备库并被正确地执行，备库就能达到跟主库统一的状态，这就是最终一致性。

主备切换可能是一个被动运维动作，比方软件降级、主库所在机器按计划下线等，也可能是被动操作，比方主库所在机器掉电。与数据同步无关的工夫点次要包含以下三个：

主库 A 执行实现一个事务，写入 binlog，咱们把这个时刻记为 T1;
之后传给备库 B，咱们把备库 B 接管完这个 binlog 的时刻记为 T2;
备库 B 执行实现这个事务，咱们把这个时刻记为 T3。

所谓主备提早，就是同一个事务，在备库执行实现的工夫和主库执行实现的工夫之间的差值，也就是 T3-T1。
能够在备库上执行show slave status 命令，它的返回后果外面会显示seconds_behind_master，用于示意以后备库提早了多少秒。seconds_behind_master 的计算方法是这样的：

每个事务的 binlog 外面都有一个工夫字段，用于记录主库上写入的工夫；
备库取出以后正在执行的事务的工夫字段的值，计算它与以后零碎工夫的差值，失去 seconds_behind_master。

不会的。因为，备库连贯到主库的时候，会通过执行 SELECT UNIX_TIMESTAMP() 函数来取得以后主库的零碎工夫。如果这时候发现主库的零碎工夫与本人不统一，备库在执行seconds_behind_master 计算的时候会主动扣掉这个差值。

须要阐明的是，在网络失常的时候，日志从主库传给备库所需的工夫是很短的，即 T2-T1 的值是十分小的。也就是说，网络失常状况下，主备提早的次要起源是备库接管完 binlog 和执行完这个事务之间的时间差。所以说，主备提早最间接的体现是，备库生产直达日志（relay log）的速度，比主库生产 binlog 的速度要慢。

个别的想法是，主库既然提供了写能力，那么备库能够提供一些读能力。或者一些经营后盾须要的剖析语句，不能影响失常业务，所以只能在备库上跑。
这种状况，咱们个别能够这么解决：

一主多从。除了备库外，能够多接几个从库，让这些从库来分担读的压力。
通过 binlog 输入到内部零碎，比方 Hadoop 这类零碎，让内部零碎提供统计类查问的能力。

其中，一主多从的形式大都会被采纳。因为作为数据库系统，还必须保障有定期全量备份的能力。而从库，就很适宜用来做备份。从库和备库在概念上其实差不多。

因为主库上必须等事务执行实现才会写入 binlog，再传给备库。所以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库提早 10 分钟。不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。

比方，一些归档类的数据，平时没有留神删除历史数据，等到空间快满了，业务开发人员要一次性地删掉大量历史数据。同时，又因为要防止在高峰期操作会影响业务（至多有这个意识还是很不错的），所以会在早晨执行这些大量数据的删除操作。

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

在图 1 的双 M 构造下，从状态 1 到状态 2 切换的具体过程是这样的：

判断备库 B 当初的 seconds_behind_master，如果小于某个值（比方 5 秒）持续下一步，否则继续重试这一步；
把主库 A 改成只读状态，即把 readonly 设置为 true；
判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
把业务申请切到备库 B。

这个切换流程，个别是由专门的 HA 零碎来实现的，咱们临时称之为可靠性优先流程。

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

能够看到，这个切换流程中是有不可用工夫的。因为在步骤 2 之后，主库 A 和备库 B 都处于 readonly 状态，也就是说这时零碎处于不可写状态，直到步骤 5 实现后能力复原。在这个不可用状态中，比拟消耗工夫的是步骤 3，可能须要消耗好几秒的工夫。这也是为什么须要在步骤 1 先做判断，确保 seconds_behind_master 的值足够小。
试想如果一开始主备提早就长达 30 分钟，而不先做判断间接切换的话，零碎的不可用工夫就会长达 30 分钟，这种状况个别业务都是不可承受的。当然，零碎的不可用工夫，是由这个数据可靠性优先的策略决定的。你也能够抉择可用性优先的策略，来把这个不可用工夫简直降为 0。

如果我强行把步骤 4、5 调整到最开始执行，也就是说不等主备数据同步，间接把连贯切到备库 B，并且让备库 B 能够读写，那么零碎简直就没有不可用工夫了。咱们把这个切换流程，临时称作可用性优先流程。这个切换流程的代价，就是可能呈现数据不统一的状况。

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

当初，咱们一起剖析下这个切换流程：

步骤 2 中，主库 A 执行完 insert 语句，插入了一行数据（4,4），之后开始进行主备切换。
步骤 3 中，因为主备之间有 5 秒的提早，所以备库 B 还没来得及利用“插入 c=4”这个直达日志，就开始接管客户端“插入 c=5”的命令。3. 步骤 4 中，备库 B 插入了一行数据（4,5），并且把这个 binlog 发给主库 A。
步骤 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) 这两行数据，都不会被对方执行。
从下面的剖析中，你能够看到一些论断：

应用 row 格局的 binlog 时，数据不统一的问题更容易被发现。而应用 mixed 或者 statement 格局的 binlog 时，数据很可能悄悄地就不统一了。如果你过了很久才发现数据不统一的问题，很可能这时的数据不统一曾经不可查，或者连带造成了更多的数据逻辑不统一。
主备切换的可用性优先策略会导致数据不统一。因而，大多数状况下，我都倡议你应用可靠性优先策略。毕竟对数据服务来说的话，数据的可靠性个别还是要优于可用性的。

有一个库的作用是记录操作日志。这时候，如果数据不统一能够通过 binlog 来修补，而这个短暂的不统一也不会引发业务问题。同时，业务零碎依赖于这个日志写入逻辑，如果这个库不可写，会导致线上的业务操作无奈执行。

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

假如，主库 A 和备库 B 间的主备提早是 30 分钟，这时候主库 A 掉电了，HA 零碎要切换 B 作为主库。咱们在被动切换的时候，能够等到主备提早小于 5 秒的时候再启动切换，但这时候曾经别无选择了。

采纳可靠性优先策略的话，你就必须得等到备库 B 的 seconds_behind_master=0 之后，能力切换。但当初的状况比刚刚更重大，并不是零碎只读、不可写的问题了，而是零碎处于齐全不可用的状态。因为，主库 A 掉电后，咱们的连贯还没有切到备库 B。

能不能间接切换到备库 B，然而放弃 B 只读呢？这样也不行。因为，这段时间内，直达日志还没有利用实现，如果间接发动主备切换，客户端查问看不到之前执行实现的事务，会认为有“数据失落”。尽管随着直达日志的持续利用，这些数据会复原回来，然而对于一些业务来说，查问到“临时失落数据的状态”也是不能被承受的。

在满足数据可靠性的前提下，MySQL 高可用零碎的可用性，是依赖于主备提早的。提早的工夫越小，在主库故障的时候，服务复原须要的工夫就越短，可用性就越高。

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

在主库上，影响并发度的起因就是各种锁了。因为 InnoDB 引擎反对行锁，除了所有并发事务都在更新同一行（热点行）这种极其场景外，它对业务并发度的反对还是很敌对的。所以，你在性能测试的时候会发现，并发压测线程 32 就比单线程时，总体吞吐量高。

而日志在备库上的执行，就是图中备库上 sql_thread 更新数据 (DATA) 的逻辑。如果是用单线程的话，就会导致备库利用日志不够快，造成主备提早。

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 在散发的时候，须要满足以下这两个根本要求：

不能造成更新笼罩。这就要求更新同一行的两个事务，必须被散发到同一个 worker 中。
同一个事务不能被拆开，必须放到同一个 worker 中。

官网 MySQL5.6 版本，反对了并行复制，只是反对的粒度是按库并行。了解了下面介绍的按表散发策略和按行散发策略，你就了解了，用于决定散发策略的 hash 表里，key 就是数据库名。

这个策略的并行成果，取决于压力模型。如果在主库上有多个 DB，并且各个 DB 的压力平衡，应用这个策略的成果会很好。相比于按表和按行散发，这个策略有两个劣势：

结构 hash 值的时候很快，只须要库名；而且一个实例上 DB 数也不会很多，不会呈现须要结构 100 万个项这种状况。
不要求 binlog 的格局。因为 statement 格局的 binlog 也能够很容易拿到库名。

然而，如果你的主库上的表都放在同一个 DB 外面，这个策略就没有成果了；或者如果不同 DB 的热点不同，比方一个是业务逻辑库，一个是系统配置库，那也起不到并行的成果。实践上你能够创立不同的 DB，把雷同热度的表平均分到这些不同的 DB 中，强行应用这个策略。不过据我所知，因为须要顺便挪动数据，这个策略用得并不多。

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

配置为 DATABASE，示意应用 MySQL 5.6 版本的按库并行策略；
配置为 LOGICAL_CLOCK，示意的就是相似 MariaDB 的策略。不过，MySQL 5.7 这个策略，针对并行度做了优化。这个优化的思路也很有趣儿。

同时处于“执行状态”的所有事务，是不是能够并行？不能。因为，这外面可能有因为锁抵触而处于锁期待状态的事务。如果这些事务在备库上被调配到不同的 worker，就会呈现备库跟主库不统一的状况。

两阶段提交细化过程图。

其实，不必等到 commit 阶段，只有可能达到 redo log prepare 阶段，就示意事务曾经通过锁抵触的测验了。因而，MySQL 5.7 并行复制策略的思维是：

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

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

binlog_group_commit_sync_delay 参数，示意提早多少微秒后才调用 fsync;
binlog_group_commit_sync_no_delay_count 参数，示意累积多少次当前才调用 fsync。

这两个参数是用于成心拉长 binlog 从 write 到 fsync 的工夫，以此缩小 binlog 的写盘次数。在 MySQL 5.7 的并行复制策略里，它们能够用来制作更多的“同时处于 prepare 阶段的事务”。这样就减少了备库复制的并行度。也就是说，这两个参数，既能够“成心”让主库提交得慢些，又能够让备库执行得快些。在 MySQL 5.7 解决备库提早的时候，能够思考调整这两个参数值，来达到晋升备库复制并发度的目标。

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

COMMIT_ORDER，示意的就是后面介绍的，依据同时进入 prepare 和 commit 来判断是否能够并行的策略。
WRITESET，示意的是对于事务波及更新的每一行，计算出这一行的 hash 值，组成汇合 writeset。如果两个事务没有操作雷同的行，也就是说它们的 writeset 没有交加，就能够并行。
WRITESET_SESSION，是在 WRITESET 的根底上多了一个束缚，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保障雷同的先后顺序。

当然为了惟一标识，这个 hash 值是通过“库名 + 表名 + 索引名 + 值”计算出来的。如果一个表上除了有主键索引外，还有其余惟一索引，那么对于每个惟一索引，insert 语句对应的 writeset 就要多减少一个 hash 值。你可能看进去了，这跟咱们后面介绍的基于 MySQL 5.5 版本的按行散发的策略是差不多的。不过，MySQL 官网的这个实现还是有很大的劣势：

writeset 是在主库生成后间接写入到 binlog 外面的，这样在备库执行的时候，不须要解析 binlog 内容（event 里的行数据），节俭了很多计算量；
不须要把整个事务的 binlog 都扫一遍能力决定散发到哪个 worker，更省内存；
因为备库的散发策略不依赖于 binlog 内容，所以 binlog 是 statement 格局也是能够的。

因而，MySQL 5.7.22 的并行复制策略在通用性上还是有保障的。当然，对于“表上没主键”和“外键束缚”的场景，WRITESET 策略也是没法并行的，也会临时进化为单线程模型。

如下图所示，就是一个根本的一主多从构造。

图中，虚线箭头示意的是主备关系，也就是 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 上曾经执行过的事务。一种取同步位点的办法是这样的：

期待新主库 A’把直达日志（relay log）全副同步实现；
在 A’上执行 show master status 命令，失去以后 A’上最新的 File 和 Position；
取原主库 A 故障的时刻 T；
用 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 的主机就掉电了。那么，这时候零碎的状态是这样的：

在从库 B 上，因为同步了 binlog，R 这一行曾经存在；
在新主库 A’上，R 这一行也曾经存在，日志是写在 123 这个地位之后的；
咱们在从库 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 参数。等到主备间的同步关系建设实现，并稳固执行一段时间之后，咱们还须要把这个参数设置为空，免得之后真的呈现了主从数据不统一，也跳过了。

通过 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 的值。

如果 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复制代码
如果 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 模式下，备库 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 的逻辑是这样的：

实例 B 指定主库 A’，基于主备协定建设连贯。
实例 B 把 set_b 发给主库 A’。
实例 A’算出 set_a 与 set_b 的差集，也就是所有存在于 set_a，然而不存在于 set_b 的 GTID 的汇合，判断 A’本地是否蕴含了这个差集须要的所有 binlog 事务。a. 如果不蕴含，示意 A’曾经把实例 B 须要的 binlog 给删掉了，间接返回谬误；b. 如果确认全副蕴含，A’从本人的 binlog 文件外面，找出第一个不在 set_b 的事务，发给 B；
之后就从这个事务开始，往后读文件，按程序取 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 汇合是一样的。这就达到了咱们预期。

业务高峰期的慢查问性能问题时，剖析到如果是因为索引缺失引起的性能问题，咱们能够通过在线加索引来解决。然而，思考到要防止新增索引对主库性能造成的影响，咱们能够先在备库加索引，而后再切换。

在双 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 上执行这条更新。接下来，执行完主备切换，而后照着上述流程再执行一遍即可。

关于mysql:Mysql-实战笔记-六-实践5

十五、MySQL 是怎么保障高可用的？

主备提早

如果主备库机器的零碎工夫设置不统一，会不会导致主备提早的值不准？

主备提早的起源

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

备库的压力大

大事务

备库的并行复制能力

可靠性优先策略

可用性优先策略

可用性优先级更高的场景

依照可靠性优先的思路，异样切换会是什么成果？

十六、备库为什么会提早好几个小时？

MySQL 多线程复制

MySQL 5.6 版本的并行复制策略

MySQL 5.7 的并行复制策略

MySQL 5.7.22 的并行复制策略

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

基于位点的主备切换

GTID

基于 GTID 的主备切换

GTID 和在线 DDL