十一、MySQL 第 4-7 章

第 4 章 MySQL5.x 源码安装

4.1 源码安装概述

1. 源码安装特点

• 优点：高度自定义，可以自定义编译参数、自定义功能、自定义安装路径；适合深度定制。
• 缺点：编译耗时长，依赖库多，排错难度大；升级、维护麻烦；生产优先选择 RPM/YUM 二进制包。

1. 编译工具：cmake（MySQL5.5 以后废弃 configure，全部使用 cmake 做编译配置）。
2. 依赖包：需要安装开发库：gcc gcc‑c++ cmake ncurses‑devel bison openssl‑devel。

4.2 编译安装完整流程

1. 创建 mysql 系统用户，不允许登录系统

   groupadd mysql
   useradd -r -g mysql -s /sbin/nologin mysql

2. 创建安装目录、数据目录

   mkdir -p /usr/local/mysql
   mkdir -p /data/mysql
   chown -R mysql:mysql /data/mysql

3. 解压源码包

   tar -xf mysql‑5.x.x.tar.gz
   cd mysql‑5.x.x

4. 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 引擎
• 字符集：设置默认字符集与排序规则

1. 编译 && 安装

   make -j4 #‑j 多线程编译，CPU核心数，编译时间较长
   make install

2. 初始化数据库（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 密码，屏幕输出记录临时密码。

1. 配置 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

2. 配置 systemd 服务或者拷贝 sysv 启动脚本

   cp support‑files/mysql.server /etc/init.d/mysqld
   chmod +x /etc/init.d/mysqld
   chkconfig mysqld on

3. 启动服务

   /etc/init.d/mysqld start

4. 修改 root 密码

   /usr/local/mysql/bin/mysql_secure_installation

4.3 源码安装常见故障

1. cmake 报错：缺少依赖包，yum 安装对应 devel 开发库。
2. make 编译报错：内存不足，虚拟机增加内存。
3. 启动失败：目录权限不对，my.cnf 参数错误，端口被占用。
4. 初始化失败：datadir 目录必须为空，不能有旧数据文件。

4.4 源码 vs RPM 二进制包对比

表格

方式	优点	缺点	适用场景
源码编译	高度自定义编译选项，自定义路径	编译慢，依赖多，维护复杂	定制化需求，学习研究
RPM/YUM 二进制包	安装简单，稳定，官方测试好	自定义程度低	生产环境推荐

---

第 5 章 MySQL 备份与恢复

5.1 备份分类

按备份数据范围

1. 全量备份：备份整个数据库所有数据。
2. 增量备份：只备份上一次备份之后变化的数据。
3. 差异备份：备份自上一次全量备份之后变化的数据。

按备份实现方式

1. 逻辑备份 ：备份 SQL 语句；工具mysqldump。
   • 优点：跨平台，跨版本，可编辑 SQL 文本；兼容性好。
   • 缺点：速度慢；需要 MySQL 运行，读取数据库，锁表；大库耗时久。
2. 物理备份（裸文件备份） ：直接拷贝磁盘上的数据文件。
   • 工具：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，不停机热备份，不需要锁表。

1. 核心工具

• xtrabackup：备份 InnoDB 数据文件，不备份 MyISAM。
• innobackupex：封装脚本，同时支持 InnoDB+MyISAM。

1. 备份三步流程：备份 → 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 备份策略最佳实践

1. 中小库：mysqldump --single‑transaction做全量备份，开启 binlog。
2. 大库：Percona‑XtraBackup 物理全量 + 增量，配合 binlog。
3. 备份文件需要异地保存；定期做恢复演练（只备份不做恢复演练等于没有备份）。

---

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

6.1 主从复制概念

主库 Master 负责写；从库 Slave 复制主库数据，保持数据同步。

• 用途：1）读写分离，读请求分摊到从库，减轻主库压力；2）数据备份；3）故障切换，主库宕机提升从库为主库。
• 原理：基于 binlog 二进制日志完成数据同步。

6.2 主从复制三大线程

1. Master dump 线程：主库，有从库连接，dump 线程读取 binlog，发送给从库。
2. Slave IO 线程：从库，连接主库，接收 binlog 日志，写入本地 relay‑log 中继日志。
3. 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 三种格式

1. STATEMENT 语句模式：记录执行的 SQL 语句；节省日志，部分函数主从会产生数据不一致。
2. ROW 行模式（推荐）：记录每一行数据修改前后，不会主从数据不一致，日志体积大。
3. MIXED 混合模式：MySQL 自动选择 statement 或者 row。

6.6 主从常见故障

1. IO 线程 No：网络不通，账号密码错误，IP、端口，防火墙，server‑id 重复。
2. SQL 线程 No：数据不一致，从库有手动修改数据，主键冲突。

• 临时跳过错误：set global sql_slave_skip_counter=1;（应急，不建议长期使用）

1. 主从延迟：大事务，从库硬件性能差，大 DDL 语句。

6.7 读写分离

1. 原理：写操作全部路由到 Master 主库；查询读请求分发到多个 Slave 从库，分担主库压力。
2. 实现方案
   • 方案 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 架构角色

1. Manager 管理节点：独立机器，运行mha_manager监控程序；不部署 MySQL。负责检测 master 故障，执行故障切换。
2. Node 节点：所有 MySQL 主、从库都必须安装 MHA‑node 组件。做日志保存、binlog/relay‑log 处理，故障切换时数据补齐。
3. MySQL 集群：1 主 N 从，全部开启主从复制。
4. VIP 虚拟 IP：业务访问 VIP，故障发生时脚本完成 vip 漂移。

7.3 MHA 工作流程

1. 正常状态：Manager 定期 ping 探测 Master 存活状态。
2. Master 主库故障：Manager 检测到主库不可达，进入故障切换流程。
   1. 选主：算法挑选数据最完整的 Slave 作为候选新 Master。
   2. 补数据：各个从库应用剩余中继日志，把各个从库数据追到一致状态。
   3. 提升：把候选从库提升为新主库；执行 vip 漂移脚本绑定 vip 到新主库。
   4. 其余所有旧从库，自动 change master to 指向新主库，开启复制。
3. 旧主库修复上线后，自动加入集群，作为新主库的从库。

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.133

7.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 优缺点

✅优点

1. 基于原生 MySQL 主从复制，不需要修改 MySQL 内核；
2. 自动选主，自动补齐从库数据，其余从库自动重定向新主库；
3. 开源免费。

❌缺点

1. Manager 是单点故障；需要做 Manager 高可用。
2. 不自带 VIP，需要自己编写漂移脚本。
3. 主从复制本身有延迟，故障切换会存在少量数据丢失风险。
4. 不支持 MGR；8.0 之后社区维护活跃度下降。

7.7 MHA 对比其他高可用方案

1. MHA：传统主从复制，故障切换，适合 5.x。
2. MySQL‑MGR：MySQL 组复制，内置高可用，强一致性。
3. Orchestrator：开源主从管理切换工具。

---