标签: mirroring

我负责管理多个 SQL Server 实例，其中大多数使用 SQL Server 镜像来复制数据以用于 DR 目的。

我会自动为镜像编写登录、角色和作业的脚本，在发生故障转移时，我们实际上需要运行一个脚本来使镜像联机、应用登录、应用滚动和作业，然后它们就会消失（给予或采取一些不匹配的 SID 和通常的小问题）。

现在，我已经记录了这个故障转移过程，以防万一发生故障时我不在现场；然而，管理层认为这个过程过于复杂，并一直试图推动诸如DoubleTake等可以进行实例级复制的3rd方复制产品。

（公司不想在实例级别使用集群，因为共享存储将成为单点故障——他们不愿意购买多个复制 SAN。）

我们拥有从几兆到 200GB+ 的数据库。

以这种方式，DoubleTake 对于 DR 真的实用吗？我可以相信数据会在主要和次要之间保持最新吗？（正是出于这个原因，我们运行高安全模式镜像。）

我在论坛上读过很多意见，但总是有偏见或未经证实；我对这些产品有一些第一手的经验。

我们使用 SQL Server 2008 R2 标准版进行镜像。

但是我们发现网络延迟太高了。当镜像处于活动状态时，完成一个事务需要将近四倍的时间。是否可以用直接交叉电缆连接这两个服务器并强制sql server使用此链接进行镜像？那会有帮助吗？

我们已经在这两个服务器之间设置了交叉电缆。但是我们如何配置sql server使用这个链接进行镜像呢？

任何帮助将不胜感激。

我的公司有一对 SQL Server 2005 实例的故障转移对，它们为 UL 许可的警报/呼叫中心提供数据库可用性，其中正常运行时间和可用性对生命安全至关重要。

下面是来自其中一个关键业务应用程序的 connectionStrings 的示例行（为了我们的保护而进行了消毒）：

<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
 connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
 Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
 providerName="System.Data.SqlClient" />

大约半小时前，这是我们认为的场景：

1. DBA 在指定时间向所有用户报告 Principal-DB 服务器上的硬件维护需求，并建议他们在遇到数据库连接问题时关闭并重新启动客户端应用程序。
2. DBA 从主体数据库故障转移到镜像数据库。客户端应用程序不受影响。
3. DBA 关闭 Principal-DB 服务器。
4. 某些客户端应用程序开始在池连接上超时（正如预期的那样）。遇到这些错误的用户按照 DBA 的建议关闭并重新启动。
5. 由于无法从数据库接收响应，这些客户端应用程序现在无法完全启动。
6. 欢闹随之而来。

我们的理论是，因为主要-DB不在状态，以响应连接请求在所有的，当它通常会迅速地拒绝这样的连接，如果它是在恢复状态，客户端应用程序结束了等待整个分配连接超时（默认为 20 秒）让主服务器响应，然后返回超时错误，而无需尝试连接到列出的故障转移伙伴。

快速修复是将更新推送到包含交换数据源和故障转移伙伴实例的 App.config 的客户端应用程序，因此 Mirror-DB 现在是应用程序首先尝试连接的服务器。当我们故障恢复到 Principal-DB 时，我们将不得不使用另一个应用程序更新来撤消此更改。

我需要一个更永久的修复。这不是故障转移对的预期行为，并且不允许再次发生。必须有一种方法来配置客户端应用程序，以便它在返回错误之前在这种情况下正确尝试连接到故障转移伙伴。

我一直在尝试找出相同的 CPU 限制数据库镜像是否适用于可用性组。我的猜测是存在相同的限制，因为可用性组是基于与镜像相同的技术构建的，因此以下内容仍然适用。

• 主体服务器：每个镜像数据库有 1 个全局线程和 2 个线程。
• 镜像服务器： – 64 位架构：1 个全局线程，每个镜像数据库 2 个线程，每个镜像数据库每 4 个处理器核心一个附加线程。

这样对吗？谢谢！

我们刚刚将我们的 Windows Server 2003\SQL Server 2005 设置升级到 Windows Server 2012/SQL Server 2012。两种配置都有一个没有见证服务器的镜像。

在旧设置中，事务日志仍然很小，总共大约 22 GB。现在它们已超过 160 GB，并且新服务器的分区已满。我需要减少事务日志文件的大小。

但是，我读过的所有描述都说要将恢复模式从完整切换到简单，然后再切换回完整。这是行不通的，因为我们有一个镜像，所以恢复模式必须保持在完全恢复模式。除非打破镜像，否则我无法更改恢复模式。

减少日志文件大小的最佳行动方案是什么？我应该继续打破镜子，从完整->简单切换回来吗？有没有人有这种设置的经验？

对于 SQL Server 2008 R2 中的异步镜像，需要使用完整恢复模型。

假设Mirror两边的网络和磁盘IO都可以跟上事务日志和镜像，那么这种没有镜像和简单恢复的数据库还有性能损失吗？如果是这样，什么类型的操作会受到影响以及是什么导致它们受到影响？

问题是我有两个相同的数据库，一个在我的笔记本电脑的本地主机服务器上，另一个在办公室的主服务器上。是否有任何自动方式或软件可以同步这两个相同数据库之间的数据？我正在使用 SQL Server 2008 R2。

我们有两个数据中心，它们之间的 ping 时间为 2 ms，通过站点到站点 VPN 连接。在主数据中心，我们有 2 台服务器，在辅助数据中心，我们有一个数据库服务器。所有服务器的规格和配置都相同，运行 Windows 2012 R2，我们有两个 SQL Server 2016 Enterprise 许可证。一种用于主站点 + 故障转移，一种用于辅助站点。

问题是我们应该使用什么技术？始终在可用性组上，在主数据中心的两个节点之间进行同步复制并异步复制到辅助数据中心。另一种选择是在主数据中心使用镜像，然后将日志传送到辅助数据中心。唯一需要注意的是，我们需要使用透明数据加密 (TDE)，因此需要使用企业许可证。

我们的运维团队目前有 2 人并且在不断增长，但还没有完全分配 DBA，我知道如何设置这两种技术，但只在生产中使用过镜像和日志传送。

人们会推荐什么，always on 看起来很棒，但我读过一些文章说你需要大量的 DBA 资源来照顾它，而镜像和日志传送要容易得多。

我知道在 SQL Server express 版本中做镜像之类的事情是不可能的，但是我们可以做实时数据库备份和恢复，并设置一些像镜像一样的自动化任务并使它们保持同步。

我相信在数据库镜像中改变主数据库的兼容模式会改变镜像数据库。

但事实证明这是错误的。我sys.databases在 Primary 上查询使用，我将兼容模式更改为 120 ，但是在其镜像数据库兼容级别仍然是 100。为什么？

我在 sys.databases 中使用了不正确的 fn 吗？

此外，如果它没有改变它的含义，我是否需要进行故障转移/故障回复来反映？

如果我有只读日志传送辅助数据库以及此更改需要反映的地方怎么办？那我需要重建日志传送吗？

谢谢