# Replication lag 2 nodes cluster

**URL:** <https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212>\
**Category:** Percona XtraDB Cluster 5.x\
**Created:** [February 25, 2018, 7:25am UTC](https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212 "2018-02-25T07:25:30Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![eliransh](https://avatars.discourse-cdn.com/v4/letter/e/b9e5f3/32.png) [@eliransh](https://forums.percona.com/u/eliransh)\
**Post date:** [February 25, 2018, 7:25am UTC](https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212/1 "2018-02-25T07:25:30Z")

</div>

Hello,  
I have a setup of PXC with 2 nodes in aws, both in the save AZ with 0.168 ms lag.  
My setup is Proxysql with 1 writer and 1 reader, with query routing.  
When i insert 48k raw and run count right after i get 0 raw. if i add 430ms delay after the insert i can find the new raw in the reader node

Without sleep:

```auto
create table
fill members
filter members
Sunday 25th of February 2018 12:51:27 PM
no sleep
QUERY SELECT COUNT(member_id) count FROM tmp_auto_submit_1776
TOTAL FOUND 0

```

With 430ms sleep:

```auto
create table
fill members
filter members
Sunday 25th of February 2018 12:51:57 PM
430ms sleep
QUERY SELECT COUNT(member_id) count FROM tmp_auto_submit_1776
TOTAL FOUND 48064

```

wsrep\_sync\_wait value is 3 which improved the latency from 1 sec to 430ms.

Please advice

Thanks!

---

<div class="post-metadata">

**Author:** ![krunalbauskar](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@krunalbauskar](https://forums.percona.com/u/krunalbauskar)\
**Post date:** [February 27, 2018, 1:02am UTC](https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212/2 "2018-02-27T01:02:05Z")

</div>

1. Setting wsrep\_sync\_wait to 3 will place SELECT request after the active replication request.
2. Say you are inserting all 48K rows as a single transaction using INSERT. This means once the transaction is complete it will start replicating.
3. On the reader node when you fire SELECT with the sync\_wait=3 packet for SELECT will be placed in a queue that will be served once the replicating transaction completes.
4. From your description, it sounds like it takes 430 ms for the replication applier to complete.

I presume you need instant access to the data w/o the said latency.

- You can play around with wsrep\_sync\_wait setting. Try setting it to 0 (DISABLED) and check the effect.
- You can split loading transaction into 5K rows each (if application allow) so that this transaction gets replicated immediately and applied immediately reducing latency further (even with wsrep\_sync\_wait=3)
- You can also try to increase wsrep\_slave\_threads so if one replication thread is busy applying the first batch of 5K transaction, 2nd applier thread can pick and proceed with the second batch.

Let us know how it goes and we would be happy to support and help you achieve the bigger setup and goal.

---

<div class="post-metadata">

**Author:** ![eliransh](https://avatars.discourse-cdn.com/v4/letter/e/b9e5f3/32.png) [@eliransh](https://forums.percona.com/u/eliransh)\
**Post date:** [February 27, 2018, 5:56am UTC](https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212/3 "2018-02-27T05:56:06Z")

</div>

Hi, It’s possible to split the transaction into chunks but i’m trying to avoid it.  
After changing the wsrep\_sync\_wait to 0 there’s no change in the lag of the replication. still takes 430 ms to replicate 48K raws.  
wsrep\_slave\_threads is set to 32

---

<div class="post-metadata">

**Author:** ![krunalbauskar](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@krunalbauskar](https://forums.percona.com/u/krunalbauskar)\
**Post date:** [March 1, 2018, 9:56pm UTC](https://forums.percona.com/t/replication-lag-2-nodes-cluster/6212/4 "2018-03-01T21:56:36Z")

</div>

That probably means all 48K rows are being loaded as a single transaction. When the rows are being applied you can enable (wsrep-debug=1) on replicating node and check how they are being applied. (Note: wsrep-debug shouldn’t be enabled during production). Alternative is to check using show processlist.
