1. 搜索引擎数据迁移概述
大家好，我是这次课程的主讲。今天咱们聊聊搜索引擎数据迁移这个话题。说实话，我在这个领域摸爬滚打了十几年，踩过的坑真不少。数据迁移这事儿，看着简单，做起来全是细节。
什么是数据迁移
数据迁移，说白了就是把搜索引擎里的一堆数据，从一个地方搬到另一个地方。可能是换集群、换机房、换版本，也可能是做灾备。我见过最夸张的一次，是把上百TB的索引数据从自建机房搬到云上，光规划就花了两个月。
你可能会问：不就是复制粘贴吗？嗯，还真不是。搜索引擎的数据迁移有几个特殊的地方：
- 数据量大——动不动就是几十TB甚至PB级别
- 实时性要求高——用户还在搜着呢，不能停服务
- 一致性难保证——迁移过程中数据还在不断写入
- 恢复成本高——一旦出问题，重建索引可能要好几天
我个人习惯把数据迁移分成两类：在线迁移和离线迁移。在线迁移就是系统不停机，边服务边搬数据；离线迁移则是先停服务，搬完再开。大部分生产环境都要求在线迁移，但说实话，离线迁移更安全。
迁移的挑战与风险
我在项目中遇到过不少迁移翻车的情况。有一次，团队在迁移过程中忽略了索引分片的路由规则，结果数据是搬过去了，但查询全都超时。嗯，这里要注意，迁移不只是搬数据，还要搬配置、搬策略。
常见的挑战有这几个：
| 挑战类型 | 具体表现 | 我踩过的坑 |
|---|---|---|
| 数据一致性 | 源和目标数据对不上 | 曾经因为时间戳精度问题，丢了2%的增量数据 |
| 性能影响 | 迁移过程拖慢线上服务 | 有一次迁移把CPU打满，用户搜索延迟从50ms飙到2s |
| 版本兼容 | 新旧版本数据结构不同 | ES 5.x到6.x的迁移，type字段直接废了 |
| 回滚困难 | 迁移失败后恢复原状 | 没有做全量快照，回滚花了3天 |
为什么会这样？因为搜索引擎的数据结构太复杂了。索引、分片、副本、路由、分词器、打分策略……任何一个环节出问题，都可能让迁移白干。你想想看，一个搜索请求要经过多少层才能返回结果？迁移过程中任何一层出问题，用户感知到的就是「搜不到东西」。
迁移策略分类
我一般把迁移策略分成四种，每种都有适用的场景：
- 全量迁移——把整个索引数据一次性搬过去。适合数据量不大、可以停服的情况。我建议小规模集群用这个，简单粗暴。
- 增量迁移——只搬变化的数据。适合数据量大、不能停服的情况。但要注意，增量迁移需要记录变更日志，否则容易丢数据。
- 双写迁移——同时写入新旧两个集群，等数据一致后再切换。这是我最喜欢的方式，安全系数高。不过代价是资源消耗翻倍。
- 滚动迁移——逐个节点替换，边替换边服务。适合分布式搜索引擎，比如Elasticsearch的滚动升级。我建议大集群用这个，对业务影响最小。
我的经验之谈：选迁移策略时，先问自己三个问题：
- 能停服多久？——如果只能停5分钟，就别想全量迁移了
- 数据量多大？——超过10TB，增量迁移是唯一选择
- 业务容忍度？——搜索延迟增加50%能接受吗？不能的话就选双写
举个例子。我之前帮一个电商平台做搜索迁移，数据量大概50TB，要求零停机。我们最后选了双写+滚动迁移的组合方案：先用双写保证数据一致，再用滚动迁移逐步切换流量。整个过程持续了4天，用户完全无感知。
💡 小技巧：不管选哪种策略，一定要先做一次小规模演练。我习惯先在测试环境跑一遍，记录每个步骤的耗时和资源消耗。这样到了生产环境，心里就有底了。
好了，这一章的内容就到这里。数据迁移这事儿，说白了就是「搬数据」三个字，但背后的门道多着呢。下一章咱们聊聊具体的迁移工具和方案，到时候我会分享一些我亲手写过的迁移脚本。
公众号:蓝海资料掘金营，微信deep3321