MySQL DBA 复制参数优化(十)
复制中重要参数及优化
复制和性能相关的参数
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