Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
Implement BACKUP LOCK [database.]table_name and BACKUP UNLOCK
These commands are needed for external backup tools, like mariabackup, to ensure that all files for a table are from the same generation (ie, was created by the same CREATE, RENAME or ALTER TABLE statement).
The typical usage of this by a backup tools is to do the following when copying a table:
- BACKUP LOCK [database.]table_name
- Open all files related to a table (for example, test.frm, test.MYI and test.MYD)
- BACKUP UNLOCK
- Copy data
- Close files
The idea is that the BACKUP LOCK should be hold as short time as possible.
The time to take an uncontested lock is very short; While testing on a laptop from a perl program, I was able to do more than 50,000 LOCK + UNLOCK per second.
Other things:
- Internally BACKUP LOCK is implemented by taking a MDLSHARED_HIGH_PRIO on the table object, which protects the table from any DDL operations.
- One should use different connections for BACKUP STAGE ... and BACKUP LOCK commands as one should be able to do BACKUP LOCK commands while waiting to get the new BACKUP STAGE lock.
Attachments
Issue Links
- blocks
-
MDEV-17308 BACKUP: mariabackup support
-
- Closed
-
- is part of
-
MDEV-5336 Implement BACKUP STAGE for safe external backups
-
- Closed
-
Activity
Link |
This issue blocks |
Assignee | Michael Widenius [ monty ] |
Summary | BACKUP: fine-grained locking | BACKUP LOCK: fine-grained DDL locking |
Description |
{{BACKUP ...}} syntax and fine grained locking specific to each stage as described in |
Implement BACKUP LOCK [database.]table_name and BACKUP UNLOCK
These commands are needed for external backup tools, like mariabackup, to ensure that all files for a table are from the same generation (ie, was created by the same CREATE, RENAME or ALTER TABLE statement). The typical usage of this by a backup tools is to do the following when copying a table: - BACKUP LOCK [database.]table_name - Open all files related to a table (for example, test.frm, test.MYI and test.MYD) - BACKUP UNLOCK - Copy data - Close files The idea is that the BACKUP LOCK should be hold as short time as possible. The time to take an uncontested lock is very short; While testing on a laptop from a perl program, I was able to do more than 50,000 LOCK + UNLOCK per second. Internally BACKUP LOCK is implemented by taking a MDLSHARED_HIGH_PRIO on the table object, which protects the table from any DDL operations. |
Summary | BACKUP LOCK: fine-grained DDL locking | BACKUP LOCK: DDL locking of tables during backup |
issue.field.resolutiondate | 2019-02-04 10:12:28.0 | 2019-02-04 10:12:28.829 |
Fix Version/s | 10.4.2 [ 23229 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
Description |
Implement BACKUP LOCK [database.]table_name and BACKUP UNLOCK
These commands are needed for external backup tools, like mariabackup, to ensure that all files for a table are from the same generation (ie, was created by the same CREATE, RENAME or ALTER TABLE statement). The typical usage of this by a backup tools is to do the following when copying a table: - BACKUP LOCK [database.]table_name - Open all files related to a table (for example, test.frm, test.MYI and test.MYD) - BACKUP UNLOCK - Copy data - Close files The idea is that the BACKUP LOCK should be hold as short time as possible. The time to take an uncontested lock is very short; While testing on a laptop from a perl program, I was able to do more than 50,000 LOCK + UNLOCK per second. Internally BACKUP LOCK is implemented by taking a MDLSHARED_HIGH_PRIO on the table object, which protects the table from any DDL operations. |
Implement BACKUP LOCK [database.]table_name and BACKUP UNLOCK
These commands are needed for external backup tools, like mariabackup, to ensure that all files for a table are from the same generation (ie, was created by the same CREATE, RENAME or ALTER TABLE statement). The typical usage of this by a backup tools is to do the following when copying a table: - BACKUP LOCK [database.]table_name - Open all files related to a table (for example, test.frm, test.MYI and test.MYD) - BACKUP UNLOCK - Copy data - Close files The idea is that the BACKUP LOCK should be hold as short time as possible. The time to take an uncontested lock is very short; While testing on a laptop from a perl program, I was able to do more than 50,000 LOCK + UNLOCK per second. Other things: - Internally BACKUP LOCK is implemented by taking a MDLSHARED_HIGH_PRIO on the table object, which protects the table from any DDL operations. - One should use different connections for BACKUP STAGE ... and BACKUP LOCK commands as one should be able to do BACKUP LOCK commands while waiting to get the new BACKUP STAGE lock. |
Link | This issue relates to MDEV-19752 [ MDEV-19752 ] |
Link | This issue relates to MENT-132 [ MENT-132 ] |
Workflow | MariaDB v3 [ 89794 ] | MariaDB v4 [ 133698 ] |
The hours are for Documentation.
Development work was logged in
MDEV-5336