[MDEV-14095] Concurrent DDL can break xtrabackup-v2 SST in 10.2 Created: 2017-10-19  Updated: 2020-08-25  Resolved: 2017-11-29

Status: Closed
Project: MariaDB Server
Component/s: Galera, Galera SST, Storage Engine - InnoDB
Affects Version/s: 10.2.9
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Andrii Nikitin (Inactive)
Resolution: Won't Do Votes: 1
Labels: ddl, galera, sst, xtrabackup

Issue Links:
Relates
relates to MDEV-12116 Tables created during backup may be m... Closed

 Description   

Concurrent DDL can cause xtrabackup to see the following error in MariaDB 10.2:

[FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet.

This problem is described here:

https://www.percona.com/blog/2017/08/08/avoiding-the-an-optimized-without-redo-logging-ddloperation-has-been-performed-error-with-percona-xtrabackup/

This also seems to effect xtrabackup-v2 SSTs. Should the SST script use the --lock-ddl-per-table option in 10.2 to avoid this?



 Comments   
Comment by Andrii Nikitin (Inactive) [ 2017-10-28 ]

That will not help until MDEV-5336 is implemented

Comment by Geoff Montee (Inactive) [ 2017-10-28 ]

Sorry, I think I should have written --lock-ddl-per-table, not --lock-ddl. According to Percona's blog post, --lock-ddl-per-table is compatible with MariaDB, but --lock-ddl is not.

Comment by Geoff Montee (Inactive) [ 2017-11-06 ]

anikitin,

Do you think that this issue still needs to be blocked by MDEV-5336, considering that XtraBackup has --lock-ddl-per-table, which already supports MariaDB?

Comment by Andrii Nikitin (Inactive) [ 2017-11-10 ]

I've removed blocker , but I see no strong reasoning to change behavior and introduce --lock-ddl-per-table as default behavior. (Because I have no proof that it will not cause actual problems and it changes behavior and will differ from upstream).
In fact I am sure it may cause downtime in some cases of busy server with huge datadir. And - oh - `LOCK TABLE` command is not supported by galera, so there is a chance that `--lock-ddl-per-table` causes similar galera-specific problems?.
Even in your provided link I see "Use --lock-ddl-per-table with caution, it can block updates to tables for highly loaded servers under some circumstances".
If user sees or suspects the problem - they can add that flag to the script.
If upstream galera adds that flag - it will be merged eventually.

Generated at Thu Feb 08 08:10:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.