Creating a Backup
Choosing the backup type #
As described in Backup types, you choose to run a full Backup (the default) or an incremental Backup.
Full backups will use the backup engine chosen in the tablet's configuration. Incremental backups will always copy MySQL's binary logs, irrespective of the configured backup engine.
Using xtrabackup #
The default backup implementation is builtin, however we strongly recommend using the xtrabackup engine as it is more robust and allows for non-blocking backups. Restores will always be done with whichever engine was used to create the backup.
Prerequisites #
A compatible version of xtrabackup and xbstream, if needed, must be present in your $PATH prior to running the Backup[Shard] command.
Supported Versions #
Configuration #
To use xtrabackup with Vtbackup, VTTablet or Vtctld, the following flags must be set.
Required flags:
--backup_engine_implementation=xtrabackup--xtrabackup_user string- The user that xtrabackup will use to connect to the database server. This user must have the necessary privileges.
- This user will need to be authorized to connect to mysql locally without a password using auth_socket.
Additionally required for MySQL 8.0:
--xtrabackup_stream_mode=xbstream
Common Errors and Resolutions #
No xtrabackup User passed to vttablet:
E0310 08:15:45.336083 197442 main.go:72] remote error: rpc error: code = Unknown desc = TabletManager.Backup on zone1-0000000102 error: xtrabackupUser must be specified.: xtrabackupUser must be specified
Fix: Set the vtctld and vttablet flag --xtrabackup_user
xtrabackup binary not found in $PATH:
E0310 08:22:22.260044 200147 main.go:72] remote error: rpc error: code = Unknown desc = TabletManager.Backup on zone1-0000000102 error: unable to start backup: exec: "xtrabackup": executable file not found in $PATH: unable to start backup: exec: "xtrabackup": executable file not found in $PATH
Fixes:
* Ensure the xtrabackup binary is in the $PATH for the $USER running vttablet
* Alternatively, set --xtrabackup_root_path on vttablet provide path to xtrabackup/xbstream binaries via vtctld and vttablet flags
Tar format no longer supported in 8.0:
I0310 12:34:47.900363 211809 backup.go:163] I0310 20:34:47.900004 xtrabackupengine.go:310] xtrabackup stderr: Invalid --stream argument: tar
Streaming in tar format is no longer supported in 8.0; use xbstream instead
Fix: Set the --xtrabackup_stream_mode flag to to xbstream on vttablets and vtctlds
Unsupported mysql server version:
I0310 12:49:32.279729 215835 backup.go:163] I0310 20:49:32.279435 xtrabackupengine.go:310] xtrabackup stderr: Error: Unsupported server version 8.0.23-0ubuntu0.20.04.1.
I0310 12:49:32.279773 215835 backup.go:163] I0310 20:49:32.279485 xtrabackupengine.go:310] xtrabackup stderr: Please upgrade PXB, if a new version is available. To continue with risk, use the option --no-server-version-check.
To continue with risk: Set --xtrabackup_backup_flags=--no-server-version-check. Note this occurs when your MySQL server version is technically unsupported by xtrabackup.
Create a full backup with vtctl #
Run the following vtctl command to create a backup:
vtctldclient --server=<vtctld_host>:<vtctld_port> Backup <tablet-alias>
If the engine is builtin, replication will be stopped prior to shutting down mysqld for the backup.
If the engine is xtrabackup, the tablet can continue to serve traffic while the backup is running.
Run the following vtctl command to backup a specific shard:
vtctldclient --server=<vtctld_host>:<vtctld_port> BackupShard [--allow_primary=false] <keyspace/shard>
Create an incremental backup with vtctl #
An incremental backup requires additional information: the point from which to start the backup. An incremental backup is taken by supplying --incremental_from_pos to the Backup command. The argument may either indicate a valid position, or the value auto. Examples:
vtctlclient -- Backup --incremental_from_pos="MySQL56/0d7aaca6-1666-11ee-aeaf-0a43f95f28a3:1-53" zone1-0000000102
vtctlclient -- Backup --incremental_from_pos="auto" zone1-0000000102
When --incremental_from_pos="auto", Vitess chooses the position of the last successful backup as the starting point for the incremental backup. This is a convenient way to ensure a sequence of contiguous incremental backups.
An incremental backup backs up one or more MySQL binary log files. These binary log files may begin with the requested position, or with an earlier position. They will necessarily include the requested position. When the incremental backup begins, Vitess rotates the MySQL binary logs on the tablet, so that it does not back up an active log file.
An incremental backup fails in these scenarios:
- It is unable to find binary log files that covers the requested position. This can happen if the binary logs are purged earlier than the incremental backup was taken. It essentially means there's a gap in the changelog events. Note that while on one tablet the binary logs may be missing, another tablet may still have binary logs that cover the requested position.
- There is no change to the database since the requested position, i.e. the GTID position has not changed since.
v17 only supports --incremental_from_pos in the Backup command, not in BackupShard. Also, only vtctlclient supports the flag, where vtctldclient does not. v18 is expected to support incremental backups for BackupShard and for vtctldclient.
Backing up Topology Server #
The Topology Server stores metadata (and not tablet data). It is recommended to create a backup using the method described by the underlying plugin: