# Seconds\_Behind\_Master keeps increasing **URL:** \ **Category:** Percona XtraBackup\ **Created:** [April 3, 2024, 3:50pm UTC](https://forums.percona.com/t/seconds-behind-master-keeps-increasing/29536 "2024-04-03T15:50:07Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![CL69](https://avatars.discourse-cdn.com/v4/letter/c/c4cdca/32.png) [@CL69](https://forums.percona.com/u/CL69)\ **Post date:** [April 3, 2024, 3:50pm UTC](https://forums.percona.com/t/seconds-behind-master-keeps-increasing/29536/1 "2024-04-03T15:50:07Z")
Hi, I’m having an issue where “seconds\_behind\_master” keeps increasing on my replica server. I can’t figure out why so any ideas would be helpful. Both servers are running: _ **MASTER** _ _ **======** _ 2024-04-02T21:07:38.379338-00:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --log\_bin=mysql-bin --server-id=1 xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86\_64) (revision id: 6beb4b49) mysql Ver 8.0.33-0ubuntu0.20.04.2 for Linux on x86\_64 ((Ubuntu)) _ **REPLICA** _ _ **=======** _ 2024-04-02T21:06:45.939781-00:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --log\_bin=mysql-bin --server-id=2 xtrabackup version 8.0.35-30 based on MySQL server 8.0.35 Linux (x86\_64) (revision id: 6beb4b49) mysql Ver 8.0.36-0ubuntu0.22.04.1 for Linux on x86\_64 ((Ubuntu)) Both servers are in the same ISP so I don’t think it’s a networking or resource issue. The **replica** server has: replica\_parallel\_type = LOGICAL\_CLOCK replica\_preserve\_commit\_order = ON replica\_parallel\_workers = 4 binlog\_format = ROW _ **22:42pm ! 02/04/2024** _ **REPLICA STATUS** **==============** Slave\_IO\_State Waiting for source to send event Master\_Host //MASTER IP ADDRESS Master\_User repl Master\_Port 3306 Connect\_Retry 60 Master\_Log\_File mysql-bin.000291 Read\_Master\_Log\_Pos 95339364 Relay\_Log\_File 724805F-relay-bin.000372 Relay\_Log\_Pos 62343421 Relay\_Master\_Log\_File mysql-bin.000194 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 62343205 Relay\_Log\_Space 10209233453 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 176327 _ **22:52pm ! 02/04/2024** _ **REPLICA STATUS** **==============** Slave\_IO\_State Waiting for source to send event Master\_Host //MASTER IP ADDRESS Master\_User repl Master\_Port 3306 Connect\_Retry 60 Master\_Log\_File mysql-bin.000292 Read\_Master\_Log\_Pos 16192157 Relay\_Log\_File 724805F-relay-bin.000372 Relay\_Log\_Pos 80616437 Relay\_Master\_Log\_File mysql-bin.000194 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 80616221 Relay\_Log\_Space 10234954547 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 176613 _ **16:00pm ! 03/04/2024** _ **REPLICA STATUS** **==============** Slave\_IO\_State Waiting for source to send event Master\_Host //MASTER IP ADDRESS Master\_User repl Master\_Port 3306 Connect\_Retry 60 Master\_Log\_File mysql-bin.000321 Read\_Master\_Log\_Pos 70852457 Relay\_Log\_File 724805F-relay-bin.000408 Relay\_Log\_Pos 25340929 Relay\_Master\_Log\_File mysql-bin.000212 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 25340713 Relay\_Log\_Space 11390823716 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 195472 _ **22:52pm ! 02/04/2024** _ # **MASTER STATUS** Variable Value File mysql-bin.000292 Position 14494109 Binlog\_Do\_DB Binlog\_Ignore\_DB ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [April 3, 2024, 4:42pm UTC](https://forums.percona.com/t/seconds-behind-master-keeps-increasing/29536/2 "2024-04-03T16:42:15Z")
Hello @CL69, On the replica, try setting the following: ``` innodb_flush_log_at_trx_commit=0 sync_binlog=0 ``` Those are the heaviest IO users. This should help replication catch up. I would also do `replica_parallel_workers=8` What this also means is that your replica might be disk-bound and I would check the await% and disk utilization. Use PMM to see where most of your waits are happening. ---
**Author:** ![CL69](https://avatars.discourse-cdn.com/v4/letter/c/c4cdca/32.png) [@CL69](https://forums.percona.com/u/CL69)\ **Post date:** [April 4, 2024, 1:44pm UTC](https://forums.percona.com/t/seconds-behind-master-keeps-increasing/29536/3 "2024-04-04T13:44:19Z")
Hi @matthewb , You Sir are a genius and an angel 🙌. Thanks so much for your suggestions, the servers have now caught up and I have: “ **Seconds\_Behind\_Master 0** ” Thanks again!