lib/wsrep-lib
1
0
Fork 0
mirror of https://github.com/codership/wsrep-lib.git synced 2026-10-23 09:48:57 +03:00
Code Activity

MDEV-38843: BF applier failed on a node causing complete Cluster lockup

Browse Source 
log_dummy_write_set() is what releases commit order through
commit_order_leave() - which hands the apply error to the provider to
drive the inconsistency vote - and advances the storage engine
checkpoint. Skipping it on a rollback error leaves the seqno stuck in
commit order so all following appliers block on commit_order_enter, and
the node silently locks the cluster while staying in the primary
component.
Always call log_dummy_write_set() on the apply-error path, regardless of
the rollback result. The rollback result is still folded into ret so it
is not lost.
This commit is contained in:
Hemant Dangi
2026-05-27 17:10:53 +05:30
parent 93bf4e5b7c
commit 5eeef4009d
1 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/server_state.cpp
View File

@@ -340,10 +340,17 @@ static int apply_write_set(wsrep::server_state& server_state,
}
else
{
ret = high_priority_service.rollback(ws_handle, ws_meta);
ret = ret || (high_priority_service.after_apply(), 0);
ret = ret || high_priority_service.log_dummy_write_set(
ws_handle, ws_meta, err);
// Always log a dummy write set, even on rollback failure: it
// releases commit order (drives the inconsistency vote) and
// advances the SE checkpoint. The rollback result is still
// propagated into ret.
int const rollback_ret(
high_priority_service.rollback(ws_handle, ws_meta));
high_priority_service.after_apply();
int const dummy_ret(
high_priority_service.log_dummy_write_set(
ws_handle, ws_meta, err));
ret = rollback_ret || dummy_ret;
ret = resolve_return_error(err.size() > 0, ret, apply_err);
}
}