Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MDEV-32823 Sequences may diverge with Galera #363

Open
wants to merge 2 commits into
base: 10.4
Choose a base branch
from

Conversation

sciascid
Copy link

No description provided.

This patch improves support for SEQUENCEs when used with Galera.
The original ticket, MDEV-28971, comes with a test case showing that
the combination SEQUENCES do not work in combination with Galera's
streaming replication. To fix that, it is necessary to include the
contents of stmt cache when preparing a fragment for replication.

Additional testing showed that support for SEQUENCEs is broken, even
for regular transactions replicated through Galera. Galera did not
correctly implement the non-transactional semantics of SEQUENCEs.
For instance:
```
BEGIN;
INSERT INTO some_table VALUES(...)
SELECT NEXTVAL(s);
ROLLBACK;
```
should result in the `INSERT` to be rolled back, while the value
consumed SEQUENCE `s` by `NEXTVAL(s)`, can't be rolled back and must
be committed. This is problematic for Galera, as ROLLBACK results in
no writeset. Therefore, transactions that rollback voluntarily
rollback, or are rolled back due to cluster-wide conflicts, result in
SEQUENCEs that diverge throughout the cluster. Also, when binlogs are
enabled, those diverge too.
To fix this, we replicate the contents statment cache whenever a value
from a sequence is consumed. Allowing ROLLBACK to undo transactional
changes, while preserving the changes made to the SEQUENCEs.
Move replication from SEQUENCE::next_value() to
ha_sequence::write_row(). This has the following benefits:
1. We get replication of sequence SETVAL(), which was not working
2. In write_row(), first the pending row event is generated, and
   replicated before the row is written to storage engine.
   Should replication fail, we get rid of the pending row event and
   return the error.

Added tests for BF aborts, and a test that shows nodes can recover
sequence operations through IST (even after certification failure).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant