MySQL 高级运维核心：备份恢复、主从复制与 MHA 高可用复习总结

MySQL 5、6、7 章详细总结

文档对应章节：第 5 章 MySQL 备份与恢复第 6 章 MySQL 主从复制 & 读写分离（Amoeba 中间件）第 7 章 MHA MySQL 高可用

第 5 章 MySQL 的备份与恢复

5.1 备份的意义

生产环境数据是核心资产，任何数据丢失都会造成严重业务损失。

造成数据丢失常见原因

程序 BUG：业务代码逻辑错误，误更新、删除数据
人为操作失误：删库、误改表、错误执行 SQL
硬件故障：磁盘损坏、IO 故障
运算异常：数据库内部崩溃
灾难事故：火灾、水灾、服务器被盗

⚠️ 备份不等于高可用：高可用解决宕机快速切换；备份解决数据彻底损坏、误删，属于最后兜底手段。

5.2 备份的分类（物理备份、逻辑备份）

1）物理备份

直接复制 MySQL 底层磁盘上的数据文件、日志文件，备份数据库物理存储。分为冷、热、温备份。

表格

备份类型	执行条件	特点
冷备份（脱机备份）	数据库完全关闭，服务停止	优点：备份恢复简单，速度快；缺点：业务停机，业务不可用
热备份（联机备份）	数据库正常运行，业务不停机	依赖二进制日志 binlog；业务不受影响，生产常用；InnoDB 支持热备，MyISAM 不支持
温备份	数据库锁表，可读，不可写入	会阻塞写业务，生产很少使用

物理冷备份实操流程

停止 MySQL 服务：systemctl stop mysqld
进入数据目录，打包全部数据文件

cd /usr/local/mysql/data
mkdir /mysql_bak
tar czf /mysql_bak/mysql-backup-$(date +%F).tar.gz *
启动服务，业务恢复：systemctl start mysqld

恢复冷备份

停止 MySQL 服务
清空损坏的数据目录
解压备份压缩包到 data 目录
修改文件属主属组chown -R mysql:mysql /usr/local/mysql/data
启动 MySQL 服务完成恢复。

缺点：必须停机，适合测试环境，不适合 7×24 小时业务。

2）逻辑备份

备份数据库对象（库、表、数据），导出 SQL 语句，不是复制磁盘文件 。工具：mysqldump，MySQL 自带逻辑备份工具。

优点：跨平台，可只备份部分库 / 部分表；备份文件是可读 SQL 文本；缺点：大数据量备份恢复速度比物理备份慢。

mysqldump 常用备份语法

复制代码

#备份单个数据库 school
mysqldump -uroot -p school > /mysql_bak/school.sql

#备份多个数据库 --databases
mysqldump -uroot -p --databases school mysql > /mysql_bak/school‑mysql.sql

#备份全部数据库 --all‑databases
mysqldump -uroot -p --opt --all-databases > /mysql_bak/all.sql

#只备份某一张表
mysqldump -uroot -p school info > /mysql_bak/info.sql

逻辑备份恢复

两种恢复方式

shell 命令行恢复

mysql -uroot -p school < /mysql_bak/info.sql
mysql 客户端内 source 导入

use school;
source /mysql_bak/info.sql;

5.3 增量备份（二进制日志 binlog 实现）

完整备份（全量备份）：某一个时间点全部数据；增量备份：记录上一次备份之后新产生的变更操作 ，只备份变化部分。 MySQL 依靠binlog二进制日志实现增量备份。

binlog 二进制日志

开启配置my.cnf中添加 log-bin=mysql-bin，重启 MySQL 生效。 binlog 记录：DDL（建库建表）、DML（insert/update/delete）所有写操作，select 查询不会记录。

增量备份完整流程

做一次全量完整备份（mysqldump），作为基础数据；
执行mysqladmin flush‑logs，刷新 binlog，生成新 binlog 文件；

flush‑logs：关闭当前 binlog，新建下一个编号的 binlog；刷新之后，后续的写操作记录到新日志文件。

业务持续运行，后续所有增删改操作全部记录在新 binlog 中；binlog 就是增量备份；
故障恢复

：
- 第一步：导入全量备份，恢复到全量备份时间点；
- 第二步：使用mysqlbinlog工具重放 binlog，把全量备份之后所有变更重新执行一遍，恢复到故障前状态。

binlog 查看和重放命令

复制代码

#解析binlog日志
mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000003

#重放binlog，恢复数据
mysqlbinlog --no-defaults /usr/local/mysql/data/mysql-bin.000003 | mysql -uroot -p

5.4 备份工具补充

mysqldump：逻辑备份，自带，适合中小库；
mysqlhotcopy：仅支持 MyISAM、ARCHIVE 引擎；
Percona‑XtraBackup：第三方开源工具，InnoDB 热物理备份，企业生产常用。

备份策略最佳实践：定期全量备份 + 开启 binlog 增量备份。

第 6 章 MySQL 主从复制和读写分离

6.1 MySQL 主从复制

概念

主从复制：一台 MySQL 作为主库 (master) ，多台 MySQL 作为从库 (slave) ；主库发生写操作，数据自动同步复制到从库。 作用：

数据冗余，灾难备份；
读写分离基础，分担查询读压力；
做数据备份可以在从库执行，不影响主库业务。

⚠️原生主从复制：主库单点故障不会自动切换，主库宕机，需要人工干预切换。

主从复制三大核心组件

binlog 二进制日志（主库） 主库所有 DDL/DML 写操作记录到 binlog 日志文件，是复制数据源。
IO 线程（从库） 从库 IO 线程建立网络连接连向主库，请求读取主库 binlog；收到 binlog 事件，写入本地的relay‑log 中继日志。
SQL 线程（从库） 读取本机 relay‑log 中继日志，解析日志，重放执行 SQL 语句，实现从库数据和主库保持一致。

完整主从复制工作流程

客户端在主库执行写操作 insert/update/delete；
主库完成事务提交，将变更事件写入本地 binlog 二进制日志；
从库 IO 线程连接主库，请求读取 binlog 日志；主库 dump 线程把 binlog 日志事件推送给从库 IO 线程；
IO 线程收到日志，写入本机 relay‑log 中继日志；
从库 SQL 线程读取 relay‑log 中继日志，解析并执行里面 SQL 语句；
执行完成，从库数据和主库保持一致。

校验复制状态命令：show slave status\G 关键状态：Slave_IO_Running: Yes，Slave_SQL_Running: Yes，两个全部 Yes 复制正常；任意 No 代表复制故障。

主从复制搭建步骤

实验拓扑：

master 主库：192.168.108.101 server‑id=11
slave01 从库：192.168.108.102 server‑id=22
slave02 从库：192.168.108.103 server‑id=23

⚠️集群所有 MySQL server‑id 必须不一样！不能重复。

主库配置 /etc/my.cnf

server-id = 11
log-bin = master-bin
log-slave-updates = true

重启 MySQL 服务。 2. 在主库创建复制账号，专门给从库连接同步数据

复制代码

GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.108.%' IDENTIFIED BY '123456';
FLUSH PRIVILEGES;
show master status; --记录 File 和 Position，给从库配置使用

从库配置（两台从库都操作） 修改 my.cnf

server-id =22 #slave01；slave02改为23
relay-log = relay-log-bin
relay-log-index = slave-relay-bin.index

如果是克隆虚拟机生成从库：删除auto.cnf，每个 mysql 实例 UUID 必须唯一，否则复制异常

复制代码

systemctl stop mysqld
rm -f /usr/local/mysql/data/auto.cnf
systemctl start mysqld

从库执行 change master to 指定主库信息

change master to
master_host='192.168.108.101',
master_user='myslave',
master_password='123456',
master_log_file='master-bin.000001',
master_log_pos=604;

master_log_file、master_log_pos 的值来自主库 show master status 输出。

启动复制

start slave;
show slave status\G
验证：主库建库建表插入数据，观察从库是否同步出相同数据。

主从复制常见问题

server‑id 重复 → 复制无法启动；
auto.cnf 中 UUID 重复（克隆虚拟机）；
主从库数据初始状态不一致；
SQL 线程报错：SQL 执行出错，数据不一致。

6.2 读写分离

原理

写操作（INSERT、UPDATE、DELETE）全部发送给主库执行 ；读操作（SELECT 查询）发送给从库执行；依靠主从复制机制，主库变更自动同步给从库，保证从库数据和主库一致。

读写分离目的：分担数据库读压力，提高数据库并发查询性能。

注意：读写分离不做数据同步，底层依赖已经部署完成的 MySQL 主从复制。

两种实现方案：

代码层实现读写分离：业务程序代码中判断 SQL 语句类型，写请求连主库，读请求连从库；优点：不引入中间件；缺点：业务代码侵入，开发改造成本高。
中间代理层实现：独立中间件程序，业务连接中间件，中间件解析 SQL，自动转发读写；业务代码零修改。代表工具 MySQL‑Proxy、Amoeba、MyCat。

Amoeba 中间件（实验使用）

Amoeba 是 Java 开发的 MySQL 代理中间件，SQL 路由器。

业务客户端连接 Amoeba（端口 8066），不是直接连接 MySQL 数据库。
Amoeba 解析收到的 SQL 语句：
- DML 写语句：转发给写池（主库 master）；
- SELECT 查询语句：转发读池（slaves 从库集群，自动轮询负载均衡）。
底层依赖 MySQL 主从复制保证多节点数据一致。

重点：Amoeba 只负责 SQL 路由转发，不会做数据同步！必须提前搭好主从复制。

Amoeba 核心配置文件

复制代码

   amoeba.xml

：代理核心配置

客户端访问 amoeba 的账号密码；
writePool写池：指定主库；
readPool读池：指定从库集群。

dbServers.xml：定义后端各个 MySQL 数据库节点 IP、账号密码。

Amoeba 部署步骤

准备 Java JDK 环境；解压 amoeba 程序包，配置环境变量；
在所有 MySQL 数据库授权 amoeba 访问账号；

grant all on . to test@'192.168.108.%' identified by '123.com';
修改dbServers.xml配置后端 master、slave1、slave2 数据库信息；配置虚拟池 slaves 包含两个从库；
修改amoeba.xml配置客户端账号密码，设置 writePool="master" readPool="slaves"；
启动 amoeba 服务，监听 8066 端口；
客户端连接 amoeba，测试：写操作落到主库，select 查询轮询访问两台从库。

缺陷：Amoeba 项目已经停止维护；企业生产更多使用 MyCat。

第 7 章 MHA MySQL 高可用

7.1 MHA 简介

MHA（Master High Availability），MySQL 主从高可用开源工具，使用 Perl 语言开发。

原生 MySQL 主从痛点

普通主从复制架构中，如果主库硬件故障宕机，从库不会自动升级成为新主库；必须人工登录从库执行大量切换操作，业务中断时间长。

MHA 解决的问题

监控主库运行状态；主库故障自动完成故障转移；切换时间 0‑30 秒；
尽可能保存故障主库剩余 binlog，最大限度减少数据丢失；
自动选举数据最完整的从库升级为新主库；
自动让剩余其他从库向新主库建立复制；
配合 VIP 虚拟 IP，业务连接地址不变，业务无感知切换。

MHA 底层完全依赖 MySQL 原生主从复制，MHA 只是管理工具，本身不做数据同步。

MHA 两大组件

MHA Node（数据节点程序）

所有 MySQL 数据库节点（主、全部从库）都必须安装 Node 组件。功能：处理 binlog/relay‑log 日志读取、保存差异日志，故障时应用中继日志。

MHA Manager（管理节点程序）

只部署一台独立管理服务器，不要部署在数据库节点上。功能：持续监控整个 MySQL 集群状态；故障发生时执行整套故障转移逻辑。
集群最低硬件要求：至少 3 台数据库实例，1 主 2 从。

MHA 两种工作模式

自动故障转移 Failover Manager 检测主库宕机，自动完成全部切换操作，不需要人工干预。
手动在线切换 Switchover 业务维护场景，手动执行脚本，把运行正常主库降级为从库，某台从库提升为主库，业务不停机切换。

7.2 MHA 故障自动转移完整流程

MHA Manager 持续监控集群主库存活状态；
检测确认主库完全宕机；
尝试访问故障旧主库，尽可能读取剩下未同步的 binlog，保存下来，尽量减少数据丢失；
对比所有从库已接收的中继日志，选出数据最完整的从库，提升为新主库

；
- 参数candidate_master=1可以设置优先候选主库；
将保存的旧主库剩余 binlog 应用到新主库；
其余剩下的所有从库，重置复制，全部改为向新主库做主从复制；
执行master_ip_failover脚本，完成 VIP 虚拟 IP 漂移，VIP 从旧主库移除，绑定到新主库；
业务访问 VIP，不需要修改数据库连接配置，业务恢复。

VIP 虚拟 IP：浮动 IP 地址，业务程序只连接 VIP，故障时 VIP 飘到新主，应用不用改配置。

7.3 MHA 部署完整步骤

前置条件：已经搭建好一主两从 MySQL 主从复制集群。

环境准备
- 所有节点关闭防火墙、selinux；时间同步ntpdate ntp.aliyun.com；
- 所有节点配置 SSH 免密互通（Manager 可以 ssh 免密登录全部 MySQL 节点，MySQL 节点之间也免密）。
MySQL 数据库账号准备
- 复制账号：用于主从复制；
- MHA 管理账号：所有数据库授权同一个 MHA 监控管理账号，拥有 replication、super 权限；
- 所有从库设置read_only=1，普通用户不能写，只有 super 账号可以写入。
安装软件包
- 全部 MySQL 节点：安装 MHA‑Node；
- Manager 管理节点：安装 MHA‑Manager（自动依赖 node）。
编写 MHA 配置文件（示例 app1.cnf），配置各个 db 节点、账号密码、vip 切换脚本路径。
环境预检查（部署必做）

masterha_check_ssh --conf=/etc/mha/app1.cnf #检查ssh免密是否正常
masterha_check_repl --conf=/etc/mha/app1.cnf #校验主从复制状态

两项检查全部 OK，才可以启动 MHA 监控。 6. 启动 MHA Manager 监控服务

复制代码

nohup masterha_manager --conf=/etc/mha/app1.cnf &

模拟主库宕机，测试自动故障转移；观察 VIP 漂移，从库自动切换到新主库。

关键参数说明

candidate_master=1：标记该从库优先被选为新主库；搭配check_repl_delay=0，忽略复制延迟。
master_ip_failover：VIP 漂移脚本，故障切换核心脚本。
no_master=1：手动切换场景参数。

7.4 MHA 注意事项

MHA 无法 100% 保证零数据丢失，如果旧主完全硬件损坏，磁盘不可访问，无法读取剩余 binlog，会丢失少量数据；
Manager 节点是单点，生产环境要做 Manager 高可用；
MHA 不处理读写分离中间件（Amoeba/MyCat），主库切换后需要通知中间件更新主库地址；
MHA 只是故障切换工具，备份依旧必须做；高可用 ≠ 备份。

5‑6‑7 章整体层级关系梳理

备份恢复（第 5 章）：兜底保障，应对误删、数据损坏，独立于集群高可用；
主从复制（第 6 章）：数据同步底座，实现多实例数据冗余；是读写分离、MHA 高可用的底层基础；
读写分离 (Amoeba)（第 6 章）：性能扩展 ，在主从复制之上，分担数据库读压力；不能解决主库宕机问题；
MHA 高可用（第 7 章）：故障自动转移，基于主从复制，解决主库单点故障，主库坏了自动选新主库，业务快速恢复。

企业完整架构：备份 + MySQL 主从复制 + 读写分离中间件 + MHA 自动故障转移。