CLup读写分离场景的使用
1. 使用介绍
架构图如下:
读写分离的工作原理如下:
- 有一个主库和有多个备库库,Standby库与主库通过streaming replication进行同步。streaming replication的同步模式可以设置为同步或异步。
- 在所有的主机上部署一个叫CSTLB的负载均衡模块。
- 有一个写VIP,这个写VIP在主库所在的机器上。
- 应用如果需要执行写数据的操作,需要连接写VIP,通过写VIP访问主库。当然对于读延迟敏感的应用也需要通过写VIP访问主库。
- 应用的一些可以接受少量延迟的读请求可以通过访问读VIP来对只读的备库的访问。由于备库有多个,所以读请求实际上是发送到有读VIP的备库上的负载均衡器CSTLB上。然后再由CSTLB负载均衡到多台只读备库上。
- 当主库坏的时候,CLup会自动把其中一台Standby库提升为主库,同时会把这台备库从负载均衡器中移除掉
- 当一台Standby库出现问题时,如果读VIP也在这台机器上时,CLup会把读VIP切换到另一台机器上。同时会把这台备库从负载均衡器中移除掉。
- 当一台备库恢复正常后,其会自动加入到负载均衡器CSTLB中。
2. 安装CSTLB模块
需要在每台数据库主机中安装。
下载安装包:cstlb2.0.0.x86_64.tar.xz
https://gitee.com/csudata_admin/clup-community/releases/download/4.2.2/cstlb2.0.0.x86_64.tar.xz
解压此压缩包,包中只有一个执行文件cstlb,建一个目录/opt/cstlb,把此可执行文件拷贝到/opt/cstlb目录下。
手工启用cstlb负载均衡方法为:
cd /opt/cstlb
export CSTLB_TOKEN=1e82ff78-d73f-11e7-8a50-60f81dd129c2
nohup ./cstlb 2>&1 >cstlb.log &
注意:这里的
cstlb_token
是一个token,可以任意的一个UUID,但这里设置了此UUID,需要把此UUID配置到CLup中,CLup才能通过此token访问此负载均衡器。
每次手工启动,不是很方便,所以我们通常把cstlb配置成开机自启动,建服务文件/etc/systemd/system/cstlb.service:
[Unit]
Description=cstlb
After=network.target
[Service]
Type=simple
User=root
Environment="CSTLB_TOKEN=1e82ff78-d73f-11e7-8a50-60f81dd129c2"
ExecStart=/opt/cstlb/cstlb
[Install]
WantedBy=multi-user.target
设置为开机启动:
systemctl enable cstlb
启动cstlb:
systemctl start cstlb
3. CLup的配置
在CLup中创建流复制集群时,或修改已经创建好的流复制集群中的下面三项配置:
三项说明如下:
- 只读VIP: 使用一个未使用的IP做为只读VIP
- 只读VIP所在主机:集群第一次上线时,会把只读VIP加载到这台机器上。
- 均衡器列表:需要配置多个,多个由逗号分隔。IP地址冒号加端口的格式。如10.197.167.27:8082,10.197.167.28:8082。8082的端口是CSTLB默认的管理端口。
我们知道访问cstlb需要一个token,这个token配置在CLup中的系统管理
-> clup参数设置
中,如下图:
需要把之前cstlb中使用的token配置到上面的界面中。
然后我们就可以让集群上线了。如果没有配置正确,在CLup的日志中,可以看到如下信息:
[root@clup0 logs]# tail -f clupserver.log
...
...
...
2022-10-28 17:25:26,425 INFO begin online cluster(26): 上线成功
2022-10-28 17:25:28,202 INFO Cluster(26): read vip(10.197.167.253) needs to be added on host(10.197.167.27)
2022-10-28 17:25:30,378 ERROR Cluster(26): 无法连接负载均衡器: 10.197.167.27:8082:
HTTP Error 400: Bad Request
2022-10-28 17:25:30,382 ERROR Cluster(26): 无法连接负载均衡器: 10.197.167.28:8082:
HTTP Error 400: Bad Request
2022-10-28 17:25:50,760 ERROR Cluster(26): 无法连接负载均衡器: 10.197.167.27:8082:
HTTP Error 400: Bad Request
2022-10-28 17:25:50,763 ERROR Cluster(26): 无法连接负载均衡器: 10.197.167.28:8082:
HTTP Error 400: Bad Request
上面的错误通常是token没有配置对或者cstlb没有启动。使用命令systemctl status cstlb
检查cstlb是否在机器10.197.167.27和10.197.167.28上启动正确。
集群上线后会自动把备库加入到负载均衡器中。
我们可以使用流量器查看当前负载均衡器中的配置,方法是在浏览器中输入负载均衡器的IP和8082端口:
http://10.197.167.27:8082/backend/list?token=1e82ff78-d73f-11e7-8a50-60f81dd129c2
注意:上面的token就是我们负载均衡器使用的token
如下图所示:
集群上线后,到机器10.197.167.27上用命令ip a
检查 读VIP 是否已经在机器10.197.167.27上存在了:
[root@clup2 opt]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:b8:73:84 brd ff:ff:ff:ff:ff:ff
inet 10.197.167.27/20 brd 10.197.175.255 scope global dynamic ens3
valid_lft 1516599211sec preferred_lft 1516599211sec
inet 10.197.167.253/32 scope global ens3
valid_lft forever preferred_lft forever
inet6 fe80::215c:310f:2a26:9f01/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::a259:294f:8c64:6254/64 scope link tentative dadfailed
valid_lft forever preferred_lft forever
...
...
如果 读VIP 没有上来,检查CLup的日志,查看问题原因。
4. 测试负载均衡
我们用psql连接VIP和负载均衡器的默认端口(5435),看看是否能正常工作了:
[postgres@clup1 ~]$ psql -h 10.197.167.253 -p 5435 -Upostgres
Password for user postgres:
psql (11.16)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
10.197.167.27
(1 row)
从上面可以看出,可以连接到,此次连接负载均衡器把其负载均衡到 10.197.167.27机器上。我们这个psql不要关闭,再新建一个psql的连接:
[postgres@clup1 ~]$ psql -h 10.197.167.253 -p 5435 -Upostgres
Password for user postgres:
psql (11.16)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
10.197.167.28
(1 row)
可以看到这个连接被负载均衡到10.197.167.28机器上了。
从上面可以看出负载均衡器已经正常工作了。