在没有停机的情况下转移网站

我经常做这些移民。 没有停机时间是困难的，但低或全部不明显的停机是可能的。 总体思路是：

• 将原始服务器热备份到新服务器; 这是一个完整的工作副本，而您的起源仍在工作（在LAMP服务器上：在原点上运行mysqldump，然后通过rsync将整个文件系统转移到目标上）
• 如果应用程序处理得很好，或者2 / 显示一个维护页面 ，或者1 /将原始文件放在只读模式下 （ shell> mount -remount o,ro /path/to/fs + mysql> flush tables with read lock
• 做一个冷增量备份 ，即。 重新转储您的SQL，并只传输自热备份以来修改的内容。 使用rsync，成本仅取决于目标上的inode（文件）数量，因为它们都必须经过修改testing; 这很less是带宽问题。 在1 – 10 GB的站点上有100 – 500k inode，根据我的经验，这个增量备份需要1秒到1分钟。
• 在原点上设置一个反向代理 ，将所有stream量redirect到新的目标。 你完成了，如果有问题，你可以在几秒钟内回滚（放弃原始服务器上的反向代理部分）。 显然，你已经准备好了configuration，以便对apachectl graceful的简单调用apachectl graceful就足以应用它。
• 如果一切顺利，您可以最终完成迁移并更新您的DNS （我通常会在24小时后执行此操作）。 然后等待stream量从源服务器（通常是另外的24-48小时）停止stream动。

细节比较棘手，但是当它是你的工作，而且你已经习惯了，那实际上很简单。 除了知道如何运行“rsync”，“mysqldump”，并在Apache中设置一个反向代理几行，你就完成了。

通常你必须调整一些与源和目标服务器不同的东西（比如主机名）。 在这种情况下，我写了一个小脚本，用于自动执行备份部分和“修复”（使用sed，perl等）。 使用rsync -a --delete您可以使用相同的脚本进行热备份和冷备份。

关于这一点的好处是， 你不依赖于DNS 。 在我的经验中，DNS托pipe总是很糟糕，或者几乎无法控制网站所有者。 来自许多DNS提供商的DNS更新是不可预测的，不可debugging的。 TTL被大多数高速cachingDNS服务器忽略或毁坏。 你会遇到这个有趣的时间窗口，很多人看不到使用相同名称的同一台服务器，而且会造成非常糟糕的客户关系。 把DNS排除在外对我来说是一个巨大的胜利（除非我可以直接托pipeDNS区域，然后我100％控制，但这是另一回事）。

我之前做过的事情是做master＆leftrightarrow;掌握两个数据库之间的复制。 这样，无论您的传入stream量正在打到哪个实际的服务器，数据库更新都会同时发生。

复制是一个非常深入的主题，不能在这里完全覆盖，而且在你的DNS更新之前你现在还没有足够的时间，但是每当下一步移动的时候，这是一个好主意。

没有停机时间是很困难的，但最大限度地减less停机时间是相对简单的。

• 将网站设置为与单独的数据存储同时运行，对旧系统交换机拍摄DNSlogging的快照，然后当您感到高兴的是DNS更改已经传播时，将自旧快照上累积的数据迁移到新的。

• 允许从旧系统访问新系统的数据存储，后台同步新的站点存储，禁用旧的和新的处理，重新同步数据以使其重新联机，将DNS切换到指向新的站点（同时）更改旧站点以使用新存储

• 为新网站设置一个备用域名（例如new.example.com以及www.example.com），但不允许在新名称上进行任何事务处理。 后台将存储同步到新框或复制快照。 禁用旧机器上的所有事务处理，并重新同步数据。 启用新计算机上的事务处理（两个名称）configuration旧计算机以发送redirect到新计算机上的所有HTTP请求的新名称，并重写两个系统的HTML /逻辑层中的所有硬编码URL以使用新.example.com代替www.example.com。 一旦旧机器不再使用，请将URL恢复到www.example.com

这不是微不足道的，但使用正确的工具，它应该能够自动化大部分。 如果你使用数据库序列生成器/ MySQL的自动增量列，那么你需要一个防止冲突的计划。

这是我做到的：

• 完全备份在老主机上
• 上传到新的主机。
• 在更改名称服务器之前，我将数据库从旧的上传到新的主机。
• 更改名称服务器。
• 在老主机上制作“正在build设中的主页”。

在大约2小时内，域名指向新的主机。