自动跟随获取轮询间隔配置

配置项作用 #

plugins.replication.autofollow.fetch_poll_interval 配置项用于控制自动跟随任务轮询远程（Leader）集群检查新索引的间隔时间。

在跨集群复制（CCR）的自动跟随模式下，Follower 集群需要定期检查 Leader 集群是否有匹配自动跟随模式的新索引被创建。此配置决定了检查的频率。

配置项属性 #

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

配置项详解 #

工作机制 #

自动跟随轮询机制

自动跟随任务循环:
1. 等待轮询间隔
   delay(fetch_poll_interval)
   ↓
2. 轮询 Leader 集群
   ├── 获取所有索引列表
   └── 匹配自动跟随模式
   ↓
3. 过滤已存在索引
   ├── 忽略已复制的索引
   └── 忽略失败的索引
   ↓
4. 启动新索引的复制
   └── 批量处理新索引
   ↓
5. 返回步骤 1


fetch_poll_interval = 30s (默认):
├── 每 30 秒检查一次
├── 平衡负载和延迟
└── 适合大多数场景 ✅


fetch_poll_interval = 5s (快速):
├── 每 5 秒检查一次
├── 更快检测新索引
└── 更高 Leader 集群负载


fetch_poll_interval = 5m (慢速):
├── 每 5 分钟检查一次
├── 降低 Leader 集群负载
└── 更高的复制延迟

自动跟随流程 #

完整的自动跟随流程

配置自动跟随模式:
PUT _replication/autofollow_patterns/my-pattern
{
  "leader_alias": "leader-cluster",
  "pattern": "logs-*",
  "settings": {...}
}


自动跟随任务执行:
时间线:
0s  ─── 初始检查
       └── 发现: logs-2026-01-01
       └── 启动复制 ✅


30s ─── 第二次检查
       └── 发现: logs-2026-01-02
       └── 启动复制 ✅


60s ─── 第三次检查
       └── 无新索引
       └── 继续等待


90s ─── 第四次检查
       └── 发现: logs-2026-01-03
       └── 启动复制 ✅


效果:
├── 新索引在 30 秒内被检测
├── 自动启动复制
└── 无需手动干预

负载影响 #

轮询间隔对集群的影响

短间隔 (5s):
Leader 集群:
├── 频繁的索引列表请求
├── CPU 使用: 高
├── 网络流量: 高
└── 可能影响性能 ❌


Follower 集群:
├── 更快检测新索引
├── 复制延迟: 低 ✅
└── 网络开销: 高


长间隔 (5m):
Leader 集群:
├── 较少的索引列表请求
├── CPU 使用: 低 ✅
├── 网络流量: 低 ✅
└── 性能影响小


Follower 集群:
├── 较慢检测新索引
├── 复制延迟: 高 ❌
└── 网络开销: 低

配置建议 #

生产环境（默认） #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 30s  # 默认值

建议: 保持默认值 30s。平衡延迟和负载。

低延迟需求 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 5s  # 快速检测

建议: 需要快速复制新索引时使用。注意 Leader 集群负载。

高负载环境 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 5m  # 降低轮询频率

建议: Leader 集群负载高时增加间隔。

测试环境 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 10s  # 快速验证

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

代码示例 #

easysearch.yml 基础配置 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 30s

低延迟配置 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 5s
      concurrent_replication_jobs_trigger_size: 1

节省资源配置 #

plugins:
  replication:
    autofollow:
      fetch_poll_interval: 5m
      concurrent_replication_jobs_trigger_size: 10

动态更新配置 #

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

完整自动跟随配置 #

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

相关配置 #

使用场景 #

推荐使用默认值的场景 #

• 标准部署: 大多数生产环境
• 中等复制需求: 每分钟几个到几十个新索引
• 平衡要求: 需要平衡延迟和负载

推荐减少间隔的场景 #

• 实时复制: 需要尽快复制新索引
• 关键数据: 新索引包含重要数据
• 测试验证: 需要快速验证复制功能

推荐增加间隔的场景 #

• 高负载 Leader: Leader 集群负载已很高
• 低频创建: 新索引创建频率低
• 节省资源: 减少 Leader 集群的请求负载

性能影响分析 #

复制延迟对比 #

复制延迟对比分析

新索引创建时间: T0


间隔 = 5s:
├── 最早检测: T0 + 5s
├── 最晚检测: T0 + 10s
├── 平均延迟: 7.5s ✅
└── Leader 负载: 高


间隔 = 30s (默认):
├── 最早检测: T0 + 30s
├── 最晚检测: T0 + 60s
├── 平均延迟: 45s
└── Leader 负载: 适中 ✅


间隔 = 5m:
├── 最早检测: T0 + 5m
├── 最晚检测: T0 + 10m
├── 平均延迟: 7.5m ❌
└── Leader 负载: 低


计算公式:
平均延迟 = fetch_poll_interval × 1.5


推荐选择:
├── 秒级延迟 → 5s
├── 分钟级延迟 → 30s (默认) ✅
└── 十分钟级延迟 → 5m

注意事项 #

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

2. 动态更新: 可以动态更新，立即生效。

3. Leader 负载: 减少间隔会增加 Leader 集群负载。

4. 复制延迟: 间隔时间直接影响复制延迟。

5. 网络开销: 频繁轮询会产生更多网络流量。

6. 模式匹配: 只处理匹配自动跟随模式的索引。

7. 失败索引: 失败的索引不会在正常轮询中重试。

8. 配合重试: 应与 retry_poll_interval 配合配置。

9. 监控建议: 监控复制延迟和 Leader 集群负载。

10. 测试验证: 调整后应验证对集群的影响。

故障排查 #

常见问题排查

问题 1: 新索引复制延迟

检查:
├── fetch_poll_interval 设置
├── Leader 集群响应时间
└── 网络连接状态


解决:
├── 减少 fetch_poll_interval
├── 检查 Leader 集群健康
├── 优化网络
└── 监控自动跟随任务


问题 2: Leader 集群负载过高

检查:
├── 轮询频率
├── 自动跟随模式数量
└── 索引数量


解决:
├── 增加 fetch_poll_interval
├── 合并自动跟随模式
├── 优化模式匹配
└── 添加更多协调节点


问题 3: 某些索引未复制

检查:
├── 自动跟随模式配置
├── 索引是否匹配模式
└── 自动跟随任务日志


解决:
├── 验证模式配置
├── 检查索引命名
├── 查看任务状态
└── 必要时手动复制

最佳实践 #

配置最佳实践

1. 标准部署
   plugins:
     replication:
       autofollow:
         fetch_poll_interval: 30s

   ├── 默认值
   ├── 平衡性能
   └── 推荐 ✅


2. 实时场景
   plugins:
     replication:
       autofollow:
         fetch_poll_interval: 5s

   ├── 快速检测
   ├── 低延迟
   └── 监控负载


3. 节省资源
   plugins:
     replication:
       autofollow:
         fetch_poll_interval: 5m

   ├── 减少 Leader 负载
   ├── 降低网络开销
   └── 接受更高延迟


4. 分时段配置
   高峰期:
   fetch_poll_interval: 5m

   低峰期:
   fetch_poll_interval: 10s

   ├── 动态调整
   ├── 优化资源使用
   └── 按需配置


5. 配合其他配置
   ├── retry_poll_interval
   ├── trigger_size
   ├── 复制并发限制
   └── 综合优化

与重试间隔的配合 #

fetch 和 retry 间隔的配合

正常流程:
fetch_poll_interval: 30s
    │
    ├── 每 30 秒检查新索引
    ├── 发现新索引 → 启动复制
    └── 忽略失败索引


重试流程:
retry_poll_interval: 30m
    │
    ├── 每 30 分钟重试失败索引
    ├── 清除失败记录
    └── 重新尝试复制


推荐配置:
├── 正常轮询: 30s - 5m
├── 重试轮询: 10m - 1h
├── 重试间隔 >> 正常间隔
└── 避免频繁重试 ✅