Does IST Block the donor node

Haven’t been able to find the answer online.

was wondering if its possible to determine from global variables whether or not the donor node is performing an IST or and SST to determine if it’s block from receiving client request using the clustercheck script.

Using PXC 5.6 :slight_smile:

SHOW GLOBAL STATUS like ‘wsrep%’ will show you if the node is in a Donor/Desynced mode, but this could mean 3 possible things:

  1. Node is SST Donor
  2. Node is IST Donor
  3. Node is in wsrep_desync=ON state

The clustercheck script will (given the right option) report the node is unavailable if the node is in the Donor/Desynced state, but as you point out that doesn’t mean the node can’t take client connections. IST is non-blocking, so clients could continue there. We could file a bug ([url]https://bugs.launchpad.net/percona-xtradb-cluster/+bugs[/url]) and see if it’s conceivable to have such an indicator, but even an SST like Xtrabackup is mostly non-blocking, so we may want to keep clients on the node until it takes the file lock.

Maybe IST and SST don’t matter, and what you really want is to know when the wsrep provider is actually “paused” as reported in the log when a Donor actually gets a lock. ([url]http://www.mysqlperformanceblog.com/2013/10/08/taking-backups-percona-xtradb-cluster-without-stalls-flow-control/[/url]). You can determine this after it happens by watching the size of the local recv queue: a backlog there on a Donor node indicates a locked provider, but you only see that after the lock happens, which may be too late to take clients cleanly out of rotation.

Hey Jayj,

Yeah I think having a global variable or even just an additional state even (Donor SST and Donor IST) could be useful in some cases. But the provider paused sounds like an even better solution that would catch that.

Meaning it would be a lot easier to filter nodes that cant currently receive requests.

Steve