一.一主多从的结构

 二.基于位点的主备切换

1.提供读服务的从库设置为备份库
 

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，MASTER_PORT.MASTER_USER和MASTER_PASSWORD四个参数，分别代表主库IP，端口，用户名和密码
• MASTER_LOG_FILE和MASTER_LOG_POSS，主库对应的文件名和日志偏移量

2.找同步位点方案一：

1. 等待新主库将中转日志（relay log）全部同步完成；
2. 在新主库执行show master status命令，得到最新的文件名和日志偏移量
3. 取原主库A故障时刻T
4. 用mysqlbinlog工具解析主库的文件，得到时刻的位点

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

存在问题：

      T时刻，主库执行完成一个insert语句插入一行数据R，并将binlog传给 备份库和从库，传完主库就掉电了

     系统的状态：

• 从库B，由于同步了binlog，R这行已经存在
• 新主库R这一行也 已经存在，日志时写在123这个 位置之后的
• 从库B上执行chang master命令，指向新主库file文件123位置，就会把插入R这一行数据的binlog又同步到从库B去执行。

从库B的同步线程会报告Duplicate entrity 'id_of_R' for key 'PRIMARY'提示主键冲突，停止同步

通常情况下，我们在切换任务的时候，要先主动跳过这些错误，有两种常用的方法。

解决方案：

      

set global sql_slave_skip_counter=1;
satrt salve;

每次碰到错误就停下来，执行一次跳过命令，直到不再出现停下的情况。

设置salve_skip_errprs参数

• 1062错误是插入数据时唯一键冲突
• 1032错误是删除数据时找不到行

slave_skip_errors 设置为 “1032,1062”

三.GTID

• GTID:Global Transaction  indentifier就是全局事务ID
• 是一个事务在提交的时候生成，是这个事务的唯一标识

GTID = server_uuid:transaction_id

为什么要有GTID

• 在主从复制时，master的dump进程要一边发送binlog给salve，一边等待slave的ack消息，这个过程是同步串行的
• 通过GTID，salve直接通过数据流获得GTID信息

优点：

• 根据GITD可以快速的确定事务最初在哪个实例上提交
• 简单的实现failover，不需要在找文件和日志偏移量
• 简单的搭建主从复制，确保每个事务都会被执行一次
• 一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或主从不一致
• GTID是连续的没有空洞的保证数据的一致性，零丢失
• GTID用来替代classic的复制方法，不再使用binlog+pos开启复制，而是master_auto_postion=1 的方式自动匹配 GTID 断点进行复制
• GTID让DBA在集群变迁时更加方便