---
title: "自动跟随重试轮询间隔配置"
date: 2026-01-02
lastmod: 2026-01-02
description: "plugins.replication.autofollow.retry_poll_interval 配置项用于控制自动跟随任务重试失败索引的轮询间隔时间。"
tags: ["Replication", "跨集群复制", "自动跟随", "重试机制"]
summary: "配置项作用 #  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."
---


## 配置项作用

`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. 自动重试复制


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

## 配置建议

## 生产环境（默认）

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

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

## 快速恢复场景

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

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

## 低频重试场景

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

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

## 测试环境

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

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

## 代码示例

## easysearch.yml 基础配置

```yaml
plugins:
  replication:
    autofollow:
      retry_poll_interval: 30m
```

## 完整自动跟随配置

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

## 快速恢复配置

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

## 动态更新配置

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

## 查看重试状态

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

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

## 相关配置

| 配置项 | 作用 | 默认值 |
|--------|------|--------|
| `retry_poll_interval` | 重试轮询间隔 | 30m |
| `fetch_poll_interval` | 正常轮询间隔 | 30s |
| `concurrent_replication_jobs_trigger_size` | 批量触发大小 | 3 |

## 使用场景

## 推荐使用默认值的场景

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

## 推荐减少间隔的场景

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

## 推荐增加间隔的场景

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

## 性能影响分析

| retry_poll_interval 设置 | 优点 | 缺点 |
|------------------------|------|------|
| 5m | 快速恢复 | 频繁重试 |
| 30m（默认） | 平衡恢复和负载 | - |
| 2h | 减少重试开销 | 恢复慢 |

## 恢复时间对比

```
恢复时间对比分析

错误发生时间: 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


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