weixin_47056515的博客

由 go 编写的 MySQL 高可用性和复制拓扑管理工具，支持复制拓扑结构的调整、自动故障转移和手动主从切换等。后端数据库使用 MySQL 或 SQLite 存储元数据，并提供 Web 界面展示 MySQL 复制的拓扑关系及状态。通过 Web 可更改 MySQL 实例的复制关系和部分配置信息，同时也提供命令行和 api 接口，便于运维管理。

部署一个一主两从的orchestrator集群，当主节点宕机时，会在从节点中选举出新的主节点，保证orchestrator集群的高可用性，并继续为检测MySQL集群服务。注意：使用两种方式切换启动,先确保Orch进程未启动。想获取更多实用干货，关注微信公众号【雅俗数据库】。注意检查是否配置如下参数，若未配置，请手工配置。登录网页 11.186.63.78:3000。数据库安装部署省略，可自行安装。11.186.63.78节点。所有节点都启动 Orch。三节点，分别建软连接。Orch集群健康检查。

参数定义了从库从主库获取数据等待的超时时间，超过这个时间从库会主动断开连接并尝试重新获取。被Orch纳管的MySQL实例，需要启用GTID,主从同步使用。打印拓扑实例的 ASCII 树 通过以下方式传递集群名称。想获取更多实用干货，关注微信公众号【雅俗数据库】。输入ip(hostname)和port。过长会导致切换延迟过久，所以需要调整。检查主库和从库之间的IO链路。显示当前已知的集群（显示主节点）温馨提示：推荐使用界面方式来接管。

Orchestrator默认仅提供MySQL主从复制的扩展管理。在发生故障转移时，会重新组织扩展，选出新主库并指定其他从库连接到它。但Orch自身不会进行任何DNS更改或VIP漂移。切换后，应用程序可能连接到错误的数据库。那么是否可以按照MHA+VIP类似的方式，来使用Orchestrator呢？建议开启无损半同步（rpl_semi_sync_master_wait_point=AFTER_SYNC）。

笔者目前在hook脚本中，只对DeadMaster和DeadMasterAndSomeReplicas两种故障场景做了切换，其余故障场景，不会发生高可用切换。生产环境，需要根据实际业务需要，定义自己所需切换的故障场景。想获取更多实用干货，关注微信公众号【雅俗数据库】。

不论集群主库是否故障，都会进行后续切换操作，需要用户确认已发生故障。，是因为老主库不是故障的，首先会让候选主库追上老主库。最后，将老主库作为新主库的从库（但没有执行。指定的故障主库必须是故障的，也就是已确认发生故障，如果不是故障的，不进行切换。这种切换方式针对的是：老主库是正常的，需要提升新主库，老主库可作为从库。不人为指定新主库host和端口，让orchestrator自己选新主库，老主库。：从库提升为主库，并且候选主库必须是集群主库的直连从库。不会将老主库作为新主库的从库，老主库成为孤立的实例。

自动切换受到以下条件限制和约束：主库是downtime的集群不进行故障切换。如果希望忽略集群故障，可以设置downtime。处于故障活跃期的集群不进行故障切换（即只对配置项匹配的集群进行故障切换。：在Orchestrator的配置文件中，可能会有类似如下的配置来设置这里的和就是与相关的配置项，分别表示在处理主节点集群故障和中间主节点故障时的活动时间周期，单位为秒。

想获取更多实用干货，关注微信公众号【雅俗数据库】。