数据同步与运维

数据同步模式

Elasticsearch 常作为业务数据库的派生索引。同步方式决定延迟、完整性和恢复成本。

方式	优点	局限
应用双写	延迟低、实现直观	两次写入难以原子提交，失败补偿复杂
Outbox + 消息队列	与业务事务结合，易重试和审计	需要发布器、消费者及幂等设计
CDC	对业务代码侵入小，可捕获更新和删除	依赖数据库日志与连接器运维
Logstash JDBC 轮询	上手简单，适合批量导入	删除难捕获，时间戳边界和全量恢复需额外设计
离线批处理	适合首次建索引和周期重建	实时性较低

数据同步至少要定义：稳定文档 ID、顺序策略、幂等写入、删除事件、失败重试、积压监控和全量重建流程。只同步 update_time > :sql_last_value 时，要处理相同时间戳、事务提交顺序及数据库时钟精度造成的边界遗漏。

零停机重建索引

Mapping 或分析器发生不兼容变更时，采用版本化索引与 Alias：

1. 创建带新 Mapping 的 articles-v2。
2. 从事实数据源全量写入，并持续追平增量事件。
3. 校验文档数量、抽样内容和关键查询。
4. 原子切换读写 Alias。
5. 观察稳定后再按保留策略删除旧索引。

日志数据生命周期

日志是只追加的时间序列数据，优先使用 Data Stream；普通业务搜索索引则不必强行使用。生命周期治理需要同时考虑：

• Rollover：按分片大小、文档量或时间切换写入索引。
• 数据层：热数据承载频繁写入与查询，温/冷层降低长期保存成本。
• Retention：按合规与排障窗口删除过期数据。
• Snapshot：备份到独立对象存储，副本不能替代备份。

不要机械地每天创建一个索引。低流量场景会形成大量小分片，高流量场景又可能让单日分片过大，应根据实际写入量设置 Rollover。

容量与监控

重点观察：

• 集群健康、未分配分片和分片恢复进度。
• JVM Heap、GC、CPU、磁盘使用率和磁盘水位。
• Indexing/Search 延迟、拒绝数、Refresh 与 Merge 开销。
• 单分片大小、分片总数、字段数量和高基数字段。
• Snapshot 成功率与恢复演练结果。

容量估算不能只计算原始日志大小，还要包含 _source、倒排索引、Doc Values、副本、Segment Merge 临时空间和安全余量。压测应使用接近真实字段分布、查询组合及保留周期的数据。

常见问题

现象	优先检查
集群 Yellow	副本未分配、节点数与 Allocation 规则
集群 Red	主分片未分配、磁盘或节点故障、恢复来源
写入被拒绝	线程池、下游磁盘、Merge、客户端批量大小
查询变慢	慢查询、宽泛通配符、深分页、分片过多、缓存命中
磁盘持续增长	Retention、Rollover、Snapshot、删除后 Segment 合并
字段数暴涨	动态 Mapping、把用户键名展开为字段、日志结构不稳定