在进行数据恢复前,务必优先停止MySQL服务,防止新的写入操作覆盖原有数据(尤其是InnoDB引擎的表,数据可能仍在内存或redo log中)。执行以下命令停止服务:
sudo systemctl stop mysqld
同时,备份当前数据目录(默认路径为/var/lib/mysql
),避免恢复过程中出现意外:
sudo cp -R /var/lib/mysql /var/lib/mysql_backup
若你定期使用mysqldump
工具创建了逻辑备份(.sql
文件),这是最可靠的恢复方式。
mysql -u 用户名 -p 数据库名 < 备份文件.sql
例如,恢复mydatabase
数据库:
mysql -u root -p mydatabase < /path/to/mydatabase_backup.sql
输入密码后,备份中的表结构和数据将导入到指定数据库。
若只需恢复单个表,可将备份文件中的对应表结构及数据导入:
mysql -u root -p 数据库名 < /path/to/backup_file.sql
或直接指定表名(需备份文件包含该表数据):
mysql -u root -p 数据库名 表名 < /path/to/table_backup.sql
若启用了二进制日志(log_bin=ON
),可通过binlog记录的SQL操作,精准恢复误删或误修改的数据。
SHOW VARIABLES LIKE 'log_bin';
若返回ON
,则表示已开启。
SHOW BINARY LOGS;
记录下包含误操作时间点的binlog文件名(如mysql-bin.000002
)。
使用mysqlbinlog
工具解析binlog,提取误操作前后的SQL语句:
mysqlbinlog --no-defaults --start-datetime="2025-08-18 00:00:00" --stop-datetime="2025-08-18 23:59:59" /var/lib/mysql/mysql-bin.000002 > binlog.sql
参数说明:
--start-datetime
/--stop-datetime
:指定时间范围,缩小恢复范围;/var/lib/mysql/mysql-bin.000002
:binlog文件路径;> binlog.sql
:将解析结果输出到binlog.sql
文件。打开binlog.sql
,找到误删操作的逆操作(如DELETE
对应INSERT
),执行即可。例如:
INSERT INTO users (id, name, age) VALUES (2, 'Bob', 25);
若需恢复到误操作前的状态,可直接回放binlog到误操作前的时间点:
mysqlbinlog --stop-datetime="2025-08-18 15:30:00" /var/lib/mysql/mysql-bin.000002 | mysql -u root -p
这会将binlog中截至15:30:00
的所有操作重新执行,覆盖误删后的数据。
若数据丢失是由于表损坏(而非误删),可使用MySQL自带的工具修复:
sudo myisamchk -r /var/lib/mysql/数据库名/表名.MYI
-r
参数表示修复表,若修复失败,可尝试-o
(更彻底的修复)。
sudo mysqlcheck -u root -p --all-databases --auto-repair
或针对特定数据库/表:
sudo mysqlcheck -u root -p 数据库名 表名 --auto-repair
--auto-repair
参数会自动修复损坏的表。
若你有完整的物理备份(如整个/var/lib/mysql
目录的快照或磁盘分区备份),可通过以下步骤恢复:
sudo rsync -avz /path/to/physical_backup/mysql/ /var/lib/mysql/
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl start mysqld
mysqldump
或mydumper
工具定期创建逻辑备份,或配置物理备份(如rsync
+cron
);my.cnf
中设置log_bin=ON
,保留足够的binlog文件(通过expire_logs_days
参数设置过期时间);DELETE
、DROP
等高危操作权限。以上方法覆盖了Linux环境下MySQL数据恢复的常见场景,可根据实际情况选择合适的方式。若数据极其重要且无法自行恢复,建议联系专业数据恢复服务商。