一、一主多从结构：
1、一主多从基本结构：
![]()
一主多从基本结构
2、图的含义：
虚线箭头表示的是主备关系，也就是A和A'互为主备， 从库B、C、D指向的是主库A。一主多从的设置，一般用于读写分离，主库负责所有的写入和一部分读，其他的读请求则由从库分担。
二、主库发生故障时的主备切换：
1、
![]()
2、切换过程：
<1>、MySQL 5.6版本之前的方法：
(1)、当把节点B设置成节点A'的从库的时候，需要执行一条change master命令：
CHANGE MASTER TO
MASTER_HOST=$host_name
MASTER_PORT=$port
MASTER_USER=$user_name
MASTER_PASSWORD=$password
MASTER_LOG_FILE=$master_log_name
MASTER_LOG_POS=$master_log_pos
其中，
MASTER_HOST表示主库A'的IP
MASTER_PORT表示主库A'的端口
MASTER_USER表示主库A'的用户名
MASTER_PASSWORD表示主库A'的密码
MASTER_LOG_FILE和MASTER_LOG_POS表示，要从主库的master_log_name文件的master_log_pos这个位置的日志继续同步。而这个位置就是同步位点，也就是主库对应的文件名和日志偏移量。
<2>、取同步位点的方法：
①、等待新主库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后面的值表示的就是A'这个实例，在T时刻写入新的binlog的位置。可以把1这个值作为$master_log_pos ，用在节点B的change master命令里。
(3)、切换任务时主动跳过错误的两种常用的方法：
①、主动跳过一个事务。
set global sql_slave_skip_counter=1;
start slave;
每次碰到这些错误就停下来，执行一次跳过命令，直到不再出现停下来的情况，以此来跳过可能涉及的所有事务。
②、设置slave_skip_errors参数，直接设置跳过指定的错误。
执行主备切换时，经常遇到的两类错误：
1062错误：插入数据时唯一键冲突；
1032错误：删除数据时找不到行。
因此，把slave_skip_errors 设置为 “1032,1062”，这样中间碰到这两个错误时就直接跳过。
<2>、MySQL 5.6版本之后的方法：GTID
(1)、GTID的含义：
GTID的全称是Global Transaction Identifier，也就是全局事务ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。它由两部分组成，格式是：
GTID=server_uuid:gno
其中：
server_uuid是一个实例第一次启动时自动生成的，是一个全局唯一的值；
gno是一个整数，初始值是1，每次提交事务的时候分配给这个事务，并加1。
(2)、GTID模式的启动方法：
在启动一个MySQL实例的时候，加上参数gtid_mode=on和enforce_gtid_consistency=on。
(3)、GTID的生成方式：
有两种生成方式，使用哪种方式取决于session变量gtid_next的值。
如果
gtid_next=automatic，代表使用默认值。这时，MySQL就会把server_uuid:gno分配给这个事务。
a. 记录binlog的时候，先记录一行 SET@@SESSION.GTID_NEXT=‘server_uuid:gno’;
b. 把这个GTID加入本实例的GTID集合。
如果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。
3、基于GTID的主备切换：
<1>、在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协议。
<2>、假设此时实例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的GITD的集合，判断A'本地是否包含了这个差集需要的所有binlog事务:
a. 如果不包含，表示A'已经把实例B需要的binlog给删掉了，直接返回错误；
b. 如果确认全部包含，A'从自己的binlog文件里面，找出第一个不在set_b的事务，发给B；
④、之后就从这个事务开始，往后读文件，按顺序取binlog发给B去执行。
这个逻辑里面包含了一个设计思想：在基于GTID的主备关系里，系统认为只要建立主备关系，就必须保证主库发给备库的日志是完整的。因此，如果实例B需要的日志已经不存在，A’就拒绝把日志发给B。
<3>、此时的主备切换过程为：
①、从库B、C、D只需要分别执行change master命令指向实例A'。
②、之后这个系统就由新主库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集合是一样的。这就达到了预期。
4、GTID和在线DDL:
假设两个互为主备关系的库是实例X和实例Y，且当前主库是X，并且都打开了GTID模式。这时的主备切换流程可以变成下面这样：
①、在实例X上执行stop slave。
②、在实例Y上执行DDL语句。注意，这里并不需要关闭binlog。
③、执行完成后，查出这个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上执行这条更新。
⑤、接下来，执行完主备切换，然后照着上述流程再执行一遍即可。
