事务复制作为DR解决方案

Question

我已经设置了生产数据库服务器和故障转移数据库服务器。来自主生产db服务器的所有事务都被复制到故障转移数据库服务器(从备份初始化的事务性复制)，并且运行良好。

在故障转移服务器中不执行任何活动(没有报告)，它只是从初级生产数据库中获取所有更改。甚至报告(报告最少)也是从初级生产数据库服务器完成的。

目标是将其用作故障转移服务器，我知道事务性复制对DR来说不是一个好主意，还有其他推荐的解决方案。但这是以前的DBA设置的方式，我听说在这段时间听起来还不错。因此，如果我必须进行故障转移，我必须手动完成，因为我理解这个主题的研究。

有3个应用服务器(app1、app2、app3)使用负载均衡器进行管理。一个数据库服务器(目前是初级生产服务器)

我只是有一个模糊的想法，如何做故障转移，通过我自己的研究。我有以下两个问题：

• 是否有人慷慨地告诉我如何对复制的数据库服务器执行故障转移。
• 故障转移之后，如何将新事务/更改管理回主生产数据库服务器。

Answer 1

事务复制不是一个"DR解决方案“--您可能面临很多问题(并非所有表都复制了，每个DB中有不同的数据)，即使它在过去工作过，在现在也没有任何保证。建议使用一些受支持的工具，如日志传送或始终打开。

即使您决定这样做，正如@Queue Mann所说，您将需要将所有内容指向新服务器，对于您的问题没有自动选项(但始终是on)：( A)没有“正式”故障转移，您只需使用复制的DB并将所有应用程序指向DB。

( B)在发生故障转移的情况下，您将需要再次设置所有内容(在“始终打开”中，您不会像在同步模式下那样设置)。

老实说，我不知道为什么继续使用复制而不是官方的DR解决方案，您将节省许多配置(和麻烦)以正确的方式进行。

Answer 2

回答您的问题：

是否有人慷慨地告诉我如何对复制的数据库服务器执行故障转移。

“故障转移”并不适用于复制，因为它不是DR技术。您必须将应用程序重定向为指向副本服务器的“故障转移”。你也可以用CNAME。将服务器指向指向主服务器的DNS中的CNAME，然后将CNAME更改为指向副本服务器。

您需要为CNAME设置一个较低的TTL，以便客户端机器能够尽快地选择这一更改。此外，您还需要停止和禁用复制代理作业，以防止在另一边运行时出现数据错误。

故障转移之后，如何将新事务/更改管理回主生产数据库服务器。

在SQL事务复制中没有“反转”，所以您必须中断，备份数据库，在主服务器上恢复DB，并将应用程序重定向回主服务器。

现在澄清一些事情：

我提出的这些建议不是很好。复制不是DR技术，它既不适合DR，也不适合DR，您需要放弃它作为解决方案。如果您关心的是复杂性，复制比简单的DR选项更复杂，比如日志传送。如果您担心成本问题，SQL Server的后期版本在Standard Edition中有可用的基本可用性组，而在2016年之前，标准版中有数据库镜像-当然，在所有版本中都使用代理进行日志传送。

查看这篇关于日志运输的文档文章。它是您最好的低成本、低复杂度的解决方案，并为您提供了复制不具备的功能，例如事务一致性。

与复制相比，具有以下优势：

• 交易一致。
• 自动包含整个数据库、所有表、视图、procs等。
• 成本低，易于实现。
• 可在标准版中获得

请参阅这篇关于总是在可用性组上的文档文章，这是Server的更好的HADR解决方案之一，以及一些关于基本AGs的其他信息。

与复制相比，具有以下优势：

• 事务一致
• 自动包含整个数据库、所有表、视图、procs等。
• 通过使用侦听器自动重定向客户端。
• 根据版本\edition\licensing，可以实现多个副本以实现HADR解决方案。
• 在标准版中提供基本的AGs。
• 故障转移后数据的自动反转
• 执行数据移动不需要代理作业

最后，看看这篇关于数据库镜像的文档文章，如果您运行的版本或版本不支持AGs或基本AGs。

与复制相比，具有以下优势：

• 事务一致
• 自动包含整个数据库、所有表、视图、procs等。
• 可在标准版中获得
• 故障转移后数据的自动反转
• 执行数据移动不需要代理作业