baijiu1的博客

前言上篇文章中：《orchestrator的discover模块》主要讲述的是在client发出discover这个命令后，orchestrator服务端所采取的动作，那么，后续的持续discover，是如何实现，并且如何探测到失败实例的呢，今天这篇文章就来讲述这方面的内容。持续发现入口函数在：logic/orchestrator.go文件：ContinuousDiscovery()函数调用handleDiscoveryRequests()，handleDiscoveryRequests()该函数就

Orchestra失败类型我们可以从官网上了解到，orchestrator有很多中失败类型，如DeadMaster、DeadMasterAndReplicas、DeadMasterAndSomeReplicas等等。那么，它是如何来判断这些类型的呢，今天一起走进orchestrator的内心世界。orchestrator数据采集过程要知道orchestrator如何判定失败类型，那么首先要知悉orchestrator的探测或检测过程，这部分的内容，会在单独的一篇文章中写，这篇文章主要讨论的是失败类型的

orchestrator的discover原理当我们发出命令：orchestrator-client -c discover -i hostname:port首先，orchestrator会发现给定的实例，即命令中的hostname:port这个实例，然后进而通过该实例来发现整个拓补结构。具体如何进行发现：1、使用MySQLHostnameResolveMethod和HostnameResolveMethod两个参数来发现给定实例。2、使用DiscoverByShowSlaveHosts来发现

概述在之前，比较笼统的讲述了Orchestrator的大概部署与用法，本篇则详细描述Orchestrator的Hook、API命令的使用。还有其他部署过程中需要注意的点。如果对Orchestrator还不太了解，可以参考：《 MySQL中间件:Orchestrator上篇》配置细化在说明Hook之前，要先了解Orchestrator是如何做故障检测的，以及是如何进行故障恢复的。需要的配置Orchestrator配置文件中的配置有一项：{ “ FailureDetectionPerio

Orchestrator解读第一部分最近在二次开发Orchestrator，所以研读了一下优雅切换部分的代码。入口首先，通过orchestrator-client来做为客户端请求入口来说明：代码位于：orchestrator/resources/bin/orchestrator-clientmain：function main { check_requirements detect_leader_api instance_hostport=$(to_hostport $ins

orchestrator是一个MySQL高可用复制拓补的管理和可视化工具，同时也是GitHub官方在使用的一个复制拓补管理工具，它允许：1）发现：orchestrator主动发现拓补结构并读取基本的MySQL信息，如复制状态和配置。2）重构：可以将一个不可用的服务器从拓补结构中剔除，并把数据副本移动到另一个从库下面3）恢复：在不可用时，可以选择一个适合的从库提升为主库...