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

一、单机版 MySQL1. 架构说明只有一台 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重启会冲刷日志现场1MySQL 错误日志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内存配置过大操作系统杀掉 MySQLerror.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优先使用最近备份恢复数据2innodb_force_recovery仅用于导出数据不能用来对外提供业务读写。4.4 参数配置错误修正 my.cnf 配置启动实例。4.5 如果实例无法修复只能依靠全量备份 binlog 恢复业务业务中断时间较长。单机没有备库可以切换所有修复都是在故障本机操作修不好只能靠备份。二、高可用版 MySQL主从 / MGR1. 架构说明至少 2 台机器一主多从架构。主库负责写入通过 binlog 复制把数据同步到多个从库搭配切换组件Keepalived 虚 IP、MGR 自动选主实现故障转移。优点单台机器故障可以手动 / 自动切换到从库业务尽量不中断多机器保存数据副本支持读写分离缺点架构复杂需要监控主从延迟、复制状态异步复制场景切换存在少量数据丢失风险存在脑裂风险适用线上核心生产业务注意仅仅搭建主从复制没有切换组件不算完整高可用主库宕机业务依旧不可用。MGR说明MGR 是MySQL 官方组复制基于 Paxos 协议。生产多用 3 节点单主模式主节点故障自动选举新主依靠多数派投票保障数据一致性多主模式所有节点都可写但存在事务冲突风险线上很少使用2. 高可用主库宕机排查步骤原则优先恢复业务不要先重启故障主库保留故障机器现场用于排查问题2.1 确认主库是否真实宕机ps -ef | grep mysqld netstat -lnp | grep 3306区分1进程 crashmysqld 进程已经消失2网络、虚 IP 漂移导致访问不到MySQL 实例本身正常活着3实例卡死mysqld 进程还在但是内部卡死不响应请求解释说明MGR /keepalived 环境常见虚 IP 飘到别的机器防火墙策略变更客户端网络不通。数据库实例 mysqld 还在本机正常运行。ps 看不到 mysqld、netstat 无 3306 →进程 crashps 有 mysqldnetstat 有 3306此时有两种可能性网络虚 IP 漂移ORMySQL 实例卡死本地 socket 登录 MySQL绕过 TCP 网络、绕过虚 IP关键判断mysql -S /tmp/mysql.socksocket 走本地文件通信不经过 3306 TCP 端口、不经过虚 IP、不走网卡网络。✅如果socket 可以正常登录执行 SQL 可以正常返回→ MySQL 实例内部是健康正常。业务连不上是外部问题虚 IP 漂移、防火墙、业务机器网络、代理故障❌如果socket 登录也卡住、超时、无法执行 SQL→ 证明 MySQL 实例本身内部卡死不是外部网络问题而是实例卡死2.2 在故障旧主库机器收集日志保留现场1读取 MySQLerror.log2执行dmesg -T确认是否 OOM‑killer 杀死进程3df -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手段一样业务影响业务长时间中断切换成功业务影响很小数据保障仅靠备份多副本切换有极小概率丢数据