MySQL operation and maintenance 33-MySQL backup

1. MySQL backup strategy

1. Prioritize backup based on the slave library : reduce the load on the production environment.
2. Prioritize hot backup : Hot (Hot) means that the MySQL service is not shut down during backup, and production is not affected.
3. If the amount of data is large, physical backup is preferred, and if the amount of data is small, logical backup can be used : logical backup (usually mysqldump) is simpler, but the recovery time is long.
4. A comprehensive data backup strategy should be formulated : including daily backup, weekly backup, monthly backup, and quarterly backup. When the amount of data is large, regular full backups (low frequency) and frequent incremental backups (high frequency). In principle, it is necessary to back up every day in the near future. The expi re_logs_days parameter must span at least 2~3 backups;
5. The backup server should be considered as important as the production server : backup files should be physically separated from the database host, and FTP upload or other network transmission methods can be selected to keep backup files on an independent backup server. You can use NFS to mount the file system for remote backup.
6. The main library should enable binary logs: in order to build a slave library and do point-in-time recovery.

2. Use mysqldump to backup and restore data

2.1. Basic backup and recovery

1. Whole database backup command format

shell> mysqldump --databases db_name > db_name.sql

2. Recovery method one:

shell> mysql db_name < db_name.sql

3. Restoration method 2, you can use the source command to execute:

mysql > source /path/to/db_name.sql

4. In the production environment, the master-slave configuration is generally used, and regular backups should be performed on the slave database. Here is a complete example of using mysqldump backup.

mysqldump --single-transaction --flush-logs --master-data=2 --hex-blob -R -E -f --all-databases 2>> /path/to/log | gzip > sql.name.gz

• --single-transaction parameter: realize non-blocking backup, only lock the table at the beginning, and then it is non-blocking backup, that is, the backup does not affect the operation of the transaction.
• -f parameter: Since the view has dependencies, if the underlying table does not exist or has no permissions, the export of the view will fail and cause the exit of the mysqldump command. To avoid this problem, you can add a parameter -f to force the data to be exported instead of Quit halfway.
• --result-file parameter: For the backup of mysqldump, you need to check its output to check whether there are errors or warnings. After the normal backup, there should be the words "Dump completed on". We can use the --result-file parameter to save the mysqldump result.

2.2. Backup and recovery of stored procedures

1. Backup stored procedure:

shell> mysqldump  -td -R --triggers=false  db_name > db_name_procedure.sql

2. Only data is backed up, not stores and triggers.

mysqldump --triggers=false  db_name > db_name_data.sql

3. When restoring the trigger, you need to delete the original trigger in the database first. Since there is no DROP TRIGGIER statement in the dump file of the exported trigger, we need to manually generate the DROP TRIGGER statement. The following statement can automatically generate a trigger deletion statement based on information_schema:

SELECT CONCAT('drop trigger ',TRIGGER_NAME,';') INTO OUTFILE '/tmp/drop_trigger.sql' FROM information_schema.triggers WHERE TRIGGER_SCHEMA='db_name';

3. Summary

1. It is best to back up MySQL on the slave database. A large amount of data is suitable for physical backup (backup of data files), and a small amount of data is suitable for logical backup (mysqldump).
2. It is best to do hot backup for MySQL backup, that is, it does not affect production and does not require downtime.
3. For databases with a large amount of data, it is recommended to perform regular full backup at low frequency and regular backup at high frequency.