标签: clustering

这里的要求是存储历史日志。

为简单起见，我将假设这个示例场景，我们在我们的网站上销售一些产品，我们需要保留销售员每天销售的每种产品的销售记录。销售员和产品的数量是已知且恒定的。

现在，假设我们有 3 种产品在售，笔记本电脑、咖啡杯和笔。
这里我有这张表来记录今天的销售记录（实时记录，将全天更新）

CREATE TABLE IF NOT EXISTS sales_record (
    id SERIAL,
    salesman_id INT NOT NULL,
    sold_laptop INT NOT NULL,
    sold_mugs INT NOT NULL,
    sold_pen INT NOT NULL,
    PRIMARY KEY (id)
);

另一个表来保存旧数据的记录

CREATE TABLE IF NOT EXISTS sales_record_log (
    id SERIAL,
    salesman_id INT NOT NULL,
    sold_laptop INT NOT NULL,
    sold_mugs INT NOT NULL,
    sold_pen INT NOT NULL,
    record_for_day TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (id)
);

启动并运行它后，我们需要做的就是不断更新记录集并为每次销售将适当的列增加 1。

我们在此设置中遇到的问题是，必须在每天结束时将数据从实时表移动到另一个表并从实时表中刷新 …

• SQL Server 2008 R2 多实例集群（在 VMware vSphere 5.1 上）
• 2 个节点，每个节点运行 2 个实例（共 4 个实例）
• 每个节点 16GB RAM。

实例在同一节点上的唯一时间是我修补另一个节点时。

Brent Ozar 的“最大服务器内存”建议是保留 Windows 4GB 或 10%，以较大者为准。

由于这是一个集群，我应该如何在每个节点上设置最大内存？我应该将每个服务器视为独立服务器吗？这将确保每个节点上的内存不会浪费。但是，在节点故障时，所有 4 个实例的最大内存总量将超过单个节点的系统内存。在我们恢复第二个节点之前，这会在时间范围内导致任何问题吗？是否需要降低 4 个实例的最大内存设置，直到辅助节点恢复？或者 SQL Server 足够聪明以继续工作（如有必要，使用页面文件）。

我正在制作一个 2 节点 SQL Server 2012 故障转移群集；我需要安装 MSDTC 组件吗？

如果是，两者都可以安装在单个共享磁盘上吗？

我们计划为 SQL Server 2005/2008 故障转移群集设置静态端口。关于为每个集群的 4 个节点选择/选择什么端口的任何指南？（主动/主动）我还认为一些应用程序需要了解静态端口。了解哪个应用程序设置为使用来自 SQL 实例的默认端口的最佳方法是什么？一般来说，在 sql server 故障转移群集上实现端口号更改的最佳方法是什么？

我们遇到了一种情况，我们要迁移到新的托管设施并尝试配置我们的新数据库环境。然而，我们都不是正式的 DBA，所以我们所做的很多事情都是在尝试做出明智决定的同时猜测和阅读文章。

首先，我们目前是一家小公司，一个月要处理几十万条记录（其中大约 1/2 有图像数据）。我们正在快速发展，在发生严重故障（SAN 阵列完全瘫痪，我们在 12 小时内丢失所有内容）之后，我们正在迁移到具有更好灾难恢复能力的新托管设施。

新的托管设施将在 50 磁盘 SAN 上拥有我们的数据库。每分钟都会拍摄一张快照。如果 SAN 出现故障，快照会加载到另一个 SAN，并且服务器会自动在新的 SAN 上启动。停机时间为几分钟。

除此之外，我们还需要一个冗余的数据库设置。我们讨论了在 2 个单独的 SAN 上使用 DFS 的 Sql Server 集群，但这违反了我们必须拥有的 PCI 合规性。因此，我认为在 SAN 发生故障时，集群不会比托管公司的内置快照系统为我们带来更多的冗余。

我们正在讨论的另一个选项是使用镜像。但是，我们阅读的信息使我们相信，使用见证进行镜像会对性能影响太大。提出的一种选择是使用“Safety Off”镜像，直到我们想要执行维护，然后启动见证，一次关闭一台服务器并执行维护。然后，完成后，关闭见证服务器。这似乎两全其美，但也令人头疼。

那么现在最大的问题是 - 我们托管公司的快照系统将我们的停机时间缩短到几分钟，建议使用什么配置来提供高可用性和最佳性能？

我正在测试一个 2 节点 Windows 故障转移集群，在高安全模式下进行镜像和自动故障转移。我的镜像和见证服务器一样是独立的服务器。所有实例均为 2008 R2 RTM 企业版（64 位）（此为测试，亲测为 Express in prod）

因为当我将一个集群节点故障转移到另一个集群节点时（或者在我们刚刚丢失一个节点的情况下），我想防止故障转移到镜像，所以我提高了合作伙伴超时值。我的集群故障转移相当快，大约在 25 到 30 秒之间。但是，即使我将超时值设置为 59 秒，镜像数据库仍然故障转移到镜像服务器，而且速度相当快。

通常，我通过简单地将 SQL 资源从集群管理器中的一个节点移动到另一个节点来进行测试，但我也通过重新启动活动节点进行了尝试。当我故障恢复时也是如此。我可以关闭我的镜像服务器上的 SQL 服务（现在是原则），并通过查询 sys.database_mirroring，我看到镜像（前主体）以非常短的顺序更改状态和描述。

那么，我做错了什么或假设超时如何工作？

我们正在从旧的 SAN 迁移到新的 SAN，需要将我们的 SQL Server 实例迁移到新的 LUN。我们可以毫无问题地迁移数据，但 SQL Server 实例本身是集群的（单实例），并且集群磁盘也必须迁移到新的 SAN。

路径如下：

1. 在新的 SAN 上创建 LUN。
2. 向集群提供新的 LUN。
3. 将旧群集磁盘资源中的所有内容复制到新群集磁盘资源。
4. 将旧磁盘资源重命名为某物。
5. 将新磁盘资源重命名为旧名称。
6. 交叉手指。

或者

1. 在集群上重新安装 OS/Sql。

我们将不得不为 13 个实例执行此操作。

我有一个双节点 SQL 集群 (2008 R2)。

该 SQL 实例中的一些数据库被镜像到远程站点上的另一台服务器，使用具有自动故障转移的高安全性。这些数据库的镜像连接超时值设置为 90 秒。

当我将 SQL 从集群中的一个节点移动到另一个节点时，使用故障转移集群管理器应用程序的“将此服务或应用程序移动到另一个节点”选项，被镜像的数据库会立即故障转移到镜像。

这是不受欢迎的行为。我设置镜像连接超时值的原因是我只想在集群完全失败并且没有运行节点的情况下故障转移到数据库镜像。

有没有办法实现这一目标？感觉好像应该是可能的，否则混合集群和自动故障转移数据库镜像的概念将是行不通的，因为集群内的每个节点故障转移都会触发镜像故障转移。

谢谢。

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

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

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

所以我设置了我们的 SQL 服务器来通知我们严重程度为 17 或更高的警报（如各种 SQL Server 文章所建议的那样）。我对具有三个多子网节点的 SQL Server Always On Availability Cluster 的每个节点都执行了此操作。

上周末，我们从一个辅助节点收到了近一百条关于一条“仅供参考”消息的通知。其他节点没有这样做，警报似乎没有引起任何实际问题。警报是：

DESCRIPTION:    Skipping the default startup of database '<database>' because the database belongs to an availability group (Group ID: <...>). 
The database will be started by the availability group. 
This is an informational message only. No user action is required.

可能的罪魁祸首：我们的网络存在一些问题，节点可能正在断开连接并重新连接或超时。

我想我的问题是，是否应该采取任何措施来解决此警报？为什么它只影响我的一个节点？如果它确实是信息性的并且不需要采取任何措施，我可以配置我的警报以忽略这些警报吗？

根据评论，我查看了日志，似乎服务器一直在运行，但在那个时候它与始终在线的服务器断开了连接：

AlwaysOn Availability Groups: Local Windows Server Failover Cluster node is no longer online.  
The Availability replica is going offline because …