数据库
首页 > 数据库> > MySQL架构原理（八）读写分离和双主模式

MySQL架构原理（八）读写分离和双主模式

作者：互联网

文章目录

读写分离

读写分离引入时机

  大多数互联网业务中，往往读多写少，这时候数据库的读会首先成为数据库的瓶颈。如果我们已经优化了SQL，但是读依旧还是瓶颈时，这时就可以选择“读写分离”架构了。

  读写分离首先需要将数据库分为主从库，一个主库用于写数据，多个从库完成读数据的操作，主从库之间通过主从复制机制进行数据的同步，如图所示。

在这里插入图片描述
在应用中可以在从库追加多个索引来优化查询，主库这些索引可以不加，用于提升写效率。

读写分离架构也能够消除读写锁冲突从而提升数据库的读写性能。使用读写分离架构需要注意：主从同步延迟和读写分配机制问题

主从同步延迟

  使用读写分离架构时，数据库主从同步具有延迟性，数据一致性会有影响，对于一些实时性要求比较高的操作，可以采用以下解决方案。

读写分离落地

  读写路由分配机制是实现读写分离架构最关键的一个环节，就是控制何时去主库写，何时去从库读。目前较为常见的实现方案分为以下两种：

目前有很多性能不错的数据库中间件，常用的有MySQL Proxy、MyCat以及Shardingsphere等等。

读写分离配置

  使用MySQL Proxy进行读写分离的实验配置，基于上一篇虚拟机环境进行配置，之前是两台虚拟机，分别是一主一从，现在要增加一台虚拟机，作为代理服务器使用。

双主模式

适用场景

  很多企业刚开始都是使用MySQL主从模式，一主多从、读写分离等。但是单主如果发生单点故障，从库切换成主库还需要作改动。因此，如果是双主或者多主，就会增加MySQL入口，提升了主库的可用性。因此随着业务的发展，数据库架构可以由主从模式演变为双主模式。双主模式是指两台服务器互为主从，任何一台服务器数据变更，都会通过复制应用到另外一方的数据库中。
在这里插入图片描述
使用双主双写还是双主单写？

建议使用双主单写，因为双主双写存在以下问题：

高可用架构如下图所示，其中一个Master提供线上服务，另一个Master作为备胎供高可用切换，Master下游挂载Slave承担读请求。

这里的VIP指的是虚拟IP
在这里插入图片描述
随着业务发展，架构会从主从模式演变为双主模式，建议用双主单写，再引入高可用组件，例如Keepalived和MMM等工具，实现主库故障自动切换。

MMM架构

  MMM（Master-Master Replication Manager for MySQL）是一套用来管理和监控双主复制，支持双主故障切换 的第三方软件。MMM 使用Perl语言开发，虽然是双主架构，但是业务上同一时间只允许一个节点进行写入操作。下图是基于MMM实现的双主高可用架构。

在这里插入图片描述

MHA架构

  MHA（Master High Availability）是一套比较成熟的 MySQL 高可用方案，也是一款优秀的故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。MHA还支持在线快速将Master切换到其他主机，通常只需0.5－2秒。

  目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器。

在这里插入图片描述

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

  master的二进制日志、识别差异的中继日志事件并将其差异的事件应用于其他的slave、清除中继日志。MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

MHA故障处理机制：

MHA优点：

主备切换

主备切换是指将备库变为主库，主库变为备库，有可靠性优先和可用性优先两种策略。

通过上面介绍了解到，主备切换采用可用性优先策略，由于可能会导致数据不一致，所以大多数情况下，优先选择可靠性优先策略。在满足数据可靠性的前提下，MySQL的可用性依赖于同步延时的大小，同步延时越小，可用性就越高。

配置双主模式

基于上面读写分离的环境，将原来作为mysql_proxy的服务器用作，备份的主库服务器

relay-log=mysql-rela-bin
log_slave_updates=1
#1,3,5,7...
auto_increment_offset=1
auto_increment_increment=2
#

在这里插入图片描述

server-id=3
sync-binlog=1
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sys
relay-log=mysql-relay-bin
log_slave_updates=1
#2,4,6,8,....
auto_increment_offset=2  #设置自动增长的起始偏移
auto_increment_increment=2 # 设置自动增长的步长
#

在这里插入图片描述

MHA搭建

MHA需要基于之前的半同步复制模式，半同步复制的搭建请参考上一篇文章

服务器环境搭建

  我这里选择的是本地虚拟机环境，使用了三台虚拟机，已经是8G内存的上限，其中包括一台主库，两台从库，MHA和其中一台从库搭建在同一台服务器上面

三台机器ssh互通

在三台服务器上分别执行下面命令，生成公钥和私钥（注意：连续按换行回车采用默认值）

ssh-keygen -t rsa

在三台MySQL服务器分别执行下面命令，密码输入系统密码，将公钥拷到MHA Manager服务器上

ssh-copy-id 192.168.31.126

之后可以在MHA Manager服务器上检查下，看看.ssh/authorized_keys文件是否包含3个公钥

cat /root/.ssh/authorized_keys

执行下面命令，将MHA Manager的公钥添加到authorized_keys文件中（此时应该包含4个公钥），如果MHA服务器分开部署这里会有4个公钥，如果是跟我一样部署在同一台服务器，那么第三个和第四个公钥是同一个

cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

从MHA Manager服务器执行下面命令，向其他三台MySQL服务器分发公钥信息，下面的ip换成自己虚拟机的对应IP，下面展示的是MHA单独部署时要执行的命令，如果部署在同一台机器，发送到自己这台服务器的这句可以不用执行。

scp /root/.ssh/authorized_keys root@192.168.137.144:/root/.ssh/authorized_keys
scp /root/.ssh/authorized_keys root@192.168.137.145:/root/.ssh/authorized_keys
scp /root/.ssh/authorized_keys root@192.168.137.146:/root/.ssh/authorized_keys

可以MHA Manager执行下面命令，检测下与三台MySQL是否实现ssh互通。

ssh 192.168.137.144
exit
ssh 192.168.137.145
exit
ssh 192.168.137.146
exit

MHA下载安装

MHA下载

MySQL5.7对应的MHA版本是0.5.8，所以在GitHub上找到对应的rpm包进行下载，MHA manager和
node的安装包需要分别下载：

https://github.com/yoshinorim/mha4mysql-manager/releases/tag/v0.58
https://github.com/yoshinorim/mha4mysql-node/releases/tag/v0.58

下载后，将Manager和Node的安装包分别上传到对应的服务器。（可使用WinSCP等工具）

提示：也可以使用wget命令在linux系统直接下载获取，例如
wget https://github.com/yoshinorim/mha4mysqlmanager/releases/download/v0.58/mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

MHA node安装

在四台服务器上安装mha4mysql-node。
MHA的Node依赖于perl-DBD-MySQL，所以要先安装perl-DBD-MySQL。

yum install perl-DBD-MySQL -y

wget https://github.com/yoshinorim/mha4mysqlnode/releases/download/v0.58/mha4mysql-node-0.58-0.el7.centos.noarch.rpm

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

MHA manager安装

在MHA Manager服务器安装mha4mysql-node和mha4mysql-manager。

MHA的manager又依赖了perl-Config-Tiny、perl-Log-Dispatch、perl-Parallel-ForkManager，也分别进行安装。

wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm

yum install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager -y

wget https://github.com/yoshinorim/mha4mysqlnode/releases/download/v0.58/mha4mysql-node-0.58-0.el7.centos.noarch.rpm
rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

wget https://github.com/yoshinorim/mha4mysqlmanager/releases/download/v0.58/mha4mysql-manager-0.58-0.el7.centos.noarch.rpm
rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

提示：由于可能会提示perl-Log-Dispatch和perl-Parallel-ForkManager这两个被依赖包在yum仓库找不到，
因此安装epel-release-latest-7.noarch.rpm。在使用时，可能会出现下面异常：Cannot retrieve metalink for repository: epel/x86_64。可以尝试使用/etc/yum.repos.d/epel.repo，然后注释掉metalink，取消注释baseurl。

MHA 配置文件

MHA Manager服务器需要为每个监控的 Master/Slave 集群提供一个专用的配置文件，而所有的
Master/Slave 集群也可共享全局配置。
初始化配置目录

#目录说明
#/var/log (CentOS目录)
#           /mha (MHA监控根目录)
#                 /app1 (MHA监控实例根目录)
#                         /manager.log (MHA监控实例日志文件)
mkdir -p /var/log/mha/app1
touch /var/log/mha/app1/manager.log

配置监控全局配置文件
vim /etc/masterha_default.cnf

[server default]
#主库用户名，在master mysql的主库执行下列命令建一个新用户
#create user 'mha'@'%' identified by '123123';
#grant all on *.* to mha@'%' identified by '123123';
#flush privileges;
user=mha
password=123123
port=3306
#ssh登录账号
ssh_user=root
#从库复制账号和密码
repl_user=root
repl_password=123456
port=3306
#ping次数
ping_interval=1
#二次检查的主机
secondary_check_script=masterha_secondary_check -s 192.168.137.144 -s 192.168.137.145 -s 192.168.137.146

配置监控实例配置文件
先使用mkdir -p /etc/mha 命令创建目录，然后使用vim /etc/mha/app1.cnf 命令编辑文件

[server default]
#MHA监控实例根目录
manager_log=/var/log/mha/app1/manager.log
#MHA监控实例日志文件
manager_workdir=/var/log/mha/app1

#[serverx] 服务器编号
#hostname 主机名
#candidate_master 可以做主库
#master_binlog_dir binlog日志文件目录

[server1]
candidate_master=1
hostname=192.168.137.144
master_binlog_dir="/var/lib/mysql"

[server2]
candidate_master=1
hostname=192.168.137.145
master_binlog_dir="/var/lib/mysql"

[server3]
candidate_master=1
hostname=192.168.137.146
master_binlog_dir="/var/lib/mysql"

MHA 配置检测

执行ssh通信检测
在MHA Manager服务器上执行：

masterha_check_ssh --conf=/etc/mha/app1.cnf

检测MySQL主从复制
在MHA Manager服务器上执行：

masterha_check_repl --conf=/etc/mha/app1.cnf

出现“MySQL Replication Health is OK.”证明MySQL复制集群没有问题。

注意：如果出现下面这个报错的，需要修改/etc/my.cnf文件的配置，方法来自于这篇文章https://www.cnblogs.com/gered/p/12263895.html
其他方式测试了都不能解决，要么就是mysqlbinlog 报错 要么会导致mysql客户端连接报错

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

MHA Manager启动

在MHA Manager服务器上执行：

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &

查看监控状态命令如下：

masterha_check_status --conf=/etc/mha/app1.cnf

查看监控日志命令如下：

tail -f /var/log/mha/app1/manager.log

测试MHA故障转移

模拟主节点崩溃
在MHA Manager服务器执行打开日志命令：

tail -200f /var/log/mha/app1/manager.log

关闭Master MySQL服务器服务，模拟主节点崩溃

systemctl stop mysqld

查看MHA日志，可以看到哪台slave切换成了master

show master status;

在这里插入图片描述

标签：主库,log,读写,MySQL,MHA,master,proxy,mysql,主模式
来源： https://blog.csdn.net/Kiven_ch/article/details/118740075