第 4 章 MySQL5.x 源码安装
4.1 源码安装概述
- 源码安装特点
- 优点：高度自定义，可以自定义编译参数、自定义功能、自定义安装路径；适合深度定制。
- 缺点：编译耗时长，依赖库多，排错难度大；升级、维护麻烦；生产优先选择 RPM/YUM 二进制包。
- 编译工具：
cmake（MySQL5.5 以后废弃 configure，全部使用 cmake 做编译配置）。 - 依赖包：需要安装开发库：
gcc gcc‑c++ cmake ncurses‑devel bison openssl‑devel。
4.2 编译安装完整流程
- 创建 mysql 系统用户，不允许登录系统
groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql- 创建安装目录、数据目录
mkdir -p /usr/local/mysql mkdir -p /data/mysql chown -R mysql:mysql /data/mysql- 解压源码包
tar -xf mysql‑5.x.x.tar.gz cd mysql‑5.x.x- cmake 编译配置（关键编译选项）
cmake . \ ‑DCMAKE_INSTALL_PREFIX=/usr/local/mysql \ ‑DMYSQL_DATADIR=/data/mysql \ ‑DSYSCONFDIR=/etc \ ‑DWITH_INNOBASE_STORAGE_ENGINE=1 \ ‑DWITH_MYISAM_STORAGE_ENGINE=1 \ ‑DDEFAULT_CHARSET=utf8mb4 \ ‑DDEFAULT_COLLATION=utf8mb4_general_ci \ ‑DWITH_SSL=system常见 cmake 参数说明
CMAKE_INSTALL_PREFIX：程序安装路径MYSQL_DATADIR：数据存放目录SYSCONFDIR：配置文件 my.cnf 存放目录- 存储引擎：
WITH_INNOBASE_STORAGE_ENGINE编译 InnoDB 引擎 - 字符集：设置默认字符集与排序规则
- 编译 && 安装
make -j4 #‑j 多线程编译，CPU核心数，编译时间较长 make install- 初始化数据库（MySQL5.7 使用 mysqld‑initialize）
cd /usr/local/mysql chown -R mysql:mysql . #5.6及以前 scripts/mysql_install_db --user=mysql --datadir=/data/mysql #5.7 bin/mysqld --initialize --user=mysql --datadir=/data/mysql⚠️5.7 初始化会生成临时 root 密码，屏幕输出记录临时密码。
- 配置 my.cnf 配置文件
/etc/my.cnf
[mysqld] basedir=/usr/local/mysql datadir=/data/mysql user=mysql port=3306 socket=/tmp/mysql.sock [mysqld_safe] log‑error=/data/mysql/mysql‑error.log pid‑file=/data/mysql/mysql.pid- 配置 systemd 服务或者拷贝 sysv 启动脚本
cp support‑files/mysql.server /etc/init.d/mysqld chmod +x /etc/init.d/mysqld chkconfig mysqld on- 启动服务
/etc/init.d/mysqld start- 修改 root 密码
/usr/local/mysql/bin/mysql_secure_installation4.3 源码安装常见故障
- cmake 报错：缺少依赖包，yum 安装对应 devel 开发库。
- make 编译报错：内存不足，虚拟机增加内存。
- 启动失败：目录权限不对，my.cnf 参数错误，端口被占用。
- 初始化失败：datadir 目录必须为空，不能有旧数据文件。
4.4 源码 vs RPM 二进制包对比
表格
| 方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 源码编译 | 高度自定义编译选项，自定义路径 | 编译慢，依赖多，维护复杂 | 定制化需求，学习研究 |
| RPM/YUM 二进制包 | 安装简单，稳定，官方测试好 | 自定义程度低 | 生产环境推荐 |
第 5 章 MySQL 备份与恢复
5.1 备份分类
按备份数据范围
- 全量备份：备份整个数据库所有数据。
- 增量备份：只备份上一次备份之后变化的数据。
- 差异备份：备份自上一次全量备份之后变化的数据。
按备份实现方式
- 逻辑备份：备份 SQL 语句；工具
mysqldump。- 优点：跨平台，跨版本，可编辑 SQL 文本；兼容性好。
- 缺点：速度慢；需要 MySQL 运行，读取数据库，锁表；大库耗时久。
- 物理备份（裸文件备份）：直接拷贝磁盘上的数据文件。
- 工具：
xtrabackup(Percona‑XtraBackup) - 优点：速度快，直接拷贝磁盘块，适合大数据库。
- 缺点：受版本、存储引擎限制，跨平台兼容性差。
- 工具：
按锁机制
- 热备份：数据库正常读写，不锁库，业务不停机（InnoDB 支持热备）。
- 温备份：读可以，写会阻塞，锁表。
- 冷备份：数据库完全关闭，拷贝文件，业务停止。
5.2 逻辑备份工具 mysqldump
mysqldump 是 MySQL 自带逻辑备份工具，输出 SQL 文本。
常用语法
#备份单个数据库 mysqldump -uroot -p dbname > dbname.sql #备份多个数据库 mysqldump -uroot -p --databases db1 db2 > multi.sql #备份全部所有数据库 mysqldump -uroot -p --all‑databases > all.sql #只备份某些表 mysqldump -uroot -p dbname t1 t2 > table.sql重要参数
‑‑single‑transaction：InnoDB 快照热备！不加锁，InnoDB 必备，通过 MVCC 实现一致性快照。‑‑lock‑tables：MyISAM 引擎，锁表备份。‑‑no‑data：只备份表结构，不备份数据。‑‑routines：备份存储过程、函数。‑‑triggers：备份触发器。
mysqldump 恢复
两种恢复方式
#方式1 shell重定向 mysql -uroot -p dbname < dbname.sql #方式2 mysql客户端source命令 mysql> use dbname; mysql> source /root/dbname.sql;注意：
--databases导出的文件自带create database；不加 --databases 导出，恢复需要手动先创建数据库。
5.3 物理备份 Percona‑XtraBackup（InnoDB 热备份）
Percona 开源工具，专门针对 InnoDB，不停机热备份，不需要锁表。
- 核心工具
xtrabackup：备份 InnoDB 数据文件，不备份 MyISAM。innobackupex：封装脚本，同时支持 InnoDB+MyISAM。
- 备份三步流程：备份 → prepare 预准备（应用 redo log，把数据文件达成一致） → 恢复拷贝回数据目录。
#全量备份 innobackupex --user=root --password=xxx /backup #prepare 预准备，redo log回滚，数据文件一致性 innobackupex --apply‑log /backup/时间目录 #恢复：停止mysql，清空datadir，拷贝文件，修改mysql权限 innobackupex --copy‑back /backup/时间目录 chown -R mysql:mysql /data/mysql增量备份：基于上一次全量备份，备份变化的数据页。
5.4 binlog 二进制日志备份（时间点恢复 point‑in‑time）
binlog 记录所有 DML/DDL 修改数据的 SQL；可以实现时间点恢复，误删除数据找回。 开启 binlog：my.cnf配置log‑bin=mysql‑bin。
#查看binlog事件 mysqlbinlog mysql‑bin.000001 #恢复binlog日志 mysqlbinlog mysql‑bin.000001 | mysql -uroot -p组合方案：
mysqldump全量备份 + binlog增量日志，可以恢复到任意时间点。
5.5 备份策略最佳实践
- 中小库：
mysqldump --single‑transaction做全量备份，开启 binlog。 - 大库：Percona‑XtraBackup 物理全量 + 增量，配合 binlog。
- 备份文件需要异地保存；定期做恢复演练（只备份不做恢复演练等于没有备份）。
第 6 章 MySQL 主从复制与读写分离
6.1 主从复制概念
主库 Master 负责写；从库 Slave 复制主库数据，保持数据同步。
- 用途：1）读写分离，读请求分摊到从库，减轻主库压力；2）数据备份；3）故障切换，主库宕机提升从库为主库。
- 原理：基于 binlog 二进制日志完成数据同步。
6.2 主从复制三大线程
- Master dump 线程：主库，有从库连接，dump 线程读取 binlog，发送给从库。
- Slave IO 线程：从库，连接主库，接收 binlog 日志，写入本地 relay‑log 中继日志。
- Slave SQL 线程：从库，读取 relay‑log 中继日志，执行 SQL，把数据应用到从库。
流程：Master 写操作记录 binlog → dump 线程发送 → Slave IO 线程接收写入 relay‑log → Slave SQL 线程重放 relay‑log，完成同步。
6.3 主库 Master 配置 my.cnf
[mysqld] server‑id=1 #集群内id必须唯一！ log‑bin=mysql‑bin #开启二进制binlog日志 binlog_format=ROW #行模式，推荐，记录行数据变化 #binlog_do_db 可选，只同步指定库；binlog_ignore_db忽略库重启主库；创建复制账号，从库用来连接主库。
CREATE USER repl@'%' IDENTIFIED BY 'Repl@123456'; GRANT REPLICATION SLAVE ON *.* TO repl@'%'; FLUSH PRIVILEGES; #锁表，记录show master status输出File和Position，记录binlog文件名和偏移量 FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;拿到 File、Position，解锁
UNLOCK TABLES;。
6.4 从库 Slave 配置 my.cnf
[mysqld] server‑id=2 #不能和主库重复 relay‑log=relay‑bin #开启中继日志重启从库；导入主库全量备份数据，保证主从初始数据一致。 从库执行 change master to 配置主库信息：
CHANGE MASTER TO MASTER_HOST='192.168.108.128', MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_LOG_FILE='mysql‑bin.000001', MASTER_LOG_POS=154; START SLAVE; --启动复制 #查看复制状态，重点看Slave_IO_Running:Yes Slave_SQL_Running:Yes SHOW SLAVE STATUS\G故障判断：两个线程必须全部 Yes；任意 No 代表复制异常。
6.5 binlog 三种格式
- STATEMENT 语句模式：记录执行的 SQL 语句；节省日志，部分函数主从会产生数据不一致。
- ROW 行模式（推荐）：记录每一行数据修改前后，不会主从数据不一致，日志体积大。
- MIXED 混合模式：MySQL 自动选择 statement 或者 row。
6.6 主从常见故障
- IO 线程 No：网络不通，账号密码错误，IP、端口，防火墙，server‑id 重复。
- SQL 线程 No：数据不一致，从库有手动修改数据，主键冲突。
- 临时跳过错误：
set global sql_slave_skip_counter=1;（应急，不建议长期使用）
- 主从延迟：大事务，从库硬件性能差，大 DDL 语句。
6.7 读写分离
- 原理：写操作全部路由到 Master 主库；查询读请求分发到多个 Slave 从库，分担主库压力。
- 实现方案
- 方案 1：应用层代码实现，程序内区分读写，简单；维护成本在开发。
- 方案 2：中间件代理层，代理工具：MyCat、ProxySQL、MaxScale。代理接收 SQL，自动路由读写到对应数据库节点。
注意：主从存在同步延迟；业务要处理延迟带来的数据读取不一致问题。
第 7 章 MHA 高可用（Master High Availability）
7.1 MHA 介绍
MHA（Master High Availability）开源 MySQL 主从故障切换高可用工具。
- 组成两部分：MHA Manager 管理节点 + MHA Node（部署在每一台 MySQL 数据库节点）。
- 作用：监控主库状态；主库故障自动故障转移，挑选最优从库提升为新主库，其余从库自动指向新主库，实现数据库故障自动切换。
MHA 本身不提供虚拟 IP，需要配合 vip 脚本，业务连接虚拟 IP，切换时 vip 漂移。 适用环境：基于传统 MySQL 主从复制架构；支持 5.5/5.6/5.7。
7.2 MHA 架构角色
- Manager 管理节点：独立机器，运行
mha_manager监控程序；不部署 MySQL。负责检测 master 故障，执行故障切换。 - Node 节点：所有 MySQL 主、从库都必须安装 MHA‑node 组件。做日志保存、binlog/relay‑log 处理，故障切换时数据补齐。
- MySQL 集群：1 主 N 从，全部开启主从复制。
- VIP 虚拟 IP：业务访问 VIP，故障发生时脚本完成 vip 漂移。
7.3 MHA 工作流程
- 正常状态：Manager 定期 ping 探测 Master 存活状态。
- Master 主库故障：Manager 检测到主库不可达，进入故障切换流程。
- 选主：算法挑选数据最完整的 Slave 作为候选新 Master。
- 补数据：各个从库应用剩余中继日志，把各个从库数据追到一致状态。
- 提升：把候选从库提升为新主库；执行 vip 漂移脚本绑定 vip 到新主库。
- 其余所有旧从库，自动 change master to 指向新主库，开启复制。
- 旧主库修复上线后，自动加入集群，作为新主库的从库。
MHA 不会修复已经宕机的旧主库，旧主库恢复后需要重新加入集群。
7.4 mha 配置文件/etc/mha.cnf
[server default] user=root password=Root@123 repl_user=repl repl_password=Repl@123 ping_interval=1 manager_workdir=/var/log/mha manager_log=/var/log/mha/mha.log ssh_user=root #vip漂移脚本 master_ip_failover_script=/usr/local/bin/master_ip_failover [server1] hostname=192.168.108.131 [server2] hostname=192.168.108.132 [server3] hostname=192.168.108.1337.5 MHA 常用命令
#检查ssh互信是否正常 masterha_check_ssh --conf=/etc/mha.cnf #检查mysql主从复制状态 masterha_check_repl --conf=/etc/mha.cnf #启动mha manager管理监控 nohup masterha_manager --conf=/etc/mha.cnf & #查看mha状态 masterha_check_status --conf=/etc/mha.cnf #手动故障切换（主库已经宕机，手动执行切换） masterha_master_switch --conf=/etc/mha.cnf --master_state=dead前提：MHA 所有节点之间配置 ssh 免密互信。
7.6 MHA 优缺点
✅优点
- 基于原生 MySQL 主从复制，不需要修改 MySQL 内核；
- 自动选主，自动补齐从库数据，其余从库自动重定向新主库；
- 开源免费。
❌缺点
- Manager 是单点故障；需要做 Manager 高可用。
- 不自带 VIP，需要自己编写漂移脚本。
- 主从复制本身有延迟，故障切换会存在少量数据丢失风险。
- 不支持 MGR；8.0 之后社区维护活跃度下降。
7.7 MHA 对比其他高可用方案
- MHA：传统主从复制，故障切换，适合 5.x。
- MySQL‑MGR：MySQL 组复制，内置高可用，强一致性。
- Orchestrator：开源主从管理切换工具。
