MySQL的主从复制以及高可用架构MHA理解

一.主从复制

1.主从复制的定义

2.MySQL支持的复制类型

2.主从复制的原理

 3.主从复制常用的拓扑结构

4.主从复制的过程

5.主从复制实战练习

1.首先我们需要在主服务器上：

2.从库上设置（只写了一个，另一个配置方法一致）

 二.高可用架构MHA理解

1.简介

 2.服务角色以及作用

 3.提供的工具

4.工作原理

---

一.主从复制

1.主从复制的定义

主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。

2.MySQL支持的复制类型

基于语句（ statement ）的复制

在主服务器上执行 SQL 语句，在从服务器上执行同样的语句。 MySQL 默认采用基于语句的复制，效率比

较高。

基于行（ row ）的复制

把改变的内容复制过去，而不是把命令在从服务器上执行一遍。从 MySQL 5.0 开始支持。

混合型（ mixed ）的复制

默认采用基于语句的复制，一旦发现基于语句的无法精确复制时，就会采用基于行的复制。

2.主从复制的原理

1 、 MySQL 将数据变化记录到二进制日志中；

2 、 Slave 将 MySQL 的二进制日志拷贝到 Slave 的中继日志中；

3 、 Slave 将中继日志中的事件在做一次，将数据变化，反应到自身（ Slave ）的数据库

注：

主要基于 MySQL 二进制日志

主要包括三个线程（2个 I/O 线程， 1 个 SQL 线程）

 3.主从复制常用的拓扑结构

主从类型（ Master-Slave ）

主主类型（ Master-Master ）

级联类型（ Master-Slave-Slave ）

4.主从复制的过程

在主服务器（master）上

1.启用二进制日志

2.选择一个唯一的server-id

3.创建具有复制权限的用户

在从服务器（slave）上

1.启用中继日志

2.（二进制日志可开启，也可不开启）

3.选择一个唯一的 server-id

4.连接至主服务器，并开始复制

5.主从复制实战练习

环境准备：我使用的是一主两从

主机	IP
master	192.168.41.134
slave1	192.168.41.135
slave2	192.168.41.138

1.首先我们需要在主服务器上：

1 ）设置 server - id 值并开启 binlog 参数

[mysqld]
log_bin=mysql-bin  ----开启二进制日志
server_id=1        ----设置server_id（唯一）

重启数据库

2 ） 建立同步账号

mysql> grant replication slave on *.* to 'rep'@'192.168.41.%' identified by
'123456'; ------创建并赋予rep用户复制权限（MySQL8.0以后需要先创建再赋权）
mysql> show grants for 'rep'@'192.168.95.%';----查看rep的权限

3 ）锁表设置只读

为后面备份准备，注意生产环境要提前申请停机时间；

mysql> flush tables with read lock;

4 ）查看主库状态

查看主库状态，即当前日志文件名和二进制日志偏移量

mysql> show master status;

5 ）备份数据库数据

mysqldump -uroot -p -A -B |gzip > /backup/mysql_bak.$(date +%F).sql.gz

6 ）解锁

mysql> unlock tables;

7 ）主库备份数据上传到从库

scp /backup/mysql_bak.2023-07-24.sql.gz 192.168.41.135:/backup/
scp /backup/mysql_bak.2023-07-24.sql.gz 192.168.41.138:/backup/

2.从库上设置（只写了一个，另一个配置方法一致）

1 ）设置 server - id 值并关闭 binlog 参数

[mysqld]
#log_bin
server_id=2

重启数据库：

2 ）还原从主库备份数据

cd /backup/
gzip -d mysql_mysql_bak.2023-07-24.sql.gz
mysql -uroot -p'密码' < mysql_bak.2023-07-24.sql

检查还原：

# mysql -uroot -p -e 'show databases;'

3 ）设定从主库同步

mysql> change master to
MASTER_HOST='192.168.41.134',
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=154;

 4）启动从库同步开关

mysql> start slave;
检查状态：
mysql> show slave status\G

 当出现即表示连接配置成功

 5）测试主从同步：

主库创建一个数据库：
# mysql -uroot -p -e 'create database test_m_s;'
从库检查：
# mysql -uroot -p -e 'show databases;' |grep "test_m_s"

 二.高可用架构MHA理解

1.简介

　　 MHA （ Master HA ）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了

automating master failover 功能。 MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的

slave 节点成为新的 master 节点，在此期间， MHA 会通过于其它从节点获取额外信息来避免一致性方

面的问题。 MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。

　　 MHA 是由日本人 yoshinorim （原就职于 DeNA 现就职于 FaceBook ）开发的比较成熟的 MySQL 高

可用方案。 MHA 能够在 30 秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前

淘宝也正在开发相似产品 TMHA ， 目前已支持一主一从。

 2.服务角色以及作用

　　 MHA 服务有两种角色， MHA Manager( 管理节点 ) 和 MHA Node( 数据节点 ) ：

MHA Manager ：

　　通常单独部署在一台独立机器上管理多个 master/slave 集群 ( 组 ) ，每个 master/slave 集群称作一 个 application ，用来管理统筹整个集群。

MHA node ：

　　运行在每台 MySQL 服务器上 (master/slave/manager) ，它 通过监控具备解析和清理 logs 功能的脚 本来加快故障转移。

　　主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是

用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完

成操作，如果没有发给新主节点在本地应用后提升为主节点。

 3.提供的工具

　　 MHA 会提供诸多工具程序， 其常见的如下所示：

Manager 节点：

　　 masterha_check_ssh ： MHA 依赖的 ssh 环境监测工具；

　　 masterha_check_repl ： MYSQL 复制环境检测工具；

　　 masterga_manager ： MHA 服务主程序；

　　 masterha_check_status ： MHA 运行状态探测工具；

　　 masterha_master_monitor ： MYSQL master 节点可用性监测工具；

　　 masterha_master_swith:master ：节点切换工具；

　　 masterha_conf_host ：添加或删除配置的节点；

　　 masterha_stop ：关闭 MHA 服务的工具。

Node 节点：（这些工具通常由 MHA Manager 的脚本触发，无需人为操作）

　 save_binary_logs ：保存和复制 master 的二进制日志；

　　 apply_diff_relay_logs ：识别差异的中继日志事件并应用于其他 slave ；

　　 purge_relay_logs ：清除中继日志（不会阻塞 SQL 线程）；

　　 自定义扩展：

　　 secondary_check_script ：通过多条网络路由检测 master 的可用性；

　　 master_ip_failover_script ：更新 application 使用的 masterip ；

　　 report_script ：发送报告 ;

　　 init_conf_load_script ：加载初始配置参数；

　　 master_ip_online_change_script ; 更新 master 节点 ip 地址。

4.工作原理

MHA 工作原理总结为以下几条：

1 ） 从宕机崩溃的 master 保存二进制日志事件（ binlog events ）；

2 ） 识别含有最新更新的 slave ；

3 ） 应用差异的中继日志 (relay log) 到其他 slave ；

4 ） 应用从 master 保存的二进制日志事件 (binlog events) ；

5 ） 提升一个 slave 为新 master ；

6) 使用其他的 slave 连接新的 master 进行复制。