MySQL数据传输空表问题全攻略从原因分析到解决方案

引言

MySQL作为最流行的开源关系型数据库管理系统之一，在各种应用场景中广泛使用。在数据库管理过程中，数据传输是一个常见操作，包括数据备份、迁移、同步等。然而，许多数据库管理员和开发者在进行数据传输时经常遇到一个棘手的问题——传输完成后发现目标表是空的，或者只有表结构而没有数据。这种情况不仅会影响业务的连续性，还可能导致数据丢失，造成严重后果。

本文将全面分析MySQL数据传输中出现空表问题的各种原因，并提供详细的检测方法和解决方案，帮助读者有效预防和解决此类问题，确保数据传输的完整性和可靠性。

MySQL数据传输空表的原因分析

权限问题

权限不足是导致MySQL数据传输空表的常见原因之一。当执行数据传输操作的用户没有足够的权限时，可能只能读取表结构而无法读取表中的数据。

具体表现：

传输过程没有报错，但目标表为空
在源数据库中可以查询到数据，但传输工具无法读取数据
错误日志中可能包含权限相关的警告或错误信息

例子： 假设我们有一个用户transfer_user，它只有对test_db数据库中employees表的SELECT权限，但没有LOCK TABLES权限。当我们使用mysqldump工具进行数据传输时：

mysqldump -u transfer_user -p test_db employees > employees_backup.sql

虽然命令执行成功，但生成的SQL文件中可能只包含表结构创建语句，而没有数据插入语句，因为mysqldump默认需要LOCK TABLES权限来确保数据一致性。

表结构问题

某些表结构特性可能导致数据传输问题，特别是在跨版本或跨平台传输时。

具体表现：

目标表结构与源表不一致
特殊字段类型或字符集导致数据无法正确传输
外键约束导致数据插入失败

例子： 考虑一个使用了MySQL 8.0特有特性的表，如JSON字段类型：

CREATE TABLE product_details ( id INT PRIMARY KEY, details JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

当尝试将此表传输到不支持JSON数据类型的旧版本MySQL（如5.5）时，可能会导致表创建失败或数据无法正确插入。

数据过滤条件问题

在数据传输过程中，如果使用了不恰当的过滤条件，可能会导致意外地过滤掉所有数据。

具体表现：

使用了过于严格的WHERE条件
时间范围设置错误
传输工具的过滤参数配置不当

例子： 使用mysqldump进行数据传输时，如果添加了WHERE条件：

mysqldump -u root -p test_db employees --where="1=0" > employees_backup.sql

由于1=0条件永远为假，生成的SQL文件中将不包含任何数据插入语句，导致目标表为空。

传输工具或方法问题

不同的数据传输工具有其特定的行为和限制，使用不当可能导致数据传输问题。

具体表现：

工具默认配置跳过了数据传输
工具版本不兼容
网络问题导致传输中断

例子： 使用mysqldump时，如果忘记添加--skip-add-locks选项，在某些情况下可能导致锁表超时：

mysqldump -u root -p --single-transaction --flush-logs --master-data=2 test_db > backup.sql

如果表很大，锁表时间可能超过wait_timeout设置，导致连接断开，数据传输不完整。

存储引擎问题

MySQL支持多种存储引擎，如InnoDB、MyISAM、Memory等，不同存储引擎在数据传输时可能有不同的表现。

具体表现：

源表和目标表使用不同的存储引擎
某些存储引擎特有的功能无法正确传输
事务处理方式不同导致数据不一致

例子： 将一个使用MyISAM存储引擎的表传输到只支持InnoDB的环境中：

-- 源表定义 CREATE TABLE session_data ( session_id VARCHAR(32) PRIMARY KEY, data TEXT, last_access TIMESTAMP ) ENGINE=MyISAM; -- 如果目标环境不支持MyISAM，传输时可能需要转换存储引擎 -- 但某些MyISAM特有的特性（如全文索引）可能无法正确转换

MySQL数据传输空表的检测方法

基本检测命令

在发现数据传输后目标表为空时，首先需要确认源表是否确实包含数据，以及传输过程是否正确执行。

常用检测命令：

检查源表数据量：

-- 检查表中的行数 SELECT COUNT(*) FROM source_table; -- 检查表的基本信息 SHOW TABLE STATUS LIKE 'source_table';

检查目标表数据量：

-- 检查目标表中的行数 SELECT COUNT(*) FROM target_table; -- 如果目标表为空，检查表结构是否正确 DESCRIBE target_table;

检查传输文件内容（如果使用文件传输）：

# 对于SQL文件，检查是否包含INSERT语句 grep -c "INSERT" backup.sql # 检查文件大小，过小的文件可能不包含数据 ls -lh backup.sql

例子： 假设我们传输了一个名为orders的表，发现目标表为空，我们可以执行以下检测步骤：

-- 在源数据库上 USE source_db; SELECT COUNT(*) FROM orders; -- 返回结果：1250 -- 在目标数据库上 USE target_db; SELECT COUNT(*) FROM orders; -- 返回结果：0 -- 检查目标表结构 DESCRIBE orders; -- 确认表结构是否与源表一致

日志分析方法

MySQL和各种传输工具都会生成日志，通过分析这些日志可以找出数据传输失败的原因。

MySQL错误日志：

-- 查看错误日志位置 SHOW VARIABLES LIKE 'log_error'; -- 在Linux系统上，可以使用tail命令实时查看日志 tail -f /var/log/mysql/error.log

传输工具日志：

对于mysqldump，可以使用-v（verbose）选项获取更详细的输出：

mysqldump -u root -p -v test_db employees > employees_backup.sql 2> dump.log

然后检查dump.log文件中的错误或警告信息。

例子： 假设在传输过程中遇到了权限问题，日志中可能包含如下信息：

mysqldump: Got error: 1142: SELECT, LOCK TABLES command denied to user 'transfer_user'@'localhost' for table 'employees' when using LOCK TABLES

这明确指出了权限不足的问题。

监控工具使用

使用专业的监控工具可以更有效地检测和诊断数据传输问题。

MySQL Enterprise Monitor： 这是MySQL官方提供的监控工具，可以实时监控数据库状态和性能。

Percona Monitoring and Management (PMM)： 一个开源的数据库监控和管理平台，支持MySQL等多种数据库。

自定义监控脚本： 可以编写简单的脚本来监控数据传输过程：

#!/bin/bash # 监控数据传输的简单脚本 SOURCE_DB="source_db" TARGET_DB="target_db" TABLE_NAME="employees" USER="monitor_user" PASS="password" # 获取源表行数 SOURCE_COUNT=$(mysql -u $USER -p$PASS -e "SELECT COUNT(*) FROM $SOURCE_DB.$TABLE_NAME" -s -N) # 获取目标表行数 TARGET_COUNT=$(mysql -u $USER -p$PASS -e "SELECT COUNT(*) FROM $TARGET_DB.$TABLE_NAME" -s -N) echo "Source table count: $SOURCE_COUNT" echo "Target table count: $TARGET_COUNT" if [ "$SOURCE_COUNT" -eq "$TARGET_COUNT" ]; then echo "Data transfer successful!" else echo "Data transfer failed! Source: $SOURCE_COUNT, Target: $TARGET_COUNT" fi

例子： 使用上述脚本监控employees表的传输过程：

$ chmod +x monitor_transfer.sh $ ./monitor_transfer.sh Source table count: 1250 Target table count: 0 Data transfer failed! Source: 1250, Target: 0

这清楚地表明数据传输存在问题，需要进一步调查。

解决方案与最佳实践

权限相关的解决方案

确保执行数据传输操作的用户具有足够的权限是解决空表传输问题的第一步。

权限配置：

-- 为数据传输用户授予必要权限 GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON source_db.* TO 'transfer_user'@'%'; GRANT ALL PRIVILEGES ON target_db.* TO 'transfer_user'@'%'; FLUSH PRIVILEGES;

使用root用户： 对于关键的数据传输操作，可以考虑使用root用户执行，但需注意安全性：

mysqldump -u root -p source_db > backup.sql

例子： 假设我们之前因为权限不足导致数据传输失败，现在为用户transfer_user授予必要的权限：

-- 登录MySQL服务器 mysql -u root -p -- 授予权限 GRANT SELECT, LOCK TABLES ON source_db.* TO 'transfer_user'@'localhost'; FLUSH PRIVILEGES; -- 退出MySQL EXIT; -- 重新尝试数据传输 mysqldump -u transfer_user -p source_db employees > employees_backup.sql

表结构优化方案

确保表结构兼容性是成功传输数据的关键。

表结构检查与调整：

-- 检查表结构 SHOW CREATE TABLE source_table; -- 检查字符集和排序规则 SHOW TABLE STATUS LIKE 'source_table';

跨版本兼容性处理： 当在不同MySQL版本之间传输数据时，需要考虑兼容性问题：

-- 创建兼容旧版本的表结构 CREATE TABLE target_table ( id INT(11) NOT NULL AUTO_INCREMENT, name VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

例子： 将包含JSON字段的表从MySQL 8.0传输到5.7：

-- 源表（MySQL 8.0） CREATE TABLE product_details ( id INT PRIMARY KEY, details JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- 修改为兼容MySQL 5.7的结构 CREATE TABLE product_details ( id INT PRIMARY KEY, details TEXT, -- 将JSON类型改为TEXT created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

然后，在传输数据时，可能需要使用应用程序逻辑或存储过程来处理JSON数据的转换。

数据传输参数调整

适当调整数据传输工具的参数可以解决许多空表传输问题。

mysqldump常用参数：

# 完整备份，包括存储过程和事件 mysqldump -u root -p --routines --events --triggers --all-databases > full_backup.sql # 单事务备份，适合InnoDB表 mysqldump -u root -p --single-transaction --routines --triggers source_db > backup.sql # 仅备份数据，不包含表结构 mysqldump -u root -p --no-create-info source_db > data_only.sql # 仅备份表结构，不包含数据 mysqldump -u root -p --no-data source_db > structure_only.sql

mysqlimport参数：

# 导入CSV文件 mysqlimport -u root -p --local --fields-terminated-by=, target_db /path/to/data.csv

例子： 使用mysqldump进行数据传输时，确保包含所有必要的数据：

# 确保传输数据和表结构 mysqldump -u root -p --single-transaction --routines --triggers source_db > backup.sql # 检查生成的SQL文件是否包含INSERT语句 grep "INSERT INTO" backup.sql | head -5

传输工具选择与配置

根据具体场景选择合适的数据传输工具，并正确配置，可以有效避免空表问题。

常用数据传输工具比较：

mysqldump：MySQL官方提供的逻辑备份工具，适合中小型数据库。
mydumper：多线程备份工具，适合大型数据库。
MySQL Shell Util：MySQL 8.0+提供的实用工具，支持多种导入导出格式。
pt-archiver：Percona Toolkit中的工具，适合归档和迁移数据。
MySQL Replication：主从复制，适合持续的数据同步。

工具配置示例：

使用mydumper进行多线程备份：

# 安装mydumper # Ubuntu/Debian sudo apt-get install mydumper # CentOS/RHEL sudo yum install mydumper # 使用mydumper备份 mydumper -u root -p password -o /backup/ --threads 4 --database source_db

使用MySQL Shell Util进行数据导出导入：

// 使用MySQL Shell sql connect root@localhost:3306 js // 导出数据 util.exportTable("source_db.employees", "/path/to/employees.csv", {fieldsEscapedBy: "\", fieldsTerminatedBy: ",", linesTerminatedBy: "n"}); // 导入数据 util.importTable("/path/to/employees.csv", {schema: "target_db", table: "employees", columns: ["id", "name", "department"], fieldsTerminatedBy: ",", linesTerminatedBy: "n"});

例子： 假设我们需要传输一个大型数据库，使用mysqldump可能太慢，可以使用mydumper：

# 备份源数据库 mydumper -u root -p password -o /backup/source_db --threads 8 --database source_db --rows=100000 # 恢复到目标数据库 myloader -u root -p password -d /backup/source_db --threads 8 --database target_db

存储引擎考虑

处理不同存储引擎之间的数据传输需要特别注意。

存储引擎转换：

-- 将MyISAM表转换为InnoDB ALTER TABLE myisam_table ENGINE=InnoDB; -- 在创建表时指定存储引擎 CREATE TABLE new_table ( id INT PRIMARY KEY, name VARCHAR(100) ) ENGINE=InnoDB;

存储引擎特定功能处理：

-- 处理MyISAM的全文索引（转换为InnoDB时） -- MySQL 5.6+的InnoDB支持全文索引 ALTER TABLE articles ADD FULLTEXT INDEX (title, content); -- 处理外键约束（在传输数据时可能需要临时禁用） SET FOREIGN_KEY_CHECKS=0; -- 执行数据导入 SET FOREIGN_KEY_CHECKS=1;

例子： 将一个使用MyISAM存储引擎的表传输到使用InnoDB的环境中：

-- 源表（MyISAM） CREATE TABLE user_sessions ( session_id VARCHAR(32) PRIMARY KEY, user_id INT, data TEXT, last_access TIMESTAMP, INDEX (user_id) ) ENGINE=MyISAM; -- 目标表（InnoDB） CREATE TABLE user_sessions ( session_id VARCHAR(32) PRIMARY KEY, user_id INT, data TEXT, last_access TIMESTAMP, INDEX (user_id), FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ) ENGINE=InnoDB;

在传输数据时，可能需要临时禁用外键检查：

-- 在目标数据库上 SET FOREIGN_KEY_CHECKS=0; -- 导入数据 SOURCE /path/to/data.sql; SET FOREIGN_KEY_CHECKS=1;

实际案例分析

案例一：权限问题导致的空表传输

问题描述： 某公司的数据库管理员尝试使用mysqldump将一个重要的业务表从生产环境传输到测试环境，但传输完成后发现测试环境中的表是空的，只有表结构没有数据。

排查过程：

首先确认源表确实包含数据：

USE production_db; SELECT COUNT(*) FROM orders; -- 返回结果：15420

检查传输命令：

mysqldump -u transfer_user -p production_db orders > orders_backup.sql

检查生成的SQL文件：

grep -c "INSERT INTO" orders_backup.sql -- 返回结果：0

检查用户权限：

SHOW GRANTS FOR 'transfer_user'@'%';

发现用户只有SELECT权限，没有LOCK TABLES权限。

解决方案：

为用户授予必要的权限：

GRANT SELECT, LOCK TABLES ON production_db.* TO 'transfer_user'@'%'; FLUSH PRIVILEGES;

重新执行数据传输：

mysqldump -u transfer_user -p production_db orders > orders_backup.sql

验证生成的SQL文件：

grep -c "INSERT INTO" orders_backup.sql -- 返回结果：15420

在测试环境导入数据：

mysql -u root -p test_db < orders_backup.sql

验证数据：

USE test_db; SELECT COUNT(*) FROM orders; -- 返回结果：15420

经验总结：

确保执行数据传输的用户具有足够的权限，特别是LOCK TABLES权限
在执行传输前，先验证源表数据量和用户权限
传输后验证生成的SQL文件是否包含数据

案例二：WHERE条件错误导致的数据过滤

问题描述： 一位开发人员尝试使用mysqldump导出特定时间段内的订单数据，但导出的SQL文件执行后发现目标表为空。

排查过程：

检查源表数据：

USE sales_db; SELECT COUNT(*) FROM orders; -- 返回结果：32654 SELECT COUNT(*) FROM orders WHERE order_date BETWEEN '2023-01-01' AND '2023-01-31'; -- 返回结果：1250

检查使用的导出命令：

mysqldump -u root -p sales_db orders --where="order_date BETWEEN '2023-01-01' AND '2023-01-31'" > jan_orders.sql

检查生成的SQL文件：

grep -c "INSERT INTO" jan_orders.sql -- 返回结果：0

仔细检查WHERE条件，发现日期格式可能有问题：

# 检查orders表的order_date列格式 DESCRIBE orders;

发现order_date是DATETIME类型，而WHERE条件中只提供了日期部分。

解决方案：

修正WHERE条件，使其匹配DATETIME格式：

mysqldump -u root -p sales_db orders --where="order_date BETWEEN '2023-01-01 00:00:00' AND '2023-01-31 23:59:59'" > jan_orders.sql

或者使用DATE函数：

mysqldump -u root -p sales_db orders --where="DATE(order_date) BETWEEN '2023-01-01' AND '2023-01-31'" > jan_orders.sql

验证生成的SQL文件：

grep -c "INSERT INTO" jan_orders.sql -- 返回结果：1250

导入数据并验证：

mysql -u root -p test_db < jan_orders.sql mysql -u root -p -e "USE test_db; SELECT COUNT(*) FROM orders;" -- 返回结果：1250

经验总结：

使用WHERE条件进行数据过滤时，确保条件与列的数据类型匹配
对于DATETIME类型，要么提供完整的时间部分，要么使用适当的函数进行转换
在执行完整的数据传输前，可以先测试WHERE条件是否返回预期的结果

案例三：存储引擎不兼容问题

问题描述： 一家公司尝试将数据库从旧的服务器（MySQL 5.5）迁移到新的服务器（MySQL 8.0），迁移后发现某些表为空。

排查过程：

检查源表数据：

USE old_db; SHOW TABLE STATUS;

发现某些表使用的是MEMORY存储引擎。

检查这些表的数据：

SELECT COUNT(*) FROM session_table; -- 返回结果：450

检查使用的迁移命令：

mysqldump -u root -p old_db > old_db_backup.sql

检查生成的SQL文件：

grep -A 10 "CREATE TABLE `session_table`" old_db_backup.sql

发现表定义中包含ENGINE=MEMORY。

尝试在新服务器上导入数据：

mysql -u root -p new_db < old_db_backup.sql

检查导入后的表：

USE new_db; SELECT COUNT(*) FROM session_table; -- 返回结果：0

问题分析： MEMORY存储引擎的数据是存储在内存中的，而不是磁盘上。当使用mysqldump备份时，它只备份表结构，而不备份MEMORY表中的数据，因为这些数据在服务器重启后会丢失。

解决方案：

在源服务器上，将MEMORY表转换为InnoDB表：

USE old_db; ALTER TABLE session_table ENGINE=InnoDB;

验证数据是否仍然存在：

SELECT COUNT(*) FROM session_table; -- 返回结果：450

重新执行备份：

mysqldump -u root -p old_db > old_db_backup.sql

在新服务器上导入数据：

mysql -u root -p new_db < old_db_backup.sql

验证数据：

USE new_db; SELECT COUNT(*) FROM session_table; -- 返回结果：450

如果需要，可以将表转换回MEMORY引擎：

USE new_db; ALTER TABLE session_table ENGINE=MEMORY;

经验总结：

了解不同存储引擎的特性和限制
MEMORY表的数据不会通过mysqldump备份，因为它们是临时存储在内存中的
在迁移数据库前，检查所有表的存储引擎，特别是对于特殊用途的表
考虑使用物理备份工具（如Percona XtraBackup）作为逻辑备份的补充

预防措施与建议

数据传输前的准备工作

在进行数据传输前，做好充分的准备工作可以有效避免空表问题。

检查清单：

验证源数据： “`sql – 检查表中的数据量 SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema = ‘your_database’;

– 检查表结构 SHOW CREATE TABLE your_table;

 2. **确认用户权限：** ```sql SHOW GRANTS FOR 'your_user'@'%';

检查存储空间： “`bash
检查源服务器磁盘空间
df -h

# 检查目标服务器磁盘空间 ssh target_server “df -h”

 4. **评估数据量：** ```sql -- 估算表大小 SELECT table_name AS `Table`, round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` FROM information_schema.tables WHERE table_schema = 'your_database' ORDER BY (data_length + index_length) DESC;

准备回滚方案：

# 导出目标数据库的当前状态（如果存在） mysqldump -u root -p target_db > target_db_pre_migration.sql

数据传输过程中的监控

实时监控数据传输过程可以及时发现问题并采取措施。

监控脚本示例：

#!/bin/bash # 监控数据传输进度的脚本 SOURCE_DB="source_db" TARGET_DB="target_db" USER="monitor_user" PASS="password" LOG_FILE="transfer_progress.log" # 获取所有表名 TABLES=$(mysql -u $USER -p$PASS -e "SELECT table_name FROM information_schema.tables WHERE table_schema='$SOURCE_DB'" -s -N) # 记录开始时间 echo "Transfer started at $(date)" > $LOG_FILE # 监控每个表的传输进度 for TABLE in $TABLES; do SOURCE_COUNT=$(mysql -u $USER -p$PASS -e "SELECT COUNT(*) FROM $SOURCE_DB.$TABLE" -s -N) TARGET_COUNT=$(mysql -u $USER -p$PASS -e "SELECT COUNT(*) FROM $TARGET_DB.$TABLE" -s -N) echo "Table: $TABLE, Source: $SOURCE_COUNT, Target: $TARGET_COUNT" >> $LOG_FILE if [ "$SOURCE_COUNT" -ne "$TARGET_COUNT" ]; then echo "WARNING: Row count mismatch for table $TABLE" >> $LOG_FILE # 可以在这里添加发送警报的代码 fi done # 记录结束时间 echo "Transfer completed at $(date)" >> $LOG_FILE

使用MySQL Enterprise Monitor或PMM： 这些专业工具可以提供更全面的监控功能，包括性能指标、查询分析和警报系统。

数据传输后的验证

数据传输完成后，进行全面的验证是确保数据完整性的关键步骤。

验证脚本示例：

-- 创建存储过程来验证数据一致性 DELIMITER // CREATE PROCEDURE verify_data_transfer(IN source_db VARCHAR(64), IN target_db VARCHAR(64)) BEGIN DECLARE done INT DEFAULT FALSE; DECLARE table_name VARCHAR(64); DECLARE source_count INT; DECLARE target_count INT; DECLARE tables_cur CURSOR FOR SELECT table_name FROM information_schema.tables WHERE table_schema = source_db; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; CREATE TEMPORARY TABLE IF NOT EXISTS verification_results ( table_name VARCHAR(64), source_count INT, target_count INT, status VARCHAR(20) ); OPEN tables_cur; read_loop: LOOP FETCH tables_cur INTO table_name; IF done THEN LEAVE read_loop; END IF; SET @sql = CONCAT('SELECT COUNT(*) INTO @source_cnt FROM ', source_db, '.', table_name); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; SET @sql = CONCAT('SELECT COUNT(*) INTO @target_cnt FROM ', target_db, '.', table_name); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; SET source_count = @source_cnt; SET target_count = @target_cnt; IF source_count = target_count THEN INSERT INTO verification_results VALUES (table_name, source_count, target_count, 'OK'); ELSE INSERT INTO verification_results VALUES (table_name, source_count, target_count, 'MISMATCH'); END IF; END LOOP; CLOSE tables_cur; SELECT * FROM verification_results WHERE status = 'MISMATCH'; DROP TEMPORARY TABLE verification_results; END // DELIMITER ; -- 使用存储过程验证数据传输 CALL verify_data_transfer('source_db', 'target_db');

数据校验工具： 使用pt-table-checksum（Percona Toolkit的一部分）可以更高效地验证数据一致性：

# 在源服务器上安装Percona Toolkit # Ubuntu/Debian sudo apt-get install percona-toolkit # CentOS/RHEL sudo yum install percona-toolkit # 使用pt-table-checksum验证数据一致性 pt-table-checksum --replicate=test.checksums --databases=source_db

定期备份与恢复演练

建立定期备份机制，并定期进行恢复演练，是确保数据传输可靠性的重要措施。

备份策略示例：

#!/bin/bash # 全量备份脚本 BACKUP_DIR="/var/backups/mysql" DATE=$(date +%Y%m%d_%H%M%S) USER="backup_user" PASS="password" # 创建备份目录 mkdir -p $BACKUP_DIR/$DATE # 执行全量备份 mysqldump -u $USER -p$PASS --single-transaction --routines --triggers --events --all-databases | gzip > $BACKUP_DIR/$DATE/all_databases.sql.gz # 记录备份信息 echo "Backup completed at $(date)" > $BACKUP_DIR/$DATE/backup_info.txt echo "Backup size: $(ls -lh $BACKUP_DIR/$DATE/all_databases.sql.gz | awk '{print $5}')" >> $BACKUP_DIR/$DATE/backup_info.txt # 清理旧备份（保留最近7天） find $BACKUP_DIR -type d -mtime +7 -exec rm -rf {} ;

恢复演练脚本：

#!/bin/bash # 恢复演练脚本 BACKUP_DIR="/var/backups/mysql" TEST_DB="test_restore" USER="root" PASS="password" # 获取最新备份 LATEST_BACKUP=$(ls -t $BACKUP_DIR | head -1) # 创建测试数据库 mysql -u $USER -p$PASS -e "CREATE DATABASE IF NOT EXISTS $TEST_DB" # 恢复数据 gunzip < $BACKUP_DIR/$LATEST_BACKUP/all_databases.sql.gz | mysql -u $USER -p$PASS $TEST_DB # 验证恢复的数据 mysql -u $USER -p$PASS -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='$TEST_DB' ORDER BY table_rows DESC" # 清理测试数据库 mysql -u $USER -p$PASS -e "DROP DATABASE IF EXISTS $TEST_DB" echo "Restore test completed at $(date)"