Re: [Maria-developers] ed477a6d30c: MDEV-29056 Replica thread reports error on ALTER ONLINE after LOCK WRITE
Hi, Nikita, No, in this case (and commonly for collateral changes) I'd rather prefer to refine the original (878a92e) commit to not cause the MDEV-29056 in the first place. Ignoring LOCK= clause is logically correct and that's what the old code was doing anyway. But perhaps ALTER TABLE still needs to check that ALGORITHM= and LOCK= clauses are compatible? On Aug 27, Nikita Malyavin wrote:
revision-id: ed477a6d30c (mariadb-10.6.1-521-ged477a6d30c) parent(s): 56206e60315 author: Nikita Malyavin committer: Nikita Malyavin timestamp: 2022-07-26 00:41:00 +0300 message:
MDEV-29056 Replica thread reports error on ALTER ONLINE after LOCK WRITE
Commit 878a92e (MDEV-28943) changes the behavior of ALTER TABLE under prelocking. It now ignores passed LOCK= value in that case.
However, LOCK TABLES command is never replicated, so the replica node remains unaware of it.
The solution would be to guess on the replica side on the mode used by master. To make a deduction reliable, master's locked_tables_mode state is passed for query log events.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Up to you, I have no straight opinion which way is better.
I only think that both ways are manageable.
BTW, why we have no such problem with INPLACE?
On Sat, 27 Aug 2022 at 18:11, Sergei Golubchik
Hi, Nikita,
No, in this case (and commonly for collateral changes) I'd rather prefer to refine the original (878a92e) commit to not cause the MDEV-29056 in the first place.
Ignoring LOCK= clause is logically correct and that's what the old code was doing anyway. But perhaps ALTER TABLE still needs to check that ALGORITHM= and LOCK= clauses are compatible?
On Aug 27, Nikita Malyavin wrote:
revision-id: ed477a6d30c (mariadb-10.6.1-521-ged477a6d30c) parent(s): 56206e60315 author: Nikita Malyavin committer: Nikita Malyavin timestamp: 2022-07-26 00:41:00 +0300 message:
MDEV-29056 Replica thread reports error on ALTER ONLINE after LOCK WRITE
Commit 878a92e (MDEV-28943) changes the behavior of ALTER TABLE under prelocking. It now ignores passed LOCK= value in that case.
However, LOCK TABLES command is never replicated, so the replica node remains unaware of it.
The solution would be to guess on the replica side on the mode used by master. To make a deduction reliable, master's locked_tables_mode state is passed for query log events.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- Yours truly, Nikita Malyavin
participants (2)
-
Nikita Malyavin -
Sergei Golubchik