Mysql主从复制-从机Crash

mysql主从复制相关参数

--server-id：未指定，默认为0的情况类似；

--replicate-same-server-id：指定主从的uuid相同；

SET @@ auto_increment_increment =10，设置auto_increment属性列的步长；

auto_increment_offset决定了AUTO_INCREMENT列的起始值

在auto_increment_offset大于auto_increment_increment的情况下，offset值被忽略；

建立原生主从复制

从机上面进行CHANGE MASTER TO操作，如下：

CHANGE MASTER TO MASTER_HOST='主节点IP',MASTER_USER=‘用于复制的用账号',MASTER_PASSWORD='密码',MASTER_PORT=主节点端口,MASTER_AUTO_POSITION=1;

从机上执行可执行如下操作：

--replicate-*：这类命令只有在从机起来后才能够进行设置；

--log-slave-updates：设置从写入执行的更新到从自己的binlog，即A->B->C其中B同时为主、从的情况

--slave_parallel_workers：设置从并行回放的线程数

--slave-parallel-type：当使用多线程并行回放时，用于指定哪类事务被执行，其取值可分为：LOGICAL_CLOCK，mysql5.6及之前版本只支持库级别的并行回放；

在设置了slave_preserve_commit_order=1的情况下，只能够使用 LOGICAL_CLOCK；

mysql5.7多线程并行复制

需要在从节点上执行如下设置

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-type=DATABASE #兼容MySQL 5.6基于schema级别的并发复制

slave-parallel-workers=4 ＃开启多线程复制

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

从节点中途宕机

从I/O 线程中恢复过来的信息存于表 mysql.slave_master_info中；

从SQL 线程中恢复过来的信息存于表 mysql.slave_relay_log_info中；

在GTID模式下，从机使用多线程进行回放

场景1：MASTER_AUTO_POSITION开启，设置 relay_log_recovery=0. 其他变量降不会影响恢复；

场景2：用位置点进行复制，建议设置 relay_log_recovery=1,sync_relay_log=1（多线程）, 及relay_log_info_repository=TABLE.sync_relay_log=1表示每一个事务都会被刷到relay log中；

数据可能出现的不一致的情况

场景1 半回放

一个事务更新非事务表，部分数据已经被更新；

场景2 间隙gaps

一个事务没有被完全回放完，后面的事务提前回放了；

消除这种gaps的方法：设置slave_preserve_commit_order=1，这同时要求 slave_parallel_type=LOGICAL_CLOCK, 并且使能log-bin 和log-slave-update.

场景3 Gap-free low-watermark position

多线程复制可能产生gtid gap和Gap-free low-watermark position，这会导致Salve上重复已经回放过的event。后果就是数据不一致或者复制中断，除非设置binlog格式为row模式并且设置slave_exec_mode=IDEMPOTENT和slave_exec_mode=IDEMPOTENT，允许Slave回放binlog时忽略重复键和找不到键的错误，使得binlog回放具有幂等性，但这也意味着如果真的出现了主备数据不一致也会被它忽略。

多线程复制还会存在一个问题：已经事务已经提交，但是位置还没更新；

在基于logical_clock的MTS场景下，用户可以通过配置参数slave_preserve_commit_order=1 来保证提交的顺序性；参见官网：数据一致性的分析讨论，参见链接