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