XTrabackup holds a global write-lock for no reason

[Dmitry Gribov]

During backup (in fact we deal with SST in XtraDB Cluster, but anyway) innobackupex script executes mysql_lockall sub, which acquires a global lock on the database. Considering we only use XtraDB tables, this lock only needs to block DDL execution after mysql folder is dumped. But script forcibly blocks all and any write-requests. Big database’s structure files may take several minutes to copy and during all this time server/cluster is write-locked for no reason. Painfull.

innobackupex should somehow be integrated with Percona XtraDB (Cluster) so that it would only hang DDL queries and leave data writing alone.

I'm not sure should this issue be in XTrabackup or XtraDB because it requires some database-side support like query "lock table ## structure" as well as innobackupex new options. Still locking the database for no reason looks like a bug.

Ps. We made software-level DDL-block and patched innobackupex so it now only holds the lock while backing up “mysql” folder. All other table files are copied with software-level DDL-lock, no delay. This turns >1minute hang into ~1 second delay which is absolutely acceptable. This makes cluster manipulations MUCH more comfortable and transparent.

[Alexey Kopytov (akopytov)]

Dmitry,

We are aware of this problem. In fact, it is one of the major features we are going to work on next: https://blueprints.launchpad.net/percona-xtrabackup/+spec/lightweight-lock-backup

You are right, it requires some server-side support to be implemented properly. Once implemented, making XtraBackup support those lightweight locks would be trivial.

Closing the bug as invalid (as it duplicates an existing blueprint), but referencing it from the blueprint for the record.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1256