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