Backups and Restores
The default settings created by
mysqlctl set the binlog
expire_logs_days to 3. Once the binlogs expire, you will not be able to bring up new empty replicas that can catch up to the current state.
So, you need to take regular backups, probably through a cron job. Assuming that you’ve configured the shared storage and provided the correct parameters to the Vitess components, you should be able to create a backup as follows:
vtctlclient Backup cell1-101
Backupcommand will shut down the MySQL instance to perform the operation. The instance will be unavailable until the backup is finished, the restarted MySQL instance is pointed back at the primary and caught up on replication.
Once a backup is taken, bringing up a subsequent vttablet-MySQL pair will cause it to restore from the backup instead of starting with a fresh MySQL instance. This will make it catch up from the beginning of time. You should see the following messages in the vttablet logs:
I0102 13:06:01.379759 30842 backup.go:227] Restore: looking for a suitable backup to restore I0102 13:06:01.379820 30842 shard_sync.go:70] Change to tablet state I0102 13:06:01.380757 30842 backupengine.go:221] Restore: found backup commerce/0 2021-01-02.205158.cell1-0000000101 to restore
If a MySQL with existing data is restarted either manually or due to a failure, an automatic restore will not be performed. Instead, a recovery will be performed from the existing data files.
Please refer to the Backup and Restore documentation for more information.