Hello guys,
We have a MySQL master-slave setup (one master and one slave) running “5.7.14-7-log Percona Server (GPL), Release 7, Revision 083e298” on both master and slave. We use GTID and MTS. Following are replication and InnoDB settings on master and slave:
- on master
#replication
server_id=1
log_bin
gtid_mode=ON
enforce_gtid_consistency=ON
#Innodb
innodb_buffer_pool_size = 48G
innodb_buffer_pool_instances = 48
innodb_log_file_size = 4G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_thread_concurrency = 0
innodb_read_io_threads=48
innodb_write_io_threads=48
innodb_flush_neighbors = 0
innodb_io_capacity = 10000
innodb_buffer_pool_dump_pct = 100
binlog_cache_size = 32M
- on slave
#replication
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
slave_pending_jobs_size_max = 128M
slave_preserve_commit_order = On
log_bin = ON
log_slave_updates = ON
#Innodb
innodb_buffer_pool_size = 48G
innodb_buffer_pool_instances = 48
innodb_log_file_size = 4G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_thread_concurrency = 0
innodb_read_io_threads=32
innodb_write_io_threads=32
innodb_flush_neighbors = 0
innodb_io_capacity = 10000
innodb_buffer_pool_dump_pct = 100
binlog_cache_size = 32M
When we check slave status (show slave status \G), slave is lagging behind master for a few seconds (1-5 secs) most of the time and Slave_SQL_Running_State is ‘Waiting for dependent transaction to commit’.
Example:
=======================
Slave_IO_State: Waiting for master to send event
Master_Host: x.x.x.x
Master_User: xxxxx
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: db-bin.000062
Read_Master_Log_Pos: 114817922
Relay_Log_File: dbslv-relay-bin.000213
Relay_Log_Pos: 114256657
Relay_Master_Log_File: db-bin.000062
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: 114814928
Relay_Log_Space: 114818844
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: 4
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: 1
Master_UUID: b7a72845-68e9-11e6-9fcc-00269e9bc0c4
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Waiting for dependent transaction to commit
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: b7a72845-68e9-11e6-9fcc-00269e9bc0c4:81-7675670
Executed_Gtid_Set: b7a72845-68e9-11e6-9fcc-00269e9bc0c4:1-7675662
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
=======================
When we were using the plain old ‘Binary Log File Position Based Replication’, we did not have this problem and Seconds_Behind_Master was rarely greater than 0 seconds.
Could this be due to slave_preserve_commit_order = On?
Anyone experienced this problem with GTID replication and MTS?
Thank you!