PS：MySQL的源码编译进行实验环境操作
1、MySQL安装及初始化
（1）生成启动脚本
（2） 修改环境变量
（3）生成配置文件
（4）数据库初始化建立mysql基本数据
（5）数据库安全初始化
（5）测试
2、组从复制
以下是配置mastesr（作者在 mysql-node1 上）
（1）编辑配置文件并重启数据库
（2）进入数据库配置用户权限
注意：做完这些配置不能将数据库退出，否则master的状态会变化。
以下是配置slave（作者在 mysql-node2 上）
（1）编辑配置文件并重启数据库
（2）进入数据库配置用户权限
（3）查看从服务是否配置成功
在主从服务器上的配置已经配置好了，现在进行测试：
（1）在 mysql-node1 上建立库表并添加数据
（2）在 mysql-node2 上进行查看数据是否能查看到
3、当有数据时添加slave2
注意：此时我们需要配置第二台 slave，第二台主机的环境要进行编译与初始化。（环境进行源码编译和此文第一个实验即可
| 主机名 | IP地址 |
|---|---|
| mysql-node3 | 172.25.254.30 |
（1）修改 mysql-node3 的配置文件并重启
（2）从 master 节点备份数据
（3）复制给 slave2
（4）利用 master 节点中备份出来的 moon.sql 在 slave2 中拉平数据
（5）配置 slave2 的 slave 功能
在 mysql-node1 上查看 master 状态：
进行 mysql-node3 的配置：
（6）测试
先在 mysql-node1 上写入：
再在是mysql-node3 上查看：
小知识点：
- 写入大于读取 => 主多从少
- 读取大于写入 => 主少从多
4、延迟复制
注意：此实验只用到 mysql-node1 和 mysql-node3
（1）查看 slave 状态
在这个命令下我们可以发现延迟效果参数为0：
（2）配置延迟效果
找到延迟效果参数，发现参数已经变化：
（3）测试
在 mysql-node1 上删除 user1 这条数据：
1分钟之内在 mysql-node3 上查看，此时发现 user1 这条数据还在：
一分钟之后在 mysql-node3 上查看，此时发现 user1 这条数据已经没有了：
5、慢查询日志
- 慢查询，顾名思义，执行很慢的查询；
- 当执行SQL超过long_query_time参数设定的时间阈值（默认10s）时，就被认为是慢查询，这个SQL语句就是需要优化的；
- 慢查询被记录在慢查询日志里；
- 慢查询日志默认是不开启的；
- 如果需要优化SQL语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。
注意：此实验在 matser 上进行，这样我们的 slave 上也会拥有
（1）查看慢查询状态
（2）开启慢查询日志
（3）测试
6、并行复制
注意：在 mysql-node2 上做此实验，因为我们刚刚在 mysql-node3 上做了延迟复制，所以在 mysql-node3 上做此实验无意义。
查看slave中的线程信息：
默认情况下slave中使用的是sql单线程回放，在master中时多用户读写，如果使用sql单线程回放那么会造成组从延迟严重。
开启MySQL的多线程回放可以解决上述问题
（1）修改配置文件并重启
（2）查看slave中的线程信息
7、gtid日志模式
（1）设置 gtid 并重启
在 mysql-node1 上：
在 mysql-node2 上：
在 mysql-node3 上：
（2）停止 slave 端
在 mysql-node2 和 mysql-node3 上：
（3）开启 slave 端的 gtid
（4）查看 mster 状态
发现 master 和 slave 的gtid是一致的！
8、半同步模式
在 master 端上（mysql-node1）：
（1）配置启用半同步模式
（2）安装同步插件
（3）查看插件情况
（4）打开半同步功能
（5）查看半同步功能状态
在 slave 端上（mysql-node2 和 mysql-node3）：
注意：mysql-node2 和 mysql-node3 在 mysql 上的步骤相同，配置文件有所不同点，作者将其在以下内容中标明解释。
（1）修改配置文件
- 注释只读模块后要重启
- 添加半同步模块不能重启，会报错
（2）进入 mysql 配置
（3）测试
在 master 端写入数据：
模拟故障：
停止从服务器上的复制 I/O 线程（mysql-node2 和 mysql-node3）
在master端插入数据
9、实现mysql组复制
注意：在做这个实验前一定要记得给三台主机（mysql-node1、mysql-node2和mysql-node1）做本地解析。
在 mysql-node1 上：
（1）关闭MySQL
（2）删除原先数据库数据
‘
（3）修改配置文件
（4）初始化数据库’
（5）配置sql
（6）复制给 mysql-node2 和 mysql-node3
在 mysql-node2 和 mysql-node3 上：（操作相同，除了配置文件有两个地方需要改，作者已在图中注明，以 mysql-node2 为演示）
（1）停止数据库并删除数据
（2）修改配置文件
（3）初始化数据库
（4）配置sql
测试：
在 mysql-node1 中：
在 mysql-node2 中：
在 mysql-node3 中：
10、路由
注意：实验开始前请将作者放在文章顶部的资源包拖入 mysql-node1 上
（1）安装 mysql-router
（2）配置 mysql-router
编辑配置文件并开启路由服务：
vim /etc/mysqlrouter/mysqlrouter.conf
停止数据库：
（3）测试
查看调度效果：
11、mysql高可用集群MHA
注意：实验开始前请将作者放在文章顶部的资源包拖入 MHA 上
11.1 搭建一主两从架构
（1）修改配置文件并停止服务：
（2）数据库初始化
PS：mysql-node1、mysql-node2 和 mysql-node3配置都相同
（3）配置gtid 日志模式和半同步模式
在 master 端上（mysql-node1）
在 slave 端上（mysql-node2 和 mysql-node3配置都相同）
11.2 安装MHA所需要的软件
（1）解压 MHA 压缩包
（2）安装 MHA 包
（3）免密登录
mysql-node1：
mysql-node2：
mysql-node3：
免密文件复制给一主两从：
（4）复制给一主两从
（5）在一主两从中安装
三台都需要安装，这里以 mysql-node1 为演示：
11.3 配置 MHA 的管理环境
（1）配置本地解析
（2）生成配置文件
（3）编辑配置文件
11.4 检测配置
（1）检测网络及ssh免密
masterha_check_ssh --conf=/etc/masterha/app1.cnf
（2）检测数据主从复制情况
在数据节点 master 端允许 root 远程登陆：
执行检测：
masterha_check_repl --conf=/etc/masterha/app1.cnf
12 MHA的故障切换
MHA的故障切换过程：
- 配置文件检查阶段，这个阶段会检查整个集群配置文件配置
- 宕机的master处理，这个阶段包括虚拟ip摘除操作，主机关机操作
- 复制dead master和最新slave相差的relay log，并保存到MHA Manger具体的目录下
- 识别含有最新更新的slave
- 应用从master保存的二进制日志事件（binlog events）
- 提升一个slave为新的master进行复制 7.使其他的slave连接新的master进行复制
12.1 master 未出现故障手动切换
配置前查看 slave 状态，此时 master 在mysql-node1 上：
在master数据节点还在正常工作情况下
这里指定新的 master 节点不能为 mysql-node3，因为我们之前在配置文件中设定了 mysql-node3 不能为 master。
查看 slave 状态，此时 master 在mysql-node2 上
12.2 master故障手动切换
（1）模拟master故障
（2）在MHA-master中做故障切换
--ignore_last_failover => 表示忽略在/etc/masterha/目录中在切换过程中生成的锁文件
（3）查看 slave 状态
发现此时 mster 为 mysql-node1，切换成功
（4）恢复故障mysql节点
在 mysql-node2 上：
12.3 自动切换
（1）查看 slave 状态，此时 master 在 mysql-node1上
（2）删除防火墙策略与添加环回
当有防火墙策略时，自动切换实验会失败，mysql-node1、mysql-node2、mysql-node3 和 MHA四台主机上都需删除：
因为我们在之前的配置文件的 冗余检测上写入了 172.25.254.11 这个IP，我们要将它写入 mysql-node2 这个备用 master 上，否则日志报错显示为在一直进行网络检测，找不到 172.25.254.11 这个IP。
查看环回是否添加成功：
（3）删掉切换锁文件
（4）监控程序通过指定配置文件监控master状态，当 master 出问题后自动切换并退出避免重复做故障切换
此时会生成一个健康状态检测的文件，打开另一个 MHA 主机会话进行查看：
（5）打开实时监控日志
（6）停止 master
此时发现监控日志下进行三遍 mysql-node1 为 master 的检测，当依旧检测不到 mysql-node1 后，开始自动切换 master 为 mysql-node2：
监控master状态切换故障节点后自动退出：
（7）恢复故障节点
开启 mysql ：
配置现 master 的 slave 策略：
13、为MHA添加VIP功能
注意：两个资源包在文章顶部
（1）复制
（2）修改脚本在脚本中只需要修改下vip即可
（3）删除锁文件和日志
（4）开启脚本调用
（5）查看主从状态，发现现在 mysql-node2 为主
（6）在 master 上添加 vip
（7）启动监控程序
（8）模拟故障自动切换模式，自动切换后查看vip变化
关闭 master 节点服务：
此时 master 变为 mysql-node1 ：
查看 vip 是否存在于 mysql-node1 上：
（9）恢复故障主机
（10）模拟故障手动切换模式，手动切换后查看vip变化
查看 vip 是否存在于 mysql-node2 上：
总结：当 VIP 开启后，无论手动或是自动，VIP都会跟随 master 的迁移而迁移！
