.. _parallel-ibk:
=================================
Accelerating the backup process
=================================
Accelerating with :option:`--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 :option:`--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 (:term:`innodb_file_per_table`) or the shared tablespace must be stored in multiple :term:`ibdata` files with the :term:`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 :option:`--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.
Accelerating with :option:`--rsync` option
------------------------------------------
In order to speed up the backup process and to minimize the time ``FLUSH TABLES WITH READ LOCK`` is blocking the writes, option :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::
This option cannot be used together with :option:`innobackupex --remote-host` or :option:`innobackupex --stream` options.