mysql.主从复制.读写分离.高可用.集群实战

架构图如下:

image

1.按照架构图所示,准备机器,做好时间同步,主机名解析

192.168.42.150 node1 [proxySQL keepalived]
192.168.42.151 node2 [proxySQL keepalived]
192.168.42.152 node3 [mysql-master wha]
192.168.42.153 node4 [mysql-slave1 wha]
192.168.42.154 node5 [mysql-slave2 wha]
192.168.42.155 node6 [mysql-slave3 wha]

2.我们先做主从复制

(1).在node3,node4,node5,node6上分别安装mariadb

(2).node3配置/etc/my.cnf.d/server.conf
node3[master]:

(3).启动node3节点的mariadb

(4).登录mysql,创建主从复制账号

(5).配置其他从节点
node3:

node4:

node5:

配置完之后,启动mariadb

(6).启动从节点的slave(各个节点)

写这个之前需要在master节点上查看:

然后启动从节点mysql

至此主从复制就完成了

(7).测试主从复制

在master上创建helloword数据库:

查看一下子:

然后在各个从节点上查看:

测试成功.

3.现在我们来做主从复制的读写分离

(1).在node1,node2上分别安装ProxySQL.
下载ProxySQL:

安装mariadb客户端

(2).配置ProxySQL:

配置示例:

(3).启动proxySQL

(4).连接mysql,查看一下子

(5).将另一个节点node2也配置下,并启动测试一下

4.将node1和node2的proxysql做成高可用(读写分离高可用)

(1).node1和node2分别安装keepalived

(2).node1的keepalived的配置:

(4).notify.sh脚本

(5).因为keepalived是引用漂移ip地址,所以,我们上面配置的proxysql.conf的IP绑定需要修改

记得是node1和node2都要修改哦!

(6).在node1启动keepalived测试

(7).在node2上也启动keepalived

此时ifconfig是看不到ens33:0的地址的

可以看到proxysql是启动起来的

(8).在node1上关闭keepalived

(9).在node2上ifconfig查看,192.168.42.182地址是否漂移过去

可以看到果然漂移过来了 至此我们的proxysql高可用已经完成了

5.接下来我们做mariadb 主节点的高可用 我们这里的办法是用MHA,将从节点提升为主节点

MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供 了 automating master failover 功能。MHA 在监控到 master 节点故障时,会提升其中拥有最新 数据的 slave 节点成为新的 master 节点,在此期间,MHA 会通过于其它从节点获取额外信 息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点。

MHA 服务有两种角色,MHA Manager(管理节点)和 MHA Node(数据节点): MHA Manager:通常单独部署在一台独立机器上管理多个 master/slave 集群,每个 master/slave 集群称作一个 application; MHA node:运行在每台 MySQL 服务器上(master/slave/manager),它通过监控具备解析 和清理 logs 功能的脚本来加快故障转移。

(1).在node3 [mariadb master]节点上创建秘钥

(2).在node1,node2,node3,node4,node5,node6上下载MHA

cd ~

下载:MHA

(3).我们使用node1,node2来当管理节点,并做高可用 node1:

node2同上

(4).我们在node3,node4,node5,node6上安装mha4mysql-node-0.56-0.el6.noarch.rpm即可

(5).Manger 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件, 而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf,其为可 选配置。如果仅监控一组 master/slave 集群,也可直接通过 application 的配置来提供各服务 器的默认配置信息。而每个 application 的配置文件路径为自定义,

例如,本示例中将使用 先创建目录

其内容如下所示:

(8).检查管理的 MySQL 复制集群的连接配置参数是否 OK:

输出信息如下所示,最后一行的“Health is OK”信息表示通过检测。

(9).启动 MHA:

启动成功后,可通过如下命令来查看 master 节点的状态。

上面的信息中“app1 (pid:4978) is running(0:PING_OK)”表示 MHA 服务运行 OK,否则,则 会显示为类似“app1 is stopped(1:NOT_RUNNING).”。

如果要停止 MHA,需要使用 masterha_stop 命令。

(10).测试故障转移

1.在 master 节点关闭 mariadb 服务

我们再一次去node1查看

2.在 manager 节点查看日志

cat /data/masterha/app1/manager.log 日 志 文 件 中 出 现 的 如 下 信 息 , 表 示 manager 检 测 到 192.168.42.152 节点故障,而后自动执行故障转移,将 192.168.42.153 提升为了主节点。

注意,故障转移完成后,manager 将会自动停止,此时使用 masterha_check_status 命令检测 将会遇到错误提示,如下所示。

  1. 提供新的从节点以修复复制集群

(1).在新的主节点,备份数据

(2).node3节点操作
清空所有的数据

将原来主节点的配置更改为从配置

启动mariadb

导入数据

查看复制点

登录mysql,连接进行主从复制

在现在的主节点删除一个库,查看一下子

node3节点查看:

我们可以看到库被删了,因此我们的故障转移到恢复已经成功

我们先在目前的mariadb主节点上flush privileges,然后去manage节点操作

步骤同上面的
(8).检查管理的 MySQL 复制集群的连接配置参数是否 OK:
(9).启动 MHA:
一样

原有 master 节点故障后,需要重新准备好一个新的 MySQL 节点。基于来自于 master 节点 的备份恢复数据后,将其配置为新的 master 的从节点即可。注意,新加入的节点如果为新 增节点,其 IP 地址要配置为原来 master 节点的 IP,否则,还需要修改 app1.cnf 中相应的 ip 地址。随后再次启动 manager,并再次检测其状态。

后续的mha高可用是集成在proxysql的高可用里面的,这个我们以后再续.

原创文章,作者:srayban,如若转载,请注明出处:/80462

发表评论

登录后才能评论

评论列表(1条)

  • PowerMichael
    PowerMichael 2017-07-16 21:49

    牛逼啊

联系我们

400-080-6560

在线咨询:点击这里给我发消息

邮件:1823388528@qq.com

工作时间:周一至周五,9:30-18:30,节假日同时也值班

友情链接:万达娱乐  万达娱乐主管  万达开户  guoqibee.com  万达娱乐注册  万达娱乐直属QQ  万达主管QQ  guoqibee.com  万达娱乐主管QQ  万达主管