# IST fallback to SST due to large seqno gap

**URL:** <https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200>\
**Category:** MySQL & MariaDB\
**Created:** [February 12, 2026, 2:49pm UTC](https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200 "2026-02-12T14:49:24Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![SQLCaesar](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@SQLCaesar](https://forums.percona.com/u/SQLCaesar)\
**Post date:** [February 12, 2026, 2:49pm UTC](https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200/1 "2026-02-12T14:49:24Z")

</div>

Hi all,

During the MySQL service startup (following a manual data restore (copying data) to a node), the IST process failed. The error log contained the following warning:

[Note] [MY-000000] [WSREP] may fallback to sst. ist\_seqno [x] \< safe\_ist\_seqno [x + y]

_In general, what determines the maximum valid gap between ist\_seqno and safe\_ist\_seqno for IST to be possible?_

We have observed inconsistent behavior during our tests:

1. In one instance, IST was successful even though the sequence gap was relatively larger.
2. In a subsequent test with a smaller gap, the node failed to perform IST and defaulted to SST. 😮

_What could cause a smaller gap to be rejected while a larger one is accepted?_

_Could you please describe in more detail how synchronization from the **GCache** works?_

My understanding is that if the seqno found in a joiner’s grastate.dat is lower than the donor’s wsrep\_local\_cached\_downto, an **IST (Incremental State Transfer)** cannot occur, and the node must perform a full **SST (State Snapshot Transfer)**. Is this correct?

Additionally, I frequently see this specific line in the error logs: [WSREP] may fallback to sst. ist\_seqno [x] \< safe\_ist\_seqno [x + Y]

_What exactly do **ist\_seqno** and **safe\_ist\_seqno** represent in this context, and why is the “safe” value often significantly higher than the joiner’s request?_

---

<div class="post-metadata">

**Author:** ![Yunus](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/yunus/32/6430_2.png) [@Yunus](https://forums.percona.com/u/Yunus)\
**Post date:** [February 13, 2026, 2:27am UTC](https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200/2 "2026-02-13T02:27:29Z")

</div>

What was the gcache.size defined?

You can take a look at this detailed blog about gcache

> **[All You Need to Know About GCache (Galera-Cache)](https://www.percona.com/blog/all-you-need-to-know-about-gcache-galera-cache/)**
>
> This blog discusses the important aspects of GCache.

---

<div class="post-metadata">

**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:** [February 13, 2026, 10:03pm UTC](https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200/3 "2026-02-13T22:03:15Z")

</div>

Also, checkout the value `ist_only` which only allows IST. If it cannot IST, mysqld exits instead of fallback to SST.

> **[wsrep\_sst\_method - Percona XtraDB Cluster - Index of wsrep system variables](https://docs.percona.com/percona-xtradb-cluster/8.4/wsrep-system-index.html#wsrep_sst_method)**
>
> Percona XtraDB Cluster introduces a number of MySQL system variables related to write-set replication. | Percona XtraDB Cluster introduces a number of MySQL system variables
> related to write-set replication.

---

<div class="post-metadata">

**Author:** ![SQLCaesar](https://avatars.discourse-cdn.com/v4/letter/s/9fc348/32.png) [@SQLCaesar](https://forums.percona.com/u/SQLCaesar)\
**Post date:** [February 16, 2026, 1:25pm UTC](https://forums.percona.com/t/ist-fallback-to-sst-due-to-large-seqno-gap/40200/4 "2026-02-16T13:25:19Z")

</div>

Thank you both @matthewb and @Yunus for your inputs.

Indeed, I came across an incredibly helpful article by Krunal Bauskar that explains the inner workings of IST in great detail.

As the article points out, the contents of the GCache can vary from node to node. Therefore, to determine if an IST is possible, it is critical to compare the sequence number (`seqno`) from the joining node’s `grastate.dat` file against the wsrep\_local\_cached\_downto value on the donor node.

The rule is simple: If the donor’s `wsrep_local_cached_downto` is higher than the joiner’s `seqno`, an IST cannot occur.

Additionally, the article mentions a “safety gap” mechanism. This internal buffer ensures that the donor doesn’t offer an IST if the requested data is dangerously close to being purged from the cache during the transfer. The formula for this safety margin is:

**safety gap = (Current State of Cluster – Lowest available seqno from any existing node) \* 0.008**

Below, I am attaching the original article by Krunal Bauskar, which elaborates on these topic.

> **[Understanding how an IST donor is selected](https://www.percona.com/blog/understanding-ist-donor-selected/)**
>
> Krunal Bauskar looks at the way an IST donor is selected when a node is ready to rejoin when using Percona XtraDB Cluster to manage the MySQL cluster