不能直接TRUNCATE或DROP从库表，因从库read_only=ON会拒绝DDL/DML；清空数据不重置binlog位点会导致同步异常；安全重置须按STOP SLAVE→RESET SLAVE ALL→临时关只读再删库重建顺序执行。
为什么不能直接 TRUNCATE 或 DROP DATABASE 从库表？
因为从库（replica）默认是只读的，read_only=ON 会拦住所有 DDL/DML（除了 super 用户），强行执行会报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。更关键的是，清空数据不等于重置复制位点——binlog position 还在老地方，后续 START SLAVE 会直接跳过历史事件或报错 Could not execute Write_rows_v1 event。
安全重置从库的三步操作顺序
必须按顺序做，漏一步就可能丢数据或同步中断：
- 先停复制：
STOP SLAVE; - 再清日志和位点：
RESET SLAVE ALL;（注意是ALL，否则master.info文件残留旧配置） - 最后删库重建（需临时关只读）：
SET GLOBAL read_only = OFF;→DROP DATABASE xxx;→CREATE DATABASE xxx;→SET GLOBAL read_only = ON;
别用 RESET SLAVE 不带 ALL，它不清理 master.info，下次 CHANGE MASTER TO 可能被旧配置干扰。
CHANGE MASTER TO 时必须指定的 4 个关键参数
重新指向主库时，光写 MASTER_HOST 和 MASTER_USER 不够，缺一不可：
-
MASTER_HOST：主库 IP 或域名 -
MASTER_PORT：主库端口（默认 3306，但显式写上防疏漏） -
MASTER_LOG_FILE和MASTER_LOG_POS：必须从主库SHOW MASTER STATUS实时取，不能抄旧值；如果主库已切 binlog，用mysqlbinlog找最新起始位置
漏掉 MASTER_LOG_POS 会导致从库从 binlog 开头重放，可能重复插入或主键冲突；设成 0 或 4 是常见错误，实际起始位置一般远大于此。
重同步后验证是否真“在线”完成
不是 START SLAVE 成功就完事了。要确认三件事：
- 看
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否持续下降并归零（不是一直为NULL） - 检查
Slave_IO_Running和Slave_SQL_Running都是Yes，且Retrieved_Gtid_Set/Executed_Gtid_Set在增长（如果是 GTID 模式） - 在从库查一张业务表的
COUNT(*)，和主库比对——别只信同步线程状态，数据没真正追平等于白忙
最容易被忽略的是 GTID 模式下没清空 gtid_purged，导致新从库拒绝执行部分事务。重置前最好在主库执行 SELECT @@gtid_purged; 记下来，重置后在从库 SET GLOBAL gtid_purged = 'xxx'; 补上。
