Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Do
-
10.2.9
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:
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?
Attachments
Issue Links
- relates to
-
MDEV-12116 Tables created during backup may be missed after restore
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Andrii Nikitin [ anikitin ] |
| Link |
This issue relates to |
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.
| Description |
Concurrent DDL can cause xtrabackup to see the following error in MariaDB 10.2:
{noformat} [FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. {noformat} 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 option in 10.2 to avoid this? |
Concurrent DDL can cause xtrabackup to see the following error in MariaDB 10.2:
{noformat} [FATAL] InnoDB: An optimized(without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. {noformat} 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? |
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?
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.
| Fix Version/s | N/A [ 14700 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Resolution | Won't Do [ 10201 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Workflow | MariaDB v3 [ 83087 ] | MariaDB v4 [ 153007 ] |
| Zendesk Related Tickets | 113927 |
That will not help until
MDEV-5336is implemented