前言
其实在GitHub上面Maxscale很清楚的告诉了我们是如何搭建的。但是那种安装是多年前的安装情况了。一般不适合在 Centos7 上面照猫画虎的安装。
这篇文章演示的是相同的软件配置 Maxscale 的 HA, 但是由于软件和操作系统比较新. 还是在一定程度上和官网给的有差别的。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
安装配置 maxscale systemctl
在 192.168.137.11, 192.168.137.12 都安装 maxscale, 两台(多台)机器上都用同一个/u01/maxscale/data/.secrets文件，这样生成的加密密码才会一样。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
并且配置上 systemctl 的方式启动 maxscale(如果是yum或者rpm安装的就不用设了默认直接就可以使用 systemctl 管理 maxscale)。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
vim /usr/lib/systemd/system/maxscale.service [Unit] Description=MariaDB MaxScale Database Proxy After=network.target [Service] Type=forking Restart=on-abort # PIDFile=/var/run/maxscale/maxscale.pid ExecStartPre=/usr/bin/install -d /var/run/maxscale -o maxscale -g maxscale ExecStart=/usr/local/maxscale/bin/maxscale -f /etc/maxscale.cnf TimeoutStartSec=120 LimitNOFILE=65535 [Install] WantedBy=multi-user.target # 测试 systemctl start maxscale.service systemctl status maxscale.service systemctl stop maxscale.service systemctl status maxscale.service
安装 corosync pacemaker pcs crmsh
yum install corosync pacemaker pcs -y cd /etc/yum.repos.d/ wget http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/network:ha-clustering:Stable.repo yum install crmsh -y
pcsd 基本使用配置
启动 pcsd 集群资源管理服务文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
这边使用了ansible来实现同时在多台服务器上都启用 pcsd 服务, 有兴趣的可以了解一下如何使用, 个人比较喜欢使用这个来对多台机器同时管理。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
ansible maxscale -m service -a 'name=pcsd state=started enabled=yes'
命令介绍文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
ansible: ansible命令。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
maxscale: /etc/ansible/hosts 文件下的 maxscale 模块, 指定了需要同时执行命令的IP。文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
-m service: 指定执行命令的是操作系统的一个服务文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
-a "...": 指定我们要对什么服务进行操作文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
创建 hacluster 用户并设置密码文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
ansible maxscale -m shell -a 'echo "123456" | passwd --stdin hacluster'
这边使用hacluster用户的原因是在使用yum安装的时候就帮你创建好了这个用户文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
检查 pcs 集群的 maxscale 用户是否通文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
pcs cluster auth 192.168.137.11 192.168.137.12
创建 maxscalecluster 集群资源文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
pcs cluster setup --name maxscalecluster 192.168.137.11 192.168.137.11
查看corosync配置文件文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
cat /etc/corosync/corosync.conf
启动集群 maxscalecluster文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
pcs cluster start --all
查看启动节点状态文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
ansible maxscale -m shell -a "corosync-cfgtool -s"
查看集群信息文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
corosync-cmapctl | grep members
CRM 查看集群状态文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
crm status
上面是 corosync pacemaker pcs crmsh 的基本安装, 就没做过多的演示文章源自运维生存时间-https://www.ttlsa.com/mysql/maxscale-ha-configuration/
配置 maxscale HA
这边我们指定的 VIP 是: 192.168.137.111
normal11 -> 192.168.137.11 ip别名对应关系
normal12 -> 192.168.137.12 ip别名对应关系
- 任何东西都没配置的情况
[root@normal11 data]# crm crm(live)# status Last updated: Tue Nov 8 21:05:38 2016 Last change: Tue Nov 8 20:14:43 2016 by root via cibadmin on normal11 Stack: corosync Current DC: normal12 (version 1.1.13-10.el7_2.4-44eb2dd) - partition with quorum 2 nodes and 0 resources configured Online: [ normal11 normal12 ] Full list of resources:
- 配置VIP和监控的服务
# (配置VIP)每60秒监控一次，超时时长为30秒，时间不能小于建议时长，否则会报错
crm(live)configure# primitive maxscaleip ocf:IPaddr params ip=192.168.137.111 op monitor timeout=30s interval=60s
# 配置监控的服务(maxscale.service)
crm(live)configure# primitive maxscaleserver systemd:maxscale op monitor timeout=30s interval=60s
# 将 VIP(maxscaleip) 和 监听的服务(maxscaleserver) 归为同一个组
crm(live)configure# group maxscalegroup maxscaleip maxscaleserver
# 由于我们只用两个节点我们这边不配置仲裁, 否则服务会不稳定来回切换
crm(live)configure# property no-quorum-policy=ignore
# 验证配置, 提交修改的配置
crm(live)configure# verify
crm(live)configure# commit
crm(live)configure# show
node 1: normal11 \
attributes standby=off
node 2: normal12 \
attributes standby=off
primitive maxscaleip IPaddr \
params ip=192.168.137.111 \
op monitor timeout=30s interval=60s
primitive maxscaleserver systemd:maxscale \
op monitor timeout=30s interval=60s
group maxscalegroup maxscaleip maxscaleserver
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7_2.4-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=maxscalecluster \
stonith-enabled=false \
no-quorum-policy=ignore
crm(live)configure# cd
# 查看服务情况
crm(live)# status
Last updated: Tue Nov 8 21:18:22 2016 Last change: Tue Nov 8 21:17:44 2016 by root via cibadmin on normal11
Stack: corosync
Current DC: normal12 (version 1.1.13-10.el7_2.4-44eb2dd) - partition with quorum
2 nodes and 2 resources configured
Online: [ normal11 normal12 ]
Full list of resources:
Resource Group: maxscalegroup
maxscaleip (ocf::heartbeat:IPaddr): Started normal11 # VIP 服务已经启动
maxscaleserver (systemd:maxscale): Started normal11 # maxscale.server 已经启动
crm(live)# quit
- 查看启动的资源
# 查看添加的VIP
[root@normal11 data]# ip addr | grep 192.168.137
inet 192.168.137.11/24 brd 192.168.137.255 scope global enp0s3
inet 192.168.137.111/24 brd 192.168.137.255 scope global secondary enp0s3
# 查看启动的 maxscale
[root@normal11 data]# ps -ef | grep maxscale
root 14894 1 0 21:17 ? 00:00:00 /usr/local/maxscale/bin/maxscale -f /etc/maxscale.cnf
root 15142 2505 0 21:21 pts/0 00:00:00 grep --color=auto maxscale
[root@normal11 data]# netstat -natpl | grep max
tcp 0 0 0.0.0.0:4008 0.0.0.0:* LISTEN 14894/maxscale
tcp 0 0 0.0.0.0:6603 0.0.0.0:* LISTEN 14894/maxscale
tcp 0 0 0.0.0.0:5308 0.0.0.0:* LISTEN 14894/maxscale
tcp 0 0 0.0.0.0:4006 0.0.0.0:* LISTEN 14894/maxscale
tcp 0 0 192.168.137.11:45126 192.168.137.23:3306 ESTABLISHED 14894/maxscale
tcp 0 0 192.168.137.11:47418 192.168.137.22:3306 ESTABLISHED 14894/maxscale
tcp 0 0 192.168.137.11:46747 192.168.137.21:3306 ESTABLISHED 14894/maxscale
tcp 0 0 192.168.137.11:46758 192.168.137.21:3306 ESTABLISHED 14894/maxscale
- 服务转跳测试
这边主要是演示宕机的情况下，看看 maxscale 服务 和 VIP 是否是会漂移到 normal12(192.168.137.12) 上。
我这边不演示 使用 systemctl stop maxscale.service 服务的原因是，这样关闭服务它不会马上发生VIP漂移而是会先在 本机(normal11:192.168.137.11)上尝试启动 maxscale服务, 经过多次尝试不行才发生 VIP 和 服务的转移。这边我要夸一下这样的资源管理其实是很符合常理的很好的。这比我们的MHA符合常理的多，其实在压力比较大的数据库中，也是不应该如果一宕机就马上转移的，应该先在原先的服务器上再次启动一下服务，起步来在转跳的。因为如果压力大导致的奔溃，启动服务应该需要先把热数据加载到数据库中的。
# normal11 关闭机器
[root@normal11 data]# shutdown -h now
PolicyKit daemon disconnected from the bus.
We are no longer a registered authentication agent.
# 查看 normal12 192.168.137.12 的资源情况
[root@normal12 ~]# ip addr | grep 192.168.137
inet 192.168.137.12/24 brd 192.168.137.255 scope global enp0s3
inet 192.168.137.111/24 brd 192.168.137.255 scope global secondary enp0s3:0
[root@normal12 ~]# ps -ef | grep maxscale
root 14914 1 0 21:32 ? 00:00:00 /usr/local/maxscale/bin/maxscale -f /etc/maxscale.cnf
root 14959 2467 0 21:33 pts/0 00:00:00 grep --color=auto maxscale
[root@normal12 ~]# netstat -natpl | grep max
tcp 0 0 0.0.0.0:4008 0.0.0.0:* LISTEN 14914/maxscale
tcp 0 0 0.0.0.0:6603 0.0.0.0:* LISTEN 14914/maxscale
tcp 0 0 0.0.0.0:5308 0.0.0.0:* LISTEN 14914/maxscale
tcp 0 0 0.0.0.0:4006 0.0.0.0:* LISTEN 14914/maxscale
tcp 0 0 192.168.137.12:45904 192.168.137.21:3306 ESTABLISHED 14914/maxscale
tcp 0 0 192.168.137.12:39643 192.168.137.22:3306 ESTABLISHED 14914/maxscale
tcp 0 0 192.168.137.12:44636 192.168.137.23:3306 ESTABLISHED 14914/maxscale
这样就完成了高可用了，其实用传统的 heartbeat + 脚本也是可以很好的完成的，我这边选择的是官网推荐的。
昵称: HH
QQ: 275258836
ttlsa群交流沟通(QQ群②: 6690706 QQ群③: 168085569 QQ群④: 415230207（新） 微信公众号: ttlsacom)
逛逛衣服店，鼓励作者写出更好文章。
1F
不错！