commit 65510b5c1f59a52bcf18da5452a64f0c9ba4282d
Merge: fb8e85e 5059434
Author: Krunal Bauskar <email address hidden>
Date: Thu Nov 30 19:01:07 2017 +0530
Merge pull request #574 from kbauskar/5.7-pxc-895
PXC#895: Transaction lost after recovery
commit 5059434eb2eeaac685262d242f2e5f9b5a252952
Author: Krunal Bauskar <email address hidden>
Date: Tue Nov 28 12:08:44 2017 +0530
PXC#895: Transaction lost after recovery
If binlog is enabled then SE will persist redo at following stages:
during prepare
during binlog write
during innodb-commit
3rd stage (fsync) can be skipped as transaction can be recovered
from binlog.
During 3rd stage, commit co-ordinates are also recorded in sysheader
under wsrep placeholder. These co-ordinates are then used to stop
binlog scan (in addition to get recovery position in case of node-crash).
Since fsync of 3rd stage is delayed (as transaction can be recovered
using binlog) it is possible that even though transaction is reported
as success to end-user said co-ordinates are not persisted to disk.
On restart, a prepare state transaction could be recovered and committed
but since wsrep co-ordinates are not persisted a successfully committed
transaction recovery is skipped causing data inconsistency from end-user
application perspective.
This behavior is now changed to let recovery proceed independent of
wsrep co-ordinates and wsrep co-ordinates are updated to reflect
the recovery committed transaction.
commit 65510b5c1f59a52 bcf18da5452a64f 0c9ba4282d 5.7-pxc- 895 685262d242f2e5f 9b5a252952
Merge: fb8e85e 5059434
Author: Krunal Bauskar <email address hidden>
Date: Thu Nov 30 19:01:07 2017 +0530
Merge pull request #574 from kbauskar/
PXC#895: Transaction lost after recovery
commit 5059434eb2eeaac
Author: Krunal Bauskar <email address hidden>
Date: Tue Nov 28 12:08:44 2017 +0530
PXC#895: Transaction lost after recovery
If binlog is enabled then SE will persist redo at following stages:
during prepare
during binlog write
during innodb-commit
3rd stage (fsync) can be skipped as transaction can be recovered
from binlog.
During 3rd stage, commit co-ordinates are also recorded in sysheader
under wsrep placeholder. These co-ordinates are then used to stop
binlog scan (in addition to get recovery position in case of node-crash).
Since fsync of 3rd stage is delayed (as transaction can be recovered
using binlog) it is possible that even though transaction is reported
as success to end-user said co-ordinates are not persisted to disk.
On restart, a prepare state transaction could be recovered and committed
but since wsrep co-ordinates are not persisted a successfully committed
transaction recovery is skipped causing data inconsistency from end-user
application perspective.
This behavior is now changed to let recovery proceed independent of
wsrep co-ordinates and wsrep co-ordinates are updated to reflect
the recovery committed transaction.
Fixed with 5.6 and 5.7