[MDEV-25477] Auto-create breaks replication when triggering event was not replicated Created: 2021-04-21 Updated: 2022-05-06 Resolved: 2022-04-23 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Documentation, Partitioning, Replication, Versioned Tables |
| Affects Version/s: | None |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Critical |
| Reporter: | Elena Stepanova | Assignee: | Aleksey Midenkov |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
Partitioning auto-creation cannot be enabled in a replication topology, unless only non-transactional engines are used (which is hardly realistic these days). The reason is that when a partition is auto-created within a transaction, but the transaction is later rolled back, there will be nothing written in the binary log. Thus, the master will have the new partition, but the slave will not. This discrepancy will almost inevitably cause a replication abort some time later. If it's intentional, at the very least it has to be documented, as it is a pretty big limitation. Example:
After rollback, the master has 2 historical partitions, while the slave has only one:
So, the master is allowed to drop partition p0, but the slave is not:
Also test case from |
| Comments |
| Comment by Aleksey Midenkov [ 2021-04-22 ] |
|
This doesn't matter as auto-creation also works on slave. Discrepancy in names of history partitions is acceptable but this should be documented somewhere. I don't believe this is a big limitation as neither current data nor history get lost or made inconsistent across the nodes. |
| Comment by Elena Stepanova [ 2021-04-22 ] |
|
You can see from the description above that auto-creation does not work on slave – it can't work on slave because there is no DML. Discrepancy in names and in the number of partitions is not acceptable for replication, because it will always break replication at the end. Either auto-creation works with replication, and then the table structure consistency must be maintained, or it doesn't work with replication. And yes, incompatibility with replication is a very big limitation. |
| Comment by Aleksey Midenkov [ 2021-04-22 ] |
|
We should resurrect |
| Comment by Sergei Golubchik [ 2021-12-29 ] |
|
This seems to be rather trivial to fix? On auto-create you can set "non transactional tables were modified" flag, and then the transaction will be written into binlog all right, with ROLLBACK at the end. Or you set a flag OPTION_KEEP_LOG. See trans_cannot_safely_rollback() — you need to trick it to return true. |
| Comment by Ralf Gebhardt [ 2022-01-26 ] |
|
|
| Comment by Aleksey Midenkov [ 2022-02-08 ] |
|
AFAICS this bug blocks |
| Comment by Aleksey Midenkov [ 2022-04-23 ] |
|
Pushed to bb-10.9- |