FaN()

首先说明, “不合理"只是站在个人角度的结论. 到底合理不合理, 我说了不算.以我对Orchestrator的了解, Orchestrator目标是追求可用性优先, 而非数据完整性. 很多公司也使用了Orchestrator, 我感觉未必知道有这个问题, 或者说, 别问, 问就是"我们追求可用性”.然而矛盾的点是, 线上主从的复制延迟是大家都要监控和管理的, 不会长期处于高延迟状态, 起码我经历的公司都是这样, 99.9%的集群主从延迟在1s内. 个别集群在高峰期会升高一点, 但很快又会下降;

其实还没来得及翻代码, 同事就已经发现新加的三个从库server_id与原集群提供备份节点的server_id是一样的, 所以基本猜测就是server_id导致。同事要做一个数据库迁移, 方法就是加从库, 然后主从切换, 再下掉老主库, 完成迁移。继续梳理代码可以发现。这里我部署1主4从, 虽然比线上实际少了一个从库, 但不影响复现问题.原本是一主两从集群, 增加三个从库变为一主无从。使用命令切换时报错(以下是本地测试复现的命令)原生的问题是, 没有输出这段错误信息。通过对日志中关键字的搜索, 发现。

Orchestrator Failover过程源码分析-III书接上文Orchestrator Failover过程源码分析-IIGetCandidateReplica// RegroupReplicasGTID will choose a candidate replica of a given instance, and take its siblings using GTIDfunc RegroupReplicasGTID( masterKey *InstanceKey, // 实参传

Orchestrator Failover过程源码分析-II书接上文Orchestrator Failover过程源码分析-IDeadMaster恢复流程首先通过getCheckAndRecoverFunction获取"checkAndRecoverFunction"func getCheckAndRecoverFunction(analysisCode inst.AnalysisCode, analyzedInstanceKey *inst.InstanceKey) ( checkAndR

模拟故障使用测试环境, 模拟3307集群故障角色IP端口主机名主库172.16.120.103307centos-1从库172.16.120.113307centos-2从库172.16.120.123307centos-3关闭3307主库172.16.120.10:3307[2022-04-25 13:10:56][root@centos-1 13:10:56 ~][2022-04-25 13:11:22]#systemctl stop

配置参数详解-IIIApplyMySQLPromotionAfterMasterFailover类型: bool默认值: true当为true 时, orchestrator 将在选举出的新主库上执行reset slave all 和set read_only=0 . 默认: true . 当该参数为true 时, 将覆盖MasterFailoverDetachSlaveMasterHost .Should orchestrator take upon itself to apply MySQL

配置参数详解-ⅡClusterNameToAlias类型: map[string]string默认值: make(map[string]string)就是可以定义集群的别名. 配置文件示例是这样的 "ClusterNameToAlias": { "127.0.0.1": "test suite" // 感觉例子不好, 集群名字怎么会是127.0.0.1呢 },map between regex matching cluster name to a human friendly

配置参数详解-Ⅰorchestrator/conf 下有几个实例配置文件orchestrator-ci-env.conf.jsonorchestrator-ci-upgrade.conf.jsonorchestrator-raft-env.conf.jsonorchestrator-sample.conf.jsonorchestrator-sample-sqlite.conf.jsonorchestrator-simple.conf.jsonsimple和sample区别不大.参数的解