【GreatSQL茶话会10】给GreatSQL提新功能建议赢好礼~

感谢大家的参与，本次茶话会已结束，根据点赞数量及回帖内容质量统计公布获奖名单：

参与回帖奖：社区金币 100 个；
获奖用户名：zhengda,chongzh,PaddyZhang,hades,ShawnYan,zxq,renduy,fander,周欢欢,vvvvvv；

Proxy代理功能：三节点架构能够提供高可用服务，但最后一公里多主（主从）切换，负载均衡功能缺失，还需要自己寻找和沉淀代理方案，无官方提供的最佳实践，美中不足。
希望通过proxy代理，用户可以轻松连接高可用集群，提供完美的服务，目前负载均衡和故障转移是最大的痛点，必须额外引入开源代理方案。

数据仓库或异地容灾工具：在更高级的功能方面希望是否提供基于类似binlog等技术，实现集群与集群级联实现异地容灾，数据仓库的数据实时更新功能。这样可以扩展上下游的联动，数据不是孤岛。通过类似canal可以在线增量同步数据，解决客户痛点。

1、GreatSQL ansible 部署脚本 不但能支持MGR，还能支持主从架构
2、GreatSQL ansible 部署脚本 只修改不同的端口就可以支持多实例
3、GreatSQL 主从架构支持内嵌vip漂移

大家尽量多提提对数据库本身的功能需求，当然了，周边配套工具及解决方案也是欢迎的 ：）

1. GreateSQL希望能支持限流、熔断等功能。这些功能在传统的公司，都要在中间件中完成和实现。成本相对其他企业或者团队很高，但在故障处理的场景非常有用。所以GreateSQL为了更好的在不同企业中适配，可以考虑此功能。
2. 仲裁节点，仲裁节点不存储数据，但是可以将binlog保存。这样仲裁节点也可以组成Binlog中心，方便架构扩展。以及MGR本地节点无需保留过多重复的binlog，达到成本控制。
3. MGR节点添加，在这个过程会影响Primary的吞吐性能，也会影响doner节点的磁盘消耗。可以考虑适配备份远程路径，还原备份后以异步slave方式到仲裁节点（Binlog节点）回追增量，然后开启增强半同步保持数据强一致后，直接转换成MGR节点加入集群。可以最小程度的在节点添加过程影响集群的性能。
4. 打上地理标签，Primary的地理标签是1，IDC2的地理标签是2，那么地理标签2，每增加一个MGR节点后，都会导致Primary的QPS的承载力下降几千。这个感觉和Paxos+地理标签2中只要有一个节点返回ACK即可的集群，会有矛盾。
5. 业务是写少读多。传统为了读写分离，都要依赖全量副本，而且能做读写分离的请求，也是按需的，但全副本就让读库承载了不需要的表的数据同步和成本。又让写库承担了读库才需要的索引。所以GreateSQL可以考虑创建slave节点，但减少无用表的传输，只按照SQL传输需要的表数据，所以在只读区域（阉割后的Slave节点维护），会比传统slave全量写到relay log里再通过sql thread进行filter 过滤回放要快的多。同时MGR主要作为写节点的容灾区域。
6. MGR流控自动降级，在Second节点异常，导致Primary节点性能下降时，可以考虑Second节点自动退化成Slave节点，保证Primary节点的稳定性。

提供一个基于仲裁节点的双中心MGR架构图：

chongzh 发表于 2023-12-11 14:39
1、GreatSQL ansible 部署脚本 不但能支持MGR，还能支持主从架构
2、GreatSQL ansible 部署脚本 只修改不同 ...

1和2可以关注fander老师的dbops项目 https://gitee.com/fanderchan/dbops。
3可以直接用Keepalived就好。

zhengda 发表于 2023-12-11 11:35
Proxy代理功能：三节点架构能够提供高可用服务，但最后一公里多主（主从）切换，负载均衡功能缺失，还需要 ...

我司目前有个proxysql可以实现这个目标，不过是商业的，暂时还没开源计划。

你可以先尝试使用MySQL Router。

希望有些周边配套工具，不一定需要强耦合到数据库安装包里面，也不一定需要全部开源。
类似对比表结构差异的工具（支持类型多）、旁路抓包工具、要是有更好的类似proxysql这样的工具那是最好了！
MGR功能更加完善，做成比官方更好的plus版本！