MaxScale 6.0引入了本地集群，允许多个MaxScale实例相互通信和共享配置更新。在这篇博文中，我们将解释该功能是如何工作的，并演示如何实现它。
常见的最大规模拓扑
集中式MaxScale服务器
这是最常见的安装，其中MaxScale位于应用程序服务器和数据库之间。它很简单，但没有任何高可用性。如果MaxScale下降，应用程序将失去与数据库的所有连接。
MaxScale HA设置
另一种常见的设置是将MaxScale安装到每个应用程序服务器或单独的服务器上。此设置的好处是，丢失一台MaxScale/app服务器不会导致整个应用程序停机。
动态配置更改
MaxScale允许通过MaxScale GUI、MaxCtrl或REST API更改运行时配置。这些运行时更改保存在persistdir目录中的磁盘上。如果有多个MaxScale，则必须手动对每个MaxScale执行任何运行时更改。
内部工作流程
基本上，这个配置同步包括六个阶段。
运行时更改
所有运行时更改都由MaxScale GUI、MaxCtrl或REST API完成。这些更改保存在磁盘上。
数据存储
配置信息存储在mysql模式下的“maxscale_config”表中。它包含：
-
集群名称（来自MaxScale配置的集群名称），
-
配置版本号。该版本号将随着每次更改而递增，
-
以JSON格式存储的实际配置数据。
版本号从0开始，第一次动态更改将其设置为1。这意味着存储在数据库中的第一次更新将具有版本号1，所有后续配置更新将增加版本。
更新配置
在应用配置更改之前，通过使用SELECT…FOR UPDATE query从数据库中选择当前配置版本。如果配置版本与MaxScale中存储的版本相同，则可以继续更新。如果配置版本不同，则向客户端返回错误。
版本检查
修改完成后，MaxScale尝试更新“MaxScale_config”表中的行。这里，SELECT…FOR UPDATE查询读取配置版本。如果成功，它将更新该行。如果版本检查由于死锁或该事务中的任何冲突而失败，MaxScale将向客户端返回错误。它保证只有一个MaxScale成功更新配置。无法执行更新的MaxScale将向客户端返回错误，并从数据库中读取新配置。
运行时配置更改以JSON格式存储在磁盘上。这是“缓存配置”。如果此缓存配置可用，将使用它而不是静态配置文件（/etc/maxscale.cnf）。这允许配置更改在崩溃和临时停机期间持续存在。
如果从当前配置到存储在集群中的配置的转换失败，则丢弃缓存的配置。这保证了只有一次尝试使用缓存配置启动，所有后续启动都使用静态配置文件。
配置同步
MaxScale定期轮询数据库以获取最新配置版本。如果数据库配置版本比当前的MaxScale配置更新，MaxScale将检查新配置和当前配置之间的差异，并通过仅应用新更改来更新配置。
如果配置更新成功，MaxScale将与其他MaxScale节点同步。如果配置更新失败，MaxScale将尝试回滚部分更改。
回降
如果配置更新在MaxScale上完成，但未能提交到数据库，MaxScale将尝试还原本地配置更改。如果此尝试失败，MaxScale将放弃缓存配置并中止进程。
与群集同步时，如果MaxScale无法应用从群集检索的配置，它将尝试将配置还原为以前的版本。如果MaxScale成功将配置恢复到以前的版本，则忽略失败的配置更新。如果无法恢复失败的配置更新，则MaxScale配置将处于不确定状态，MaxScale将丢弃缓存的配置并中止进程。
例如，假设我当前的配置版本为2。
-
如果配置更新成功，我的配置版本将为3。
-
如果更新失败，但回滚成功，配置版本将从3更改为2。
-
如果更新和回滚都失败，MaxScale将丢弃所有版本，并使用静态配置文件（/etc/MaxScale.cnf）重新启动进程。
实施
首先，我们需要获得至少2个节点。下载并安装MaxScale 6.0或更高版本，然后启动新版本。这里我们有一个3节点的Galera集群，所有数据库节点上都安装了MaxScale 6.4.0。
节点1-172.31.83.144
节点2-172.31.81.34
节点3-172.31.85.115
虚拟IP-172.31.xx.xx
首次配置MaxScale同步时，应在所有使用相同群集的MaxScale实例上使用相同的静态配置文件。所有MaxScale实例的“config_sync_cluster”值必须相同，并且在每个配置中，它指向的群集（即监视器）及其服务器必须相同。
为了创建MaxScale集群，我们需要在数据库节点上创建新用户，以便在MaxScale实例之间同步配置更改。
此用户必须具有以下权限：
MariaDB> grant SELECT, INSERT, UPDATE, CREATE ON mysql.maxscale_config to 'sync_user'@'%';
我们需要在[MaxScale]标签下的MaxScale配置中添加上述用户详细信息。
实例：
config_sync_cluster="Galera-Monitor"
config_sync_user=sync_user
config_sync_password=R00t@123
示例配置
这是我们的示例配置。所有MaxScale节点上的配置文件应相同。
$ cat /etc/maxscale.cnf
# Global parameters
[maxscale]
threads=auto
config_sync_cluster="Galera-Monitor"
config_sync_user=sync_user
config_sync_password=R00t@123
admin_secure_gui=false
admin_host=0.0.0.0
# Server definitions
[node1]
type=server
address=172.31.83.144
port=3306
protocol=MariaDBBackend
[node2]
type=server
address=172.31.81.34
port=3306
protocol=MariaDBBackend
[node3]
type=server
address=172.31.85.115
port=3306
protocol=MariaDBBackend
# Monitor for the servers
[Galera-Monitor]
type=monitor
module=galeramon
servers=node1,node2,node3
user=max_user
password=R00t@123
monitor_interval=2000
# Service definitions
在这里，我们使用读/写分离路由器来路由应用程序流量。MaxScale node1处理所有写入操作，node2和node3将处理所有读取操作。
# ReadWriteSplit
[Read-Write-Service]
type=service
router=readwritesplit
servers=node1,node2,node3
user=max_user
password=R00t@123
# Listener definitions for the services
[Read-Write-Listener]
type=listener
service=Read-Write-Service
protocol=MariaDBClient
port=4006
[root@ip-172-31-83-144 centos]# maxctrl show maxscale | grep -i 'config_sync'
│ │ "config_sync_cluster": "Galera-Monitor", │
│ │ "config_sync_interval": "5000ms", │
│ │ "config_sync_password": "*****", │
│ │ "config_sync_timeout": "10000ms", │
│ │ "config_sync_user": "max_user", │
目前，我们使用这些config_sync_interval和config_sync_timeout参数的默认值。
已添加配置。在内部，所有节点都在监视并与所有其他MaxScale节点通信。
[root@ip-172-31-83-144 centos]# maxctrl create server node4
172.31.80.237 3306
OK
在[maxscale]下添加了新节点，但maxscale不会对此节点执行任何运行状况检查。我们需要将此节点4添加到“galera monitor”。
[root@ip-172-31-83-144 centos]# maxctrl link monitor Galera-Monitor node4
OK
在“galera monitor”下添加了节点4。让我们将此节点添加到读写拆分服务。
[root@ip-172-31-83-144 centos]# maxctrl link service Read-Write-Service node4
OK
[root@ip-172-31-83-144 centos]# maxctrl list servers
┌────────┬───────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node4 │ 172.31.80.237 │ 3306 │ 0 │ Slave, Running │ │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node3 │ 172.31.85.115 │ 3306 │ 0 │ Slave, Running │ 3-3-5,1-1-47 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node2 │ 172.31.81.34 │ 3306 │ 0 │ Slave, Running │ 2-2-5,1-1-47 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node1 │ 172.31.83.144 │ 3306 │ 0 │ Master, Running │ 1-1-47 │
└────────┴───────────────┴──────┴─────────────┴─────────────────┴──────────────┘
[root@ip-172-31-83-144 centos]# maxctrl list services
┌────────────────────┬────────────────┬─────────────┬───────────────────┬────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Targets │
├────────────────────┼────────────────┼─────────────┼───────────────────┼────────────────────────────┤
│ Read-Write-Service │ readwritesplit │ 0 │ 0 │ node1, node2, node3, node4 │
无论何时在运行时修改MaxScale配置，最新配置都存储在mysql的数据库集群中。maxscale_config表。配置的本地副本存储在数据目录中，以允许MaxScale在无法连接到群集的情况下运行。默认情况下，该文件存储在/var/lib/maxscale/maxscal-config.json中。
启动时，MaxScale服务检查是否存在此配置的本地版本。如果是，并且是有效的缓存配置，则静态配置文件以及任何其他生成的配置文件将被忽略。例外情况是主静态配置文件的[maxscale]部分，该部分始终处于读取状态。
每个配置都有一个版本号，初始配置为版本0。每次修改配置时，版本号都会递增。此版本号用于检测MaxScale何时需要更新其配置。
现在在[maxscale]下添加了新节点。让我们验证此更改是否复制到其他MaxScale节点。
从MaxScale节点2和MaxScale节点3：
# maxctrl list servers
┌────────┬───────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node4 │ 172.31.80.237 │ 3306 │ 0 │ Slave, Running │ │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node3 │ 172.31.85.115 │ 3306 │ 0 │ Slave, Running │ 3-3-5,1-1-47 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node2 │ 172.31.81.34 │ 3306 │ 0 │ Slave, Running │ 2-2-5,1-1-47 │
├────────┼───────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ node1 │ 172.31.83.144 │ 3306 │ 0 │ Master, Running │ 1-1-47 │
└────────┴───────────────┴──────┴─────────────┴─────────────────┴──────────────┘
从节点2和节点3的最大刻度日志
2022-06-19 08:09:03 notice : (ConfigManager); Updating to configuration version 5
2022-06-19 08:28:43 notice : (ConfigManager); Updating to configuration version 6
2022-06-19 08:28:43 notice : (ConfigManager); Added 'node4' to 'Galera-Monitor'
2022-06-19 08:28:43 notice : 'node4' sent version string '10.6.8-MariaDB'. Detected type: 'MariaDB', version: 10.6.8.
如何验证MaxScale群集是否已同步？
maxctrl show maxscale的输出包含配置同步字段，其中包含有关本地maxscale的当前配置状态以及使用此集群的任何其他节点的状态的信息。
[root@ip-172-31-83-144 centos]# maxctrl show maxscale | grep -i 'Config Sync' -A10
│ Config Sync │ { │
│ │ "checksum": "e2f0041a344c41065dc94f5c6d8802f40c396f2a", │
│ │ "nodes": { │
│ │ "ip-172.31.83.144.ec2.internal": "OK", │
│ │ "ip-172.31.81.34.ec2.internal": "OK", │
│ │ "ip-172.31.85.115.ec2.internal": "OK", │
│ │ "ip-172.31.80.237.ec2.internal": "OK" │
│ │ }, │
│ │ "origin": "172.31.83.144.ec2.internal", │
│ │ "status": "OK", │
│ │ "version": 8 │
│ │ } │
版本字段是逻辑配置版本，原点是发起最新配置更改的节点。校验和字段是逻辑配置的校验和，可用于比较两个MaxScale实例是否处于相同的配置状态。节点字段包含映射到服务器主机名的每个MaxScale实例的状态。每当MaxScale从集群读取配置时，该字段都会更新，因此可用于检测哪个MaxScale已更新其配置。
[root@ip-172-31-83-144 centos]# maxctrl show monitors | grep -i monitor_interval
│ │ "monitor_interval": 2000, │
更新后：
从所有MaxScale节点：
# maxctrl show monitors | grep -i monitor_interval
│ │ "monitor_interval": 5000, │
[root@ip-172-31-83-144 centos]# maxctrl show maxscale | grep -i 'Config Sync' -A10
│ Config Sync │ { │
│ │ "checksum": "aea6f6ef5a2fa869041981b93493aa371d7eb8f5", │
│ │ "nodes": { │
│ │ "ip-172.31.83.144.ec2.internal": "OK", │
│ │ "ip-172.31.81.34.ec2.internal": "OK", │
│ │ "ip-172.31.85.115.ec2.internal": "OK", │
│ │ "ip-172.31.80.237.ec2.internal": "OK" │
│ │ }, │
│ │ "origin": "172.31.83.144.ec2.internal", │
│ │ "status": "OK", │
│ │ "version": 9 │
│ │ } │
禁用MaxScale群集同步
要禁用配置同步，请从配置文件中删除config_sync_cluster，或将其设置为空字符串，例如，config_sync_cluser=。这可以在运行时使用MaxCtrl通过将空字符串传递给config_sync_cluster来完成。
实例
[root@ip-172-31-83-144 centos]# maxctrl alter maxscale config_sync_cluster ""
OK
为了复位最大刻度同步，
-
停止所有MaxScale实例。
-
删除存储在/var/lib/maxscale/maxsale-config中的缓存配置文件。所有MaxScale实例上的json。
-
删除mysql.maxscale_config表。
-
启动所有MaxScale实例。
局限性
同步仅影响MaxScale配置。对象或任何外部文件的状态（例如缓存筛选规则、TLS证书、数据屏蔽规则）不通过此机制同步。
原文标题：MariaDB MaxScale 6.0 Native Clustering
原文作者：Pon Suresh Pandian
原文链接：https://mariadb.com/resources/blog/mariadb-maxscale-6-0-native-clustering/
