共计 1776 个字符，预计需要花费 5 分钟才能阅读完成。
作者：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 查问路由调整能力。
在组复制所有成员遣散的极其故障状况下，对于写操作的自动化调整往往存在一致性校验的问题，并且脚本实现逻辑比较复杂，不肯定齐全保证数据的一致性，故须要人工结合实际状况调整。