[MDEV-30714] SET SESSION ALGORITHM causes operational issues with replication Created: 2023-02-23 Updated: 2023-05-31 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Replication, Server |
| Affects Version/s: | 10.6.12 |
| Fix Version/s: | 10.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Rick Pizzi | Assignee: | Andrei Elkin |
| Resolution: | Unresolved | Votes: | 7 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
When an user wants to set an algorithm for ALTER TABLE, he can do it in two ways:
Unfortunately, the former will cause the alter to be processed in different ways on master and replicas (either async or galera replicas) because, obviously, SET SESSION is not replicated. So, the outcome in presence of replication is not what the user wants. Furthermore, this may cause galera cluster breakdown when the alter fails on master due to unsupported algorithm, but it is executed on the other galera nodes because there, default algorithm is selected. I would suggest to deprecate the former way to specify ALGORITHM for ALTER and only allow it to be specified in ALTER statement itself. This will avoid operational incidents (I have already witnessed a few myself). Thanks |
| Comments |
| Comment by Elena Stepanova [ 2023-04-01 ] |
|
You probably mean alter_algorithm. There are many variables which can cause replication problems when set on the master but not on the slave, be it dynamically or upon startup. |