我们的数据库服务器需要转移到其他数据中心.它在Microsoft sql Server 2012 Enterprise(64位)上运行,包含两个大约2TB和1TB的数据库.
对此几乎没有停机时间是理想的.
工作量
这些数据库用于.NET网站,并不断更新.
但是在周末没有它是可以接受的.在切换到新的DB之前,当前使用的DB将仍然是唯一使用的DB.
理想情况下,只需将DNS条目更改为指向新数据库服务器,同时确保数据库未更新,即可实现此转换.
此外,只要从一个服务器切换到另一个服务器(停机时间)保持较低,此操作所花费的时间就不重要了.
考虑的方法
>备份和恢复
这在过去已经完成,但即使通过内部网络完成也会导致高停机时间,因此比通过Internet更有效
>记录运输
据我了解,这种方法可以通过配置主/从设备并将主DB的精确副本传输到只读的从设备来最大限度地减少停机时间.如上所述,不需要访问从属设备,我们只需要一种方法来获得主数据库的副本而不会丢失数据.
它在资源利用方面似乎也非常有效,并且不会对主要性能产生太大影响.
我不太了解这种方法,但它似乎是一个有效的选择.不需要实时同步和主机的性能是非常重要的,因此如果要选择这种方法,则异步将是要走的路.
>其他选择？
该服务器直接在裸机硬件上运行,因此不幸的是,低级别解决方案不是一种选择.也许有更好的方法来完成这项工作？
约束
sql Server的版本将是相同的(Microsoft sql Server 2012 Enterprise 64位).
它必须通过网络在两个数据中心之间传输,因此最有可能通过Internet传输.遗憾的是,将磁盘从一个站点发送到另一个站点进行初始同步是不可取的.为转移提供某种安全性是理想的,但我们会尽力做到这一点.
这应该很好地概述了我们对这项任务的需求,并希望你们中的一些人不得不面对这种情况.
解决方法
数据库镜像设置起来相对简单,但需要两台服务器之间的实时连接,设置合作伙伴和端点等.可用性组可以是一个选项,但除了网络复杂性之外,您还必须拥有两台服务器作为同一个WSFC的成员 – 这意味着他们必须都在同一个域中.这不是数据中心移动的典型设置(或甚至可以暂时工作).
我的投票将是日志运送.关于这一点的好处是你可以使用你已经采用的备份和日志备份(对吗？)并且不一定必须在两个数据库之间有实时连接 – 他们不需要知道每个另外,您不需要为镜像,合作伙伴,安全性等设置端点.您只需要一种方法将文件从旧服务器获取到可以在新服务器上还原的位置.您可以提前完成一个完整备份,将其转移到新服务器,还原它,然后从该点应用(可能是差异和)增量日志备份,直到切换时刻.这个过程实际上非常简单,如果您遇到任何困难,可以在线获得许多关于日志传送的教程.
如果Web应用程序随数据库一起移动,由于DNS可能需要一段时间才能传播,您可能希望在旧应用程序的连接字符串中进行切换,以使其在可写入时指向新数据库服务器的IP,因为 – 即使在切换之后,即使您的TTL设置很紧 – 客户端也可能继续使用旧的Web服务器.这完全取决于他们的提供者对您的TTL的尊重程度.
