英国《卫报》是如何不停机从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 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
