![如何使 SQL Server 2008 变得冗余?](https://linux22.com/image/548698/%E5%A6%82%E4%BD%95%E4%BD%BF%20SQL%20Server%202008%20%E5%8F%98%E5%BE%97%E5%86%97%E4%BD%99%EF%BC%9F.png)
目前,我想将我部门的 SQL Server 合并为一个分布在两台服务器上的大型 SQL Server 2008 实例(出于冗余的原因)。
如何/什么是解决这个问题的最佳方法?是通过集群、日志传送还是 VMware(虚拟机管理程序)高可用性功能?
注意:此数据库服务器不能关闭,因为它还托管 VCenter 数据库和服务器监控数据库。
SQL Server 分布在几台较小的服务器 3-4 SQL Server 2000 和 2005 上,这些服务器内部总共有 70 个数据库,我想要做/构建的是将它们全部迁移到 SQL Server 2008 中,在其中我必须使其冗余,以便如果一台服务器由于某种原因出现故障,另一个实例可以立即接管它。
因此,从几个较小的 SQL Server,我想将它们全部合并为一个更强大的 SQL Server 2008 x64。但到目前为止,还不知道哪种技术适合这样做,或者是否可以在 SQL Server 2008 Standard 中做到这一点。
任何建议和意见都将非常感谢。
答案1
是通过集群、日志传送还是 VMware(虚拟机管理程序)高可用性功能?
不不不。
镜像,3台服务器(一台可以是小型免费服务器,只需决定哪台保持活跃工作)。
日志传送很慢/延迟,集群/vmware 留下一个数据库作为弱点,仍然可能被破坏。
答案2
TomTom 的说法是正确的,但让我阐述一下几个关键点:
日志传送非常适合灾难恢复,但不适合最新数据。您的数据是总是15 分钟到 1 小时甚至更久,具体取决于您的设置。重新连接是不是无缝。您需要重新配置应用程序以指向新系统。此外,第二个数据库不在线,它通常处于恢复模式(应用日志),因此您需要将其从恢复模式中取出才能使用它。这就是为什么它通常仅用于灾难恢复的原因。
当你与任何完全没有延迟。它提供了高可用性 SQL 接口,但它不会使您的数据具有高可用性,除非您的 SAN 可以为您做到这一点。我永远不会尝试在 DC 之间进行集群。
镜像。在这种情况下,镜像是您的好朋友。镜像有两种基本模式:同步或非同步。两种模式的共同点是:每个 SQL 服务器都有自己的数据库本地副本,但只有一个 SQL 服务器可以“拥有”它。换句话说,即使您有三个 SQL 服务器,但实际上只有其中一个正在使用。其他服务器都处于待机模式,等待激活。
在同步模式下,当收到写入事务时,所有 SQL 服务器都会同时执行该事务,直到每个 SQL 服务器都报告已提交事务后才会处理下一个事务。这可确保每个 SQL 服务器都拥有完全最新的数据。这对于高速、低延迟的链接非常有用,但对于高延迟的链接则不太好,因为它会有效地将数据库速度降低到最慢的合作伙伴的速度。
在异步模式下,SQL 服务器会不是等待所有其他 SQL 合作伙伴提交事务。它只是在本地提交事务并继续前进。然后,每个其他 SQL 服务器可能会落后几个事务,特别是当它们之间的链接负载很重时。这意味着您可以全速访问活动数据库,但在发生故障转移时,您可能会丢失一些数据。此外,此模式仅适用于 SQL Enterprise 版本。
VMWare HA。好吧,这真是一大堆麻烦。它很好,但同样,您需要共享同一个 SAN 才能工作。或者您是在谈论 VMWare FT(容错)?如果是,我建议您暂时忘掉 SQL 服务器的 FT。FT 在理论上很棒,我甚至在一台 VM 上使用它,但对于大多数部署来说,您需要做出的牺牲太大了。此外,由于 VM 彼此同步,带宽问题会损害性能。
为了管理自动故障转移的能力,群集为您提供了一个虚拟实例,您可以连接到该实例,并且所有操作对用户都是不可见的。对于镜像,您可以通过运行网络负载平衡角色轻松实现这一点,:1433
这样当 SQL 服务器脱离网络时,虚拟实例就会切换到其他节点。或者,根据您的应用支持情况,您可以在 SQL 连接字符串中指定备用镜像服务器。
你可能对我的问题的答复感兴趣,SQL Server 2008 R2 100% 可用性。