Backup Management and Recovery

MySQL cloud database supports database backup, Binlog automatic backup, backup recovery, backup file download, and database rollback creation functions. Console backup management:

Backup Strategy

MySQL backup is divided into automatic backup and manual backup. Automatic backup is automatically performed once a day (the default backup time is a whole point between 3:00 and 6:00, and the backup can be saved for 7 days). Users can perform three free manual backups and seven free automatic backups. The backup source can choose to backup from the main library or the standby library; it supports whether to enable forced backup. After enabling forced backup, if there are some SQL errors in the library table, the forced backup will ignore and skip this table, and in order to ensure that the backup task is not interrupted, it will continue to backup other tables. In the backup files under this circumstance, tables with SQL errors may have no data. If there are SQL errors, it is recommended to fix them in time to ensure complete backup; users can set and change the automatic backup strategy according to business needs.

The SSD type MySQL offers two backup methods, physical backup and logical backup, with logical backup being the default; standard-type MySQL provides logical backup.

The NVMe model MySQL offers two types of backup methods: physical backup and logical backup, with physical backup set as the default option. It supports the 'Save to US3' feature, which automatically uploads backup files to your selected US3 storage space. You can manage your backup files in the US3 storage space, allowing for long-term retention based on actual business needs. During the period when the retention policy has the 'Save to US3' feature enabled, please ensure that the selected US3 product's token and the corresponding storage space exist and that the token authorization is valid; otherwise, there is a risk of backup upload failure."

The NVMe model MySQL offers an automatic Binlog backup feature, which supports the automatic dumping of local Binlog files to US3. It also allows for the configuration of the Binlog dump retention period. In functions such as database rollbacks and creating replicas, the system will prioritize using the dumped backups and Binlogs for data recovery, thereby reducing IO pressure on the primary database.

Manual Backup

The MySQL instance supports manual backups, allowing users to save important data backups at specific critical points in time. The current limit for retaining manual backups is three; if this limit is exceeded, the oldest manual backup will be automatically deleted. For SSD model MySQL, the backup options include both physical and logical backups, with the default set to logical backup. The standard model MySQL only offers the logical backup option. When creating a manual backup, users simply need to enter a backup name and select the backup method, after which the system will immediately commence the backup process.

After clicking on manual backup, a pop-up dialogue box can be used to input the backup name, the backup method, and whether to force backup. Logical backup defaults to backing up all databases. If some databases are not required to be backed up, then set the backup objects to filter out the unnecessary databases and tables.

Note:

When adding a library table that does not participate in the backup, if a non-existent library table is inputted, the backup will execute normally and will not report an error.

Backup Download

Users can download the backup files generated by automatic backup and manual backup.

To view the backup files of all MySQL instances, click on "Backup Management" in the left navigation bar.

To view the backup files of the corresponding MySQL instances, select the corresponding MySQL instance and click on "Backup Management" on the details page. NVMe instances will display the MD5 information of the backup files, which can be used for data integrity verification.

Click on the download icon to pop up the download box for download.

Note: If the backup file exceeds 1G, it is recommended to download it to the cloud server (UHost) via wget or curl. For larger backup files, when the download time exceeds two hours, it will return 206, and tools like wget will continue to download automatically upon encountering 206, until finally successful. This is a normal phenomenon.

If you wish to verify the integrity of the downloaded file, you can compute the MD5 of the downloaded backup file and compare it with the MD5 in the backup list. If they are the same, it means that the downloaded file is complete.

The MD5 of the file is computed through the md5sum command

If the user has enabled the Binlog automatic dump function, the Binlog backup file can also be downloaded from the list.

Binlog Local Log Management

Local Binlog log cleanup will affect the earliest rollback time of the database rollback function, the creation of slave libraries, etc., and it is recommended to use it in conjunction with the Binlog automatic backup function.

In the Binlog log backup list menu under the "Backup Management" menu of the instance details, you can configure the Binlog local management policy, which can be configured to keep the local maximum duration (1-168 hours) or the percentage of local disk usage (5%-100%). Once configured, it will automatically clean up local logs according to the strategy.

Create MySQL Instances from Backup

Users can choose backup files to create MySQL instances, click on "Create from backup". The creation process can refer to the Quick Start document.

Note:

The backup file compression ratio is 5:1, it is recommended that the disk space size during creation is more than 5 times the size of the backup file. initialization time depends on the amount of data.

Database Rollback

Cloud database MySQL supports database rollback. If data is deleted or lost due to misoperation, you can restore the data through "Database Rollback". Just make sure that both the data backup file and binlog exist, it can be restored to any second within 7 days. In the console, select the corresponding instance and click database rollback in the operation column.

SSD and Standard Types Instances

Supports database rollback to new instances, does not support designated libraries and tables. In the rollback pop-up window, select the time you need to restore and confirm, you can start rolling back to the new instance:

NVMe Type Instances

Supports database rollback to new or current instances, supports rollback at the library table level.

a. Database rollback to original instance, specify specific libraries and tables:

Rollback will not overwrite the original data, it will create a database with a timestamp, the naming format is "database name_[specify rollback time]_[operation execution time]", users can perform the required operations after confirming that the data is correct.

For example, specify the table nash.test for rollback, after the rollback, a table named nash_1662104405_1662104655.test will be created in the database.

b. Database rollback to new instance, specify specific library table:

For scenarios of rollback to new instances: After the rollback is complete, event_scheduler will be disabled by default. Users can restart it via the command line, or restart the instance in the control panel to turn it back on.

c. Rollback the entire database instance to a new instance:

For scenarios of rollback to new instances: After the rollback is complete, event_scheduler will be disabled by default. Users can restart it via the command line, or restart the instance in the control panel to turn it back on.