搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 超微技术社团 > 基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

超微技术社团 2018-06-30

目的是尝试altas的读写分离,现有一套搭建好做测试的MGR(单主),于是就腿搓绳,在MGR基础上搭建altas。

 

复制环境准备

读写分离理论上讲,跟复制模式没有关系,atlas负责的是重定向读写,至于复制模式自己选择,这里是测试环境,之前测试MGR的单机多实例,MGR单主模式的复制模式,就顺便借助MGR做基于atlas的读写分离。

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

 

atlas安装

rpm安装,瞬间完成

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

atlas的配置文件(默认/usr/local/mysql_proxy/conf/test.cnf),个人感觉是一个非常清爽的配置,基本上配置节点的备注都非常清楚。
因为是单机多实例,这里仅仅通过不同的端口号来区分从库实例,可以是单从,也可以是多从,按照优先级来拆分。

#Atlas后端连接的MySQL从库的IP和端口,@后面的数字代表权重,用来作负载均衡,若省略则默认为1,可设置多项,用逗号分隔
proxy-read-only-backend-addresses = ***.***.***.***:8002@1, ***.***.***.***::8003@2

这个节点需要注意的是,对应的用户名必须在每个是利用都存在且密码一样,否则会出现错误

#用户名与其对应的加密过的MySQL密码,密码使用PREFIX/bin目录下的加密程序encrypt加密,下行的user1和user2为示例,将其替换为你的MySQL的用户名和加密密码!
pwds = username1:DAJnl8cVzy8=, username2:DAJnl8cVzy8=


[mysql-proxy]

#带#号的为非必需的配置项目

#管理接口的用户名
admin-username = user

#管理接口的密码
admin-password = pwd

#Atlas后端连接的MySQL主库的IP和端口,可设置多项,用逗号分隔
proxy-backend-addresses = ***.***.***.***:8001

#Atlas后端连接的MySQL从库的IP和端口,@后面的数字代表权重,用来作负载均衡,若省略则默认为1,可设置多项,用逗号分隔
proxy-read-only-backend-addresses = proxy-read-only-backend-addresses =***.***.***.***:8002@1,***.***.***.***:8003@2

#用户名与其对应的加密过的MySQL密码,密码使用PREFIX/bin目录下的加密程序encrypt加密,下行的user1和user2为示例,将其替换为你的MySQL的用户名和加密密码!
pwds = user1:DAJnl8cVzy8=, user2:DAJnl8cVzy8=

#设置Atlas的运行方式,设为true时为守护进程方式,设为false时为前台方式,一般开发调试时设为false,线上运行时设为true,true后面不能有空格。
daemon = true

#设置Atlas的运行方式,设为true时Atlas会启动两个进程,一个为monitor,一个为worker,monitor在worker意外退出后会自动将其重启,设为false时只有worker,没有monitor,一般开发调试时设为false,线上运行时设为true,true后面不能有空格。
keepalive = true

#工作线程数,对Atlas的性能有很大影响,可根据情况适当设置
event-threads = 8

#日志级别,分为message、warning、critical、error、debug五个级别
log-level = message

#日志存放的路径
log-path = /usr/local/mysql-proxy/log

#SQL日志的开关,可设置为OFF、ON、REALTIME,OFF代表不记录SQL日志,ON代表记录SQL日志,REALTIME代表记录SQL日志且实时写入磁盘,默认为OFF
#sql-log = OFF

#慢日志输出设置。当设置了该参数时,则日志只输出执行时间超过sql-log-slow(单位:ms)的日志记录。不设置该参数则输出全部日志。
#sql-log-slow = 10

#实例名称,用于同一台机器上多个Atlas实例间的区分
#instance = test

#Atlas监听的工作接口IP和端口
proxy-address = ***.***.***.***:1234

#Atlas监听的管理接口IP和端口
admin-address = ***.***.***.***:2345

#分表设置,此例中person为库名,mt为表名,id为分表字段,3为子表数量,可设置多项,以逗号分隔,若不分表则不需要设置该项
#tables = person.mt.id.3

#默认字符集,设置该项后客户端不再需要执行SET NAMES语句
#charset = utf8

#允许连接Atlas的客户端的IP,可以是精确IP,也可以是IP段,以逗号分隔,若不设置该项则允许所有IP连接,否则只允许列表中的IP连接
#client-ips = 127.0.0.1, 192.168.1

#Atlas前面挂接的LVS的物理网卡的IP(注意不是虚IP),若有LVS且设置了client-ips则此项必须设置,否则可以不设置
#lvs-ips = 192.168.1.1


启动atlas

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

 

测试读写分离

MGR是一主二从,主节点Server_id是8001,从节点的Server_id分别是8002和8003
可以发现读信息重定向到8002节点,写信息重定向到8001节点,实现了读写分离

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

强制关掉一个从节点,将读重定向到次级读节点。

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

读重定向到8003节点,写依旧是主节点,MGR状态也正常,如果尝试关闭所有的读节点,读将自动重定向到主(写)节点,说明从节点的错误都是可以兼容的。
这一点说明,从(读)节点的任何错误都是不影响atlas对外提供服务器的,如果做到主节点的高可用,atlas就可以完美地对外提供服务了。

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

Atlas中间件会自动过滤掉一些危险的操作,比如不带where条件的delete就无法执行

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

尚无进行分表测试。

 

 

遇到的问题:

一开始服务无法启动,出现错误日志proxy-plugin.c.1783: I have no server backend, closing connection,是因为配置的user信息在每个节点不一致导致的。
后来修改pwds 节点的user信息,其中user的新在每一个节点都一致,包括用户名和密码,服务正常启动。

基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想

 

基于MGR+Keepalived+Atlas的高可用加读写分离

后续可以尝试,在MGR的基础上做一个基于keepalived的自动故障转移,写节点可以基于VIP做自动故障转移,
然后在此基础上,基于VIP+其他节点做读写分离,理论上可以完美地实现自动故障转移的高可用+读写分离。
这样YY起来的话,感觉这样子也略屌,自动故障转移有了,读写分离也有了,理论上,只要有一个存活的节点,都可以正常对外提供服务。

版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《基于MGR+Atlas的读写分离尝试,以及MGR+Keepalived+Atlas自动故障转移+读写分离设想》的版权归原作者「超微技术社团」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注超微技术社团微信公众号

超微技术社团微信公众号:CWJS-LC

超微技术社团

手机扫描上方二维码即可关注超微技术社团微信公众号

超微技术社团最新文章

精品公众号随机推荐