作者：Jason
就职于捷信消费金融有限公司，担任 DBA 工作。先后从事过 Oracle 、Mongo 、MySQL 的 DBA ，以及大数据 ETL 的开发工作。对 NEWSQL 以及云原生分布式数据库具有浓厚的兴趣爱好。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
看到此标题，了解proxysql的朋友都不免一头雾水，自动扩展proxysql查询路由调整能力？提升innodb cluster可用性？围绕此话题，我们通过一些故障场景演示如何实现上述方案，在开始之前，先说下数据库架构背景：
一、数据库架构信息
1.innodb cluster采用组复制协议，信息如下：
拓扑模式：单主模式
主节点（读写角色）：mgr1_dev1:3377
副节点（只读角色）：mgr2_dev1:3377/ mgr3_dev1:3377
集群是在线的，可以容忍一个节点故障。
2.Proxysql配置信息如下：
- 组复制主机组角色定义：
- Mysql节点被分配的角色属性：
可以看到 proxysq l中的 mysql 各节点角色完全对应了 innodb cluster 中各节点的角色。
- Mysql查询路由配置信息（只截图路由到副节点的配置信息，除了只读请求，其他类型请求都会路由到主节点）：
二、故障场景分析
组复制建立在Paxos分布式算法的实现之上，以提供组成员之间的分布式协调。因此，它需要大多数组成员处于活动状态才能达到仲裁成员数，才能够做出决策。该要求会直接影响到集群在不影响自身和整体可用性的情况下能够容忍发生故障的成员数量。可以容忍发生故障的成员数量（假设为f个）和要求组内总成员数量（假设为n个，n通常为奇数）之间的关系为：n = 2 x f + 1，也可以理解为一旦2 x f > n，集群已经无法满足大多数成员仲裁协议，需要人工介入处理。
在上述集群架构中，一旦同时出现2个节点或者相继出现2个节点故障，那么首当其冲的就是只读请求失败，因为已经无副节点可提供服务，而proxysql依然会按照查询路由配置把读请求路由到副节点，此时即使人工介入，也会存在读请求失败的不可用时间期。
如果组内总成员数大于3，即使大多数成员故障，仍然可能会存在副节点可用，但也建议调整路由配置，防止出现读请求失败的不可用时间期，优先处理组复制问题，然后再恢复路由配置。
在比较极端的情况下，如果所有组成员解散，各成员全部变为只读状态，但是mysql服务可用，而这时也可以通过调整路由配置和主机组角色保证只读的请求可用。
综上所述，需要一种自动化手段扩展proxysql查询路由调整能力，尽可能地提升innodb cluster的可用性。
三、自动化实现方式以及故障模拟
通过 bash 脚本和 proxysql 自带的调度任务机制完成自动化扩展 proxysql 查询路由调整能力。
脚本如下（JInja2模板，脱敏处理，如需本地化，替换相关变量即可）
调度任务如下（每隔3秒执行1次脚本）：
1.出现2个节点故障
Innodb cluster的状态信息：
立马出现报警提示：
Proxysql 中的各 mysql 角色信息和查询路由配置信息：
人工处理后，恢复了一个副节点，报警立马出现如下提示：
另一个副节点恢复后，proxysql的mysql角色信息和查询路由配置信息都恢复正常：
2.所有组成员解散：
Innodb cluster的状态信息：
立马出现报警提示：
Proxysql的mysql角色信息和查询路由配置信息：
这时不禁有人会问这角色状态不都是正常的吗，而且还可以写入？实质上是已经禁用了组复制主机组角色定义，让节点角色恢复到初始化状态，但此时每个节点都是具有只读保护的，无法写入到任何一个节点，防止产生数据不一致的问题。
此时的组复制主机组角色定义如下：
由于组复制所有成员解散，往往问题都比较复杂，处理时间比较长，所以也自动禁用了定时任务机制，而在组复制修复后，需要手动启用组复制主机组角色定义和定时任务机制。
人工处理后，报警提示查询路由请求恢复正常：
四、总结
综上所述，proxysql自身提供的定时任务机制与bash脚本配合，能够实现自动化扩展proxysql查询路由调整能力。
在组复制所有成员解散的极端故障情况下，对于写操作的自动化调整往往存在一致性校验的问题，并且脚本实现逻辑比较复杂，不一定完全保证数据的一致性，故需要人工结合实际情况调整。