标签: availability-groups

我一直在研究 SQL Server 2012 的新功能，以及它如何帮助我目前的情况。

目前，我们使用 SQL Server 2008 R2，并通过事务复制将两个 OLTP 服务器的数据库复制到单个报告服务器。然后我们使用这些复制的 DB 进行报告。

我对 SQL Server 2012 和可用性组是否可以取代它感兴趣 - 所以我会使用新的可用性组而不是事务复制，并将两个 OLTP 服务器的数据库镜像到报告服务器 - 报告将能够访问只读副本。

我不确定这是否会奏效，甚至根本不会。

我想摆脱复制，因为它会导致我的部署策略出现问题（使用 VSDBCMD.exe）。我还想避免大型数据库上的复制重新初始化延迟。

有没有人有任何好的例子或经验？是否可以按照较低版本中的正常镜像将多个服务器的可读副本镜像到单个服务器？

这最初是在这里问的：https : //stackoverflow.com/questions/10415225/mirroring-and-availability-groups-in-sql2012对不起，我认为我还不能迁移问题。

我在 AlwaysOn 可用性组中设置了 2 个 SQL Server。

我还设置了针对数据库运行的作业。在故障转移期间，我如何确保作业将继续在辅助服务器上运行？我是否需要在两台机器上安装作业和 SSIS 包并在辅助机器上手动禁用它们...然后在故障转移的情况下手动启用它们？或者是否有内置功能来处理这个问题？

我们正在使用 SQL Server 2012 的 HADR（AlwaysOn 可用性组）功能。服务器和 AG 配置如下：

1. SQL12_SRV1 --> AG1(PRIMARY) - SYNC -->> DBTest

2. SQL12_SRV2 --> AG1(SECONDARY) -->> DBTest - ASYNC

DBTest 数据库每天都在增长 (200GB)，大约每月和相同的事务日志文件也将根据数据增长。

那么如何通过使用正确的日志备份方法来最小化事务日志文件大小。我们必须在哪个副本上进行日志备份。

提前致谢。

我需要快速说明仅复制备份与完整备份，因为它与事务日志编号和需要时的还原有关。

我有 SQL Server 2012 设置，始终为多个数据库打开。可用性组设置为副本上的首选备份。

副本上只能进行仅复制和事务日志备份。这是否意味着如果需要还原事务日志，我将需要在主服务器上进行完整备份？

谢谢

在我们所有的 AlwaysOn 设置中，在虚拟机和裸机上运行 Windows 2012 和 SQL Server 2012，我发现 log_send_rate sys.dm_hadr_database_replica_states始终返回不正确的值。

例如（对于同步模式）

sys.dm_hadr_database_replica_states.log_send_rate（ave = 36,571（以 bol 列出的 kb/s））

Perfmon - SQLServer：可用性副本 - 发送到副本的字节数/秒（最大值 = 486,000.000，平均 = 259,000.000）

Perfmon - SQLServer:Databases - Log Bytes Flushed/sec (max = 653,044.000, avg = 341,000.000)

我没有看到任何关于此的帖子，但它似乎无法正常工作。正确的log_send_rate值对于监视 AlwaysOn 很有用。

有没有其他人经历过这种情况？

首先我不得不说这个问题来自软件工程师的角度。不幸的是，我们没有 DBA，所以我们需要管理我们自己的数据库。

我们安装了 SQL Server 2012 Enterprise 来运行一个应该 24/7 可用的数据库。数据库大约 150 GB，一些表包含数十亿行。多个服务每分钟访问数据库数千次，以插入实时测量数据。所以当数据库宕机半小时，测量数据丢失半小时，这是我们承受不起的……

在这种情况下，我们有两个主要问题：

1. 我们何时以及如何安装 Microsoft 更新？
2. 我们如何应用架构更改？

我认为 Windows 更新不需要进一步解释。当新需求出现或现有需求发生变化时，我们有时需要进行一些架构更改。例如添加一些额外的列、更改数据类型、调整 varchar 字段的大小等。其中一些更改需要很长时间才能运行，甚至超时，因为数据库始终处于高负载下。

我们正在考虑安装一个额外的实例并启用 AlwaysOn，以完成以下操作：

1. 对于 Windows 更新，关闭一台服务器，安装 Windows 更新，重新启动，然后更新第二个实例。
2. 对于架构更改，关闭一台服务器，应用架构更改，将其恢复，然后将相同的更改应用于第二个实例。

这两件事可以通过 SQL Server AlwaysOn 来完成，这是一种常见的方法吗？数据甚至会在之后同步吗？还是我完全在考虑错误的方向，是否有更好的解决方案？

我们有一个由 2 个服务器组成的 Always On“集群”（还会有更多），所以一个是PRIMARY，其他是SECONDARY。这个想法是将 SECONDARY 用作只读副本，因此它在某种程度上是一个搜索服务器。

我知道如何在 C# 中设置 ConnectionString 所以它将使用 SECONDARY 副本 - 只需添加ApplicationIntent=ReadOnly.

但是如果我使用分布式查询，我不明白如何从存储过程中解决 SECONDARY。有没有办法为查询设置一些参数（如 WITH 语句或其他东西），因此查询将仅使用副本而不使用 PRIMARY 节点？

问题是，很明显，从一开始server1是 PRIMARY，server2是 SECONDARY，但是当server1 出现故障时，server2是 PRIMARY，server1在修复后将是 SECONDARY。所以我不能只使用静态server2的名称。

到目前为止，我已经设法将当前副本的服务器名称作为变量并在 EXEC 中使用它：

-- find first available replica
DECLARE @replicaServer nvarchar(50)

SELECT TOP 1
    @replicaServer = RCS.replica_server_name
FROM
    sys.availability_groups_cluster AS AGC
    INNER JOIN sys.dm_hadr_availability_replica_cluster_states AS RCS
          ON RCS.group_id = AGC.group_id
    INNER JOIN sys.dm_hadr_availability_replica_states AS …

SQL Server 2012 (11.0.5058.0) 企业版

我们在 2(HA)+1(DR) 集群中有 8 个可用性组，我们的监控 DMV 报告的结果让我感到困惑。6 个可用性组用于 HA 和 DR，1 个仅用于 HA，1 个仅用于 DR。

6 个 HA/DR 可用性组中的每一个都将“SQLB”作为主副本，将“SQLA”作为辅助（同步）HA 副本，将“SQLC”作为辅助（异步）副本。

在两个辅助节点上：

SELECT dhags.group_id, dhags.synchronization_health_desc
FROM sys.dm_hadr_availability_group_states dhags

报告所有可用性组复制同步运行状况NOT_HEALTHY和

select replica_id,synchronization_health_desc
from sys.dm_hadr_availability_replica_states

报告所有副本的同步健康状况为HEALTHY.

主副本报告同步运行状况为 的所有可用性组和副本HEALTHY。

虽然我知道一个报告副本同步健康状况，另一个报告 AG 同步健康状况，但在我看来，如果更细化 (AG) 状态不健康，这将影响更广泛上下文（副本）的整体健康状况，这似乎是合乎逻辑的. 我找不到描述如何在每个级别确定运行状况的 MSDN 文档。

为什么辅助节点会报告NOT_HEALTHY可用性组同步健康状况，但会报告HEALTHY副本同步健康状况，为什么这与主要报告不同？

Availability Groups使用一个同步副本从 SQL 2014升级到 2016的推荐过程是什么？

我的理解是in-place数据库专业人员并不真正喜欢升级。有没有办法避免in-place升级Availability Groups？是否有可能将 2016 年服务器加入现有的 2014 年可用性组并在那里进行故障转移，然后“杀死”其他实例之一并升级它？（例如，通过在同一主机上并排删除/重新安装 SQL）

是否还有其他我们应该考虑的升级方案？

理想的解决方案是我们总是有 2 个online副本，而且我们不需要做任何in-place升级。

我在 2014 年有 20 个听众，大约有 500 个 DBS，

以最少的停机时间和精力来迁移这些的最佳方法是什么

我的想法是：停止访问备份 dbs 开始恢复 dbs 在恢复运行时：在 2014 年删除 AOG 在 2016 年创建它完成

这看起来很简单，但是对于 TB 数据，这需要一些时间。

找到了这个 -> 从 2014 年到 2016 年升级 AlwaysOn AG 的推荐方法 但它也没有解释

希望有人能帮忙