做搜索平台最怕什么不是单机查询变慢而是整个集群的数据都推不出去、拉不回来。我在生产环境维护TongSearch集群的过程中被问到最多的问题不是“查询为什么慢”而是“另一套机房的集群怎么跟主集群保持同步”。TongSearch跨集群复制说白了就是解决这个问题的把A集群里的索引数据持续同步到B集群让两套集群的数据尽量保持一致从而支撑容灾切换、读写分离或者多机房就近查询。这篇内容基于我自己落地TongSearch跨集群复制数据同步流程的完整记录涵盖为什么需要跨集群复制、同步机制是怎么设计的、具体配置步骤以及我在实施过程中踩过的坑和排查思路希望能给正在评估或已经上手跨集群复制的朋友一些参考。1. 为什么要把TongSearch跨集群复制提上日程1.1 跨集群复制解决的是哪一类问题很多团队一开始用TongSearch就是单集群部署节点数从3个加到9个数据量从几百G涨到几个T查询和写入都能扛住。这个时候你很难觉得需要跨集群复制。但下面几个场景一出现单集群就开始露怯了。第一个场景是机房级容灾。单集群哪怕节点再多只要整个机房断电、断网或者底层存储出问题整个搜索服务就没了。你说我有备份可以重新建索引但重新灌一遍几个T的数据少说也要几个小时搜索服务在这几个小时内完全不可用业务方基本等不了。第二个场景是读写分离。搜索集群最怕的就是写入高峰和查询高峰叠在一起。业务在每天凌晨批量导数据白天查询量又特别大如果读写都在同一套集群上难免相互影响。通过跨集群复制可以把主集群的变更同步到一套独立的查询集群让查询集群承担全部读流量主集群专注写入和内部数据处理。第三个场景是异地多活或者就近访问。业务覆盖多个区域的时候每个区域各部署一套TongSearch集群数据从中心机房复制到各区域或者把各区域数据汇聚到中心这时候跨集群复制就成了基础能力而不是可选项。1.2 先判断你的场景真的需要跨集群复制吗跨集群复制不是银弹它有自己的成本和复杂度所以上之前一定要先做判断。如果只是单集群容量不够优先考虑横向扩容节点而不是增加一套集群再复制。集群扩容是分片级的代价远小于搭一套新集群再维护同步链路。如果是为了做数据备份可以先把快照和恢复机制用起来很多备份需求快照就能满足不需要实时复制。如果业务可以接受小时级的数据延迟而且核心诉求只是“有备份”那定时做全量导出再导入或者做快照归档比跨集群复制省心很多。我的判断标准很简单第一主集群挂了以后从集群要能直接接流量这种情况下必须做跨集群复制第二复制延迟要控制在秒级甚至更低而且主从切换流程需要反复演练这是一套系统性的工程不是配置一下就算完。第三从集群的数据不能是单纯静态备份而是持续跟踪主集群的最新状态这意味着复制链路必须是实时或准实时的。如果三条都不满足跨集群复制大概率不是你的最优解。2. TongSearch跨集群复制的同步原理拆解2.1 复制链路主集群向从集群单向同步TongSearch跨集群复制在架构上采用主从模式主集群负责正常的索引写入和数据变更从集群作为复制目标持续接收并回放主集群产生的数据变更。复制链路的核心思路非常像数据库的主从同步主集群把每一笔变更视作日志事件从集群拉取这些事件然后应用到本地索引。区别在于搜索场景下数据变更的最小粒度不是一行记录而是一个文档在某个分片上的写入、更新或删除操作。TongSearch在实现上是以索引分片为基本复制单元来推进的。每个索引有多个分片主集群的主分片负责写副本分片负责读。跨集群复制监管的是主集群的主分片和从集群的对应分片之间的同步关系而不是整个索引一个整体去复制。这么做的好处很明显分片是搜索集群数据分布和负载均衡的最小单位以分片为粒度做复制可以充分利用集群已有的数据路由能力避免复制任务集中在某一两个节点上。举一个简单的例子主集群有一个索引配置了5个主分片分布在5个节点上。跨集群复制任务开启后从集群也创建相同分片数的索引每个分片从主集群对应的主分片拉取变更数据。5个分片的复制并行进行任何一个分片复制中断只影响该分片对应的那部分数据其他分片可以继续同步。2.2 增量同步与复制位点数据怎么追上主集群跨集群复制最核心的问题不是“怎么把当前的数据拷过去”而是“怎么持续跟上主集群的新变更”。TongSearch的复制流程大体分成两步全量同步和增量同步。全量同步阶段从集群的索引分片还没有数据需要先把主集群对应分片在当前时间点的全量数据拷贝过来。这个阶段走的是底层文件拷贝直接把索引的段文件传输到从集群速度很快。全量同步完成之后进入增量同步阶段从集群开始从主集群拉取全量同步期间产生的新增操作追平主集群的最新状态。增量同步依赖复制位点机制。主集群的每个分片在写入数据时都会生产对应的变更记录并标记一个不断递增的位置信息通常是一个数字编号或者带序号的对象。这个位置信息被称作检查点或者复制位点。从集群每消费一条变更记录就会把自己的复制位点往前推进一格。复制位点的作用和书签一样。读完第20页下一次就直接从第21页开始读不需要从头翻。如果复制过程中网络抖动、任务暂停位点不会丢恢复之后从位点处继续拉取即可。主集群侧不会永远保留所有变更记录它有一个保留窗口比如最近7天。如果从集群停机时间超过这个窗口增量同步就追不上了只能重新做一次全量同步。从集群追上主集群数据的过程本质上就是位点追赶的过程。全量同步完成时当前位点落后于主集群最新写入位置落后多少取决于全量同步期间主集群产生了多少增量。此时从集群需要快速消费积压的增量记录直到两侧位点基本对齐复制进入稳态。2.3 一致性与冲突处理最终一致不等于随便一致跨集群复制不是强同步主从集群之间总有时间差所以TongSearch的跨集群复制采用的是最终一致模型。也就是说在任意一个瞬间从集群上的数据可能和主集群不完全相同但如果停止写入经过一段时间从集群一定会追平主集群。在正常使用中最需要考虑的数据一致性风险有两个。第一个是文档乱序。假设同一个文档ID被连续更新了两次先变更版本为2后变更版本为3由于网络或者队列原因从集群可能先收到版本3的变更再收到版本2的变更。如果不做处理从集群最终会停在版本2而不是主集群的版本3。TongSearch在复制处理时会对操作携带的版本信息进行校验只应用版本更新的操作丢弃旧版本操作保证从集群数据不会倒退。第二个是删除操作的特殊性。删除操作如果只记录文档删除那么同一文档在删除后又被重新写入同ID的新文档从集群在同步删除时也要有判断依据不能把新写入的文档误删。这种场景下的处理逻辑也是依赖版本号和操作类型把删除看作带有版本信息的特殊变更只有当前版本低于删除版本时删除才会生效。从我实际使用来看只要主集群写入侧不出现极端乱序比如人为绕过组件直接改底层索引文件TongSearch的复制一致性是可靠的。但要特别注意跨集群复制不等于双写从集群索引处于只读状态业务不能直接往从集群写数据否则会破坏位点对应关系和一致性校验逻辑。3. 跨集群复制的完整落地步骤3.1 部署与前置检查清单在配置跨集群复制之前先把前置条件理清楚能省掉后面一大半排查时间。版本一致性是最基本的。主集群和从集群的TongSearch版本必须保持一致至少主版本小版本都要对齐。版本不一致会导致变更记录解析格式不兼容复制任务能创建但同步进度死活不动或者报一堆解析异常。网络连通性方面从集群需要能够访问主集群的传输端口尤其是用于复制数据的内网通信端口。这里要检查的是双向网络策略虽然主集群到从集群是数据推送方向从集群到主集群是控制指令和数据拉取方向两侧都需要放通。如果中间有防火墙或安全组要让网络同事一起核对规则。安全认证方面如果主集群开启了身份认证和加密传输从集群连接主集群时需要使用对应的凭据也就是服务账号或用户令牌。建议为复制任务单独分配一个账号权限范围限定在需要复制的索引上不要直接使用管理员账号挂在复制链路上。这样做既安全也不会因为管理员密码轮换导致复制任务突然断掉。容量评估方面很多人会忽略从集群的磁盘和内存规划。跨集群复制完成后从集群的数据量会和主集群基本一致同时复制过程还会产生复制位点记录、索引分片备份等额外开销建议从集群的存储配置至少是主集群的1.2倍到1.5倍。如果使用跨集群复制是为了支持更大量级的查询流量从集群的节点规格还要相应调整不能直接按主集群的配置照抄。检查项检查内容备注版本一致性主从集群产品版本一致小版本不一致容易出解析问题网络连通性复制传输端口双向放通先telnet测试再配置任务安全认证独立服务账号、最小化权限避免使用管理员账号作为数据链路账号存储容量从集群容量至少为主集群1.2倍预留增量日志和复制位点空间索引状态待复制索引未被关闭或只读只读状态可能导致全量同步失败3.2 注册远端集群与任务配置TongSearch控制台一般都有跨集群复制功能入口核心操作就是两步注册远端集群和创建复制任务。注册远端集群时需要在当前集群的控制台上添加远端集群信息。填写内容包括远端集群名称、一组节点地址和端口以及访问凭据。这里要注意节点地址建议填写全部或至少多个数据节点的地址不要只填一个网关地址。只填一个地址意味着复制任务的所有请求都会集中到这个节点上节点故障后复制任务可能直接断掉。多填几个地址TongSearch会在连接时自动挑可用的节点健壮性会明显提升。集群注册成功后创建复制任务。复制任务一般需要指定以下几项复制方向、选择源集群索引、选择目标集群索引名称、配置同步模式。同步模式通常有全量增量模式和仅增量模式。首次建立复制关系时选全量增量之后如果复制链路中断时间过长需要重建复制任务时也建议选全量增量这样最省心。目标索引名称可以跟源索引不一致。如果你的从集群想用带后缀的索引名比如主集群索引叫product从集群索引叫product_backup直接在任务配置里指定即可。这个灵活性在做索引版本迁移和灰度切换时很有用。创建任务之后不要急着认为复制已经在跑了。先观察任务状态正常情况下任务会经历“初始化中-全量同步中-增量同步中-正常”的过程。初始化中阶段主要是校验集群连接、检查索引配置全量同步中阶段会看到实时传输速度增量同步中阶段代表全量部分已经完成开始消费增量日志状态变为正常后基本就进入了持续同步阶段。3.3 关键参数说明与调优建议跨集群复制任务跑起来之后真正影响同步效果的是几个关键参数配置不当容易出现“任务状态正常但同步一直慢半拍”的尴尬局面。带宽限制参数控制复制任务占用的网络带宽上限。生产环境的主集群同时承担着业务写入和查询复制如果无限制占用带宽会把正常的业务流量挤掉。建议先设置一个相对保守的带宽值比如总带宽的30%观察业务流量和复制速率后再动态调整。这个参数可以通过控制台直接改不用重启任务。批量大小参数控制单次从主集群拉取的变更记录条数。批量越大单次网络往返传输的数据越多吞吐量越高但也会占用更多内存。如果从集群节点内存偏小大批量请求容易触发GC频繁进而影响复制速率。建议从默认值开始逐步增大观察从集群的内存曲线。出现频繁Full GC时把批量调小一半再观察。并发分片数参数控制同时进行复制操作的分片数量。分片并发数越高整体复制速度越快但每个并发分片的复制都会占用两端的CPU和网络资源。我的经验是分片并发数不要超过集群节点数的两倍否则资源竞争反而会拖慢同步。比如5个节点的从集群分片并发开到8到10比较合适具体值还要看节点规格。另外还有一个容易踩坑的参数是复制串行间隔。有些复制任务在大批量小文档场景下性能瓶颈在发送端每次发送之间加一个小间隔比如20毫秒可以避免打爆网络小包。但这个参数在数据量大的场景下会明显拉长同步时间除非有特殊的限流需求否则不建议手动调整。注意参数调优一定要基于监控数据进行不要凭感觉改。每次修改只动一个参数观察至少30分钟到1小时确认稳定后再动下一个。一次改多个参数出了问题很难定位是哪一项导致的。4. 数据校验、监控告警与故障排查4.1 主备数据一致性校验跨集群复制上线之后只盯着任务状态正常是不够的。任务状态正常只代表复制链路在推进不代表从集群的数据和主集群完全一致。我的习惯是至少每周做一次主备数据一致性校验每次大版本变更或配置调整之后也要主动做一次。TongSearch一般提供校验接口可以在线比对主集群和从集群指定索引的文档数、分片数以及校验和。没有现成接口的情况下可以自己写一个比对脚本按分片维度分别统计文档总数和内存占用再抽样拉取部分文档ID进行比对。分片维度比对是最有效的如果某个分片不一致能直接定位到具体的主分片和从分片便于排查复制任务中对应分片的历史状态。校验结果如果出现少量不一致不用过度紧张先判断是正在同步过程中的正常延迟还是真正的数据漂移。方法是看主集群当前的写入位点和从集群的消费位点如果两者差距很小且校验时主集群还在持续写入那不一致可能是分布在不同时间点造成的假象。等写入停止后重新校验如果还是不一致就需要深入排查复制任务以及是否有数据被直接写入了从集群。4.2 同步延迟监控与告警跨集群复制的核心监控指标有四个复制位点延迟、复制速率、失败批次数量、任务状态。复制位点延迟是最重要的指标表示从集群数据落后主集群多久。延迟通常用时间差值来描述比如从集群同步到的位置是14点32分10秒主集群最新写入是14点32分40秒延迟就是30秒。秒级延迟对大部分业务是可以接受的如果业务要求切换后数据最多丢10秒那延迟超过10秒就要触发告警。复制速率反映单位时间传输的数据量速率突然归零通常是网络或者主集群节点异常。失败批次数量统计复制过程中失败的批次总量这个数字不为0时要看失败原因是网络超时、数据校验失败还是索引异常。任务状态异常是最直观的直接触发即时告警。告警阈值怎么定我的建议是分三级。监控阶段设一个信息级比如复制延迟超过30秒只记录日志提醒级延迟超过1分钟发工作群提醒严重级延迟超过5分钟或者任务中断直接电话告警。阈值要结合业务容忍度来定不要照搬别人的配置。之前有个业务场景允许小时级延迟告警设置成分钟级就天天误报最后取消告警反而没人关注复制了。监控数据的采集上TongSearch的监控指标一般都会输出到监控系统或日志平台。我们当时的做法是通过管理接口定时拉取集群健康状态和复制任务指标每30秒采集一次写入时序数据库再配合告警规则引擎判断。如果你没有现成的监控系统最简单的方式是写计划任务调用管理API把状态写入日志文件再用简单的日志关键字监控工具做告警。4.3 常见故障与排查方案跨集群复制上线半年我至少遇到过十几种异常情况其中大多数集中在下面几类。任务创建成功但一直停留在初始化中最常见的原因是远端集群地址不可达。这种情况优先检查网络连通性直接在当前集群节点上telnet远端集群端口不通就找网络同事放通规则。如果网络没问题查看服务账号是否有远程集群的访问权限很多初始化卡住其实是权限不足。全量同步阶段速度特别慢主要原因有三个网络带宽小、源集群节点IO繁忙、批量参数太小。排查时先看网络和源集群负载如果两端资源都很空闲那就是参数问题调大批量大小和带宽限制。如果源集群本身IO已经很高比如正在做Merge合并任务建议把复制任务暂时调慢等Merge结束再恢复避免互相拖累。增量同步阶段频繁失败报错信息里经常出现超时或连接重置。这种情况十个里有八个是网络不稳定或者长连接被中断。TongSearch一般会自动重试但如果失败次数持续增长就需要手动重启复制任务让管控进程重建复制连接。我的处理口诀是“先看网络、再看资源、实在不行重建任务”。还有一种比较隐蔽的坑主集群索引在复制任务启动后重建了比如删掉索引再按同名重新创建。重建后的索引内部标识和原有数据不一致从集群的复制任务会一直尝试基于旧的索引数据做增量导致同步卡住。遇到这种情况最干净的解法是在主集群关闭对应用户的写入把复制任务删除重建重新做一次全量增量同步。故障现象可能原因处理思路任务初始化卡住网络不通、权限不足检查端口连通性、核对服务账号权限全量同步慢带宽限制、源端IO繁忙调大带宽参数、避开Merge高峰期增量同步失败网络波动、长连接中断查看失败批次日志、重启复制任务同步中断后追不上保留窗口过期删除任务重建重新全量增量同步复制正常但数据不一致从集群被写入核对从集群索引状态、封锁写路由5. 落地经验与个人心得跨集群复制这套机制配置起来不难真正难的是把“主从数据最终一致”这件事变成可以信任的运维资产。我自己在实践中最大的体会是不要等到集群出问题的时候才想起来验证复制链路复制链路的日常健康度必须靠持续监控和定期演练来维持。有几件小事值得单独拿出来说。第一复制任务的命名规范要清晰源集群、目标集群、索引名、业务用途都要体现在任务名称里。我见过太多复制任务叫“test1”“copy_backup”过了三个月没人知道这个任务在复制什么、服务于哪个业务出问题只能干瞪眼。第二建议每月做一次主从切换演练不一定要真的切流量但至少要验证从集群的索引数据可用性、查询集群的接入能力以及切换后数据延迟是否能被业务接受。演练过程要用文档记录下来因为每次演练都能发现新的问题。第三跨集群复制的带宽和资源消耗不能忽略。虽然设置了带宽限制但复制过程中的CPU和内存开销是没法限制的。如果主集群本身性能余量不足复制任务可能会加剧集群压力间接影响查询延迟。我之前就遇到过一个大索引做全量同步时主集群查询P99从30毫秒涨到200毫秒的情况。临时方案是限速甚至暂停复制任务根本解法是给主集群预留充足的性能余量或者把复制任务安排在流量低峰期执行。第四索引映射结构变更要格外小心。生产环境有时会调整字段类型或删除字段这类变更在单集群场景下通过重建索引解决但在跨集群复制场景下会带来额外复杂度。如果主集群的索引映射结构发生变化从集群需要同步更新并重新做全量同步而不是继续走增量复制。所以我现在遇到任何索引映射变更都会先暂停复制任务完成主集群侧改造后再重建复制任务做全量同步。最后再说一个容易被忽略但很重要的细节从集群上的查询流量要提前压测。跨集群复制把数据同步过去之后如果从集群查询性能跟不上容灾切换时照样会出大问题。我在一次切换演练中就发现从集群节点规格偏小同一查询在主集群10毫秒内返回在从集群要350毫秒。后来我们把从集群的节点规格升了一档重新做查询压测切换后的查询性能才算合格。跨集群复制只是手段数据同步完成后从集群能不能真扛住业务值班才是最终目的。结合我的经验如果你准备在生产环境上TongSearch跨集群复制一定要把数据校验、延迟监控、切换演练三件事当成复制任务本身的一部分一起规划否则这个复制链路最终只会变成一套摆设。靠谱的跨集群复制不是配完就完了而是从配置那天开始就要持续回答“数据对不对、延迟高不高、切换行不行”这三个问题。