英国《卫报》是如何不停机从MongoDB迁移到Postgres？
|
在深入研究之前，我们试图找到一种要领来继承运行gor，但这次没有对署理施加任何压力。办理方案来自Composer的二级仓库。该仓库仅用于紧张环境，而且我们的出产监控器材会不绝对其举办测试。将流量以后仓库从头映射到CODE，速率更加，这次没有任何题目。 新发明提出了许多题目。该署理的构建也许没有像其他应用措施那样全心计划。另外，它是行使Akka Http构建的，之前没有任何团队成员行使过。代码很紊乱，而且快速修复。我们抉择开始一项重大的重构事变，以进步可读性，包罗行使领略而不是我们之前增添的嵌套逻辑，并添加更多的日记记录标志。 我们但愿通过花时刻相识统统是怎样运作的，并通过简化逻辑，我们可以或许阻止骑行。但这没结果。颠末约莫两个礼拜的实利用署理更靠得住，我们开始认为我们越来越深入兔子洞了。必需作出抉择。我们赞成冒险并留下风险，由于花在现实迁徙上的时刻比试图修复一个月内将会消散的软件更好。我们通过再经验两次出产间断来验证这个抉择，每次间断一连约莫两分钟，但总体来嗣魅这是正确的做法。 快进到2017年3月，我们此刻已经完成了迁徙CODE，对API的机能或CMS中的用户体验没有任何倒霉影响。我们此刻可以开始思量在CODE中停用署理。 第一阶段是改变API的优先级，以便署理起首与Postgres攀谈。如前所述，这是基于设置的。然而，有一个伟大性。 更新文档后，Composer会在Kinesis流上发送动静。为了停止一再动静，只有一个API应该发送这些动静。API为此设置了一个符号; 对付Mongo支持的API，该值为true，对付Postgres支持的API，该值为false。简朴地变动署理与Postgres攀谈是不足的，由于在哀求达到Mongo之前，动静不会在Kinesis流上发送。这太迟了。 为了办理这个题目，我们建设了HTTP端点，以便瞬时变动负载平衡器中全部实例的内存设置。这使我们可以或许很是快速地切换哪个API是首要的，而无需编辑设置文件并从头陈设。另外，这可以编写剧本，镌汰工钱过问和错误。 此刻全部的哀求都是Postgres，而API2正在与Kinesis攀谈，可以通过设置和从头陈设来永世变动。 下一步是完全删除署理，让客户单独与Postgres API攀谈。因为有很多客户，单独更新每个客户并不是真的可行。因此，我们将其推向了DNS。也就是说，我们在DNS中建设了一个CNAME，它起首指向署理的ELB，然后变动为指向API ELB。这应承举办单个变动，而不是更新API的每个单独客户端。 此刻是迁徙PROD的时辰了。固然有点可骇，由于它是出产。这个进程相对简朴，由于统统都基于设置。另外，当我们向日记添加舞台标志时，还可以通过更新Kibana过滤器来从头调解先前构建的仪表板。 封锁署理和MongoDB 在10个月和240万个迁徙文章之后，我们终于可以封锁全部与Mongo相干的基本办法。但起首，我们一向在守候的那一刻：杀死署理 这个小软件给我们带来了许多题目，我们火烧眉毛想要把它关掉!我们必要做的就是更新CNAME记录以直接指向APIV2负载平衡器。 该团队聚积在一台电脑周围。只需点击一下即可切换开关。没有人再呼吸了。完全沉默沉静。点击!并且改变了。什么都没产生!我们都放松了。 出乎料想的是，删除旧的MongoDB API是另一项挑衅。在猖獗删除旧代码时，我们发明我们的集成测试从未变动为行使新API。统统都很快变红了。荣幸的是，大大都题目都与设置相干，因此很轻易修复。可是测试捕捉的PostgreSQL查询存在一些题目。为了停止这个错误，我们想到了我们可以做的工作，我们意识到，在开始大量事变时你也必需接管你会失足误。 之后产生的统统都很顺遂。我们从OpsManager中疏散了全部Mongo实例，然后终止它们。剩下要做的独一工作就是庆贺。睡个好觉。 【编辑保举】
点赞 0 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
