Bug #106636 backup_lock preventing DDL changes being applied despite clone_block_ddl = 0
Submitted: 4 Mar 2022 7:32 Modified: 4 Mar 2022 9:42
Reporter: Simon Mudd (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Clone Plugin Severity:S3 (Non-critical)
Version:8.0.28 OS:Any
Assigned to: CPU Architecture:Any
Tags: 8.0.27, Backup, Clone, DDL, lock

[4 Mar 2022 7:32] Simon Mudd
Description:
Seen on a server recently:

| 792552 | system user | | NULL | Query | 71991 | Waiting for dependent transaction to commit | NULL |
| 792553 | system user | | emk | Query | 71992 | Waiting for backup lock | CREATE TABLE IF NOT EXISTS SomeTable (
pk_id INT UNSIGNED PRIMARY KEY NOT NULL,
|

This server was running 8.0.28
It was also an intermediate master, eg.  master -> intermediate master -> slave

The SQL thread was blocked.

https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-options-variables.html#sysvar_clone_b... implies this should no longer happen since 8.0.27 if clone_block_ddl = 0 which is the default and was the setting on this host.

Impact: several replicas under this intermediate master were not getting updated as expected.

How to repeat:
In theory see above.

1. Setup master --> intermediate --> master with 8.0.28
2. have the master push out CREATE TABLE IF NOT EXISTS <some_name>; statements
3. Do a native clone from the intermediate server
4. check to see if replication is blocked

I'll upload privately the configuration of the master and intermediate master.

Suggested fix:
The documentation says this should be resolved now. It appears this is not the case under some circumstances. Is this type of statement not considered a DDL statement? If so it should be.

Please ensure that as described by documentation the DDL statement can pass through and replication can continue in such conditions.
[4 Mar 2022 9:42] MySQL Verification Team
I can't reproduce this but I'm verifying non the less so that replication team can work on this.

all best
Bogdan