# Laggy master-master gtid replication in 5.7.32

**URL:** <https://forums.percona.com/t/laggy-master-master-gtid-replication-in-5-7-32/12618>\
**Category:** Percona Server for MySQL 5.7\
**Created:** [October 18, 2021, 9:40am UTC](https://forums.percona.com/t/laggy-master-master-gtid-replication-in-5-7-32/12618 "2021-10-18T09:40:29Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jiri\_Sula](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jiri_sula/32/4770_2.png) [@Jiri\_Sula](https://forums.percona.com/u/Jiri_Sula)\
**Post date:** [October 18, 2021, 9:40am UTC](https://forums.percona.com/t/laggy-master-master-gtid-replication-in-5-7-32/12618/1 "2021-10-18T09:40:29Z")

</div>

Dear all,  
we’re facing performance issues within master-master gtid replication. Secondary master(read only) is trying to catch Primary master with no luck. Write-bound workload is producing around 1GB of binlog per 10 minutes. Secondary master is having a lot of “System lock” in “Slave\_SQL\_Running\_State”, according our monitoring 3/4 of time. More precisely from performance\_schema.threads - processlist\_command = “Connect” is very frequently connected with processlist\_state = “System lock” within slave\_sql thread. Slow queries are pointing to slave thread and also trigger user (see picture in attachment). Statistics are fresh with 300 sample pages.  
We’re suspecting storage layer, although these i/o should be completely fine with current enterprise sata ssd.  
Any advices highly appreciated!  
Percona Server version: 5.7.32-35 with RBR, Debian Buster.

 ![System_lock](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/e/e772699f4ae49221ddcfc3f436e1d93ab5581294.png)  
 ![Slow_queries](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/b/b8d1f9fac86096df76c72022539878309a0b447b.png)

---

<div class="post-metadata">

**Author:** ![Ivan\_Groenewold](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ivan_groenewold/32/6299_2.png) [@Ivan\_Groenewold](https://forums.percona.com/u/Ivan_Groenewold)\
**Post date:** [October 19, 2021, 2:25pm UTC](https://forums.percona.com/t/laggy-master-master-gtid-replication-in-5-7-32/12618/2 "2021-10-19T14:25:54Z")

</div>

Hi, have you tried any of the parallel replication options? also other common tricks to make replicas run faster are sync\_binlog=0, innodb\_flush\_log\_at\_trx\_commit=2, and master\_info\_repository/relay\_log\_info\_repository=FILE.

---

<div class="post-metadata">

**Author:** ![Jiri\_Sula](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jiri_sula/32/4770_2.png) [@Jiri\_Sula](https://forums.percona.com/u/Jiri_Sula)\
**Post date:** [November 3, 2021, 11:19am UTC](https://forums.percona.com/t/laggy-master-master-gtid-replication-in-5-7-32/12618/3 "2021-11-03T11:19:00Z")

</div>

Hi igroene,  
I tried recommended setup ^^ , no change. Also NVMe disks were added into server with dedicated logs location with no change. We also changed HW completely into Epyc platform, that should be really fastest we are having. Much better in all aspects but busy hours are resulting in a lag “hill”, peaking around 2000s.  
For a next step we asked developers if there’s a chance to change UPDATEs rates, as I feel we are limited by some component of replication.  
Anyway I’m marking your answer as solution, as the root cause is probably within application design/queries themselves/replication speed. Thank you for your time!