MySQL复制相关（持续更新）

2018-08-05 本文已影响58人 Hz37

一、异步复制

异步复制原理图

after commit

master:
- Dump_Thread，通知IO_Thread数据变更
slave:
- IO_Thread，拉取binlog增量
- SQL_Thread，SQL逻辑重放

异步复制流程

master 写undo、redo
master 发起commit，写binlog（filename，position）
master 完成提交事务
slave 通过IO_Thread拉取binlog的filename，position，并写入到本地的relaylog中
slave 通过SQL_Thread逻辑重放relaylog中的SQL（单线程）

两种场景

实时同步（IO_Thread主从没有延迟），写数据之前通知IO_Thread有变更，IO_Thread拉取binlog增量
主从长时间延迟（全备恢复），IO_Thread直接去主库本地磁盘拉取binlog增量

复制中的坑

row模式下，表最好是有主键，其次要有普通索引。否则sql_thread重放需要全表扫描匹配，速度非常慢（mysql5.7中做了优化）

sql_thread重放

二、半同步复制（MySQL 5.5 after commit）

半同步复制流程图

after commit

半同步复制流程

master 写undo、redo
master 发起commit，sync binlog（filename，position）
master 存储引擎commit完成
master_sender_thread 等待slave_reciver_thread返回ack（等待过程中会阻塞下一个事务）
master_sender_thread接收到slave_reciver_thread返回的ack，并返回给客户端，客户端才可以继续操作

after带来的三个问题

性能问题：AFTER_COMMIT半同步是单线程处理的，master把事务发送完毕后，要接受和处理slave的ack应答，处理完ack后才能继续发送下一个事务，对性能影响比较大
master commit完成后才开始等待slave的ACK，其实这个时候在master上事务已经提交完成并且其他客户端已经可以读到，只是提交该事物的客户端处于等待状态。
如果master等待ack时master crash，而slave又未接收到该事务的话，那么切换到从库后就会出现读取的结果不一致的情况（因为主库已commit而从库未收到该事务binlog）

三、增强半同步复制（MySQL 5.7 after sync）

增强半同步复制流程图

after sync

增强半同步复制流程

master 写undo、redo
master 发起commit，sync binlog（filename，position）
master 通过单独的semisync_reciver_thread等待slave_reciver_thread返回ack，此过程中master_sender_thread可以处理其他事务的请求
semisync_reciver_thread接收到slave_reciver_thread返回的ack，并返回给客户端
master 存储引擎层commit

增强半同步解决的问题

AFTER_SYNC采用双工处理，master采用单独semisync_reciver_thread处理ack应答，不阻塞其他事务，提升性能
AFTER_SYNC等待ack的操作是在引擎层commit之前处理，避免了其他客户端脏读
在等待ack的期间master crash，由于master引擎层未commit，如果slave未接受到该事务，那么数据是一致的

增强半同步带来的新问题

极端情况：在master sync binlog（写入xid）后，且在发送日志之前，这个时间master crash了。那么slave是没有拿到master的binlog增量的，而master重启后的crash recovery会认为该事务已写到binlog中，然后进行重做。这样就会导致主从不一致

5.7增强半同步配置

master

SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=ON;

slave

 install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
  set global rpl_semi_sync_slave_enabled=ON;

主要参数

mster：
- rpl_semi_sync_master_enabled=ON 表示在master上已经开启半同步复制模式。
- rpl_semi_sync_master_timeout=10000 该参数默认为10000毫秒，即10秒，可以调整，表示如果主库在某次事务中等待事件超过10秒，则降级为异步复制模式，不再等待slave，如果master探测到slave恢复，则会自动回到半同步模式。
- rpl_semi_sync_master_wait_no_slave=ON 表示是否允许master每个事务提交后都要等待slave的确认信号，默认是ON，即每一个事务都会等待，如果是OFF，则slave追赶上之后，也不会回到半同步模式。
- rpl_semi_sync_master_trace_level=32 表示开启半同步复制模式时的调试级别，默认是32

slave:
- rpl_semi_sync_slave_enabled=ON
- rpl_semi_sync_master_trace_level=32

四、并行复制

并行复制的演变

MySQL 5.6 是基于库级别的并行复制（适用于单实例多库而且库之间的写入分布比较平均的情况，比较鸡肋，可以忽略）
MySQL 5.7 是基于事务级别的并行复制（主要介绍）
MySQL 8.0 是基于行级别的并行复制（太新还没来得及研究，后面补上）

MySQL 5.7基于行的并行复制

原理：
与组提交结合，一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）。

复制中的重要参数

log-bin = /binlog_dir
binlog_format = row
binlog_row_image = full //默认full
gtid_mode = on
enforce_gtid_consistency = on //打开gtid之前必须打开此选项，服务器通过允许仅执行可使用GTID安全记录的语句来强制执行GTID一致性（开启后强制检测gtid一致性，在事务中更改非事务表将会报错）
binlog_group_commit_sync_delay = 100 //单位（微秒）。如果不启用组提交，则每次提交一个事务，binlog做一次fsync。如果启用了binlog-group-commit，此时sync_binlog=N代表每N组事务，而不是每N个事务。建议设置sync_binlog=1
binlog_group_commit_sync_no_delay_count = 10
binlog_order_commit = off //开启后事务提交顺序与binlog顺序一致，默认on，设置为off则事务可并行提交，对数据一致性可能产生影响。如果启用了binlog-group-commit，则设置为off
transaction_write_set_extraction = on //8.0特性，5.7默认off
binlog_transation_dependency_tracking = COMMIT_ORDER //等同于打开binlog_order_commit，基于行级别并行复制配置成writeset_session
binlog_transation_dependency_history_size = 25000 //控制队列长度
slave_net_timeout = 20|30 //io_thread超时时间
log_slave_updates
slave_parallel_type = LOGICAL_CLOCK //从库开启并行复制
slave_parallel_type = 4|8
slave_preserve_commit_order = on //保证从库提交顺序与主库一致，前置条件log-bin，log_slave_update，slave_parallel_type = LOGICAL_CLOCK
slave_rows_search_algorithms = TABLE_SCAN,INDEX_SCAN //配置成INDEX_SCAN,HASH_SCAN，当没主键的表复制中可以用hash索引
relay_log_info_reposity = table //crash-safe replication
sync_relay_log_info = 1
relay_log_recovery = 1