大概三个月前，我们对维护的一个服务 Haty 执行了迁移工作，但由于事先考虑不周+发生突发状况，故实际维护时间远超预定时间，进而严重影响到了使用者的使用体验。虽然此后服务运行一切顺利，但我们还是希望能在资金充足后将服务架构进行进一步优化，争取此后不再出现该类状况。

同时，该文也是时隔很长时间后新写的第一篇文章，希望借此重新活跃一下文笔，避免思维讲话。

另：由于距事件发生时隔多月，因此细节难免有疏漏，望各位看官谅解。

再另：由于我们当时并没有充足的资金，故很多业界的常规操作我们并不能进行，只能出此下策。

以下，按大致时间线进行事件的回顾。

起因：机器性能的问题

其实严格来讲，那台机子的纸面数据还是很不错的，如果服务商不严重超售那就更好了。

那时，我们的服务器性能监测系统发现那台机子的 CPU Steal 突出天际的高（高的时候甚至突破了20%），这很显然不合常理且急需处理。于是我们最先联系了服务商，要求他们就此事进行对应地处置。不出所料，他们又开始要无关的内容，不过我们早有准备，将我们的监测数据发了过去，但对方很显然更想要知道我们运行了什么，一个劲要我们的登录凭据。随后我们决定不再通过工单看服务商踢皮球，而是直接打电话解决问题，于是出现了以下的一幕（原对话为英文，时间过于久远忘记了具体内容）：

……

对方：“balabalabala……”

我们：“你是否同意，CPU Steal 的值与我们运行的服务无关？”

对方：“我同意。”

我们：“那为什么你们的支持团队一直问我们要登录凭据？”

……

然后他们就开始爽快地解决问题了，先是调整参数，又是给我们搬迁服务器到另一台主机上。

但就算是搬迁后，我们发现 CPU Steal 的值仍然居高不下，维持在10%左右，而对方也不愿意进行进一步调整，直接说要我们换服务器吧。而我们和对方那时候也就此事进行了几十次拉扯，也不愿意再进行新一轮地“较量”。

好，这可是你们说的，换服务器！

于是迁移计划便提上了日程，并很快走到了执行的那一步。

迁移（上）：路在何方？

真到迁移那一步时，我们犯了难。

软件什么的倒是没什么问题，能直接迁走，关键是那个三四百G的数据库。面对这个庞然大物，我们最开始认为，我们原本设计的方法可以轻松将其搬走，于是我们信誓旦旦地说，不超过六小时就可以完成迁移工作。

我们错了，错得离谱。

由于需要控制成本，我们并没有能同时运行多台服务器来承载该数据库，且由于先前并没有相关经验（此时我们的团队并没有专业运维人员），所以出于成本和稳定性方面的考虑，我们直接放弃了热迁移的方法，转而考虑冷迁移。而冷迁移需要进行全量备份与恢复，其中最大的问题就出在备份上。由于原先的服务器以及能马上调出来的中转服务均无法承载如此大量的数据，于是我们只能借用我们的备份空间来进行中转，即将空间直接挂载到原服务器上，所有备份操作直接写入到空间内，然后再统一导出到目标服务器进行恢复。实际上如果这么做成功了，六个小时内反而真能解决问题。

很显然，没成功。

我们在漫长地等待后终于等到了导入结束的时刻，然而在检查后却发现了一个很严重的问题：大小不对！

这里的大小是对比的备份空间内正常备份的大小，很明显能感觉小了不少。秉持着宁可晚些时间开放也不能留隐患的原则，我们放弃了这条路。

迁移（下）：柳暗花明！

我们开始重新寻找方法，以期望能解决迁移的问题，最终还是找到了一个方法，允许挂载目标服务器目录直接到迁出服务器，并通过 SSH 进行数据传输。实际上我们在迁移过程中有过这种想法，然而由于事先并没有了解到而没有第一时间采用此方法。最终，除了第一次传输的结果出现了一些意外错误外，我们在第二次传输并校验完成后解决了数据库迁移的难题。本次维护时间共耗时 22.5 小时，远超最初的预期，虽然很累，但我们也收获了大量的经验，能在此后的维护工作中更高效地处理问题。

后记

实际上说是 22.5 小时的迁移，大部分时间都花费在等待数据迁移上了。无论如何，问题是解决了，经验也到手了，下一步就是争取在资金充足后早日事先业界标准，提高稳定性与抗灾应变能力，争取更好地服务与支持我们的人，以及希望自己的通信秘密不被侵犯的人。

Hashi Project 因你而美好。