[ 功能建议 ] 希望去远程MYSQL实例上执行语句之前，检查远程MYSQL的主从角色

[eric-po]

【希望能防止：有高可用功能的远程MYSQL架构主从数据不一致】

目前遇到的问题/使用障碍

我们的MYSQL架构是有高可用功能的，但在archery中配置远程MYSQL数据源时，我们只能配置主库（为了能备份所执行的SQL语句，不能配置MYSQL代理IP:PORT（如proxysql))。
当主从发生切换时，原来配置的主库就会成为从库，在这种情况下，如果通过archery执行DML或DDL SQL的话，就会发到从库去执行，导致主从数据不一致

希望如何解决/实现它

能否在审核MYSQL语句时或真正去远程MYSQL上执行语句时，也检查一下远程MYSQL的主从角色，比如向远程MYSQL实例发送show slave status;
如果有结果返回，那就证明远程MYSQL实例已经是一个从库了，不应该继续在上面执行DML或DDL语句。
如果没有结果返回，那说明远程MYSQL实例是主库，可以继续在上面执行DML或DDL语句。

其他信息

如果有其他类似的产品功能或者图片信息，可在此提交

[hhyo]

感谢反馈，最近在测试proxysql也考虑到这个问题，proxysql不支持binlogdump，也就造成通过inception执行无法备份数据，上线实例不能指定proxy地址

上面有提到通过 show slave hosts 去判断操作的实例是否是主库，这个方法如果遇到级联复制仍然会造成错误，不可取

目前有几个思路可以交流下

• 集群主从切换/故障转移时将从库设置为super_read_only=1、read_only=1，Archery在执行前通过这两个变量来判断当前实例是否可写，从而给出相应提示
• 单独给集群维护一个master的域名，Archery配置该域名
• 集群主从切换/故障转移时，通过hook的方式修改Archery数据库中的实例配置，并验证变更结果

第一种方式处理起来方便，大多数高可用架构都可以在切换后设置旧master为只读，只是当主从变更后需要手工去修改Archery的配置，但依然存在风险，比如在切换过程中设置只读失败

第二种需要单独给集群主库维护一个域名，如果用dns解析，有可能存在TTL缓存的问题，用vip又更增加了维护成本

第三种处理方式相比第二种不需要单独维护域名，也不需要像第一种那样去手工变更配置，只要集群切换hook通知新主是可靠的，同时对数据变更增加检验，再加上Archery增加只读检验，整体就是可靠的，我个人更倾向于这种处理

抱歉show slave host 那个看错了😂，如果使用show slave status可能不适用于双主的架构（虽然用的很少）

[eric-po]

非常感谢你的思路，我选取了最简单的做法：

1. 根据你的建议在archery/sql/sql_workflow.py中的以下三个方法下添加了read_only检查逻辑：
   def check
   def execute
   def timing_task

2. 向goinception的作者建议增加执行SQL前对read_only进行检查（已被采纳）