orchestrator介绍3.4 web API 的使用

使用 web API

orchestrator

提供精心设计的 Web API。

敏锐的 Web 开发人员会注意到（通过Firebug or Developer Tools）Web 界面如何完全依赖于 JSON API 请求。

开发人员可以使用 API 来实现自动化。

API使用简单举例

举例来说：

• /api/instance/:host/:port：读取并返回实例的详细信息（示例/api/instance/mysql10/3306）
• /api/discover/:host/:port：发现给定实例（正在运行的orchestrator服务将从那里获取它并递归扫描整个拓扑）
• /api/relocate/:host/:port/:belowHost/:belowPort（尝试）将一个实例移动到另一个实例下方。 orchestrator选择最佳行动方案。
• /api/relocate-replicas/:host/:port/:belowHost/:belowPort（尝试）将一个实例的副本移动到另一个实例下方。 orchestrator选择最佳行动方案。
• /api/recover/:host/:post：假设有需要恢复的内容，在给定实例上启动恢复。
• /api/force-master-failover/:mycluster：强制在给定集群上立即进行故障转移。

查看所有的API

事实上的列表是代码，请参阅api.go（向下滚动到

RegisterRequests

）。

您可能还会喜欢查看Orchestrator-client（源代码）以了解命令行如何转换为 API 调用。

或者，只需使用Orchestrator-client作为您的 API 客户端，这就是它的用途。

实例 JSON 详解

许多 API 调用返回** *****instance ***对象，描述单个 MySQL 服务器。该示例后面是字段细分：

{

    "Key": {
        "Hostname": "mysql.02.instance.com",
        "Port": 3306
    },
    "Uptime": 45,
    "ServerID": 101,
    "Version": "5.6.22-log",
    "ReadOnly": false,
    "Binlog_format": "ROW",
    "LogBinEnabled": true,
    "LogReplicationUpdatesEnabled": true,
    "SelfBinlogCoordinates": {
        "LogFile": "mysql-bin.015656",
        "LogPos": 15082,
        "Type": 0
    },
    "MasterKey": {
        "Hostname": "mysql.01.instance.com",
        "Port": 3306
    },
    "ReplicationSQLThreadRuning": true,
    "ReplicationIOThreadRuning": true,
    "HasReplicationFilters": false,
    "SupportsOracleGTID": true,
    "UsingOracleGTID": true,
    "UsingMariaDBGTID": false,
    "UsingPseudoGTID": false,
    "ReadBinlogCoordinates": {
        "LogFile": "mysql-bin.015993",
        "LogPos": 20146,
        "Type": 0
    },
    "ExecBinlogCoordinates": {
        "LogFile": "mysql-bin.015993",
        "LogPos": 20146,
        "Type": 0
    },
    "RelaylogCoordinates": {
        "LogFile": "mysql_sandbox21088-relay-bin.000051",
        "LogPos": 16769,
        "Type": 1
    },
    "LastSQLError": "",
    "LastIOError": "",
    "SecondsBehindMaster": {
        "Int64": 0,
        "Valid": true
    },
    "SQLDelay": 0,
    "ExecutedGtidSet": "230ea8ea-81e3-11e4-972a-e25ec4bd140a:1-49",
    "ReplicationLagSeconds": {
        "Int64": 0,
        "Valid": true
    },
    "Replicas": [ ],
    "ClusterName": "mysql.01.instance.com:3306",
    "DataCenter": "",
    "PhysicalEnvironment": "",
    "ReplicationDepth": 1,
    "IsCoMaster": false,
    "IsLastCheckValid": true,
    "IsUpToDate": true,
    "IsRecentlyChecked": true,
    "SecondsSinceLastSeen": {
        "Int64": 9,
        "Valid": true
    },
    "CountMySQLSnapshots": 0,
    "IsCandidate": false,
    "UnresolvedHostname": ""
}

实例的结构不断发展，而文档总是会落后。话虽如此，关键属性是：

• Key：实例的唯一指示符：主机和端口的组合
• ServerID：MySQLserver_id参数
• Version：MySQL版本
• ReadOnly：全局read_only布尔值
• Binlog_format：MySQL 全局参数 binlog_format
• LogBinEnabled：是否启用二进制日志
• LogReplicationUpdatesEnabled：MySQL参数是否log_slave_updates启用
• SelfBinlogCoordinates：二进制日志文件和此实例写入的位置（如SHOW MASTER STATUS）
• MasterKey：主机名和端口（如果有）
• ReplicationSQLThreadRuning: 直接映射自SHOW SLAVE STATUS'sSlave_SQL_Running
• ReplicationIOThreadRuning: 直接映射自SHOW SLAVE STATUS'sSlave_IO_Running
• HasReplicationFilters: true 如果有任何复制过滤器
• SupportsOracleGTID：如果配置为 true gtid_mode(Oracle MySQL >= 5.6)
• UsingOracleGTID：如果副本通过 Oracle GTID 复制，则为 true
• UsingMariaDBGTID：如果副本通过 MariaDB GTID 复制，则为 true
• UsingPseudoGTID：如果已知副本具有伪 GTID 坐标，则为 true（请参阅相关DetectPseudoGTIDQuery配置）
• ReadBinlogCoordinates：（复制时）从主机读取的坐标（轮询的内容IO_THREAD）
• ExecBinlogCoordinates：（复制时）现在正在执行的master坐标（SQL_THREAD执行了什么）
• RelaylogCoordinates：（复制时）当前正在执行的中继日志的坐标
• LastSQLError: 复制自SHOW SLAVE STATUS
• LastIOError: 复制自SHOW SLAVE STATUS
• SecondsBehindMaster: 直接从SHOW SLAVE STATUS' 映射Seconds_Behind_Master "Valid": false表示 aNULL
• SQLDelay: 配置的MASTER_DELAY
• ExecutedGtidSet：如果使用Oracle GTID，执行的GTID集
• ReplicationLagSeconds：如果ReplicationLagQuery提供，计算出的副本滞后；否则与SecondsBehindMaster
• Replicas：MySQL 副本主机名和端口列表）
• ClusterName：与该实例关联的集群的名称；唯一标识簇
• DataCenter：（元数据）数据中心的名称，由DataCenterPattern配置变量推断
• PhysicalEnvironment：（元数据）环境名称，由PhysicalEnvironmentPattern配置变量推断
• ReplicationDepth：与master的距离（master是0，直接副本是1等等）
• IsCoMaster：当此实例是主-主对的一部分时为 true
• IsLastCheckValid：最后一次尝试读取此瞬间是否成功
• IsUpToDate：该数据是否是最新的
• IsRecentlyChecked：最近是否对此实例进行了读取尝试
• SecondsSinceLastSeen：自上次成功访问此实例以来经过的时间
• CountMySQLSnapshots：已知快照数量（数据由 提供orchestrator-agent）
• IsCandidate：（元数据）true当该实例已通过CLI 命令标记为候选实例register-candidate时。可用于崩溃恢复以优先考虑故障转移选项
• UnresolvedHostname：此主机未解析的register-hostname-unresolve名称，如CLI 命令所示

API使用举例

• 获取有关集群的一般信息：

curl -s "http://my.orchestrator.service.com/api/cluster-info/my_cluster" | jq .

{
  "ClusterName": "my-cluster-fqdn:3306",
  "ClusterAlias": "my_cluster",
  "ClusterDomain": "my-cluster.com",
  "CountInstances": 10,
  "HeuristicLag": 0,
  "HasAutomatedMasterRecovery": true,
  "HasAutomatedIntermediateMasterRecovery": true
}

• 查找my_cluster没有二进制日志记录的主机：

curl -s "http://my.orchestrator.service.com/api/cluster/alias/my_cluster" | jq '.[] | select(.LogBinEnabled==false) .Key.Hostname' -r

• my_cluster找到的 master的直接副本：

curl -s "http://my.orchestrator.service.com/api/cluster/alias/my_cluster" | jq '.[] | select(.ReplicationDepth==1) .Key.Hostname' -r

或者：

master=$(curl -s "http://my.orchestrator.service.com/api/cluster-info/my_cluster" | jq '.ClusterName' | tr ':' '/')
curl -s "http://my.orchestrator.service.com/api/instance-replicas/${master}" | jq '.[] | .Key.Hostname' -r

• 查找所有中级大师my_cluster：

curl -s "http://my.orchestrator.service.com/api/cluster/alias/my_cluster" | jq '.[] | select(.MasterKey.Hostname!="") | select(.Replicas!=[]) .Key.Hostname'