一、单机版 MySQL
1. 架构说明
只有一台 MySQL 实例，一套 mysqld 进程，只有一份数据，没有备库副本。读写全部都在这一台服务器。
- 优点：部署简单、维护方便、成本低
- 缺点：无故障转移能力。机器、磁盘、MySQL 进程出问题，业务直接中断；磁盘损坏存在丢失数据风险。
- 适用：测试环境、非核心业务；不建议核心生产使用。
2. 单机版宕机现象
mysqld 进程消失，服务无法连接；
进程存在也可能出现卡死，查询无响应；
3. 宕机统一排查步骤
确认现象 → 保留现场，不要反复重启 → 查看关键日志 → 定位根因
3.1 确认是否真实宕机
ps -ef | grep mysqld
netstat -lnp | grep 3306
mysql -S /tmp/mysql.sock- 进程消失：实例真实 crash；
- 进程存在但连不上：大概率锁、慢 SQL 打满，实例卡死，不是进程崩溃。
3.2 收集两大核心日志（不要频繁重启 MySQL，重启会冲刷日志现场）
1）MySQL 错误日志 error.log，查看崩溃时间点报错：
关键词：
1)
No space left on device磁盘满、InnoDB文件损坏、参数错误。2）系统日志
dmesg -T查看是否被 Linux OOM‑killer 杀死进程：搜索
Out‑of‑memory。
3.3 检查磁盘空间
df -h看磁盘是否 100% 占满。
3.4 判断根因
- dmesg 有 OOM kill：内存配置过大，操作系统杀掉 MySQL；
- error.log 报
No space left on device：磁盘耗尽； - error.log 大量 InnoDB page 损坏：断电、硬件导致数据文件损坏；
- 进程存活但访问卡死：大 SQL、长事务压力导致。
4. 单机宕机处理方案
4.1 磁盘满导致宕机 ：清理 binlog、日志文件释放磁盘，再启动 MySQL；禁止直接 rm 物理删除 binlog，优先用purge binary logs。
4.2 OOM 被内核 kill ：调小innodb_buffer_pool_size，给操作系统预留内存，重新启动。
4.3 InnoDB 文件损坏
1）优先使用最近备份恢复数据；
2）innodb_force_recovery仅用于导出数据，不能用来对外提供业务读写。
4.4 参数配置错误：修正 my.cnf 配置，启动实例。
4.5 如果实例无法修复：只能依靠全量备份 + binlog 恢复业务，业务中断时间较长。
单机没有备库可以切换，所有修复都是在故障本机操作，修不好只能靠备份。
二、高可用版 MySQL（主从 / MGR）
1. 架构说明
至少 2 台机器，一主多从架构 。主库负责写入，通过 binlog 复制把数据同步到多个从库；搭配切换组件（Keepalived 虚 IP、MGR 自动选主）实现故障转移。
- 优点：单台机器故障，可以手动 / 自动切换到从库，业务尽量不中断；多机器保存数据副本；支持读写分离；
- 缺点：架构复杂，需要监控主从延迟、复制状态；异步复制场景切换存在少量数据丢失风险，存在脑裂风险；
- 适用：线上核心生产业务；
注意：仅仅搭建主从复制，没有切换组件不算完整高可用，主库宕机业务依旧不可用。
MGR说明：MGR 是MySQL 官方组复制，基于 Paxos 协议。生产多用 3 节点单主模式，主节点故障自动选举新主，依靠多数派投票保障数据一致性；多主模式所有节点都可写，但存在事务冲突风险，线上很少使用
2. 高可用主库宕机排查步骤
原则：优先恢复业务，不要先重启故障主库，保留故障机器现场用于排查问题
2.1 确认主库是否真实宕机
ps -ef | grep mysqld
netstat -lnp | grep 3306区分：
1）进程 crash（mysqld 进程已经消失）；
2）网络、虚 IP 漂移导致访问不到（MySQL 实例本身正常活着）；
3）实例卡死（mysqld 进程还在，但是内部卡死不响应请求）；
解释说明：
MGR /keepalived 环境常见：虚 IP 飘到别的机器；防火墙策略变更；客户端网络不通。数据库实例 mysqld 还在本机正常运行。
ps 看不到 mysqld、netstat 无 3306 → 进程 crash
ps 有 mysqld，netstat 有 3306，此时有两种可能性：网络虚 IP 漂移 OR MySQL 实例卡死
本地 socket 登录 MySQL，绕过 TCP 网络、绕过虚 IP（关键判断）
mysql -S /tmp/mysql.socksocket 走本地文件通信，不经过 3306 TCP 端口、不经过虚 IP、不走网卡网络。
- ✅如果 socket 可以正常登录，执行 SQL 可以正常返回 → MySQL 实例内部是健康正常。业务连不上是外部问题：虚 IP 漂移、防火墙、业务机器网络、代理故障
- ❌如果 socket 登录也卡住、超时、无法执行 SQL → 证明 MySQL 实例本身内部卡死，不是外部网络问题，而是实例卡死
2.2 在故障旧主库机器收集日志，保留现场
1）读取 MySQL error.log；
2）执行 dmesg -T，确认是否 OOM‑killer 杀死进程；
3）df -h检查磁盘使用率。
排查根因和单机排查日志手段完全一样：磁盘满、OOM kill、InnoDB 损坏、压力、硬件故障。
3. 高可用主库宕机处理方案
3.1 执行故障切换（最优先）
- Keepalived 主从：手动将健康从库提升为新主库，业务 IP 指向新主；
- MGR 架构：等待组件自动选主完成； 修改业务连接配置，业务恢复对外服务。
3.2 旧故障主库不要直接上线
保留日志用于故障分析；不能直接加入集群，需要重建主从同步，防止脑裂双写。
3.3 根据日志定位根因，对应修复故障节点：
- 磁盘满：清理日志；
- OOM：调整内存参数；
- InnoDB 文件损坏：该实例废弃，重新做实例重建，不要把损坏实例直接加入集群。
3.4 业务恢复后：校验主从同步状态、校验数据完整性；事后补充监控告警。
三、精简版
**单机 MySQL：**只有一个实例，无备库。
宕机排查：先确认 mysqld 进程状态，查看 error.log 错误日志、dmesg 系统日志、磁盘使用率。常见故障磁盘满、OOM kill、InnoDB 文件损坏。
处理：在本机尝试修复；无法修复只能依靠备份恢复，业务中断时间长。
**高可用 MySQL：**采用一主多从架构，具备故障切换能力。
主库宕机排查手段日志层面和单机一致。
处理：优先做故障切换，把业务切到健康从库，优先恢复业务；旧故障主库保留现场排查问题，不直接重启上线，后续重建同步。高可用也有少量丢数据、脑裂的风险，事后需要校验数据和完善监控。
四、对比
| 项目 | 单机 MySQL 宕机 | 高可用 MySQL 主库宕机 |
|---|---|---|
| 首要目标 | 修复本机实例，不行就备份恢复 | 优先故障切换，快速恢复业务 |
| 故障机器 | 必须尝试本机修复 | 故障机器保留现场，业务不再依赖它 |
| 日志排查手段 | error.log、dmesg、df ‑h，完全相同 | error.log、dmesg、df ‑h，手段一样 |
| 业务影响 | 业务长时间中断 | 切换成功业务影响很小 |
| 数据保障 | 仅靠备份 | 多副本，切换有极小概率丢数据 |