自动跟随重试轮询间隔配置

配置项作用 #

plugins.replication.autofollow.retry_poll_interval 配置项用于控制自动跟随任务重试失败索引的轮询间隔时间。

在跨集群复制（CCR）的自动跟随模式下，当复制操作失败时，失败的索引会被记录。此配置决定了系统需要等待多长时间后，才会清除失败记录并重新尝试复制这些索引。

配置项属性 #

• 配置路径: plugins.replication.autofollow.retry_poll_interval
• 数据类型: TimeValue（时间值，如 30m, 1h, 2h）
• 默认值: 30m（30分钟）
• 是否可选: 是（有默认值）
• 作用域: NodeScope（节点级别）
• 动态更新: 是（可以动态更新，无需重启）

配置项详解 #

工作机制 #

重试轮询机制

正常复制流程:
1. 检测新索引 (fetch_poll_interval: 30s)
   └── 匹配自动跟随模式
   ↓
2. 启动复制
   ├── 成功 → 完成 ✅
   └── 失败 → 记录到失败列表 ❌


重试流程:
1. 等待重试间隔
   delay(retry_poll_interval)
   ↓
2. 清除失败记录
   └── 从失败列表移除
   ↓
3. 下次正常检查时
   └── 重新尝试复制


retry_poll_interval = 30m (默认):
├── 30 分钟后清除失败记录
├── 平衡重试频率和负载
└── 适合大多数场景 ✅


retry_poll_interval = 5m (快速):
├── 5 分钟后重试
├── 更快恢复
└── 更多重试开销


retry_poll_interval = 2h (慢速):
├── 2 小时后重试
├── 减少重试频率
└── 更慢恢复

失败处理流程 #

完整的失败处理流程

场景: 索引 logs-2026-01-01 复制失败

时间线:
0s  ─── 复制失败
       └── 记录到失败列表
       └── 原因: Leader 索引不存在


30s ─── 正常检查
       └── 发现 logs-2026-01-02
       └── logs-2026-01-01 跳过 (在失败列表)


30m ─── 重试间隔到达
       └── 清除失败记录
       └── logs-2026-01-01 不再被跳过


30m30s ─── 正常检查
         └── 发现 logs-2026-01-01
         └── 重新尝试复制
         └── 成功 ✅


效果:
├── 避免频繁重试失败操作
├── 给予问题恢复时间
└── 最终自动恢复

与正常轮询的区别 #

fetch vs retry 轮询

fetch_poll_interval (正常轮询):
├── 频率: 高 (30s)
├── 目的: 检测新索引
├── 跳过: 失败列表中的索引
└── 启动: 新索引的复制


retry_poll_interval (重试轮询):
├── 频率: 低 (30m)
├── 目的: 清除失败记录
├── 清除: 过期的失败记录
└── 允许: 重新尝试复制


配合工作:
1. 正常轮询持续检测新索引
2. 跳过失败的索引
3. 重试轮询定期清除失败记录
4. 清除后的索引重新被检测
5. 自动重试复制


优势:
├── 避免频繁重试 ✅
├── 减少错误日志
├── 自动恢复机制
└── 节省系统资源

配置建议 #

生产环境（默认） #

plugins:
  replication:
    autofollow:
      retry_poll_interval: 30m  # 默认值

建议: 保持默认值 30m。平衡重试频率和负载。

快速恢复场景 #

plugins:
  replication:
    autofollow:
      retry_poll_interval: 5m  # 快速重试

建议: 临时性错误较多时使用，加快恢复速度。

低频重试场景 #

plugins:
  replication:
    autofollow:
      retry_poll_interval: 2h  # 降低重试频率

建议: 持久性错误或减少系统负载时使用。

测试环境 #

plugins:
  replication:
    autofollow:
      retry_poll_interval: 1m  # 快速验证重试

建议: 测试环境使用短间隔便于验证。

代码示例 #

easysearch.yml 基础配置 #

plugins:
  replication:
    autofollow:
      retry_poll_interval: 30m

完整自动跟随配置 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 30s
      retry_poll_interval: 30m
      concurrent_replication_jobs_trigger_size: 3

快速恢复配置 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 10s
      retry_poll_interval: 5m

动态更新配置 #

// 运行时更新
PUT /_cluster/settings
{
  "persistent": {
    "plugins.replication.autofollow.retry_poll_interval": "1h"
  }
}

查看重试状态 #

// 查看自动跟随模式状态
GET /_replication/autofollow_patterns

// 查看复制状态
GET /_replication/leader_cluster_name/logs-*/_status

相关配置 #

使用场景 #

推荐使用默认值的场景 #

• 标准部署: 大多数生产环境
• 临时性错误: 错误通常在较短时间内恢复
• 平衡要求: 需要平衡重试频率和负载

推荐减少间隔的场景 #

• 快速恢复: 需要尽快重试失败的复制
• 临时网络问题: 网络不稳定但恢复快
• 测试验证: 需要快速验证重试机制

推荐增加间隔的场景 #

• 持久性错误: 错误需要人工干预修复
• 减少负载: 减少不必要的重试尝试
• 资源限制: 系统资源有限

性能影响分析 #

恢复时间对比 #

恢复时间对比分析

错误发生时间: T0
错误修复时间: T0 + 10m


间隔 = 5m:
├── 第一次重试: T0 + 5m (仍未修复)
├── 第二次重试: T0 + 10m (已修复) ✅
└── 总恢复时间: 10m


间隔 = 30m (默认):
├── 第一次重试: T0 + 30m (已修复) ✅
├── 总恢复时间: 30m
└── 浪费了 20m


间隔 = 2h:
├── 第一次重试: T0 + 2h (早已修复)
├── 总恢复时间: 2h
└── 浪费了 1h50m


策略选择:
├── 快速修复 (10m内) → retry: 5m
├── 慢速修复 (30m内) → retry: 30m (默认) ✅
└── 人工修复 (小时级) → retry: 2h

常见错误类型 #

常见错误类型及建议重试间隔

1. 临时性错误
   ├── 网络超时
   ├── 连接重置
   ├── Leader 暂时不可用
   └── 建议: 5m - 15m


2. 资源问题
   ├── Leader 磁盘满
   ├── Follower 磁盘满
   ├── 内存不足
   └── 建议: 30m - 1h


3. 配置问题
   ├── 索引不存在
   ├── 权限问题
   ├── 设置冲突
   └── 建议: 1h - 2h (或手动修复)


4. 持久性错误
   ├── 数据损坏
   ├── 版本不兼容
   ├── 架构问题
   └── 建议: 2h+ (或禁用自动重试)

注意事项 #

1. 默认值: 默认值为 30m，适合大多数场景。

2. 动态更新: 可以动态更新，无需重启。

3. 重试频率: 减少间隔会增加重试频率。

4. 恢复时间: 间隔时间直接影响恢复速度。

5. 错误类型: 应根据错误类型调整间隔。

6. 与 fetch 配合: 通常应远大于 fetch_poll_interval。

7. 日志监控: 应监控重试日志确认效果。

8. 持久性错误: 持久性错误不会自动恢复。

9. 手动干预: 某些错误需要手动修复。

10. 测试验证: 调整后应验证重试行为。

故障排查 #

常见问题排查

问题 1: 复制失败后长时间未恢复

检查:
├── retry_poll_interval 设置
├── 错误类型
├── 问题是否已修复
└── 复制任务日志


解决:
├── 减少 retry_poll_interval
├── 修复根本问题
├── 手动触发复制
└── 检查配置


问题 2: 频繁重试浪费资源

检查:
├── retry_poll_interval 设置
├── 错误是否可自动恢复
└── 重试日志


解决:
├── 增加 retry_poll_interval
├── 修复根本问题
├── 暂停自动跟随
└── 或禁用特定模式


问题 3: 复制成功但仍在失败列表

检查:
├── 复制状态 API
├── 自动跟随任务状态
└── 重试触发时间


解决:
├── 等待重试间隔到达
├── 手动清除失败记录
├── 重启自动跟随任务
└── 或更新配置

最佳实践 #

配置最佳实践

1. 标准部署
   plugins:
     replication:
       autofollow:
         retry_poll_interval: 30m

   ├── 默认值
   ├── 适合大多数错误
   └── 推荐 ✅


2. 网络不稳定环境
   plugins:
     replication:
       autofollow:
         retry_poll_interval: 10m

   ├── 快速重试
   ├── 应对临时故障
   └── 监控成功率


3. 可靠性优先
   plugins:
     replication:
       autofollow:
         retry_poll_interval: 5m
         fetch_poll_interval: 10s

   ├── 最小化恢复时间
   ├── 接受更多开销
   └── 关键业务适用


4. 资源受限
   plugins:
     replication:
       autofollow:
         retry_poll_interval: 2h

   ├── 减少重试频率
   ├── 节省资源
   └── 需要监控


5. 分层重试策略
   ├── 快速重试临时错误
   ├── 慢速重试持久错误
   ├── 监控和告警
   └── 手动介入机制

与正常轮询的比例建议 #

fetch 和 retry 间隔比例

推荐比例:
retry_interval / fetch_interval >= 60


示例配置:
方案 1 (标准):
├── fetch: 30s
├── retry: 30m
└── 比例: 60:1 ✅


方案 2 (快速):
├── fetch: 10s
├── retry: 5m
└── 比例: 30:1


方案 3 (保守):
├── fetch: 1m
├── retry: 2h
└── 比例: 120:1


原因:
├── 避免频繁重试
├── 给予恢复时间
├── 减少系统负载
└── 提高重试成功率