Maxscale 简单介绍

MaxScale使用基于数据库语句规则检测并转发到后端集群服务的机制，透明地为应用程序提供负载均衡和高可用性功能，具有可扩展和灵活的架构。

MaxScale中也有各种限制，参考官方文档：

https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-limitations-and-known-issues-within-mariadb-maxscale/

配置分为几大模块：

全局配置[maxscale]

主要配置服务的基本参数，比如启动线程数、线程堆栈大小、日志等级、数据目录等等项...

服务状态监控[MySQL Monitor]

该项主要作用是用于对后端数据库服务进行状态检测及控制

Mysql Monitor

Galera Monitor

NDBCluster Monitor

Multi-Master 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=5Miauth_connect_timeout=10proxy_protocol=1 #协议包，使后端mariadb服务显示连接的源IPlog_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=serveraddress=10.5.10.17port=3306protocol=MySQLBackendserversize=30#负载均衡百分比#allow_external_slaves=true[server2]type=serveraddress=10.5.10.18port=3306protocol=MySQLBackendserversize=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=monitormodule=mysqlmon #模块servers=server1,server2user=maxscalepasswd=9C8890EB5EEEDB069DD56DF649001E9Cmonitor_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=servicerouter=readconnrouteservers=server2user=maxscalepasswd=9C8890EB5EEEDB069DD56DF649001E9Crouter_options=slaveweightby=serversize#负载均衡权重控制，使用每个服务的serversize值# ReadWriteSplit documentation:# https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Routers/ReadWriteSplit.md#读写分离模块配置[Read-Write Service]type=servicerouter=readwritesplit #读写分离servers=server1,server2max_slave_replication_lag=5 #允许slave延迟时间，超过该值将不会分发查询操作到slaveuser=maxscalepasswd=9C8890EB5EEEDB069DD56DF649001E9Cmaster_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=servicerouter=cli# Listener definitions for the services## These listeners represent the ports the# services will listen on.##监听端口配置##########################[Read-Only Listener]type=listenerservice=Read-Only Service #对应上面配置的只读模块名称protocol=MySQLClientport=4008 #监听端口[Read-Write Listener]type=listenerservice=Read-Write Service #对应上面配置的读写分离名称protocol=MySQLClientport=4006[MaxAdmin Listener]type=listenerservice=MaxAdmin Serviceprotocol=maxscaledsocket=default##########################

在利用sysbench进行压力测试时发现所有请求都分发在master上，这可能和sysbench事务请求方式有关，而手动操作和开发的程序操作都能正常分离，毕竟测试也就没去深究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宕了所有读写都无法操作的情况

配置文件密码可加密，操作方式：

[root@localhost maxscale]# maxkeys Generating .secrets file in /var/lib/maxscale. [root@localhost 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';