Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-5336

Implement LOCK TABLES FOR BACKUP from Percona Server

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Fix Version/s: 10.2
    • Component/s: None
    • Labels:
      None

      Description

      Have a Lock for DDL's.
      So i.e.ALTER TABLE, DROP TABLE would not break (single-transaction) Dumps.
      You can use flush tables with read lock, but then you need not to do a
      single-transaction dump anyway.
      Even xtrabackup got troubles:
      https://bugs.launchpad.net/percona-xtrabackup/+bug/722638
      I got to confess I think ignoring tablespace ids is the right solution.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              erkules erkan yanar added a comment -

              In the end we need something like LOCK TABLES FOR BACKUP like with Percona:
              http://www.percona.com/doc/percona-server/5.6/management/backup_locks.html

              Show
              erkules erkan yanar added a comment - In the end we need something like LOCK TABLES FOR BACKUP like with Percona: http://www.percona.com/doc/percona-server/5.6/management/backup_locks.html
              Hide
              Meerkat63 Peter McLarty added a comment -

              Oracle has tables as part of a tablespace and the tablespace is able to be anywhere on disk the tables are within a tablespace and oracle you can place a tablespace in backup mode, all data within that tablespace is kept consistent. Oracle writes logs of activity to be changed in that tablespace until the lock is released. This might be a step too far but may help formulate a way forward to get this to work. Tablespaces probably need to be implemented within the engine but could still be kept in the mariadb variables.
              This would allow the concept of then managing data with a lock that doesn't necessarily affect the total server instance only the tablespace/s you wish to back up in that window for consistency.
              For example now I don't necessarily need to lock the mysql database at the same time as other databases and not have a consistent databases. Often we can have different applications without interaction and can be backed up separately without the data becoming inconsistent even when those backups are at different times. Lots of sites do this now with mysqldump for their server backups.

              Show
              Meerkat63 Peter McLarty added a comment - Oracle has tables as part of a tablespace and the tablespace is able to be anywhere on disk the tables are within a tablespace and oracle you can place a tablespace in backup mode, all data within that tablespace is kept consistent. Oracle writes logs of activity to be changed in that tablespace until the lock is released. This might be a step too far but may help formulate a way forward to get this to work. Tablespaces probably need to be implemented within the engine but could still be kept in the mariadb variables. This would allow the concept of then managing data with a lock that doesn't necessarily affect the total server instance only the tablespace/s you wish to back up in that window for consistency. For example now I don't necessarily need to lock the mysql database at the same time as other databases and not have a consistent databases. Often we can have different applications without interaction and can be backed up separately without the data becoming inconsistent even when those backups are at different times. Lots of sites do this now with mysqldump for their server backups.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  erkules erkan yanar
                • Votes:
                  5 Vote for this issue
                  Watchers:
                  10 Start watching this issue

                  Dates

                  • Created:
                    Updated: