---
title: "OMS 社区版高可用（HA）介绍 | OceanBase 文档中心"
description: OMS 社区版高可用（HA）介绍 OceanBase 迁移服务（OceanBase Migration Service，OMS）社区版的高可用模块（High Available，简称 HA）为数据传输链路的稳定性和连续性提供保障。当 OMS 社区版部署服务器发生单点故障或个别任务进程发生异常时，HA 能够及时发现、介…
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*L03BS6f-o40AAAAAAAAAAAAADiGDAQ/original) 迁移服务 OMSV 4.2.11 社区版

# OMS 社区版高可用（HA）介绍

更新时间：2026-04-14 15:36:11

[编辑](https://github.com/oceanbase/oms-doc/edit/V4.2.11/zh-CN/200.product-introduction/210.oms-ha-intro.md)  

OceanBase 迁移服务（OceanBase Migration Service，OMS）社区版的高可用模块（High Available，简称 HA）为数据传输链路的稳定性和连续性提供保障。当 OMS 社区版部署服务器发生单点故障或个别任务进程发生异常时，HA 能够及时发现、介入并尝试恢复。

## HA 容灾级别

| **容灾级别** | **是否支持** | **部署要求** | **描述** |
| --- | --- | --- | --- |
| **城市级容灾** | 不支持 | -- | 暂不支持。 |
| **机房级容灾** | 支持 | 单地域多节点   多地域多节点 | OMS 社区版在同一地域的机器需要做跨机房部署。当某一机房故障时，其余机房容量需要能够承接故障机房的所有任务。 |
| **机器级容灾** | 支持 | 单地域多节点   多地域多节点 | 您需要在多节点部署 OMS 社区版。如果您在多地域部署 OMS 社区版，则每一地域中至少需要两台机器。当单机发生故障时，同地域其他机器容量需要能够承接故障机器上的所有任务。 |
| **组件级容灾** | 支持 | 单地域单节点   单地域多节点   多地域多节点 | 对 OMS 社区版部署无要求，单地域单节点亦可。异常组件会通过重启和新建等方式尝试恢复。 |

#### 注意

容灾时资源调度的范围都在同地域内，允许跨机房，但不允许跨地域（就近读写原则）。

## HA 组件守护

OMS 社区版包含 4 个组件：

| 组件名称 | 组件用途 | 是否具备高可用能力 |
| --- | --- | --- |
| Store | 数据库增量日志采集 | 是 |
| Incr-Sync | 数据库增量同步写入 | 是 |
| Full-Import | 数据库全量数据导入 | 否 |
| Full-Verification | 数据库全量数据校验 | 否 |

## HA 触发场景

从 HA 的角度来看，机房级别的容灾和机器级别的容灾是相同的。机房容灾可以被解释为同时在多台机器上发生的容灾。因此，HA 只关注以下两种场景：

|  | **Store** | **Incr-Sync** | **Full-Import** | **Full-Verification** |
| --- | --- | --- | --- | --- |
| **机器宕机** | ✅ | ✅ | ❌ | ❌ |
| **组件异常** | ✅ | ✅ | ❌ | ❌ |

### 机器宕机

每台 OMS 社区版机器都运行着一个类似代理的组件 `oms_drc_supervisor`，该组件定时向 OMS 社区版元数据库报告心跳。如果 OMS 社区版后台巡检发现某台机器在较长一段时间内（超过了 `checkHostDownIntervalSec` 设定的时间间隔）未汇报心跳，则 OMS 社区版将该机器标记为宕机。

#### 宕机后 HA 行为

1. 查询宕机机器上 Incr-Sync 组件的任务列表，根据其状态分为 **运行中** 和其它两个子集合。
 2. 对于 **运行中** 的 Incr-Sync 组件，OMS 社区版将尝试终止其任务进程。但通常该操作无法成功。因为机器已经宕机，向其发送指令很可能无法成功传递。
 3. 为确保 Incr-Sync 组件注册信息的全局唯一性，无论该注册信息所对应的 Incr-Sync 组件是否正在运行，OMS 社区版将在同一地域的其他健康机器上重新构建步骤 1 中发现的所有 Incr-Sync 组件，并同时删除它们在宕机机器上的注册信息。
 4. 对于原状态是 **运行中** 的 Incr-Sync 组件，在新机器上启动。原来就不处于运行中的 Incr-Sync 组件，迁移至新机器后保持原状态不变。

#### 机器宕机的注意事项

- HA 迁移 Incr-Sync 组件时，会复制其所有配置。
 - 如果机器宕机并重新恢复，可能会观察到 Incr-Sync 双写目标端的情况。此外，由于 HA 迁移过程中已删除注册信息，因此在 OMS 社区版控制台中无法查询到宕机机器上的 Incr-Sync 进程。

### 组件异常

| **组件名称** | **是否支持 HA** | **异常判定条件** | **HA 行为逻辑** |
| --- | --- | --- | --- |
| Store | 支持 | 见下文。 | 见下文。 |
| Incr-Sync | 支持 | 组件状态异常。   启动中、运行中、已停止和迁移中都不算异常。 | 尝试重启 Incr-Sync 进程。重启后有 10 分钟的冷却时间，在此期间 HA 不会重复操作该组件。 |
| Full-Import | 不支持 | -- | -- |
| Full-Verification | 不支持 | -- | -- |

#### Store HA 逻辑说明

同一数据源下可能存在多个 Store 以供下游消费，因此 HA 的逻辑比较复杂。本节将详细说明 Store 的 HA逻辑。

对每个数据源，HA 将检查数据源下的 Store 的数量和状态，分为以下情况：

1. 如果 Store 数量为 0，HA 不会干预。
 2. 如果 Store 数量 >=1，但状态均为 **已停止**（用户手工操作停止），HA 不会干预。

   步骤 1 和步骤 2 通常是运维人员操作的结果，此时 HA 不新建 Store，以避免影响到日常操作 Store 的连贯性。如果是较大规模的运维动作，建议预先在 OMS 的系统配置中关闭 HA 守护开关，待变更完毕后再重新打开。
 3. 如果 Store 数量达到了上限（subtopicStoreNumberThreshold），HA 不会干预。

   过多的 Store 数量是导致 HA 失效最常见的原因之一。这种设计初衷是为了避免在某些极端情况下，HA 不断地创建 Store 任务，消耗机器资源。
 4. 如果没有任何一个 Store 处于 **运行中** 状态（正常工作且持续在心跳汇报），HA 将尝试新建 Store。
 5. 当 **运行中** 的 Store 持有的数据无法满足下游的消费需求时（例如，Store 仅存储过去 8 小时的数据，而下游消费需要从 10 小时前开始），且用户在 HA 配置中开启了感知下游消费位点的功能（perceiveStoreClientCheckpoint），HA 也将尝试重新创建新的 Store。

在 HA 新建 Store 时，需要决定新建的 Store 从何时开始抓取数据库日志，即确定 Store 的启动位点 `unix timestamp`。计算逻辑如下：

1. 如果 `perceiveStoreClientCheckpoint=false`，HA 不感知下游消费位点。

   新建 Store 的启动位点 = `${当前时间} - refetchStoreIntervalMin`
 2. 如果 `perceiveStoreClientCheckpoint=true`，HA 会首先查询所有消费下游的最早位点。

   新建 Store 的启动位点 = `${下游的最早消费位点} - refetchStoreIntervalMin`

#### 组件异常的注意事项

- OMS 社区版的迁移任务不支持 Store 共享，每个迁移任务会独立创建、管理、守护自己的 Store 进程。所以如果基于同一个数据库源标识创建了多个迁移任务，HA 会为每个任务独立守护其 Store 进程。
 - 同步任务支持 Store 共享，如果有多个同步任务的源端是同一个数据库实例，且开启了 Store 共享。HA 会为这些任务共通守护 Store。
 - 如果开启了 `perceiveStoreClientCheckpoint`，但是在 HA 执行的过程中没有发现任何下游，则无法获取下游的最小消费位点。在这种情况下，HA 将放弃操作。

## HA 运行配置

HA 运行时的行为依赖以下系统参数控制。您可以在 OMS 社区版控制台的 **系统管理 - 系统参数** 页面搜索 `ha.config` 查看和编辑以下参数：

| **范围** | **配置项** | **类型** | **默认值** | **说明** |
| --- | --- | --- | --- | --- |
| **全局控制** | enable | Boolean | false | HA 总开关。 |
| **全局控制** | checkRequestIntervalSec | Integer | 600 | HA 链路操作同一对象的最小时间间隔，可用来避免短时间内对同一对象重复发起大量容灾操作。 |
| **机器宕机** | enableHost | Boolean | false | 机器宕机 HA 开关。 |
| **机器宕机** | checkHostDownIntervalSec | Integer | 540 | 机器宕机的判定阈值，单位为秒。当一台机器超过此阈值未汇报心跳时，HA 会认为该机器宕机。 |
| **组件异常(Store)** | enableStore | Boolean | true | Store HA 开关。 |
| **组件异常(Store)** | checkModuleExceptionIntervalSec | Integer | 240 | Store 异常的判定阈值，单位秒。当一个 Store 超过这个时间都没有汇报心跳，HA 会认为该 Store 异常。 |
| **组件异常(Store)** | subtopicStoreNumberThreshold | Integer | 5 | 一个「任务-数据源」对上最多可以创建的 Store 数目。当 Store 数量达到这个数量时，OMS 社区版会放弃 HA。 |
| **组件异常(Store)** | refetchStoreIntervalMin | Integer | 30 | HA 新建 Store 组件时启动位点基于当前时间回退的分钟数。   **注意：** 当下游延时较大时，新建的 Store 组件将不能保证满足下游的消费要求。   例如，10:00 时 HA 发现一个 Store 组件异常，因此 HA 新建了 Store 组件，并从 9:30 开始消费数据库的增量日志。位点的计算逻辑是从当前时间 10:00 回退 30 分钟。 |
| **组件异常(Store)** | perceiveStoreClientCheckpoint | Boolean | false | 当此配置设置为 true 时，HA 会从下游最早的消费点开始创建新的 Store，并回退 refetchStoreIntervalMin 分钟，以确保新创建的 Store 能够满足所有下游消费的要求。   **例如，** 10:00 时 HA 发现了一个 Store 异常，此时下游消费到 9:40，HA 新建 Store 将从 9:10 开始消费数据库的增量日志。位点的计算逻辑是下游消费位点 9:40 回退 30 分钟。 |
| **组件异常(Store)** | clearAbnormalResourceHours | Integer | 72 | Store 状态异常，且已超过 72 小时未汇报心跳。HA 会尝试清理该 Store，以释放磁盘空间并降低因 Store 数量过多导致的 HA 限制。 |
| **组件异常(Incr-Sync)** | enableConnector | Boolean | true | Connector HA 开关。 |

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线