#####################################
随着业务的规模越来越大,数据库的读写压力也会越来越大,一般地,mysql的架构为一主多从,实现读写分离,读的压力往往可以通过添加从库实例来解决,然而写压力就只有主库独自承担,主库可以并行写入数据。
而从库在默认情况下,只能单线程重放主库的binlog,从库通过一个io线程去拉取主库的binlog并写到从库的relay log,然后再通过从库的一个sql线程将relay log重放一次,通常地主库和从库均部署在同一个机房,因此io线程不会是性能瓶颈,sql线程往往才是性能的瓶颈。
这个时候,主库写数据压力大,这就导致从库的sql线程来不及消化relay log,也就是主库写数据量很大,但是从库重放relay log的速度太慢,这就导致一个严重的问题,主从延迟越来越大,那么从从库读取的数据就很久之前的过期数据了。
开启从库的并行复制,
1) 开启双0,提高性能,降低安全性,从库实例较多,挂掉一个从库实例没啥影响
mysql> set global sync_binlog=0; mysql> set global innodb_flush_log_at_trx_commit=0;
2)查看当前并行复制配置:
mysql> show variables like 'slave_parallel_%'; +------------------------+---------------+ | Variable_name | Value | +------------------------+---------------+ | slave_parallel_type | database | | slave_parallel_workers | 0 | +------------------------+---------------+ 2 rows in set (0.00 sec) # slave-parallel-type 默认值为database,但是针对只有一个数据库的集群而言,配置为database就没意义了,建议配置为logical_clock # slave-parallel-workers 默认值为0,建议至少配置为4
3)关闭sql线程:
在线开启: mysql> stop slave sql_thread; Query OK, 0 rows affected (0.07 sec)
4)开启基于组提交的并行复制
mysql> set global slave_parallel_type='LOGICAL_CLOCK'; Query OK, 0 rows affected (0.00 sec)
5)配置从库worker线程数,不要配置为0和1,建议至少配置为4
mysql> set global slave_parallel_workers=16; Query OK, 0 rows affected (0.00 sec)
6)开启sql线程:
mysql> start slave sql_thread; Query OK, 0 rows affected (0.06 sec)
7)
root@10.10.10.10 ((none)) > show slave status\G *************************** 1. row *************************** Slave_IO_State: Queueing master event to the relay log Master_Host: 10.10.10.11 Master_User: mysqlsync Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.037977 Read_Master_Log_Pos: 766436384 Relay_Log_File: relay-bin.111125 Relay_Log_Pos: 766243914 Relay_Master_Log_File: mysql-bin.037977 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 766243709 Relay_Log_Space: 766436825 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 113123925 Master_UUID: 465c12f1-bbc2-11ea-9fcb-e4434be4b111 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: 1 row in set (0.04 sec) Mon Aug 30 10:41:29 2021
优化选项: 启用table模式是因为如果在多线程模式下,会频繁更新master.info文件,消耗代价过高,并且此值也不是非常准确 master_info_repository=table 对应的表为mysql.slave_master_info relay_log_recovery=on relay_log_info_repository=table 对应的表为mysql.slave_relay_log_info
# slave slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=16 master_info_repository=TABLE relay_log_info_repository=TABLE relay_log_recovery=ON innodb_flush_log_at_trx_commit=0 sync_binlog=0
#####################################