Magento升级流程和基础架构，尽可能减少停机时间

我有一个客户，他目前有一台带有Magento的服务器，他的

admin

会关闭整个站点进行数小时的更新。我想让它成为一个即时的过程，因此我想就他应该如何设置它提出新的解决方案：

• Magento生产服务器1（WEB+DB）
• Magento生产服务器2（WEB+DB）
• Magento开发服务器1

DB必须以某种方式在这两台服务器之间同步（群集？复制？），我认为为了尽可能减少停机时间，首先应该在开发服务器上测试更新（升级之前从生产服务器同步DB/WEB）在检查它是否正常工作并了解该过程看起来如何后，我将仅对服务器1禁用负载平衡或循环DNS，然后在服务器2上执行升级/更新，然后切换到服务器2作为生产服务器并更新服务器1。完成这两项操作后，打开负载平衡/循环

我来自Windows环境，所以这就是我在Windows上的工作方式（可能还有单独的数据库和Web），以及RedGate SqlCompare/Sql Data Compare等工具，它应该可以工作

---

但是我根本不了解Magento，所以如果客户不想让他的店铺倒闭，请告诉我可能的情况以及应该如何做…

您肯定需要一台生产服务器和某种登台/版本管理系统。 我建议使用Subversion或Git进行版本管理。 可以先将更改提交到存储库，然后在不停机的情况下更新到实时站点。这对于开发环境来说已经足够了

对于更大的变化，像MaGeto版本升级，你可能仍然需要/需要在半夜将站点降低几个小时，因为这是一个更大的过程。

对于多个服务器，例如，我运行了一个负载平衡器，它在主服务器和辅助服务器之间进行平衡。有一个单独的数据库服务器。对开发服务器进行更改，使用Subversion提交到主服务器，然后主服务器和辅助服务器之间的任何更改每60秒重新同步到辅助服务器

---

对于此解决方案，会话和缓存数据存储在数据库中。

IMHO，有了一个良好的托管环境，您将不需要多台服务器，除非您有数千名同时访问的用户。插件是管理相关问题的常见原因

我们在“云”环境方面取得了巨大成功。实例化一个新的云实例，获取该IP，然后在“hosts”文件中，指向dev.yourdomain.com之类的内容进行测试。唯一真正的停机时间是在数据库转换为新版本时冻结生产站点，这可能需要几个小时。我们的mySql数据库备份大约为3 GB，但谢天谢地，tgz的备份容量已降至280 MB

我们正在使用nginx和php-fpm，它们的速度非常快

我的典型迁移路径：

备份生产站点

启动新的云实例并将生产站点复制到开发站点 （恢复生产数据库）

尝试一步一步地升级开发人员站点，看看有什么中断

启动新的云实例并重新安装最新的 magento版本

工作完成后，恢复生产数据库并观察其运行情况 转换它，看看有什么中断

选择升级还是新安装

备份生产mySql，将生产站点置于维护模式 而dev站点则转换数据库

将域指向新的IP地址

---

仍然有停机时间。。。有多大的网站在这样做？我无法想象一些大商店会这样做？当然他们会。。。当他们知道自己的流量最低时，他们就会这样做。真正庞大的网站将拥有分布式服务器，升级将开始。然后，有人将不得不清理与“旧”数据库上的订单有关的松散部分…我正在考虑使用此功能，以便我可以设置新的magneto shop进行从头升级，然后使用它迁移数据。。这看起来和工作正常吗？不管你做什么，一些计算机将不得不改变数据库，并将其从旧版本更新到新版本。最好让云实例来整理这些东西。根据观察需要添加内存或CPU。在Rackspace或AmazonEC2中从头开始启动新服务器非常容易。最终，可能会出现停机或丢失的订单，这些订单需要在事后手动从旧DB转移到新DB。哦，我们也使用github进行文件版本控制。购物车迁移似乎提供了一种在一切完成后复制“丢失”订单的方法。似乎是一个很好的工具。是的，我计划有多个这样的迁移实例。非常感谢。