标签: high-availability

我知道要实现在线应用程序的某种程度的可用性，可以使用 IP 故障转移机制组织一个具有冗余的环境，并在多个相同服务器之间切换，以防其中任何一个出现问题。

但是数据库呢？数据库应该在每台服务器上，它们之间有某种复制数据，还是应该放在自己的专用服务器上？

SQL Server 2008 R2 或 SQL Server 2008 R2 Express 通常使用什么方法？

如何查看集群主节点的故障转移历史？我试图弄清楚辅助节点是在什么时候开始充当主要节点的。

我们正在运行带有 SQL Server 2012 和可用性组的 Windows Server 2012。

我们计划在 SQL Server 2008 R2 的 2 个节点上创建一个事务复制，每个节点将是一个发布者和一个订阅者。

完成此场景的最佳实践是什么？微软一直建议分发者应该独立于发布者或订阅者，因此很明显，场景中要涉及到第三个节点。但是，由于每个节点将同时是发布者和订阅者，同一个（第三个节点）可以成为 2 个发布者的分发者吗？我应该创建 2 个分发服务器，还是仍然可以使用相同的架构，只使用 2 个节点，每个节点都充当分发服务器和发布服务器？

我有两个带有 MSSQL2012 的节点，它们与 AlwaysOn 高可用性一起工作

在一些崩溃之后，我不得不从节点之一上的可用性组中删除 db。为了恢复，我已经在第二个节点上备份了数据库（完整+日志），并根据标准程序在崩溃的节点上恢复了它。看起来完全没问题，但我遇到过，当我将主要角色赋予恢复的节点时，应用程序服务（使用 Service Broker）不做任何事情。

sys.databases 说对于我的数据库 is_broker_enabled=1，但我发现了几篇关于必须显式启用还原数据库上的代理的文章。

由于 AlwaysOn，SET ENABLE_BROKER 失败。

Internet 说激活服务代理的唯一方法是使用 ENABLE_BROKER 选项再次恢复数据库。但是为了将 db 添加到 AlwaysOn，我必须使用 NORECOVERY 恢复它。

试图运行

RESTORE DATABASE [dbname]
FROM  DISK = N'D:\111.bak'
WITH  NORECOVERY, ENABLE_BROKER

我已经看到有关这两个 WITH 选项之间冲突的通知

有人知道进行这种恢复的正确方法吗？db 超过 150GB，检查每个版本总是需要两个多小时:)

提前致谢

我需要在使用 FileStream 的数据库上设置数据库复制（以实现高可用性）。这是在 SQL Server 2012 标准版上，所以永远在线或对等复制不是一个选项。此外，数据库镜像不适用于 FileStream。

我剩下的唯一选择是事务复制或合并复制。我发现当所有机器都打开时，两种复制类型都可以正常工作，但是如果一台机器关闭会发生什么？

这就是我所拥有的（服务器作为虚拟机在 Microsoft Azure 上运行）：

• 服务器 A 是 DC 服务器
• 服务器 B 是 SQL Server 2012 标准版和应用程序服务器 (IIS)
• 服务器 C 是 SQL Server 2012 标准版和应用程序服务器 (IIS)

Microsoft 每月至少执行一次维护，每次最多关闭一台服务器。如何在这些机器上设置复制，以便在一台服务器关闭时实现高可用性？

我知道这个问题一定有一个简单的答案，但我在任何地方都找不到。我们的 SQL 2012 FCI 在其 MSSQL\LOG 文件夹中有 SQLDIAG .XEL 文件。在某些情况下，这些文件通常正好为 100MB，但在 SSMS 中打开时却显示为空（表示显示 0 个事件）。

如果可能的话，我需要知道如何管理它们的最大大小和文件保留时间。

我们有一些来自 SQL 2008 FCI（升级到 SQL 2012）的根驱动器挂载点，这些挂载点只有 1GB。您可以猜到，这些挂载点正在填满，如果可能，我需要限制这些故障转移群集诊断日志，否则我将不得不提出替代解决方案。

在 2 节点 Windows Server 故障转移群集配置中，如何重新启动 SQL Server 服务而不故障转移到其他节点？

最近，Microsoft 发布了 Configuration Manager (1601) 的技术预览版 4。根据 TechNet，“Configuration Manager 现在支持使用 SQL Server AlwaysOn 可用性组来托管站点数据库。安装新站点时，您可以直接安装以使用可用性组而不是 SQL Server 的普通实例。”

然后他们注意到“可用性组的成功配置和使用要求您熟悉配置 SQL Server 可用性组，并依赖于 SQL Server 文档库中提供的文档和过程。”

目前，为 Configuration Manager 站点数据库创建容错和避免单点故障的最佳做法是在每个管理点安装 SQL 副本。我观看了几个概述视频（从 2013 年开始）以更好地了解 AlwaysOn 的工作原理。

在 DBA 社区中，AlwaysOn 是提供容错和避免 SQL 副本单点故障的更好解决方案吗？

完全披露者：我正在学习配置管理器并且对 SQL Server 有非常基本的了解，因此您的任何建议或建议将不胜感激。

最近我在我的 SQL 服务器中遇到了一个问题。请告知 AlwaysOn 集群背后的概念和机制。

背景：
我们建立了一个 AlwaysOn 集群，其中包含 1 个主节点dbs1和 1 个辅助节点dbs2。鉴于他们将可读的二级配置为“只读”。他们还创建了只读路由列表。每个指定“ ApplicationIntent=ReadOnly”的连接都将被重定向到dbs2.

问题：运行
的相同代理作业（用于从 mssql 到 MySQL 插入数据）dbs2不稳定 - 突然成功，突然失败。对于成功案例，代理会话将显示在dbs1而不是dbs2。

对于失败的情况，它显示一个错误

“无法连接到 SQL Server '（本地）'”——代理作业历史记录

“目标数据库位于可用性组中，并且当应用程序意图设置为只读时，当前可以进行连接访问”。-- SQL 错误日志

但是当我们将 readable secondary 更改为“yes”时，代理作业始终可以在会话开启的情况下成功运行dbs2。

我的问题：

1）只读意图的行为是什么？为什么代理工作失败？

2）即使它成功了，为什么会话是在dbs1而不是dbs2，因为代理工作被设置了dbs2？它与脚本中的插入/删除/更新命令有关吗？

3）只读意图和可读辅助选项是有什么区别？我已经测试过在指定“ ApplicationIntent= readonly”后后一个选项中的只读路由仍然有效

我真的很好奇他们的机制。请随时发表评论和讨论。谢谢。

附加信息（2017 年 8 月 4 日最新更新）：

以下是我的代理工作脚本。我可以ApplicationIntent=ReadOnly在上面指定“ ”吗？我很困惑，这个 T-SQL 没有在 SQL Server 表中写入任何数据，而是在另一个 MySQL 数据库中写入。为什么可用性组不让我通过？再次特别感谢 …

我在网上读了很多文章，但仍然很困惑为什么 Mongo CP、Cassandra AP、RDBMS CA ？将解释我的理解和疑问。

蒙戈

考虑这样一个场景，我有一个主人和两个奴隶。考虑

1. 写请求到达并发送给主设备。
2. 它仅在主设备上提交，但主设备在写入从设备之前就关闭（崩溃）
3. 直到重新选举master为止，写请求需要等待，系统不可用
4. 一旦前一个节点（在步骤 2 中崩溃的节点）返回，来自该节点的待处理写入将被写回从属节点。这称为最终一致性。

根据我的理解，由于步骤 3 和 4，Mongo 被称为 CP，其中 C 代表最终一致。正确的 ？

卡桑德拉

这里没有主/从模型，每个节点根据分片键接收其共享的写入和读取请求。

1. 写请求到达任意节点（称为协调节点）。
2. 协调节点根据分片键重定向到其中一个节点
3. 它已提交，但在写入其他复制节点之前节点已关闭（崩溃）。
4. 再次使用相同的分片键写入请求，现在协调节点将其立即重定向到副本节点（崩溃节点的副本）
5. 一旦前一个节点（在步骤 3 中崩溃的节点）返回，来自该节点的待处理写入将被写回到副本节点。那么 cassandra 似乎也是最终一致的？

步骤 4 解释了为什么 cassandra 具有高可用性，但步骤 5 也描述了其最终一致性。因此，根据我的理解，cassandra 提供了最终一致性和可用性。那为什么说它不提供一致性呢？