orchestrator 文档

orchestrator 文档

[toc]

一、简介

orchestrator是MySQL高可用性和同步复制管理工具，可作为服务运行，并提供命令行访问、HTTP API和Web界面。

• 自动发现拓扑，并在 web 上展示
• 重构复制关系
• 检测主节点异常，故障恢复
• 支持命令行和 web 界面管理

二、安装部署

1. 通过 rpm 安装部署，在官网下载 rpm 安装包 链接

   rpm -ivh orchestrator-1.0-1.x86_64.rpm

1. 从压缩包安装，假设安装 orchestrator 安装在 /usr/local/orchestrator, 下载二进制压缩包

   cd /usr/local
   tar xzfv orchestrator-1.0.tar.gz

三、配置文件示例

{
  "Debug": true,
  "EnableSyslog": false,
  "ListenAddress": ":3000",
  "MySQLTopologyUser": "repl",
  "MySQLTopologyPassword": "repl@1qaz2WSX",
  "MySQLTopologyCredentialsConfigFile": "",
  "MySQLTopologySSLPrivateKeyFile": "",
  "MySQLTopologySSLCertFile": "",
  "MySQLTopologySSLCAFile": "",
  "MySQLTopologySSLSkipVerify": true,
  "MySQLTopologyUseMutualTLS": false,
  "MySQLOrchestratorCredentialsConfigFile": "",
  "MySQLOrchestratorSSLPrivateKeyFile": "",
  "MySQLOrchestratorSSLCertFile": "",
  "MySQLOrchestratorSSLCAFile": "",
  "MySQLOrchestratorSSLSkipVerify": true,
  "MySQLOrchestratorUseMutualTLS": false,
  "MySQLConnectTimeoutSeconds": 1,
  "DefaultInstancePort": 3306,
  "DiscoverByShowSlaveHosts": true,
  "InstancePollSeconds": 5,
  "DiscoveryIgnoreReplicaHostnameFilters": [
    "a_host_i_want_to_ignore[.]example[.]com",
    ".*[.]ignore_all_hosts_from_this_domain[.]example[.]com",
    "a_host_with_extra_port_i_want_to_ignore[.]example[.]com:3307"
  ],
  "UnseenInstanceForgetHours": 240,
  "SnapshotTopologiesIntervalHours": 0,
  "InstanceBulkOperationsWaitTimeoutSeconds": 10,
  "HostnameResolveMethod": "none",
  "MySQLHostnameResolveMethod": "",
  "SkipBinlogServerUnresolveCheck": true,
  "ExpiryHostnameResolvesMinutes": 60,
  "RejectHostnameResolvePattern": "",
  "ReasonableReplicationLagSeconds": 10,
  "ProblemIgnoreHostnameFilters": [],
  "VerifyReplicationFilters": false,
  "ReasonableMaintenanceReplicationLagSeconds": 20,
  "CandidateInstanceExpireMinutes": 60,
  "AuditLogFile": "",
  "AuditToSyslog": false,
  "RemoveTextFromHostnameDisplay": ".mydomain.com:3306",
  "ReadOnly": false,
  "AuthenticationMethod": "",
  "HTTPAuthUser": "",
  "HTTPAuthPassword": "",
  "AuthUserHeader": "",
  "PowerAuthUsers": [
    "*"
  ],
  "ClusterNameToAlias": {
    "127.0.0.1": "edoc2v5"
  },
  "ReplicationLagQuery": "",
  "DetectClusterAliasQuery": "SELECT SUBSTRING_INDEX(@@hostname, '.', 1)",
  "DetectClusterDomainQuery": "",
  "DetectInstanceAliasQuery": "",
  "DetectPromotionRuleQuery": "",
  "DataCenterPattern": "[.]([^.]+)[.][^.]+[.]mydomain[.]com",
  "PhysicalEnvironmentPattern": "[.]([^.]+[.][^.]+)[.]mydomain[.]com",
  "PromotionIgnoreHostnameFilters": [],
  "DetectSemiSyncEnforcedQuery": "",
  "ServeAgentsHttp": false,
  "AgentsServerPort": ":3001",
  "AgentsUseSSL": false,
  "AgentsUseMutualTLS": false,
  "AgentSSLSkipVerify": false,
  "AgentSSLPrivateKeyFile": "",
  "AgentSSLCertFile": "",
  "AgentSSLCAFile": "",
  "AgentSSLValidOUs": [],
  "UseSSL": false,
  "UseMutualTLS": false,
  "SSLSkipVerify": false,
  "SSLPrivateKeyFile": "",
  "SSLCertFile": "",
  "SSLCAFile": "",
  "SSLValidOUs": [],
  "URLPrefix": "",
  "StatusEndpoint": "/api/status",
  "StatusSimpleHealth": true,
  "StatusOUVerify": false,
  "AgentPollMinutes": 60,
  "UnseenAgentForgetHours": 6,
  "StaleSeedFailMinutes": 60,
  "SeedAcceptableBytesDiff": 8192,
  "PseudoGTIDPattern": "",
  "PseudoGTIDPatternIsFixedSubstring": false,
  "PseudoGTIDMonotonicHint": "asc:",
  "DetectPseudoGTIDQuery": "",
  "BinlogEventsChunkSize": 10000,
  "SkipBinlogEventsContaining": [],
  "ReduceReplicationAnalysisCount": true,
  "FailureDetectionPeriodBlockMinutes": 60,
  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": [
    "*"
  ],
  "RecoverIntermediateMasterClusterFilters": [
    "*"
  ],
  "OnFailureDetectionProcesses": [
    "echo 'Detected {failureType} on {failureCluster}. Affected replicas: {countSlaves}' >> /tmp/recovery.log"
  ],
  "PreGracefulTakeoverProcesses": [
    "echo 'Planned takeover about to take place on {failureCluster}. Master will switch to read_only' >> /tmp/recovery.log"
  ],
  "PreFailoverProcesses": [
    "echo 'Will recover from {failureType} on {failureCluster}' >> /tmp/recovery.log"
  ],
  "PostFailoverProcesses": [
    "echo '(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
  "PostUnsuccessfulFailoverProcesses": [],
  "PostMasterFailoverProcesses": [
    "echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Promoted: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
  "PostIntermediateMasterFailoverProcesses": [
    "echo 'Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}' >> /tmp/recovery.log"
  ],
  "PostGracefulTakeoverProcesses": [
    "echo 'Planned takeover complete' >> /tmp/recovery.log"
  ],
  "CoMasterRecoveryMustPromoteOtherCoMaster": true,
  "DetachLostSlavesAfterMasterFailover": true,
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "PreventCrossDataCenterMasterFailover": false,
  "PreventCrossRegionMasterFailover": false,
  "MasterFailoverDetachReplicaMasterHost": false,
  "MasterFailoverLostInstancesDowntimeMinutes": 0,
  "PostponeReplicaRecoveryOnLagMinutes": 0,
  "OSCIgnoreHostnameFilters": [],
  "GraphiteAddr": "",
  "GraphitePath": "",
  "GraphiteConvertHostnameDotsToUnderscores": true,
  "ConsulAddress": "",
  "ConsulAclToken": "",
  "AgentAutoDiscover": "true",
  "BackendDB": "sqlite3",
  "SQLite3DataFile": "/home/orc-data/orc-sqlite.db",
  "RaftEnabled": true,
  "RaftDataDir": "/home/orc-data/RaftData/orchestrator",
  "RaftBind": "192.168.251.154",
  "DefaultRaftPort": 10008,
  "RaftNodes": ["192.168.251.154", "192.168.251.96", "192.168.251.177"]
}

四、配置解释

配置一个三个节点的 orchestrator  集群

拓扑自动发现配置

为 orchestrator 授予所有要被监控的 MySQL 数据库访问权限

CREATE USER 'repl_user'@'orch_host' IDENTIFIED BY 'orch_topology_password';
GRANT SUPER, PROCESS, REPLICATION SLAVE, REPLICATION CLIENT, RELOAD ON *.* TO 'repl_user'@'orch_host';
GRANT SELECT ON mysql.slave_master_info TO 'repl_user'@'orch_host';
# 如果是 NDB cluster
GRANT SELECT ON ndbinfo.processes TO 'orchestrator'@'orc_host';
# 如果是 MGR/集群架构
GRANT SELECT ON performance_schema.replication_group_members TO 'orchestrator'@'orc_host';

配置文件配置

{
   “ MySQLTopologyUser ”：“ Orchestrator ”，
   “ MySQLTopologyPassword ”：“ orc_topology_password ”，
}

主机解析

配置解析被监控数据库集群方式

默认配置：

{
  "HostnameResolveMethod": "default",
  "MySQLHostnameResolveMethod": "@@hostname",
}

• “HostnameResolveMethod”: “cname” ：进行CNAME 解析
• “HostnameResolveMethod”: “default” ：没有通过网络协议的特殊解析
• “MySQLHostnameResolveMethod”: “@@hostname” ：通过数据库查询select @@hostname 进行解析
• “MySQLHostnameResolveMethod”: “@@report_host” ：通过数据库查询select @@report_host进行解析，需要数据库在配置文件中配置report_host
• “HostnameResolveMethod”: “none”和”MySQLHostnameResolveMethod”: “” : 什么解析都不用。适用于使用使用 IP 地址的设置。

orchestrator 后端数据库配置

1. 使用 MySQL 后端数据库

   注意：使用后端独立数据库，需要每台 orchestrator 节点有属于自己的后端数据库，不能互相同步，或者指定 orchestartor 库同步忽略）

配置数据库账号 （此账号是 orchestrator 用来操作数据库、记录集群状态用）

CREATE DATABASE IF NOT EXISTS orchestrator;
CREATE USER 'orchestrator'@'127.0.0.1' IDENTIFIED BY 'orch_backend_password';
GRANT ALL PRIVILEGES ON `orchestrator`.* TO 'orchestrator'@'127.0.0.1';

yum 安装的默认配置文件位置为/usr/local/orchestrator/orchestrator-sample.conf.json
拷贝配置文件到 /etc/orchestrator-sample.conf.json
编辑配置文件后端数据库配置部分

"MySQLOrchestratorHost": "127.0.0.1",
"MySQLOrchestratorPort": 3306,
"MySQLOrchestratorDatabase": "orchestrator",
"MySQLOrchestratorUser": "orchestrator",
"MySQLOrchestratorPassword": "orch_backend_password",

1. 使用SQLite 后端数据库

{
  "BackendDB": "sqlite",
  "SQLite3DataFile": "/var/lib/orchestrator/orchestrator.db",  
}

Orchestrator 嵌入的 SQLite 。需要有给定路径和文件的写权限。

Raft 配置

通过 raft 获得高可用性后端数据库。适用于 orchestrator 集群状态，保证一致性

单个 orchestrator 节点将作为主节点。只有主节点才能进行故障恢复。

所有节点可以做的事情：

• 发现（探测）集群
• 进行故障检测
• 自身状态检查

非主节点不能做的事情：

• 运行任何命令（例如：relocate 、begin-donwtime）
• 手动请求恢复
• 客户端 http 请求

orchestrator 节点新增/迁移，操作方式

1. 新增节点：
   如果 orchestrator 后端采用 sqlite 数据库，则不需要任何操作。只需要将改节点加入到 raft 集群中即可。
   如果采用 mysql 数据库，则需要配置好和其他后端数据库一样的数据库用户。

2. 更换节点：
   假设你的 raft 集群为：RaftNodes: ["node1", "node2", "node3"] , 需要替换node3 为node4

   • 踢出 node3 , 此时 node1 和 node2 都将继续工作
   • 在node1 和 node2 上修改配置为RaftNodes: ["node1", "node2", "node4"]
   • 启动 node4 的 orchestrator
   • 重启 node1 和 node2 的 orchestrator

故障检测

因为 orchestartor 的故障检测使用 MySQL 主从拓扑本身的状态作为信息源，所以有必要对数据库做一些设置

• set global slave_net_timeout = 4 配置副本与主机之间的心跳间隔。使副本可以快速识别故障。
• CHANGE MASTER TO MASTER_CONNECT_RETRY=1, MASTER_RETRY_COUNT=86400 如果复制失败，使副本每隔 1s 进行1次重新连接。可以避免因为偶尔的网络波动，而进行故障切换。

判断主机是否故障，需要满足2个条件 ：

• 访问不到主机
• 可以访问从机，并且从机也无法访问主机

当所有从机都无法访问主机，就可以断定主机故障，此时进行故障转移。

故障恢复

故障恢复类型：

• 自动恢复（意外故障自动采取措施）
• 手动计划切换
• 手动恢复
• 手动强制故障转移

要运行故障转移，数据库集群拓扑必须满足以下任一一种：

• 【推荐】配置了GTID (MASTER_AUTO_POSITION=1)
• 配置了 orchestrator 的伪GTID
• Binlog 服务器

不同的环境对故障恢复后需要做的操作也不同：

{
   “ ApplyMySQLPromotionAfterMasterFailover ”：true，
   “ PreventCrossDataCenterMasterFailover ”：false，
   “ PreventCrossRegionMasterFailover ”：false，
   “ FailMasterPromotionOnLagMinutes ”：0，
   “ FailMasterPromotionIfSQLThreadNotUpToDate ”：true，
   “ DelayMasterPromotionIfSQLThreadNotUpToDate ”：false，
   “MasterFailoverLostInstancesDowntimeMinutes “：10，
   “ DetachLostReplicasAfterMasterFailover ”：true，
   “ MasterFailoverDetachReplicaMasterHost ”：false，
   “ MasterFailoverLostInstancesDowntimeMinutes ”：0，
   “ PostponeReplicaRecoveryOnLagMinutes ”：0，
}

• ApplyMySQLPromotionAfterMasterFailover：默认值true。当此参数为 true , 将在提升的新主节点上执行reset slave all （清除所有同步信息） 和 set global read_only = 0 （关闭只读模式）。当参数为 true 时， 会覆盖MasterFailoverDetachSlaveMasterHost。

• PreventCrossDataCenterMasterFailover：默认值false。设置为 true 时，orchestrator 只会将故障的主服务器替换为来自同一个DC的服务器。如果找不到来自同一 DC 的可用替代服务器，则故障转移失败。

• PreventCrossRegionMasterFailover：默认值false。设置为 true 时，orchestrator 只会将故障的主服务器替换为来自同一个区域的服务器。如果找不到来自同一区域的可用替代服务器，则故障转移失败。

• FailMasterPromotionOnLagMinutes：默认值0（升级不失败）。如果要升级的从机延迟过大，则使故障转移失败。例如：从机故障了5个小时，然后主机故障。此时可能需要停止故障转移，需要恢复中间丢失的5个小时的同步数据丢失。要使用此配置，必须设置ReplicationLagQuery 和使用心跳检测机制，如pt-heartbeat 。复制中断时 ，MySQL 内置的show slave status 的 Seconds_behind_master ( 8.0之前的版本) 并不会报告复制延迟。

• FailMasterPromotionIfSQLThreadNotUpToDate：如果所有的从机都有复制延迟。即使最接近的从机也有没有应用的中继日志。此时故障切换执行reset slave all 会清除从机上的所有中继日志。

• DelayMasterPromotionIfSQLThreadNotUpToDate：如果所有的从机都有复制延迟。即使最接近的从机也有没有应用的中继日志。设置为 true 时，orchestrator 会等待SQL线程赶上，然后再进行故障转移，将次从机提升为主。
  FailMasterPromotionIfSQLThreadNotUpToDate和DelayMasterPromotionIfSQLThreadNotUpToDate是互相排斥的。

• DetachLostReplicasAfterMasterFailover：某些从机可能在恢复过程中发生故障。当此参数为 true 时，orchestrator 将通过deatch-replica 命令强行中断其复制 。

• MasterFailoverDetachReplicaMasterHost：当配置为 true 的时候，orchestrator 将在要升级为主的从机上执行detach-replica-master-host（这可以保证新的主机不会尝试继续同步之前旧的主机）。默认为 false。如果 ApplyMySQLPromotionAfterMasterFailover 为 true，则此参数无效。

• MasterFailoverLostInstancesDowntimeMinutes：主故障转移后丢失的任何服务器停机的分钟数（包括失败的主和丢失的从）。 0表示禁用。

• PostponeReplicaRecoveryOnLagMinutes：在崩溃恢复时，滞后超过给定分钟的副本仅在主/ IM被选出并执行进程后才在恢复过程的后期复活。 值为0将禁用此功能。

1. 自动恢复

自动恢复配置

{
  "RecoveryPeriodBlockSeconds": 3600,
  "RecoveryIgnoreHostnameFilters": [],
  "RecoverMasterClusterFilters": [
    "*"
  ],
  "RecoverIntermediateMasterClusterFilters": [
    "*"
  ],
}

此配置：

• Orchestrator 将自动恢复所有集群的中间节点故障
• Orchestrator 将自动恢复所有集群的主服务器故障。手动可以进行故障转移。
• 集群恢复后， orchestrator 将在 3600s 内阻止再次恢复。

2. 手动计划切换

出于升级、主机维护等目的，有时候希望一台从机能够替换主机，进行优雅的切换。本质上来说，是一次角色切换：旧的主机变为一个从机，旧的从机提升为一台新的主机。

通过以下几种方式进行takeover:

• 命令行：

  • orchestrator-client -c graceful-master-takeover -alias mycluster -d designated.master.to.promote:3306 指定要升级为主机的从机。orchestrator 不会在降级的主机上开始复制。
  • orchestrator-client -c graceful-master-takeover-auto -alias mycluster -d designated.master.to.promote:3306 指定要升级为主机的从机。orchestrator 会在降级的主机上开始复制。
  • orchestrator-client -c graceful-master-takeover-auto -alias mycluster 让 orchestrator 自动选择要提升的从机。在降级的主机上进行复制。

• Web API：

  • /api/graceful-master-takeover/:clusterHint/:designatedHost/:designatedPort 无缝地进行故障转移，指定一台要替换主机的从机。
  • /api/graceful-master-takeover/:clusterHint无缝地进行故障转移。不需要指定从服务器，仅在主库只有一台从机时生效 。
  • /api/graceful-master-takeover-auto/:clusterHint 无缝地进行故障转移。orchestrator 自动选择一台从机。在降级的主机上进行复制。
• Web 界面：直接将从机拖拽到主机的左侧即可进行无缝故障转移。不在降级的主服务器上进行同步。

3.手动恢复

当实例被 orchestrator 识别为失败，且禁止自动恢复时，使用此功能。

可以选择 orchestrator 提供的失败的实例来恢复错误。这个实例必须是被识别为失败的。

通过以下方式恢复：

• 命令行： orchestrator-client -c recover -i dead.instance.com:3306 --debug
• Web API：/api/recover/dead.instance.com/:3306
• Web：实例颜色为黑色；点击Recover按钮

手动恢复不会受到RecoveryPeriodBlockSeconds的阻碍，此操作还覆盖RecoverMasterClusterFilters和RecoverIntermediateMasterClusterFilters。

4. 手动强制转移

不管从机现在状态如何，强制主机立刻进行故障转移。

可能 orchestrator 未发现主机故障，或者 orchestrator 不确定现在的状况但是必须要立刻从集群中移出主机。

通过以下几种操作：

• 命令行：orchestrator-client -c force-master-failover --alias mycluster 或者
  orchestrator-client -c force-master-failover -i instance.in.that.cluster

• Web API：/api/force-master-failover/mycluster 或者/api/force-master-failover/instance.in.that.cluster/3306