orchestraror使用下篇

最新推荐文章于 2025-03-03 18:09:13 发布

原创

最新推荐文章于 2025-03-03 18:09:13 发布 · 1.7k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #服务器 #数据库 #orchestrator #高可用

本文深入探讨了Orchestrator的故障检测机制，包括配置细节如FailureDetectionPeriodBlockMinutes和MySQL相关配置。Orchestrator通过连接失败、从库验证等方式判断主库故障，并在故障恢复时执行预定义的Hook脚本。同时，文章介绍了多种故障恢复策略和API命令，如自动故障恢复、优雅故障恢复和手动故障恢复。此外，还讨论了Orchestrator的Hook功能，允许在不同阶段执行自定义脚本。

概述

在之前，比较笼统的讲述了Orchestrator的大概部署与用法，本篇则详细描述Orchestrator的Hook、API命令的使用。还有其他部署过程中需要注意的点。
如果对Orchestrator还不太了解，可以参考：《 MySQL中间件:Orchestrator上篇》

配置细化

在说明Hook之前，要先了解Orchestrator是如何做故障检测的，以及是如何进行故障恢复的。

需要的配置

Orchestrator配置文件中的配置有一项：

{
   
   
   “ FailureDetectionPeriodBlockMinutes ”：60，
}
Orchestrator每秒探测一次。具体如何探测，下面会说。
FailureDetectionPeriodBlockMinutes：反垃圾邮件机制，阻止同一检测消息的重复发送

MySQL配置：
Orchestrator使用整体探测方式来检测是否故障，从而进行故障转移。
由于Orchestrator使用到MySQL本身的复制语句作为信息源，所以，需要在做主从复制的时候要配置网络心跳间隔和复制重试的相关参数，如下：

1、设置主从心跳超时时间：
set global slave_net_timeout = 4
如果在slave_net_timeout秒内没有收到来自master的任何数据，那么就会认为连接断开，进行重新连接。
2、设置重连次数与上限：
CHANGE MASTER TO MASTER_CONNECT_RETRY=1, MASTER_RETRY_COUNT=86400;
和上面的slave_net_timeout参数相关，如果slave_net_timeout秒内没有接收数据，那么会在MASTER_CONNECT_RETRY秒进行重新连接，直到MASTER_RETRY_COUNT上限制。

与传统探测机制的对比

对于一般探测的方式，一般的做法都是侦测主服务器，当无法查询或联系到主服务器时，发出警报，但是这种方式非常容易受到网络波动的影响。
由于上述方式容易受到网络波动，后来又增加了对服务器多次侦测和增加时间间隔，虽然减少了误报，但是增加了真正故障响应的时间。
Orchestrator解决了这些问题。它会在以下情况认为主机失效，要进行故障恢复：
1、连接master失败，无法连接到master，那么就判定master宕机。
2、能够连接到slave，并且在所有的slave上确认无法连接或检测到master主机，那么就判定master宕机。
从逻辑上来说，主连接不上之后，再去连接从库，在从库上去侦测主库，如果主库还是连接不上，那么断定主库宕机，然后进行故障恢复，是非常合理的。
对于一些特殊情况，Orchestrator并不会进行故障恢复：

在配置文件没有列出，或者没有配置故障恢复的集群
手动指定故障恢复不在特定的服务器上执行
手动禁用全局故障恢复设置
集群在不久前刚进行过故障恢复，在RecoveryPeriodBlockSeconds时间内
故障类型被认为是不值得故障恢复的(Orchestrator内置了非常多的故障策略，下面会细说)

Orchestrator中，探测和故障恢复两者没有关联，并且每秒都会进行一次探测，并且每次都会执行OnFailureDetectionProcesses钩子函数中的脚本。

故障恢复配置

Orchestrator故障恢复需要以下前提：
1、MySQL GTID(MASTER_AUTO_POSITION=1)
2、MariaDB GTID(logbin和log_slave_updates启用)
3、Pseudo GTID(logbin和log_slave_updates启用，并行复制设置slave_preserve_commit_order=1)
4、开启binlog日志(logbin和log_slave_updates启用)
有关故障恢复的配置如下：

{
   
   
   “ RecoveryPeriodBlockSeconds ”：3600，   --恢复后多少秒之内防止再次故障恢复
   “ RecoveryIgnoreHostnameFilters ”：[]，
   “ RecoverMasterClusterFilters ”：[      --要恢复集群的名称，也就是meta.cluster表中的集群名称
     “ thiscluster ”，
     “ thatcluster ”
  ]，
  “ RecoverIntermediateMasterClusterFilters ”：[    --恢复所有的集群
     “ * ”
  ]，
}
---
{
   
   
  "ApplyMySQLPromotionAfterMasterFailover": true,   --当为true时，Orchestrator将会在新的master上执行：reset slave all 和 set read_only=0两条命令
  "PreventCrossDataCenterMasterFailover": false,    --默认false，当为true时，Orchestrator只会使用同一个DC下的服务器进行恢复。如果在同一DC中找不到，那么恢复就会失败
  "PreventCrossRegionMasterFailover": false,       --默认false，当为true时，Orchestrator将会在同一区域内的服务器上进行故障恢复，如果找不到，那么恢复就会失败
  "FailMasterPromotionOnLagMinutes": 0,        
  "FailMasterPromotionIfSQLThreadNotUpToDate": true,   --如果所有从库都有延迟，那么提升的从库可能有未应用的中继日志，如果发出reset slave all语句，那么可能会丢失部分数据
  "DelayMasterPromotionIfSQLThreadNotUpToDate": false,   --当为true时，如果所有从库都有延迟，那么Orchestrator会等待SQL线程应用完毕，再提升新主
  "DetachLostReplicasAfterMasterFailover": true,