RESET MASTER在主库上极其危险，因它会立即删除所有binlog文件并重置编号为000001，清空索引和GTID执行历史；若存在运行中的从库，将导致复制中断报错“Could not find first log file”，仅适用于全新无从库环境。
不能直接执行 RESET MASTER 和 RESET SLAVE 就完事——90% 的数据不一致或复制失败，都源于没分清谁该重置、何时重置、重置后怎么对齐位点。
为什么 RESET MASTER 在主库上极其危险？
它会立刻删掉所有 binlog 文件（mysql-bin.000001 起始重编号），并清空 binlog 索引。从库如果还在用旧的 Relay_Master_Log_File 和 Exec_Master_Log_Pos 去连，必然报错 Could not find first log file name in binary log index file 或跳过事务。
- 仅在「全新初始化主库 + 无任何从库在运行」时才可考虑，生产环境几乎不用
- 即使要做，也必须先确认所有从库已
STOP SLAVE且SHOW SLAVE STATUS\G中Relay_Master_Log_File和Exec_Master_Log_Pos已追到最新位置 - 执行后，主库
SHOW MASTER STATUS返回的File是mysql-bin.000001，Position是154（MySQL 8.0+ 默认），但这个位置跟旧数据快照完全无关
RESET SLAVE ALL 是从库重置的唯一安全起点
MySQL 8.0 默认以「通道（channel）」管理复制状态，RESET SLAVE 只清默认通道，而 RESET SLAVE ALL 才真正删干净：mysql.slave_master_info 表、mysql.slave_relay_log_info 表、所有 relay log 文件、GTID 执行历史（当 gtid_mode=ON 且未显式设置 gtid_purged 时）。
- 执行前必须
STOP SLAVE，否则命令直接报错 - 执行后
SHOW SLAVE STATUS\G所有字段变NULL，不是“看起来像重置了”，而是元数据真没了 - 如果主库开了 GTID，从库重置后要靠
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1启动，否则会因Executed_Gtid_Set残留导致START SLAVE失败
重置后如何让从库精准接上新主库的 binlog？
关键不在命令本身，而在位点来源是否与数据快照严格一致。不要查当前 SHOW MASTER STATUS —— 那是重置后的空日志起始点，跟你导入的数据毫无关系。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果用
mysqldump --master-data=2导出主库数据，dump 文件开头一定有类似-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=123456789;的注释行，导入从库后，这条语句会被执行（除非你加了--skip-extended-insert等干扰选项） - 如果没用
--master-data=2，就必须在主库锁表期间（FLUSH TABLES WITH READ LOCK下）立刻执行SHOW MASTER STATUS，记下File和Position，然后UNLOCK TABLES—— 锁表时间越短越好，毫秒级差异都可能让位点失效 -
CHANGE MASTER TO时，这三个参数必须显式写出：MASTER_LOG_FILE、MASTER_LOG_POS、MASTER_AUTO_POSITION = 0（关 GTID）；漏掉任一，就可能连错文件或跳过事务
配置文件里写死 master-host= 会导致重置白做
很多线上事故发生在 RESET SLAVE ALL 后重启 MySQL，结果从库又自动连回旧主库——因为 my.cnf 里还留着 master-host=、master-user= 这类参数。MySQL 启动时会读这些配置，覆盖内存中已清空的复制元数据。
- 官方明确建议：复制参数一律通过
CHANGE MASTER TO动态设置，不要写进配置文件 - 如果已写入，重置前先注释掉或删掉相关行，再重启 mysqld，否则
RESET SLAVE ALL的效果只维持到下次重启 - 验证方式很简单：
SELECT * FROM mysql.slave_master_info;执行后应为空；如果还有记录，说明配置文件仍在生效
最易被忽略的一点：重置不是目的，位点对齐才是。无论用 dump 还是锁表，都要确保「数据快照」和「binlog 位置」出自同一逻辑时刻，中间不能有写入插入。时间窗口稍一失控，后续 START SLAVE 就是在复制一个根本不存在的状态。
