MaxScale使用基于数据库语句规则检测再转发到后端群集内的服务器,透明地为应用程序提供负载均衡和高可用性功能,具有可扩展和灵活的架构。
MaxScale中的限制参考官方文档:
https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-limitations-and-known-issues-within-mariadb-maxscale/
配置分为几大模块:
全局配置[maxscale]
主要配置服务的基本参数,比如启动线程数、线程堆栈大小、日志等级、数据目录等等项...
服务状态监控[MySQL Monitor]
该项主要作用是用于对后端数据库服务进行状态检测及控制
从简单master-slave架构到复杂的galera cluster都支持,就是不知道能不能支持mysql group replication,没测试过.........
后端服务定义[server name]
路由
MaxScale的主要任务是接受来自客户端应用程序的数据库连接,通过解析这些语句/链接并路由到后端正确的数据库服务上,所以路由是maxscale的核心部件,目前有四种路由方式可以供我们选择
基于链接的负载均衡:* ReadConnRoute
基于语句的读写分离:* ReadWriteSplit
库级别的简单分库:* SchemaRouter
二进制日志服务器:* Binlogrouter,可以作为中继服务使用,且不会像复制线程一样重放binlog,这使得它的效率会很高,到真正的slave节点几乎只是个网络延后
Maxadmin
监听配置
配置项就不过多做解释,Mariadb官网有详细的文档参考(https://mariadb.com/kb/en/mariadb-enterprise/maxscale/),下面是我测试的配置文件供参考,主要是对读写分离进行测试
#?MaxScale?documentation?on?GitHub: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Documentation-Contents.md #?Global?parameters # #?Complete?list?of?configuration?options: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Getting-Started/Configuration-Guide.md [maxscale] threads=4??????????????????#线程数,尽量不要超过CPU个数 thread_stack_size=5Mi auth_connect_timeout=10 proxy_protocol=1???????????#协议包,使后端mariadb服务显示连接的源IP log_to_shm=0???????????????#不将日志写入到共享缓存中?? log_warning=1??????????????#日志记录告警信息?? log_notice=1???????????????#记录notice?? log_info=1?????????????????#日志记录info?? log_debug=0????????????????#关闭debug模式?? log_augmentation=1?????????#日志递增? #datadir=/data/maxscale????#数据目录,基于binlog中继模式时保存的binlog文件目录? #?Server?definitions # #?Set?the?address?of?the?server?to?the?network #?address?of?a?MySQL?server. # [server1] type=server address=10.5.10.17 port=3306 protocol=MySQLBackend serversize=30 #负载均衡百分比 #allow_external_slaves=true [server2] type=server address=10.5.10.18 port=3306 protocol=MySQLBackend serversize=70 #allow_external_slaves=true #?Monitor?for?the?servers # #?This?will?keep?MaxScale?aware?of?the?state?of?the?servers. #?MySQL?Monitor?documentation: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Monitors/MySQL-Monitor.md #monitor配置,如不配置monitor需通过maxadmin手动设置主从状态,不然无法读写分离 [MySQL?Monitor] type=monitor module=mysqlmon?????????????????????????#模块 servers=server1,server2 user=maxscale passwd=9C8890EB5EEEDB069DD56DF649001E9C monitor_interval=1000???????????????????#监测后端服务器心跳的间隔时间,单位毫秒 detect_replication_lag=true?????????????#开启检查slave延迟 detect_stale_master=true????????????????#打开slave宕机分发查询到master的机制,当所有slave宕机服务依然可用 detect_standalone_master=true???????????#当该参数打开时,简单主从双节点的集群当master宕机会检测在线的slave能否作为新master使用,假如使用了MHA或自动切换工具就会自动检查到master并提供写服务 failcount=5?????????????????????????????#标记新master之前,发生故障的机器失败次数 allow_cluster_recovery=true?????????????#宕机恢复的节点是否允许重新加入集群提供服务 #?Service?definitions # #?Service?Definition?for?a?read-only?service?and #?a?read/write?splitting?service. # #?ReadConnRoute?documentation: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Routers/ReadConnRoute.md #只读模块,基于连接的负载均衡配置 [Read-Only?Service] type=service router=readconnroute servers=server2 user=maxscale passwd=9C8890EB5EEEDB069DD56DF649001E9C router_options=slave weightby=serversize #负载均衡权重控制,使用每个服务的serversize值 #?ReadWriteSplit?documentation: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Routers/ReadWriteSplit.md #读写分离模块配置 [Read-Write?Service] type=service router=readwritesplit???????????????????????????#读写分离 servers=server1,server2 max_slave_replication_lag=5?????????????????????#允许slave延迟时间,超过该值将不会分发查询操作到slave user=maxscale passwd=9C8890EB5EEEDB069DD56DF649001E9C master_accept_reads=false???????????????????????#是否允许master接收查询操作 #max_slave_connections=100% use_sql_variables_in=master?????????????????????#包含临时变量的sql路由到的位置,可配置项[all/master/slave] #auth_all_servers=true #?This?service?enables?the?use?of?the?MaxAdmin?interface #?MaxScale?administration?guide: #?https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Reference/MaxAdmin.md #maxadmin配置模块 [MaxAdmin?Service] type=service router=cli #?Listener?definitions?for?the?services # #?These?listeners?represent?the?ports?the #?services?will?listen?on. # #监听端口配置 ########################## [Read-Only?Listener] type=listener service=Read-Only?Service???????#对应上面配置的只读模块名称 protocol=MySQLClient port=4008???????????????????????#监听端口 [Read-Write?Listener] type=listener service=Read-Write?Service??????#对应上面配置的读写分离名称 protocol=MySQLClient port=4006 [MaxAdmin?Listener] type=listener service=MaxAdmin?Service protocol=maxscaled socket=default ##########################
在利用sysbench进行压力测试时发现所有请求都分发在master上,这可能和sysbench事务请求方式有关,而手动操作却能正常分离,毕竟测试也就没去深究怎么回事,由于我们现在的环境使用的是mysqlrouter
做的中间件,所以就直接和mysqlrouter做了个单节点压力对比,同样的节点mysqlrouter压测oltp能达到7w-8w的qps,而maxscale只有5-6W的qps,mysqlrouter大家都知道是oracle官方的轻量级路由中间件,性能
损耗很低,比直连mysql低不了多少,我们可以看成利用maxscale做中间件的单节点比直连效率降低20%左右,毕竟做了连接解析等一系列操作嘛,可以理解的......,如果一个节点扛不住可以做maxscale层做负载
嘛,maxscale是无数据存储的。
在测试途中发现maxscale几个好用的点:
自动检查slave延迟,延迟时间超过设置的值就不给对应节点路由连接过去,直到延迟时间低于阈值,maxscale主从检查方式是在master上创建一个maxscale_schema库并创建replication_heartbeat心跳表,在
master上每隔一个心跳时间就插入当前时间戳,再在slave读取该表的值进行计算延迟时间,这方式简单粗暴,相对于mysql源生复制采用读取的event和执行的event时间戳计算时间差的方式更精确一些,需要给
maxscale配置的monitor用户指定maxscale_schema库replication_heartbeat表的读写权限
master宕机自动检查是否有新master可提供写入操作,该功能使我们平时的高可用变的简单,宕机切换之后不需要对maxscale做任何操作就自动能恢复写入操作
由于maxscale的monitor机制,会检查所有节点的身份,当宕机的节点恢复时可以自动加入到集群提供服务,这个还需要和slave延迟检测像结合使用,以免读取不到新数据
读写分离路由当master宕机,slave依然可以提供读服务,不用担心master宕了所有读写都无法操作的情况
配置文件密码可加密,操作方式:
????[[email protected]?maxscale]#?maxkeys? ????Generating?.secrets?file?in?/var/lib/maxscale. ????[[email protected]?maxscale]#?maxpasswd??123456 ????17EB6DA393620980EF8294BD738E4B8A
根据maxscale对用户权限验证的方式是直接采用后端数据库服务的权限验证,以及需要检测主从角色,maxscale配置的用户有下面几个权限需求:
GRANT?replication?client?on?*.*?to?‘maxscale‘@‘maxscalehost‘; GRANT?SELECT?ON?mysql.user?TO?‘maxscale‘@‘maxscalehost‘; GRANT?SELECT?ON?mysql.db?TO?‘maxscale‘@‘maxscalehost‘; GRANT?SELECT?ON?mysql.tables_priv?TO?‘maxscale‘@‘maxscalehost‘; GRANT?SHOW?DATABASES?ON?*.*?TO?‘maxscale‘@‘maxscalehost‘;