Accelerating the backup process¶
--parallel copy and –compress-threads¶
When performing a local backup or the streaming backup with xbstream option, multiple files can be copied concurrently by using the
--parallel option. This option specifies the number of threads created by xtrabackup to copy data files.
To take advantage of this option either the multiple tablespaces option must be enabled (innodb_file_per_table) or the shared tablespace must be stored in multiple ibdata files with the innodb_data_file_path option. Having multiple files for the database (or splitting one into many) doesn’t have a measurable impact on performance.
As this feature is implemented at a file level, concurrent file transfer can sometimes increase I/O throughput when doing a backup on highly fragmented data files, due to the overlap of a greater number of random read requests. You should consider tuning the filesystem also to obtain the maximum performance (e.g. checking fragmentation).
If the data is stored on a single file, this option will have no effect.
To use this feature, simply add the option to a local backup, for example:
$ innobackupex --parallel=4 /path/to/backup
By using the xbstream in streaming backups you can additionally speed up the compression process by using the
--compress-threads option. This option specifies the number of threads created by xtrabackup for for parallel data compression. The default value for this option is 1.
To use this feature, simply add the option to a local backup, for example
$ innobackupex --stream=xbstream --compress --compress-threads=4 ./ > backup.xbstream
Before applying logs, compressed files will need to be uncompressed.
In order to speed up the backup process and to minimize the time
FLUSH TABLES WITH READ LOCK is blocking the writes, option
innobackupex --rsync should be used. When this option is specified, innobackupex uses
rsync to copy all non-InnoDB files instead of spawning a separate
cp for each file, which can be much faster for servers with a large number of databases or tables. innobackupex will call the
rsync twice, once before the
FLUSH TABLES WITH READ LOCK and once during to minimize the time the read lock is being held. During the second
rsync call, it will only synchronize the changes to non-transactional data (if any) since the first call performed before the
FLUSH TABLES WITH READ LOCK. Note that Percona XtraBackup will use Backup locks where available as a lightweight alternative to
FLUSH TABLES WITH READ LOCK. This feature is available in Percona Server 5.6+. Percona XtraBackup uses this automatically to copy non-InnoDB data to avoid blocking DML queries that modify InnoDB tables.
This option cannot be used together with
innobackupex --remote-host or
innobackupex --stream options.