MySQL 单机版 vs 高可用版：宕机排查 + 故障处理

一、单机版 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.sock

socket 走本地文件通信，不经过 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，手段一样
业务影响	业务长时间中断	切换成功业务影响很小
数据保障	仅靠备份	多副本，切换有极小概率丢数据