Understanding Percona XtraBackup (PXB) Architecture and Backup Process

Percona XtraBackup (PXB) is an open‑source physical hot‑backup tool developed by Percona for MySQL, Percona Server, and MariaDB. It is the basis of the physical backup solution used in RDS MySQL.

The package installs four executables, the most important being innobackupex (a Perl script) and xtrabackup (a C/C++ binary). xtrabackup backs up InnoDB tables only, while innobackupex wraps xtrabackup to also handle non‑InnoDB tables and interact with the MySQL server (e.g., issuing FTWRL and retrieving replication positions).

Two additional utilities are xbcrypt for encryption/decryption and xbstream , a Percona‑specific concurrent‑write stream format similar to tar , both used when encryption or parallel processing is enabled.

Communication Method

The two tools coordinate via the creation and deletion of control files such as xtrabackup_suspended_1 , xtrabackup_suspended_2 , and xtrabackup_log_copied . For example, innobackupex starts xtrabackup and waits for xtrabackup_suspended_2 to appear, indicating that InnoDB files have been copied; after processing non‑InnoDB files it removes the file to let xtrabackup continue.

Backup Process

innobackupex forks and launches xtrabackup , then waits for InnoDB file copying to finish.

xtrabackup runs two threads: a redo‑log copy thread (started first) and an ibd‑file copy thread. The redo thread copies redo logs from the latest checkpoint; the ibd thread copies InnoDB data pages while innobackupex waits for the control file.

When ibd copying completes, xtrabackup creates a control file to notify innobackupex and continues copying redo logs.

innobackupex receives the notification, issues FLUSH TABLES WITH READ LOCK to obtain a consistent point, and backs up non‑InnoDB files (frm, MYD, MYI, CSV, etc.) while the server remains read‑only.

After non‑InnoDB files are copied, innobackupex deletes the control file, allowing xtrabackup to finish redo‑log copying.

xtrabackup stops its redo thread, creates a file to signal completion, and exits.

innobackupex unlocks the tables with UNLOCK TABLES .

Both processes perform cleanup, write backup metadata, and innobackupex waits for the xtrabackup child process to terminate before exiting.

InnoDB data is copied page‑by‑page with checksum verification, while non‑InnoDB files are copied via cp or tar . The backup is truly hot for InnoDB and only briefly read‑only for non‑InnoDB tables.

Incremental Backup

PXB supports incremental backups for InnoDB only. Each page has a monotonically increasing LSN; during an incremental run, only pages with LSN greater than the previous backup’s checkpoint (recorded in xtrabackup_checkpoints ) are copied. MyISAM tables lack an incremental mechanism, so they are fully copied each time.

Restore Process

Restoration mirrors the MySQL server startup sequence: the backup set is applied to bring the data files to a consistent point, which corresponds to the FTWRL timestamp taken during backup. Non‑InnoDB files remain unchanged; InnoDB files are restored using the copied pages and the redo logs to reach the same consistent point, after which the server can be started.

Source: Database Kernel Monthly Report (http://mysql.taobao.org/monthly/2016/03/07/)