★CentOS：MySQL数据备份

一、cp 命令备份

特点：

• 优点：备份恢复数据快：直接复制文件，无需进行数据转换和复杂的处理，因此备份恢复速度非常快
• 缺点：需要停止数据库服务，灵活性差，占用空间大，可移植性差

使用：

停止数据库

创建备份目录：mkdir -p /usr/local/bin/mysql/data_backup_a

备份：

cp -a /usr/local/bin/mysql/data/* /usr/local/bin/mysql/data_backup_a/

恢复：

先备份：mv /usr/local/bin/mysql/data/ /usr/local/bin/mysql/data_backup_1

再恢复：cp -a /usr/local/bin/mysql/data_backup_a/* /usr/local/bin/mysql/data/

注：保证所有目录都存在（不存在就创建 mkdir -p ）

二、mysqldump全量备份

特点：

优点：备份文件是 SQL 语句，可以直接查看和编辑。支持热备份，可以对正在运行的数据库进行备份，而无需停止服务。跨平台，易恢复，可压缩

缺点：备份速度较慢：对于大型数据库，备份过程可能需要较长时间；恢复速度较慢：恢复时需要逐条执行 SQL 语句，速度可能比直接复制文件慢；数据一致性问题： 如果在备份过程中有数据写入，可能导致备份数据不一致。未压缩的 SQL 文件可能占用较多存储空间。备份期间可能影响性能。

设置定时任务 crontab -e，添加任务：0 8 * * * /usr/local/bin/mysql/script/xxxxxx_backup.sh

使用：

注：可以备份所有库、单个库、某张表、压缩，太多了这里以单个库为例（如果是docker，为容器中目录）

备份：

mysqldump -u root -p --single-transaction --flush-logs --source-data=2 --set-gtid-purged=OFF xiaodu > /usr/local/bin/mysql/backup/database_name_A.sql

参数说明：

• --source-data=2：在备份文件中记录二进制日志（binlog）的位置信息。这个参数在主从复制环境中非常有用，因为它允许从库在恢复备份后，从主库的正确位置开始复制

• --set-gtid-purged=OFF：GTID（Global Transaction Identifiers）是 MySQL 中用于标识事务的全局唯一标识符。主从复制

• --single-transaction确保备份时不会阻塞事务；

• --flush-logs会刷新binlog，生成新的binlog文件，方便后续的增量备份；

定期刷新binlog文件，生成新的binlog文件：mysqladmin flush-logs -u root -p

新的

恢复：

mysql -u root -p xiaodu_A < /usr/local/bin/mysql/backup/database_name_A.sql

三、mysqlbinlog增量备份

注：mysqlbinlog工具是个问题，从 MySQL 8.0 开始，mysqlbinlog 工具已经不再作为独立的二进制文件提供，而是集成在 MySQL 服务器中。因此，你不能直接在容器中运行 mysqlbinlog，而是需要通过 MySQL 服务器的命令行工具来访问二进制日志。Alpine Linux系统没有mysqlbinlog工具，但是可以使用debian版本的MySQL镜像文件（挺麻烦的，首先需要mysql有 mysqlbinlog 工具，然后需要下载各种SQL语句还原 binlog2sql 工具）

MySQL 的二进制日志工具，主要用于解析和处理 MySQL 的二进制日志文件（binlog）。虽然它本身不是直接用于备份的工具，但可以通过结合二进制日志实现增量备份和恢复。

特点：

优点：增量备份： 可以实现基于时间点的增量备份，仅备份自上次备份以来的更改。 节省存储空间，因为不需要每次都备份整个数据库。数据完整性： 二进制日志记录了所有数据更改操作，可以确保数据的完整性和一致性。恢复灵活性： 可以恢复到任意时间点，支持细粒度的恢复操作。支持主从复制： 二进制日志是主从复制的基础，使用 mysqlbinlog 可以更好地管理复制过程中的数据同步。

缺点：复杂性较高： 需要对二进制日志有较深入的了解，操作相对复杂。依赖二进制日志： 必须启用二进制日志，并且需要正确配置日志文件的存储和管理。 备份速度较慢： 二进制日志文件可能较大，解析和备份过程可能需要较长时间。 恢复速度较慢： 恢复时需要逐条应用日志中的更改，速度可能比直接复制文件慢。 对磁盘 I/O 影响大： 在解析和应用日志文件时，可能会对磁盘 I/O 产生较大压力。

使用：（mysqldump+mysqlbinlog）

Spring Boot 应用数据库用户，权限越小越安全。用 root 就像把银行金库钥匙交给前台。

-- 创建用户

CREATE USER 'app_user'@'%' IDENTIFIED BY 'StrongPassword123!';

-- 授予所需权限（示例：只对某个库有读写权限）

GRANT SELECT, INSERT, UPDATE, DELETE ON your_app_db.* TO 'app_user'@'%';

-- 刷新权限

FLUSH PRIVILEGES;

mysqlbinlog目录：/

操作：

场景：8点全量备份，9点修改A表数据，10点修改B表数据，11点整误删B表，12：30分才发现；该如何还原数据呢

前提是：你现在手里有一个事故前全量备份过的sql文件

第一步 备份：立即停止写入 & 保存现场（最好是k）

docker exec my-mysql-8 mysql -uroot -proot -e "
  SET GLOBAL read_only = 1;
  FLUSH TABLES WITH READ LOCK;"
# 2) 立即全量拷走当前数据和 binlog
docker exec mysql-8 cp -a /var/lib/mysql /backup/mysql_$(date +%Y%m%d_%H%M)

查看read_only 是否为1

SHOW GLOBAL VARIABLES LIKE 'read_only';

SELECT @@GLOBAL.read_only;

第二步：MySQL binlog 事件的可读文本转储（也就是将mysql-bin.000004变为读得懂的事件文本）

找到误删事件在 binlog 里的"坐标"

mysqlbinlog --base64-output=decode-rows -v --start-datetime="2025-08-17 10:00:00" --stop-datetime="2025-08-17 10:25:00" /var/lib/mysql/mysql-bin.000004 > /usr/local/bin/mysql/backup/around02.sql

生成"跳过误删"的两段 binlog

误删之前

mysqlbinlog --start-position=197 --stop-position=3956 --database=xiaodu --base64-output=decode-rows /var/lib/mysql/mysql-bin.000004 | grep -v -E '(^USE `alipay_config`|^DROP TABLE `alipay_config`)' > /usr/local/bin/mysql/backup/part1_before_drop.sql

误删之后

mysqlbinlog --start-position=4098 --stop-datetime="2025-8-17 10:45:00" --database=xiaodu --base64-output=decode-rows /var/lib/mysql/mysql-bin.000004 | grep -v -E '(^USE `alipay_config`|^DROP TABLE `alipay_config`)' > /usr/local/bin/mysql/backup/part2_after_drop.sql

注意：-E '(^USE `xiaodu`|^DROP TABLE `xiaodu`)' 这个正则排除掉删除表或者库的语句，需自行修改；将这段执行的SQL语句是为了不让删除语句再次执行（适当选择是否执行）

# 宿主机：然后使用 binlog2sql 将事件转为可执行的SQL语句

首先宿主机上安装 binlog2sql 工具

也可以下好了再放进来：git clone https://github.com/danfengcao/binlog2sql.git

修改 binlog2sql/requirements.txt 配置

• PyMySQL==0.9.3
• wheel==0.29.0
• mysql-replication==0.13

安装：pip install -r binlog2sql/requirements.txt

可能还需要另外升级：

• 卸载：pip3 uninstall PyMySQL binlog2sql mysql-replication -y
• 安装：pip3 install --upgrade cryptography
• 验证安装：python3 -c "from pymysqlreplication import BinLogStreamReader; print('OK')"

# 宿主机：转换为可执行的SQL语句：

python3 /usr/local/bin/mysql/binlog2sql/binlog2sql/binlog2sql.py -h127.0.0.1 -P13306 -uroot -p'root' -d xiaodu -t sys_dict --start-file='mysql-bin.000004' --start-pos=197 --stop-pos=3956 | grep -v -E '(^USE `alipay_config`|^DROP TABLE `alipay_config`)' > /usr/local/bin/mysql/backup/restore_sys_dict.sql

注：需要对SQL语句进行替换，比如bit类型，还有很多bug

# 新建一个mysql容器，以免误删或者对现场数据的再次污染（过程略过）

# 全量还原： mysql -u root -p xiaodu < /usr/local/bin/mysql/backup/database_name_A.sql

# 增量还原：

mysql -h127.0.0.1 -P13306 -uroot -p'root' xiaodu -v -v -v < /usr/local/bin/mysql/backup/restore_sys_dict.sql 2>&1 | tee /usr/local/bin/mysql/backup/restore.log

• -v -v -v：让 MySQL 把每一条语句都回显出来。

• 2>&1：把错误信息也合并到标准输出。

• tee restore.log：同时在屏幕和日志文件里保留一份。

我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！

我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！
我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！
我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！
我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！
我劝你别玩下走了，一堆的坑，放弃吧 乖！一天一备份，实在不行政商业版！！！

---

mysqlbinlog增量恢复一堆的坑等着你踩

mysqlbinlog增量恢复一堆的坑等着你踩

mysqlbinlog增量恢复一堆的坑等着你踩

mysqlbinlog增量恢复一堆的坑等着你踩

mysqlbinlog增量恢复一堆的坑等着你踩

---

复制bin文件：mysqlbinlog /var/lib/mysql/mysql-bin.000001 > /usr/local/bin/mysql/backup/mysql-bin.000001.sql

新建一个mysql容器，以免误删或者对现场数据的再次污染（过程略过）

选1、恢复：重放原始 binlog（最简单，会把所有事件重放）

mysqlbinlog --start-position=197 --stop-position=3956 /var/lib/mysql/mysql-bin.000004 | mysql -u root -p xiaodu

• 优点：一条命令搞定。

• 缺点：会把 197--3956 之间 所有库、所有表 的操作都重放，不会只针对 xiaodu 库。

选2、恢复：执行全量还原

mysql -u root -p xiaodu_A < /usr/local/bin/mysql/backup/database_name_A.sql

恢复：节点恢复

mysql -u root -p xiaodu < /usr/local/bin/mysql/backup/part1_before_drop.sql

mysqlbinlog --start-position=4691 --stop-position=1825 /var/lib/mysql/mysql-bin.000005 | mysql -u root -p

mysqlbinlog --start-position=214 /path/to/mysql-bin.000008 | mysql -u root -p
mysqlbinlog /path/to/mysql-bin.000009 | mysql -u root -p
mysqlbinlog /path/to/mysql-bin.000010 | mysql -u root -p
mysqlbinlog /path/to/mysql-bin.000011 | mysql -u root -p

按时间回复：

mysqlbinlog --stop-datetime="2025-08-16 12:00:00" /var/lib/mysql/mysql-bin.000004 | mysql -u root -p

• mysqldump：用于全量备份，生成完整的数据库备份文件。

• mysqlbinlog：用于增量备份，记录自上次全量备份以来的更改，支持基于时间点的恢复。

从 MySQL 8.4 开始，SHOW MASTER STATUS 已被弃用，取而代之的是 SHOW BINARY LOG STATUS。（MySQL中执行）

MySQL 8.0 及以下版本：

SHOW MASTER STATUS;

MySQL 8.4 及以上版本：

SHOW BINARY LOG STATUS;

SHOW BINARY LOGS;

四、Xtrabackup

还不如用mysqldump来得实在

XtraBackup 是 Percona 提供的用于备份 MySQL 的工具，它可以用来创建数据库的完整备份和增量备份。XtraBackup 相比于传统的 mysqldump 或其他备份方法，提供了更快的备份速度和更高的性能，因为它使用了 InnoDB 的热备份功能，不需要锁定数据库。

KIMI搜吧

docker compose部署mysql8.0实现xtrabackup全量备份、增量备份、恢复（详细注释）；初始化数据库：xiaodu，容器名：my-mysql-8，mysql端口13306，用户名：root，密码：root

挂载：

• /usr/local/bin/mysql/data:/var/lib/mysql

• /usr/local/bin/mysql/logs:/var/log/mysql

• /usr/local/bin/mysql/conf/my.cnf:/etc/my.cnf # 8.0版本以上

• /usr/local/bin/mysql/script:/usr/local/bin/mysql/script #脚本

• /usr/local/bin/mysql/backup:/usr/local/bin/mysql/backup # 备份数据

备份sh脚本