MySQL主从复制
MySQL主从复制
主从复制类型：
异步方式：一般的MySQL复制，主server只负责发送二进制日志，不check从是否完成
半同步方式：在一堆从中，主只保证其中一个返回同步完成即可，如果超时，自动降级为异步
级联方式：主复制给其中一个从，这个从再复制给后面的一堆从，用于减轻主的负担
架构：
普通一主多从：
带负载均衡的读写分离：
带级联复制和负载均衡的读写分离：
主从步骤：
- 主上面为每个slave开启一个dump thread
- 从上的IO thread和主上的dump thread连接，并发送二进制日志，在从上保存为realy log
- 从上的SQL thread从relay log中逐条读取并在本地执行
主从配置：
主上配置： - 开启binlog
- 设置server id
- 创建同步用户，并授予REPLICATION SLAVE和REPLICATION CLIENT权限
从上配置： - 开启relay log
- 设置与主不同的server id
- CHANGE MASTER TO MASTER_HOST='',MASTER_PORT=,MASTER_USER='',MASTER_PASSWORD='',MASTER_LOG_FILE='',MASTER_LOG_POS=;
- start slave io_thread;start slave sql_thread;
- 配置skip-slave-start=1
半同步配置： - 安装master/slave remi插件：INSTALL PLUGIN
- 启用master/slave remi插件
- 设置超时时间即可，超出此时长后自动降级为异步方式
同步过滤配置：
主上可选配置（不推荐，因为会导致二进制事件丢失）： - binlog-do-db: 二进制日志记录此库操作
- binlog-ingire-db: 二进制日志忽略此库操作
从上可选（推荐，但会导致不必要的性能消耗）： - replicate-do-db：同步此db
- replicate-ingire-db：忽略此db
- replicate-do-table：同步此表
- replicate-ingire-table：忽略此表
- replicate-wild-do-table=tb%：支持正则，同步tb开头的表
- replicate-wild-ingire-table=tb_：主持正则，忽略以tb开头后跟一个字符的表
基于GTID及多线程复制：
1、基于GTID是一种安全复制方式，MySQL5.6版本后支持全局事务ID，在复制是根据全局事务ID进行复制，在复制时从会反馈自己的复制状态以及记录复制了哪些语句，其他从也知道另外从的复制位置等，在主从切换时更安全。
2、多线程复制是基于多个库的，每个库一个单线程，多个库可以使用多个线程。
一、 什么是GTID （ Global transaction identifiers ）：
MySQL-5.6.2开始支持，MySQL-5.6.10后完善，GTID 分成两部分，一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中,
这是一个非常重要的文件，不能删除，这一部分是不会变的。另外一部分就是事务ID了，随着事务的增加，值一次递增,如下图
+---------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+--------------------------------------------+
| binlog.000029 | 23556 | | | 724afcc2-29d6-11e4-9902-000c290c0121:1-362 |
+---------------+----------+--------------+------------------+--------------------------------------------+
GTID:724afcc2-29d6-11e4-9902-000c290c0121:1-362
UUID:724afcc2-29d6-11e4-9902-000c290c0121
transactionId:1-362
在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。
例如：ServerA --->ServerB ---->ServerC
GTID从在ServerA ,ServerB,ServerC 中都是一样的。
二、 GTID的工作原理：
1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
三、 GTID的优点：
1.一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次
2.GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置
3.减少手工干预和降低服务故障时间，当主机挂了之后通过软件从众多的备机中提升一台备机为主机
那么GTID复制是怎么实现自动同步，自动对应位置的呢？
例如：ServerC <-----ServerA ----> ServerB
主机ServerA
备机:ServerB,ServerC
当主机ServerA 挂了之后 ，此时ServerB执行完了所有从ServerA 传过来的事务，
ServerC 延时一点。这个时候需要把 ServerB 提升为主机 ，Server C 继续为备机。
当ServerC 链接ServerC 之后,首先在自己的二进制文件中找到从ServerA 传过来的最新的GTID，
然后将这个GTID 发送到ServerB ,ServerB 获得这个GTID之后,就开始从这个GTID的下一个GTID
开始发送事务给ServerC。这种自我寻找复制位置的模式减少事务丢失的可能性以及故障恢复的时间。
四、 GTID的限制：
1.不支持非事务引擎
2.不支持create table ... select 语句复制(主库直接报错)
原理：（ 会生成两个sql，一个是DDL创建表SQL，一个是insert into 插入数据的sql。
由于DDL会导致自动提交，所以这个sql至少需要两个GTID，但是GTID模式下，只能给这个sql生成一个GTID ）
3.不允许一个SQL同时更新一个事务引擎表和非事务引擎表
4.在一个复制组中，必须要求统一开启GTID或者是关闭GTID
5.开启GTID需要重启（5.7除外）
6.开启GTID后，就不再使用原来的传统复制方式
7.对于create temporary table 和 drop temporary table语句不支持
8.不支持sql_slave_skip_counter