# PXC 8.0.46-38 remains in Donor/Desynced after mydumper backup **URL:** \ **Category:** Percona XtraDB Cluster 8.x\ **Created:** [August 6, 2026, 12:04pm UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146 "2026-08-06T12:04:10Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![DeBuXer](https://avatars.discourse-cdn.com/v4/letter/d/df788c/32.png) [@DeBuXer](https://forums.percona.com/u/DeBuXer)\ **Post date:** [August 6, 2026, 12:04pm UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146/1 "2026-08-06T12:04:10Z")
Since upgrading our Percona XtraDB Cluster to `8.0.46-38`, one node remains stuck in `Donor/Desynced` after a mydumper backup. This backup setup had been working for years before the upgrade. Our original backup script was: ```auto mysql --defaults-extra-file="${CREDFILE}" \ --execute "SET GLOBAL wsrep_desync = ON" mydumper \ --defaults-file="${CREDFILE}" \ --use-savepoints \ -t 2 \ -c ZSTD \ -o "${DESTDIR}/0" mysql --defaults-extra-file="${CREDFILE}" \ --execute "SET GLOBAL wsrep_desync = OFF" ``` After the backup, `wsrep_desync` is correctly set to `OFF`, but the node does not return to `Synced`. The status then looks like this: ```auto wsrep_desync OFF wsrep_desync_count 1 wsrep_local_state 2 wsrep_local_state_comment Donor/Desynced wsrep_local_recv_queue 0 wsrep_connected ON wsrep_ready ON ``` Running `SET GLOBAL wsrep_desync = OFF` again only gives: `wsrep_desync` is already `OFF`. The node only returns to `Synced` after restarting MySQL. We tested a few different scenarios. First, we tested `wsrep_desync` without mydumper: ```auto SET GLOBAL wsrep_desync = ON; -- wait about 10 minutes SET GLOBAL wsrep_desync = OFF; ``` That works normally. `wsrep_desync_count` returns to `0` and the node becomes `Synced` again. With the original backup script, the values change like this: ```auto Before backup: wsrep_desync=0 wsrep_desync_count=0 Synced During mydumper: wsrep_desync=1 wsrep_desync_count=2 Donor/Desynced After SET GLOBAL wsrep_desync=OFF: wsrep_desync=0 wsrep_desync_count=1 Donor/Desynced ``` We then ran mydumper without setting `wsrep_desync` ourselves. The result was: ```auto Before mydumper: wsrep_desync=0 wsrep_desync_count=0 Synced After mydumper started: wsrep_desync=0 wsrep_desync_count=1 Donor/Desynced ``` The counter stayed at `1` after mydumper completed. So mydumper alone is enough to trigger the problem. The explicit `wsrep_desync` commands are not the cause. We first reproduced this with: `mydumper v0.16.1-3`. We then upgraded to the latest mydumper version, but the result was the same. The problem does not occur when using: ```auto --sync-thread-lock-mode=SAFE_NO_LOCK --no-backup-locks ``` It also does not occur with: ```auto --sync-thread-lock-mode=GTID --no-backup-locks ``` With both settings, the backup completes and the node returns to: ```auto wsrep_desync=OFF wsrep_desync_count=0 wsrep_local_state_comment=Synced ``` At this point, it looks like the issue is in the interaction between PXC `8.0.46-38` and the default lock path selected by mydumper with `sync-thread-lock-mode=FTWRL`. My assumption is that mydumper’s use of FTWRL causes PXC to create an internal desync reference. After the lock is released, that reference is not removed, leaving the node stuck with: ```auto wsrep_desync=OFF wsrep_desync_count=1 Donor/Desynced ``` The issue appeared immediately after upgrading to PXC 8.0.46-38. Since that release includes changes to FTWRL handling on backup nodes, including [PXC-4799](https://perconadev.atlassian.net/browse/PXC-4799), it seems possible that the change is related. Has anyone else seen this with PXC `8.0.46-38`? ---
**Author:** ![anil.joshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anil.joshi/32/13100_2.png) [@anil.joshi](https://forums.percona.com/u/anil.joshi)\ **Post date:** [August 12, 2026, 5:57am UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146/2 "2026-08-12T05:57:14Z")
@DeBuXer I was also able to reproduce it. Will check this internally with Dev and then update you. `SET GLOBAL wsrep_desync = ON` ```auto node1 [localhost:30647] {root} ((none)) > show global status like '%wsrep_local_state_comment%'; +---------------------------+----------------+ | Variable_name | Value | +---------------------------+----------------+ | wsrep_local_state_comment | Donor/Desynced | +---------------------------+------ ``` `mydumper --threads=4 --user=root --password=msandbox --host=127.0.0.1 --port=30647 --trx-tables --events --routines --triggers --compress --outputdir backup/ --logfile mydumper.out --verbose=3` **mydumper.out:** ```auto 2026-08-12 05:41:29 [INFO] - Releasing DDL lock 2026-08-12 05:41:29 [INFO] - UNLOCK INSTANCE: OK 2026-08-12 05:41:29 [INFO] - Queue count: 0 0 0 0 0 2026-08-12 05:41:29 [INFO] - Main connection closed 2026-08-12 05:41:29 [INFO] - Finished dump at: 2026-08-12 05:41:29 ``` `SET GLOBAL wsrep_desync = OFF` ```auto node1 [localhost:30647] {root} ((none)) > show global status like '%wsrep_local_state_comment%'; +---------------------------+----------------+ | Variable_name | Value | +---------------------------+----------------+ | wsrep_local_state_comment | Donor/Desynced | +---------------------------+----------------+ 1 row in set (0.01 sec) ``` ```auto node1 [localhost:30647] {root} ((none)) > show global status like '%desync%'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_desync_count | 1 | +--------------------+-------+ 1 row in set (0.00 sec) ``` ---
**Author:** ![anil.joshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/anil.joshi/32/13100_2.png) [@anil.joshi](https://forums.percona.com/u/anil.joshi)\ **Post date:** [August 17, 2026, 5:51am UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146/3 "2026-08-17T05:51:25Z")
@DeBuXer Just a FYI, I have raised the Jira - [https://perconadev.atlassian.net/browse/PXC-5307](https://perconadev.atlassian.net/browse/PXC-5307) internally regarding this issue. Rest, you can monitor the URL for any further updates. ---
**Author:** ![Yathus](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yathus](https://forums.percona.com/u/Yathus)\ **Post date:** [September 13, 2026, 12:49pm UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146/4 "2026-09-13T12:49:16Z")
Hello I update yesterday to latest version and i have exactly same bug this morning. I add a “stop / start mysql service” on my backup node in my script. Yathus ---
**Author:** ![Denis\_Subbota](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/denis_subbota/32/23607_2.png) [@Denis\_Subbota](https://forums.percona.com/u/Denis_Subbota)\ **Post date:** [October 19, 2026, 2:33pm UTC](https://forums.percona.com/t/pxc-8-0-46-38-remains-in-donor-desynced-after-mydumper-backup/41146/5 "2026-10-19T14:33:34Z")
Hi @DeBuXer, I believe I can narrow it down a bit. FTWRL alone is fine, LOCK INSTANCE FOR BACKUP alone is fine, the problem is the two together. When FTWRL is released while the backup lock is still held, the node is not put back to Synced. Same four statements mydumper sends, by hand in one session: ```auto mysql> LOCK INSTANCE FOR BACKUP; mysql> FLUSH TABLES WITH READ LOCK; mysql> show global status like 'wsrep_desync_count'; -- 1, Donor/Desynced mysql> UNLOCK TABLES; mysql> show global status like 'wsrep_desync_count'; -- still 1 mysql> UNLOCK INSTANCE; -- still 1 ``` FTWRL alone goes 0 → 1 → 0 and the node is Synced again after UNLOCK TABLES, so the counter itself works. For the workaround, you don’t need to give up FTWRL. `--skip-ddl-locks` alone is enough, mydumper then sends only FTWRL and the node returns to Synced. `--no-backup-locks` is not enough, with it mydumper still sends LOCK INSTANCE FOR BACKUP, that is probably why you had to combine it with SAFE\_NO\_LOCK or GTID.