复制中重要参数及优化
复制和性能相关的参数
master的配置优化
io_thread配置优化
sql_thread配置优化
复制中重要功能启用及注意事项
复制过滤及实战中注意事项
crash-safe replication配置(安全）
sync_relay_log*相关配置(安全)
延迟复制
多源复制
增强半同步复制配置及注意事项
==============================================================
5.7是针对主库上的并行去修复的
8.0是针对从库引用writeset
复制中重要参数
master配置优化
binlog_format=row
binlog_row_image=full
gtid_mode=on
enforce_gtid_consistency=on
binlog_group_commit_sync_delay=100
binlog_group_commit_sync_no_delay_count=10
binlog_order_commits=off
5.7.22后新增参数
transaction_write_set_extraction=on
binlog_transaction_dependency_tracking=COMMIT_ORDER(只能用到binlog group commit，用不到writeset)
binlog_transaction_dependency_history_size=2500
writeset和binlog group commit都是针对slave并行复制的，如果从库不开启并行复制，实际上没什么效果
json binlog优化
json部分更新记录binlog
binlog_row_image=image
binlog_row_value_options=PATIAL_JSON
binlog group commit
作用:提高主库写binlog并行度
控制参数
binlog_group_commit_sync_delay=100 -- 等待100毫秒一次commit（过大不一定带来性能提升）
binlog_group_commit_sync_no_delay_count=10 --十个事务一个group（看磁盘io性能，大了可能带来落盘比较慢的问题）
过程(三阶段三队列)
原理
binlog中引入：last_commited 和sequence_number
sequence_number是自身事务ID
last_commited是上一个事务提交的事务ID
如果两个事务的last_commited相同，说明两个事务是在同一个group内提交的
非binlog group commit处理过程
InnoDB prepare(redo+Xid)->write/sync binlog->innodb commit(filename,pos->redo日志封口)
并行度不高用不了 binlog group commit
8.0的WriteSet(针对从库)
binlog group commit是5.7引入，为了提高从从库的应用速度，在主库上尽量提高并行
8.0做的设计是针对从库，即使主库在串行提交的事务，只要不互相冲突，在slave上也可以并行回放：WriteSet
binlog_transaction_dependency_tracking=commit_order|writeset|writeset_session（推荐）
transaction_write_set_extraction(hash方法)
binlog_transaction_dependency_history_size(hash大小) --性能富余可以适当调大该参数，提高备库回放并行度，内存和cpu紧张的实例设置过大，会耗光内存，降低冲突查询的效率(建议保持不动)
需要配合并行复制(logical)
=====================================
MySQL 5.7.22+ 支持基于write-set的并行复制
# master
loose-binlog_transaction_dependency_tracking = WRITESET
loose-transaction_write_set_extraction = XXHASH64
binlog_transaction_dependency_history_size = 25000 #默认
#slave
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 32
====================================
io_thread
slave_net_timeout=20|30
io_thread更多的优化：change master to
master_connect_retry=60
master_connect_count=24*3600
master_auto_position=1
master_delay=0
master_bind='' (高速磁盘，pcie，单网卡1000M被打满，建议单独设置网卡)
sql_thread
log_slave_updates
slave-parallel-type = LOGICAL_CLOCK
slave-parallel-workers = 4|8
复制过滤
不要在主库上配置
复制中重要功能启用
复制crash-safe replication
relay log损坏的处理办法
gtid->reset slave;start slave;
sql_thread->relay_master_log_file,exec_master_log_pos
stop slave;change master to master_log_file=relay_master_log_file,master_log_pos=exec_master_log_pos ... ;
start slave io_thread;
原理：change master to会清理掉slave本地relay log，io_thread会重新拉取binlog
purge relay log可能失败的原因，没有被apply的relay log可能不能被purge掉
系统方法
5.6推出方法，默认没开启
relay_log_info_repository=table
relay_log_recovery=1
sync_relay_log_info=1 & relay_log_info_repository=file 这是一个性能杀手的配置，（每次sql_thread apply完一个日志后，os都会做fsync，磁盘随机io会很重）
正确的做法
sync_relay_log_info=1 & relay_log_info_repository=table
sync_master_info=1
如果使用了crash-safe replication这个参数（sync_relay_log_info）建议设置大点，提升性能
延迟复制
防止灾难发生，快速恢复，数据量超大
物理冷备份
硬件可以不用太好
多源复制
change master to ... for channel 'channelname'
启用multi-source replication
master_info_reposity=table
relay_log_info_repository=table
GTID
从管理方便上讲:
binlog_format=row
gtid_mode=on
增强半同步
ping 延迟小于20
加载plugin
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
master:
set global rpl_semi_sync_master_enabled=1;
set global rpl_semi_sync_master_timeout = 1000;
set global rpl_semi_sync_master_wait_for_slave_count = 1000;
set global rpl_semi_sync_master_wait_no_slave=on;
slave:
set global rpl_semi_sync_slave_enabled=1;
stop slave;start slave;
总结
增强半同步
rpl_semi_sync_master_wait_point=after_sync
