Recon

受众： 集群管理员

前置要求： 熟悉 Ozone 服务与 Linux 系统管理。

1. 概述

目的： 本指南提供更换 Ozone Recon 节点上故障磁盘的简明步骤。
Recon 磁盘故障的影响： Recon 磁盘故障会导致 Recon 服务停止工作。但是，由于 Recon 不处于数据 I/O 的关键路径上，因此该故障不会对 Ozone 集群的核心运行产生任何影响。客户端的读写操作将继续正常进行。Recon 磁盘上的所有数据都可以从 OM 和 SCM 完全重建。

note

与 OM 或 SCM 等关键服务不同，Recon 磁盘故障不会影响集群的核心运行。由于 Recon 不在数据 I/O 路径上，客户端的读写操作将继续正常进行。Recon 磁盘上存储的所有数据都可以从活跃的 OM 和 SCM 服务完全重建，因此磁盘更换是一项简单、低风险的操作，无需停机即可完成。

当 Recon 磁盘故障时，服务会停止工作；但在使用空目录重启后，Recon 会自动检测到缺失的数据库，并通过从 OM 主节点下载最新快照并与 SCM 同步来启动完整重建。这一自动恢复过程确保所有 Recon 数据库——包括 OM 快照数据库、SCM 快照数据库（若已启用）以及 Recon 自身的聚合分析数据库——无需人工干预即可全部重建。

Recon 数据库目录

Recon 使用了多个数据库目录，它们可能会受到磁盘故障的影响：

ozone.recon.db.dir：存储 Recon 的主 RocksDB 数据库，其中包含聚合数据和分析结果（ContainerKey 和 ContainerKeyCount 表）。该目录通常还包含用于存储 GlobalStats、FileCountBySize、ReconTaskStatus、ContainerHistory 和 UnhealthyContainers 表的 SQL 数据库（默认为 Derby）。
ozone.recon.om.db.dir：存储 OM 数据库快照的副本，Recon 将其作为命名空间的事实来源。
ozone.recon.scm.db.dirs：存储 SCM 数据库快照的副本（通过 ozone.recon.scm.snapshot.enabled 启用 SCM 快照时）。其中包含有关 Datanode、管道和容器的信息。

如果上述任何目录位于故障磁盘上，则需要将其恢复到替换磁盘。

2. 预检

开始之前，管理员应当：

确定故障磁盘： 使用系统工具（dmesg、smartctl 等）确认哪块磁盘发生故障及其挂载点。
确定 Recon 目录： 检查 ozone-site.xml，确认哪些 Recon 目录位于故障磁盘上。主要的配置属性包括：

ozone.recon.db.dir：存储 Recon 的主 RocksDB 数据库，其中包含聚合数据和分析结果。
- ozone.recon.om.db.dir：存储 OM 数据库快照的副本，Recon 将其作为命名空间的事实来源。
- ozone.recon.scm.db.dirs：存储 SCM 数据库快照的副本（如果启用了 SCM 快照）。
- ozone.recon.sql.db.jdbc.url：SQL 数据库的 JDBC URL（若未显式配置，默认为 jdbc:derby:${ozone.recon.db.dir}/ozone_recon_derby.db）。

准备替换磁盘： 物理安装一块新的、健康的磁盘。对其执行格式化，并挂载到与故障磁盘相同的路径。确保其属主和权限对于运行 Recon 进程的用户是正确的。Recon 元数据目录的默认权限为 750（可通过 ozone.recon.db.dirs.permissions 配置）。

3. 替换 Recon 磁盘的步骤

这是一个低风险的恢复过程，可以在不影响主 Ozone 集群任何正常运行的情况下执行。

停止 Recon 服务： 在 Recon 节点上停止 Recon 守护进程。Ozone 集群的其余部分将继续完全正常运行。
替换并配置磁盘： 物理更换硬件。将新的空白磁盘挂载到 ozone.recon.db.dir、ozone.recon.om.db.dir 和 ozone.recon.scm.db.dirs（如果已配置）中定义的路径。确保这些目录存在，并且其属主和权限对于运行 Recon 进程的用户是正确的。
重新启动 Recon 服务： 只需再次启动 Recon 守护进程即可。
监控自动重建过程：
- 在空目录启动后，Recon 将自动开始重建其状态。
- 检查 Recon 日志文件（.log 和 .out）。你会看到它正在连接活动的 OM 和 SCM 的消息。
OM 快照下载：
- Recon 会检测到其 OM 数据库为空（通过检查序列号，该序列号将为 0 或负数）。
- 当序列号小于或等于 0 时，Recon 会自动触发从 OM Leader 下载完整快照。
- 这是整个过程中最耗时的部分。Recon 将下载 tar 格式的快照、解压它，并开始处理以填充其自身的命名空间数据库。
- 你会看到类似如下的日志消息：
```
Seq number of Recon's OM DB : 0
Fetching full snapshot from Ozone Manager
Obtaining full snapshot from Ozone Manager
```
- 快照通过 HTTP 从 OM Leader 下载，解压后的快照存储在 ozone.recon.om.db.dir 目录中。
SCM 同步：

Recon 还会连接到 SCM，以同步有关数据节点、管道和容器的信息。
如果启用了 SCM 快照（ozone.recon.scm.snapshot.enabled=true，此为默认值），Recon 将初始化或下载 SCM 数据库快照。
如果禁用了 SCM 快照，Recon 将通过 RPC 调用直接从 SCM 初始化管道信息。
SCM 同步会定期执行（默认间隔：24 小时），也会在初始启动时执行。

Recon 数据库重建：

OM 快照下载并处理完成后，Recon 的任务框架将自动处理元数据以重建：
- ContainerKey 和 ContainerKeyCount 表（存储在 ozone.recon.db.dir 位置的 RocksDB 中）
- GlobalStats、FileCountBySize 等 SQL 表（存储在 SQL 数据库中）
- 命名空间摘要信息
此处理过程是异步进行的，根据集群元数据的大小，可能需要额外的时间。

验证：
- 初始数据的导入和处理可能需要相当长的时间，具体取决于集群元数据的大小。
- 在此期间，Recon Web UI 可以访问，但显示的数据可能不完整或仍在加载中。
- 监控 Recon 日志以查找完成消息。请关注以下内容：
  - 快照下载并安装成功
  - 各项 Recon 任务的完成消息（NSSummaryTask、ContainerKeyMapperTask 等）
  - 表示同步进度的序列号更新
- 处理完成后，浏览 Recon UI，验证仪表板是否正确显示集群健康状况、容器信息，并确认可以浏览命名空间。
- 您也可以检查 Recon 指标端点，以确认同步操作已成功完成。

4. 其他注意事项

4.1 无数据丢失风险

此过程不会对您实际存储的对象造成任何数据丢失风险。
Recon 磁盘上的所有数据都是次要数据，可以重新构建。
Recon 服务设计为能够从空数据库或缺失的数据库中自动恢复，方法是从 OM 和 SCM 获取最新快照。

4.2 重建期间的性能影响

初始 OM 数据库快照的下载和处理可能会消耗大量资源（CPU、网络、磁盘 I/O），对 Recon 节点和 OM 主节点均有影响。
如果集群负载非常繁重，建议在非高峰时段执行此操作，以尽量减少对 OM 的性能影响。
首次同步前的默认初始延迟为 1 分钟（可通过 ozone.recon.om.snapshot.task.initial.delay 配置）。

4.3 SCM 快照配置

默认情况下，SCM 快照处于启用状态（ozone.recon.scm.snapshot.enabled=true）。
如果您禁用了 SCM 快照，Recon 仍会从 SCM 同步容器和管道信息，但将通过 RPC 调用而非下载数据库快照来完成。
在这两种情况下，恢复过程保持一致。

4.4 磁盘监控

与所有服务一样，积极监控磁盘健康状况是一项良好的实践，可主动管理硬件故障，避免 Recon 服务出现意外中断。
建议为磁盘空间使用率和磁盘健康指标设置监控告警。