mysql 物理备份 MySQL 全量备份 增量备份 差异备份 日志备份万字长文 1.3万字

3分云计算2024-08-19 14:16

版权声明：本文为博主原创文章，遵循版权协议，转载请附上原文出处链接和本声明

注意，通常 完备增备，日志（binlog)备，结合使用 差异则根据具体情况选用。

此备份过程

属于公司

常用的单个数据库备份技术中的

mysql 物理备份 MySQL 全量备份 增量备份 差异备份 日志备份

至于单个数据库备份技术中的逻辑备份

和

混合数据库及其备份技术，本人会另外开文章再进行说明

MySQL备份工具的安装

逻辑备份工具 mysqldump 自带

物理备份工具 percona-xtrabackup 需安装

MySQL数据备份方式

主要有四种：

完整备份、增量备份、差异备份和逻辑备份。它们的区别在于备份的范围和备份方式不同。

MySQL物理备份的种类及其特点

MySQL物理备份主要有三种：完整备份 、增量备份 和差异备份。每种备份方式都有其独特的特点和适用场景。

1. 完整备份
  • 特点 ：
    • 备份整个数据库的所有数据和结构。
    • 备份文件较大，占用较多存储空间。
    • 恢复速度最快，因为只需要恢复一个备份文件。
  • 适用场景 ：
    • 数据量较小的数据库。
    • 需要快速恢复的场景。
2. 增量备份
  • 特点 ：
    • 备份自上次完整备份或增量备份以来发生变化的数据。
    • 备份文件较小，节省存储空间。
    • 恢复速度较慢，因为需要先恢复完整备份，然后应用所有增量备份。
  • 适用场景 ：
    • 数据量较大且变化频繁的数据库。
    • 需要节省存储空间的场景。
3. 差异备份
  • 特点 ：
    • 备份自上次完整备份以来发生变化的数据。
    • 备份文件大小介于完整备份和增量备份之间。
    • 恢复速度较快，因为只需要恢复完整备份和一个差异备份。
  • 适用场景 ：
    • 数据量较大且变化频繁，但希望恢复过程不太复杂。
    • 需要快速恢复且节省存储空间的场景。

总结

选择哪种备份方式取决于具体需求：

  • 完整备份适用于数据量较小且需要快速恢复的场景。
  • 增量备份适用于数据量较大且变化频繁，需要节省存储空间的场景。
  • 差异备份适用于数据量较大且变化频繁，但希望恢复过程不太复杂的场景。

Percona XtraBackup 是一个开源的 MySQL 和 InnoDB 备份工具，广泛用于物理数据备份和恢复。

MySQL 安装percona-xtrabackup

逻辑备份工具 mysqldump 自带

percona-xtrabackup 版本这里有必要说明

参考官网如下：

  • 翻译过来意思就是 ：Percona XtraBackup 的版本要超过（ 大于或等于 ）数据库的版本。

比如：当前 MySQL 数据库版本 8.0.32，若安装 XtraBackup 版本为 8.0.32-xxx

尽量和数据库的版本保持一致 为啥？如果不保持一致 因为会天天输出报警信息说你的备份工具和数据库版本不匹配

查看mysql 版本：****

[root@root ~]# mysql -V
mysql Ver 14.14 Distrib 5.7.44, for Linux (x86_64) using EditLine wrapper
[root@root ~]#

注意v必须大写

安装与MySQL 5.7兼容的Percona XtraBackup版本。在你的情况下，MySQL版本是5.7.44，所以你应该安装Percona XtraBackup 2.4，因为这一版本与MySQL 5.7兼容。

MySQL********8.0.32 对应版本： Percona XtraBackup 8.0.32-x

则查看 XtraBackup 版本时

卸载 已经安装的 XtraBackup

查找已经安装的 XtraBackup 名称

查找

[ root@root soft]# yum list installed | grep -i xtrabackup

# 卸载

yum -y remove percona-xtrabackup-80.x86_64

安装percona-xtrabackup

查看mysql 版本：****

[root@root ~]# mysql -V
mysql Ver 14.14 Distrib 5.7.44, for Linux (x86_64) using EditLine wrapper
[root@root ~]#

安装与MySQL 5.7兼容的Percona XtraBackup版本。在你的情况下，MySQL版本是5.7.44，所以你应该安装Percona XtraBackup 2.4，因为这一版本与MySQL 5.7兼容。

MySQL********8.0.32 对应版本： Percona XtraBackup 8.0.32-x

[root@mysql-server ~]# vim /etc/yum.repos.d/Percona.repo

[percona]

name = CentOS $releasever - Percona

baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/

enabled = 1

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona

gpgcheck = 1 改为0 不然还要去官网获取密钥太麻烦

注:我的MySQL 5.7.44 是用yum安装的

推荐yum,二进制安装 ，切记不推荐编译，

会爆各种错，五花八门的

MySQL物理备份主要有三种：完整备份、增量备份和差异备份。每种备份方式都有其独特的特点和适用场景。

完全备份

创建备份目录：

[root@root ~]# mkdir /xtrabackup/bakwuli -p

备份之前，进入数据库，存入些数据

[root@root ~]# mysql -uroot -p'Password123$'

mysql> create database testbakwuli;

Query OK, 1 row affected (0.01 sec)

mysql> use testbakwuli

Database changed

mysql> create table t1(id int);

Query OK, 0 rows affected (0.05 sec)

mysql> exit

备份：

[root@root ~]# innobackupex --user=root --password='Password123$' /xtrabackup/bakwuli

。。。。。

。。。。。。

40815 20:43:24 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '32452021'
xtrabackup: Stopping log copying thread.
.240815 20:43:24 >> log scanned up to (32452030)

240815 20:43:24 Executing UNLOCK TABLES
240815 20:43:24 All tables unlocked
240815 20:43:24 [00] Copying ib_buffer_pool to /xtrabackup/bakwuli/2024-08-15_20-43-21/ib_buffer_pool
240815 20:43:24 [00] ...done
240815 20:43:24 Backup created in directory '/xtrabackup/bakwuli/2024-08-15_20-43-21/'
240815 20:43:24 [00] Writing /xtrabackup/bakwuli/2024-08-15_20-43-21/backup-my.cnf
240815 20:43:24 [00] ...done
240815 20:43:24 [00] Writing /xtrabackup/bakwuli/2024-08-15_20-43-21/xtrabackup_info
240815 20:43:24 [00] ...done
xtrabackup: Transaction log of lsn (32452021) to (32452030) was copied.
240815 20:43:25 completed OK!

查看:

[root@root ~]# cd /xtrabackup/bakwuli

[root@root bakwuli]# ls

2024-08-15_20-43-21

[root@root bakwuli]#

完全备份恢复

1.关闭数据库：

[root@root bakwuli]# systemctl stop mysqld

清理环境

[root@root bakwuli]# rm -rf /var/lib/mysql/*

[root@root bakwuli]# rm -rf /var/log/mysql-slow/slow.log

2.重演恢复:

[root@root bakwuli]# innobackupex --apply-log /xtrabackup/bakwuli/2024-08-15_20-43-21

。。。。。

。。。

g the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.44 started; log sequence number 32452117
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 32452136
240815 20:50:01 completed OK!

注：恢复之前需要确认配置文件内有数据库指定目录，如下，不然会随机恢复数据到某个位置

很麻烦

vim /etc/my.cnf

在命令行模式：

/datadir=/var/lib/mysq

查看里面是否有datadir=/var/lib/mysql

[mysqld]

datadir=/var/lib/mysql

：q

.恢复数据:

[root@root bakwuli]# innobackupex --copy-back /xtrabackup/bakwuli/2024-08-15_20-43-21
。。。。。。

。。。。。。

b_buffer_pool
240815 20:58:39 [01] ...done
240815 20:58:39 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
240815 20:58:39 [01] ...done
240815 20:58:39 [01] Copying ./xtrabackup_master_key_id to /var/lib/mysql/xtrabackup_master_key_id
240815 20:58:39 [01] ...done
240815 20:58:39 [01] Copying ./ibtmp1 to /var/lib/mysql/ibtmp1
240815 20:58:39 [01] ...done
240815 20:58:39 completed OK!
[root@root bakwuli]#

恢复完数据 重启失败，但是给他一个权限就能重启成功

[root@root bakwuli]# chown mysql.mysql /var/lib/mysql -R

[root@root bakwuli]# systemctl start mysqld

[root@root bakwuli]#

测试是否成功恢复数据

****[root@root bakwuli]# mysql -uroot -p"Password123$"

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| testbakwuli |
| zabbix |
+--------------------+
7 rows in set (0.01 sec)

mysql> use testbakwuli;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-----------------------+
| Tables_in_testbakwuli |
+-----------------------+
| t1 | ------------》》从这可看出刚刚删除的表，数据已恢复
+-----------------------+
1 row in set (0.00 sec)

mysql> exit

systemctl st op mysqld

增量备份

**增量备份 每次备份上一次备份到现在产生的新数据 **且基于前一天的备份为目录，在企业中增量备份通常与完备配合使用 比如1234567天 1用完备，2，3，4，5，6，7分别用增量 .

刚刚已创建指定备份目录**/xtrabackup/bakwuli/** 和 测试用的数据库testbakwuli 数据表t1

刚刚已经备份了第1天的完备

现在第2天，增备：

在数据库中插入表值，模拟第2天产生新数据

mysql -uroot -p"Password123$"

mysql> insert into testbakwuli.t1 values(2);

Query OK, 1 row affected (0.01 sec)

mysql> exit

systemctl st op mysqld

备份上一次备份到现在产生的新数据 且基于第一天的备份为目录

[root@root bakwuli]# innobackupex -uroot -p"Password123$" --incremental /xtrabackup/bakwuli/ --incremental-basedir=//xtrabackup/bakwuli/2024-08-15_20-43-21

[root@root bakwuli]# ls

2024-08-15_20-43-21 2024-08-15_21-24-39

[root@root bakwuli]#

现在第 3 天，增备：

在数据库中插入表值，模拟第 3 天产生新数据

mysql -uroot -p"Password123$"

mysql> insert into testbakwuli.t1 values( 3 );

Query OK, 1 row affected (0.01 sec)

mysql> exit

[root@root bakwuli]# ls 查看前两天的备份

2024-08-15_20-43-21 2024-08-15_21-24-39

# 备份上一次备份到现在产生的新数据 且 是 基于第 2 天的备份为目录

systemctl st op mysqld

[root@root bakwuli]# innobackupex -uroot -p"Password123$" --incremental /xtrabackup/bakwuli/ --incremental-basedir=//xtrabackup/bakwuli/2024-08-15_21-24-39

[root@root bakwuli]# ls

2024-08-15_20-43-21 2024-08-15_21-24-39 2024-08-15_21-35-30

全备周一 （ 第1天 增量周二 （ 第2天 增量周三 （ 第3天

增量备份恢复

1. 停止数据库

2. 清理环境

3. 依次重演回滚redo log－－> 恢复数据

恢复完整备份。 依次应用所有增量备份。完成恢复过程。

将恢复的数据文件复制到 MySQL 数据目录

4. 修改权限

5. 启动数据库

测试：

[root@root bakwuli]# ls

2024-08-15_20-43-21 2024-08-15_21-24-39 2024-08-15_21-35-30

[root@root bakwuli]# systemctl stop mysqld

[root@root bakwuli]# rm -rf /var/lib/mysql/*

依次重演回滚redo log: 恢复完整备份 假设完整备份存储在 /xtrabackup/bakwuli/2024-08-15_20-43-21/ 目录中。

[root@root bakwuli]# innobackupex --apply-log --redo-only /xtrabackup/bakwuli/2024-08-15_20-43-21/

回滚 周二 应用第一个增量 ： 备份 假设完整备份存储在 /xtrabackup/bakwuli/2024-08-15_21-24-39 目录中。

[root@root bakwuli]# innobackupex --apply-log --redo-only /xtrabackup/bakwuli/2024-08-15_20-43-21/ --incremental-dir=/xtrabackup/bakwuli/2024-08-15_21-24-39

回滚周三

[root@root bakwuli]# innobackupex --apply-log --redo-only /xtrabackup/bakwuli/2024-08-15_21-24-39/ --incremental-dir=/xtrabackup/bakwuli/2024-08-15_21-35-30

完成恢复

最后一步是完成恢复过程，这次不再使用 --redo-only 选项。

[root@root bakwuli]# innobackupex --apply-log /xtrabackup/bakwuli/2024-08-15_20-43-21/

恢复数据到 MySQL 数据目录

将恢复的数据文件复制到 MySQL 数据目录中。确保 MySQL 服务已停止。

[root@root bakwuli]# cp -r /xtrabackup/bakwuli/2024-08-15_20-43-21/* /var/lib/mysql/

修改权限

[root@mysql-server ~]# chown -R mysql.mysql /var/lib/mysql

[root@mysql-server ~]# systemctl start mysqld
查看是否恢复

****[root@root bakwuli]# mysql -uroot -p"Password123$"

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| testbakwuli |
| zabbix |
+--------------------+
7 rows in set (0.01 sec)

mysql> use testbakwuli;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;

**关于****增量备份恢复过程 ，**报错解决

InnoDB: Page [page id: space=0, page number=7] log sequence number 32452174 is in the future! Current system log sequence number 32452154.

InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to MySQL :: MySQL 5.7 Reference Manual :: 14.22.2 Forcing InnoDB Recovery for information about forcing recovery.

xtrabackup: error: The transaction log file is corrupted.

xtrabackup: error: The log was not applied to the intended LSN!

xtrabackup: Log applied to lsn 32452145

xtrabackup: The intended lsn is 32452347

具体的错误信息如下：

  1. Page log sequence number is in the future：

    CopyInnoDB: Page [page id: space=0, page number=7] log sequence number 32452174 is in the future! Current system log sequence number 32452154.

    这意味着某个页面的日志序列号（LSN）比当前系统的日志序列号还要大，表明数据不一致。

  2. Transaction log file is corrupted：

    Copyxtrabackup: error: The transaction log file is corrupted.
xtrabackup: error: The log was not applied to the intended LSN!
xtrabackup: Log applied to lsn 32452145
xtrabackup: The intended lsn is 32452347

    这表示事务日志文件已损坏，日志应用到了错误的 LSN。

这些错误可能是由于以下原因导致的：

  • 备份过程中 InnoDB 表空间和日志文件没有同步复制。
  • 数据库在备份时发生了写入操作，导致数据不一致。
  • 硬件故障或文件系统错误导致文件损坏。

解决方法

  1. 强制恢复 ：

    可以尝试按照 MySQL 官方文档中的指导进行强制恢复。参考链接：Forcing InnoDB Recovery

    在 my.cnf 文件中添加以下配置选项，然后重启 MySQL 服务：

    Copy[mysqld]
innodb_force_recovery = 1

    如果 innodb_force_recovery = 1 无法解决问题，可以尝试逐步增加值（最大为 6），但请注意，较高的值可能会导致数据丢失。

  2. 检查和修复文件权限 ：

    确保 MySQL 服务器对所有 InnoDB 表空间和日志文件具有适当的读写权限。

  3. 重新备份和恢复 ：

    如果可能的话，重新进行一个完整的备份，并确保备份过程没有中断或错误。

  4. 检查硬件和文件系统 ：

    确保硬件和文件系统没有问题，检查磁盘是否有坏块，文件系统是否有错误。

  5. 咨询专业支持 ：

    如果问题依然存在，考虑寻求专业的数据库支持服务，特别是如果这是一个生产环境。

为了避免InnoDB数据库损坏和备份过程中的问题，以下是一些最佳实践和预防措施：

1. 定期备份

  • 频繁备份：定期进行全量和增量备份，确保在数据损坏时有可用的恢复点。
  • 验证备份：定期验证备份文件的完整性和可恢复性，确保备份文件没有损坏。

2. 正确配置备份工具

  • 使用最新版本：确保使用对应数据库版本的备份工具，如Percona XtraBackup，以获得最新的功能和修复。
  • 正确配置：确保备份工具的配置正确，包括备份路径、日志文件路径等。

3. 数据库配置

  • 启用双写缓冲区 ：在MySQL配置文件中启用InnoDB的双写缓冲区，以减少数据损坏的可能性。

    Copy[mysqld]
innodb_doublewrite = 1

  • 适当的缓冲池大小 ：配置适当的InnoDB缓冲池大小，确保数据库性能和稳定性。

    Copy[mysqld]
innodb_buffer_pool_size = <适当的大小>

4. 数据库维护

  • 定期检查和优化 ：定期运行CHECK TABLE和OPTIMIZE TABLE命令，确保表的一致性和性能。
  • 监控错误日志：定期检查MySQL错误日志，及时发现和解决潜在问题。

5. 文件系统和硬件

  • 选择可靠的文件系统：使用支持事务的文件系统，如EXT4或XFS，以减少文件系统层面的数据损坏。
  • 硬件监控：定期检查硬件状态，包括磁盘健康状况，确保硬件没有故障。

6. 数据库操作

  • 避免长时间运行的事务：避免长时间运行的事务，减少锁争用和潜在的数据不一致性。
  • 适当的事务隔离级别：根据业务需求设置适当的事务隔离级别，避免不必要的锁争用。

7. 恢复测试

  • 定期恢复测试：定期进行恢复测试，确保备份文件在实际恢复过程中可用。

8. 业务高峰期备份

  • 避开高峰期：尽量避开业务高峰期进行备份，减少备份过程中数据写入的冲突。

9. 备份策略

  • 多层次备份：结合全量备份、增量备份和日志备份，确保多层次的备份策略。
  • 异地备份：将备份文件存储在异地，防止本地灾难导致数据完全丢失。

10. 监控和报警

  • 设置监控和报警：使用监控工具（如Prometheus、Grafana）监控数据库和备份工具的运行状态，设置报警机制，及时发现和处理异常情况。

通过以上措施，可以大大减少InnoDB数据库损坏和备份过程中的问题，确保数据的安全性和可靠性。

Binlog 备份概述

MySQL 的二进制日志（binlog）记录了所有对数据库进行更改的语句（例如，INSERT、UPDATE、DELETE等）。通过备份和恢复 binlog，可以实现数据的增量恢复和灾难恢复。

Binlog 备份

  1. 启用 binlog
    确保在 MySQL 配置文件（my.cnf 或 my.ini）中启用了 binlog。

    复制代码 
    Copy`[mysqld]
log-bin=mysql-bin
server-id=1
`

    重启 MySQL 服务以使配置生效。

    复制代码 
    Copy`systemctl restart mysqld
`

  2. 查看 binlog 文件
    使用以下命令查看当前的 binlog 文件列表。

    复制代码 
    Copy`mysql -uroot -p"Password123$" -e "SHOW BINARY LOGS;"
`

  3. 备份 binlog 文件
    定期将 binlog 文件复制到安全的位置。例如，可以使用 rsync 或 scp 命令进行远程备份。

    复制代码 
    Copy`rsync -av /var/lib/mysql/mysql-bin.* /path/to/backup/
`

Binlog 恢复的步骤

  1. 恢复完整备份
    首先恢复最近的完整备份。假设完整备份存储在 /xtrabackup/bakwuli/2024-08-15_20-43-21/ 目录中。

    复制代码 
    Copy`innobackupex --apply-log /xtrabackup/bakwuli/2024-08-15_20-43-21/
cp -r /xtrabackup/bakwuli/2024-08-15_20-43-21/* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mysqld
`

  2. 恢复 binlog 文件
    使用 mysqlbinlog 工具将 binlog 文件应用到数据库中。

    复制代码 
    Copy`mysqlbinlog /path/to/backup/mysql-bin.000001 /path/to/backup/mysql-bin.000002 | mysql -uroot -p"Password123$"
`

    如果需要应用特定的时间点，可以使用 --start-datetime 和 --stop-datetime 选项。

    复制代码 
    Copy`mysqlbinlog --start-datetime="2024-08-16 00:00:00" --stop-datetime="2024-08-16 23:59:59" /path/to/backup/mysql-bin.000001 | mysql -uroot -p"Password123$"
`

总结

通过 binlog 备份和恢复，可以实现 MySQL 数据库的增量恢复。这种方法特别适用于需要将数据库恢复到特定时间点的场景。结合完整备份和增量备份，binlog 备份提供了一种灵活且高效的数据恢复方案

差异备份概述

差异备份是备份自上次完整备份以来发生变化的数据。与增量备份不同，差异备份每次都基于上一次的完整备份，而不是基于上一次的增量备份。因此，恢复过程只需要恢复完整备份和最后一个差异备份。

差异备份

注意，通常 完备增备，日志（binlog)备，结合使用 差异则根据具体情况选用。

假设我已经完成了第1天的完整备份，现在将进行第2天和第3天的差异备份。

第1天：完整备份

假设完备（完整备份）已经完成，存储在 /xtrabackup/bakwuli/2024-08-15_20-43-21/ 目录中。

第2天：差异备份

  1. 插入新数据

    复制代码 
    Copy`mysql -uroot -p"Password123$"
mysql> insert into testbakwuli.t1 values(2);
Query OK, 1 row affected (0.01 sec)
mysql> exit
`

  2. 停止 MySQL 服务

    复制代码 
    Copy`systemctl stop mysqld
`

  3. 执行差异备份

    复制代码 
    Copy`innobackupex -uroot -p"Password123$" --incremental /xtrabackup/bakwuli/ --incremental-basedir=/xtrabackup/bakwuli/2024-08-15_20-43-21
`

  4. 查看备份目录

    复制代码 
    Copy`ls /xtrabackup/bakwuli/
`

    输出应类似：

    复制代码 
    Copy`2024-08-15_20-43-21  2024-08-16_21-24-39
`
第3天：差异备份

  1. 插入新数据

    复制代码 
    Copy`mysql -uroot -p"Password123$"
mysql> insert into testbakwuli.t1 values(3);
Query OK, 1 row affected (0.01 sec)
mysql> exit
`

  2. 停止 MySQL 服务

    复制代码 
    Copy`systemctl stop mysqld
`

  3. 执行差异备份

    复制代码 
    Copy`innobackupex -uroot -p"Password123$" --incremental /xtrabackup/bakwuli/ --incremental-basedir=/xtrabackup/bakwuli/2024-08-15_20-43-21
`

  4. 查看备份目录

    复制代码 
    Copy`ls /xtrabackup/bakwuli/
`

    输出应类似：

    复制代码 
    Copy`2024-08-15_20-43-21  2024-08-16_21-24-39  2024-08-17_21-35-30
`

差异备份的恢复

  1. 停止 MySQL 服务

    复制代码 
    Copy`systemctl stop mysqld
`

  2. 清理 MySQL 数据目录

    复制代码 
    Copy`rm -rf /var/lib/mysql/*
`

  3. 恢复完整备份

    复制代码 
    Copy`innobackupex --apply-log --redo-only /xtrabackup/bakwuli/2024-08-15_20-43-21/
`

  4. 应用第一个差异备份

    复制代码 
    Copy`innobackupex --apply-log --redo-only /xtrabackup/bakwuli/2024-08-15_20-43-21/ --incremental-dir=/xtrabackup/bakwuli/2024-08-16_21-24-39/
`

  5. 应用第二个差异备份

    复制代码 
    Copy`innobackupex --apply-log /xtrabackup/bakwuli/2024-08-15_20-43-21/ --incremental-dir=/xtrabackup/bakwuli/2024-08-17_21-35-30/
`

  6. 将恢复的数据文件复制到 MySQL 数据目录

    复制代码 
    Copy`cp -r /xtrabackup/bakwuli/2024-08-15_20-43-21/* /var/lib/mysql/
`

  7. 修改权限

    复制代码 
    Copy`chown -R mysql:mysql /var/lib/mysql
`

  8. 启动 MySQL 服务

    复制代码 
    Copy`systemctl start mysqld
`

总结

差异备份的恢复过程相对简单，只需要恢复完整备份和最后一个差异备份。相比增量备份，差异备份的恢复速度更快，因为不需要依次应用所有增量备份。选择哪种备份方式应根据具体的需求和场景来决定。

待补充，，，，

相关推荐
Ai 编码助手1 小时前
MySQL中distinct与group by之间的性能进行比较
数据库·mysql
陈燚_重生之又为程序员1 小时前
基于梧桐数据库的实时数据分析解决方案
数据库·数据挖掘·数据分析
caridle1 小时前
教程：使用 InterBase Express 访问数据库（五）：TIBTransaction
java·数据库·express
白云如幻1 小时前
MySQL排序查询
数据库·mysql
萧鼎1 小时前
Python并发编程库：Asyncio的异步编程实战
开发语言·数据库·python·异步
^velpro^2 小时前
数据库连接池的创建
java·开发语言·数据库
苹果醋32 小时前
Java8-＞Java19的初步探索
java·运维·spring boot·mysql·nginx
荒川之神2 小时前
ORACLE _11G_R2_ASM 常用命令
数据库·oracle
IT培训中心-竺老师2 小时前
Oracle 23AI创建示例库
数据库·oracle
小白学大数据2 小时前
JavaScript重定向对网络爬虫的影响及处理
开发语言·javascript·数据库·爬虫
热门推荐
01如何才能让手机厂商主动拥抱华为，接入鸿蒙系统？02【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测05(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明06【经验分享】Ubuntu22.04安装微信(linux官方版)07【TC3xx芯片】TC3xx芯片电源管理系统PMS详解08全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）09RAG 实践- Ollama+RagFlow 部署本地知识库10你还在傻傻的打开页面输用户名和密码？来我教你实现自动化