只读备机并非绝对安全，需验证read_only和super_read_only均为1，并比对主从gtid确认是否已同步攻击事务；定位干净binlog位点须通过mysqlbinlog反查可疑sql；导出时严禁--all-databases，应显式指定业务库并设--set-gtid-purged=off；恢复前须扫描触发器/存储过程、在隔离环境校验、用最小权限账号操作，且关闭慢日志等潜在污染源。
只读备机是否真“无污染”？先验证 binlog 位置和 GTID 状态
勒索病毒通常通过写操作加密数据，但只读备机（read_only=ON）不等于绝对安全——如果主库被攻陷后恶意 SQL 已经通过复制流到达备机，且备机未启用 super_read_only=ON 或未及时暂停复制，那数据可能已在 relay log 中执行完毕。必须立刻确认两点：
- 检查备机是否真正处于只读状态：
SELECT @@read_only, @@super_read_only;，二者都必须为1 - 比对主从 GTID 集合：
SELECT @@gtid_executed;在主、备上分别执行，若备机的 GTID 集合包含主库被攻陷后产生的事务（比如时间戳明显晚于攻击发生时刻），说明污染已同步 - 查看复制状态：
SHOW SLAVE STATUS\G，重点看Seconds_Behind_Master和Exec_Master_Log_Pos，若延迟为 0 且位置持续推进，风险极高
如何定位“最后一个干净”的 binlog 位点？
不能靠时间估算，得靠日志内容反查。攻击往往伴随异常写入模式（如批量 UPDATE/DELETE、大量 INSERT INTO ... SELECT、或非业务表如 mysql.user 被修改）。操作步骤如下：
- 在备机上用
mysqlbinlog解析最近的 binlog 文件，例如：mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A5 -B5 "UPDATE\|DELETE\|DROP\|ALTER" - 重点筛查含
ENCRYPT、RENAME\|TO\|_backup、SET\|@.*='.*\.enc'等可疑关键词的 event - 找到第一个疑似攻击事务的
GTID（如8a5d7e1f-1234-11ee-a9c1-0242ac120003:123456），然后用SELECT * FROM performance_schema.replication_applier_status_by_coordinator;查它之前最后一个已执行的 GTID - 若未启用 GTID，退而求其次：用
SHOW BINLOG EVENTS IN 'mysql-bin.000012' FROM 12345 LIMIT 100;手动定位最后一条正常业务事务的End_log_pos
从备机导出时为何不能直接 mysqldump --all-databases？
mysqldump --all-databases 会导出所有系统库（mysql、performance_schema、information_schema），其中 mysql 库若已被篡改（如用户权限被植入后门账号、user 表被加密字段覆盖），恢复后将直接带入污染。更危险的是，某些勒索变种会伪造 mysql.db 或 mysql.tables_priv 记录来维持持久化访问。
- 必须显式指定业务库名导出：
mysqldump -h备机IP -u用户 --single-transaction --routines --triggers --set-gtid-purged=OFF db1 db2 > clean_backup.sql - 跳过
mysql库是底线，连--ignore-table=mysql.general_log这类参数都不够保险 -
--set-gtid-purged=OFF是关键：避免 dump 文件里硬编码 GTID，否则恢复到新环境时可能触发 GTID 冲突或跳过本该执行的事务
恢复前必须做三件事：校验、隔离、最小权限
拿到 dump 文件不等于安全。勒索病毒常伴随后门行为，比如在触发器、存储过程中埋入恶意逻辑，或利用 sys 库视图注入代码。这些不会被 mysqldump 的默认参数捕获。
- 用
grep -n "CREATE TRIGGER\|CREATE PROCEDURE\|CREATE FUNCTION" clean_backup.sql扫描所有定义语句，人工核对是否属于已知业务逻辑 - 在隔离环境（如 Docker 容器）中先导入并启动 MySQL 实例，用
SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.EVENTS;和SELECT TRIGGER_SCHEMA FROM information_schema.TRIGGERS;检查是否有未知对象 - 恢复时禁止使用 root 或高权限账号；应新建专用用户，仅授予目标库的
SELECT, INSERT, UPDATE, DELETE, CREATE, DROP（不含GRANT OPTION）
最易被忽略的一点：备机上的 slow_query_log_file 或 general_log 若未关闭，其文件本身可能被加密或注入恶意 payload——导出前务必确认这些日志功能处于 OFF 状态，并删除对应物理文件。
