Questions tagged «availability-groups»

可用性组是SQL Server 2012的一项新功能，可为一个或多个SQL Server数据库提供连续的数据同步，自动故障转移和辅助读取访问。

1
谁在使用我的工作线程？SQL Server 2014-HADR
最近，我们在SQL Server 2014 HADR环境中遇到问题，其中一台服务器的工作线程不足。 我们收到消息： AlwaysOn可用性组的线程池无法启动新的工作线程，因为没有足够的可用工作线程。 我已经打开了另一个问题，以获得一个（我认为）应该帮助我分析问题的语句（是否可以查看哪个SPID使用哪个调度程序（工作线程）？）。尽管现在有了查询来查找正在使用系统的线程，但我不明白为什么该服务器用完了工作线程。 我们的环境如下： 4 Windows Server 2012 R2 SQL Server 2014企业版 24个处理器-> 832个工作线程 256 GB内存 12个可用性组（整体） 642个数据库（整体） 因此，出现问题的服务器具有以下配置： 5个可用性组（3个主要/ 2个辅助） 325个数据库（127个主要/ 198个次要） MAXDOP = 8 Cost Threshold for Parallelism = 50 电源计划设置为“高性能” 为了“解决”该问题，我们手动将一个可用性组故障转移到辅助服务器。该服务器的配置现在为： 5个可用性组（2个主要/ 3个辅助） 325个数据库（77个主要数据库/ 248个辅助数据库） 我正在使用以下语句监视可用线程： declare @max int select @max = max_workers_count …
1
升级后，SQL Server AlwaysOn数据库卡在“不同步” /“恢复”模式下。错误：无法打开数据库“…”版本782
测试从SQL Server 2014 SP1（12.0.4422.0）到SQL Server 2016 CTP 3.2（13.0.900.73）的升级时，我遵循建议的更新过程，并遇到了故障转移后数据库无法在旧主数据库上启动的问题到更新的中学。我们的设置是一个主副本和一个辅助副本，我完成的步骤是： 在同步提交的辅助副本上删除自动故障转移 将辅助服务器实例升级到新版本 手动故障转移到辅助副本 验证数据库在新的主副本上是否在线 将以前的主副本升级到新版本 辅助服务器的升级和故障转移以使其成为主要服务器，完全可以按预期进行。但是，在升级了先前的主副本之后，我注意到其上的数据库在SSMS中被列为“ 未同步/正在恢复”。同样尝试访问它们也会生成错误消息： 数据库...不可访问。（对象浏览器） 通过我看到的SQL Server日志进行检查 无法打开数据库“ ...”版本782。将数据库升级到最新版本。 查询master..sysdatabases表表明它确实是一个较旧的版本，并且在升级过程中未进行更新： 不幸的是，日志没有指出为什么不对其进行更新，并且可用性组仪表板仅给出一般性警告，指示某些可用性数据库的数据同步状态不正常，没有任何原因。 我尝试使用TSQL分离数据库或将其设置为脱机以“踢”数据库以进行更新，但是由于它们是SQL AG的一部分，因此这些命令不起作用。 如果数据库是SQL AG的一部分，如何将其升级到最新版本？
6
具有只读应用程序意图的SSMS注册服务器
我们正在使用AlwaysOn进行SQL Server 2014 POC测试，其中一位用户被问到如何使用本地服务器组中注册的服务器使用ReadOnly Intent 保存SSMS的配置。这样，他们不必在每次需要访问ReadOnly副本时都键入别名。 不幸的是，与常规对象资源管理器不同，已注册服务器中没有添加ApplicationIntent选项的选项。 我从Microsoft那里碰到过有关更改RegSrvr.xml中的连接字符串的这篇文章。 https://connect.microsoft.com/SQLServer/feedback/details/786323/ssms-sql-server-management-studio-2012-missing-connection-properties-for-availability-groups 我尝试了他们的建议，当通过已注册服务器中的本地服务器连接时，它没有连接到正确的副本节点。 使用连接窗口>其他连接参数中的选项时，ReadOnly选项在对象资源管理器中可以正常工作。但是它不会保存对连接所做的更改。 有谁知道通过SSMS 使用ReadOnly Intent属性保存配置的任何替代解决方案吗？在此先感谢您的帮助。
2
AlwaysOn可用性组自动故障转移不起作用
使用AG设置，我启动了WSFC，并在一个称为DevClusterOnline的可用性组中配置了两个节点。两个节点（主要是DEV-AWEB5，次要是DEV-AWEB6）都运行Windows Server 2008 R2。 如果我检查AG的运行状况，则会得到以下信息： 运行以下查询将返回此结果集： select ar.replica_server_name, availability_group_name = ag.name, ar.availability_mode_desc, ar.failover_mode_desc from sys.availability_replicas ar inner join sys.availability_groups ag on ar.group_id = ag.group_id order by availability_group_name, replica_server_name; 如果断开DEV-AWEB5的连接，则无法连接到组侦听器（DevListener），但可以对其执行ping操作，并且它将响应我的ping操作。副本-DEV-AWEB6进入RESOLVING状态，并且无法访问我的数据库。但是，我可以手动进入Management Studio并将故障转移设置为DEV-AWEB6，然后重新启动并运行，DevListener将再次接受连接。 考虑到这些事实可确认故障转移确实有效，我已同步提交并配置了自动故障转移，因此我不知道安装程序是否出现故障该怎么办。 当我断开DEV-AWEB5的连接时，我希望我的副本将保持连接，因此，DevListener也将保持连接。我希望自动故障转移可以使我透明地连接到AG Listener。从最终用户的角度来看，使用Web系统应该不会注意到其中一台数据库服务器出现故障。 我被困在这里，有人可以启发我做错什么吗？
1
HADR高工作线程使用率
为什么HADR池中的可用性组的工作线程数会大大增加，而不是每个副本“ 通常有3–10个共享线程 ”的最低使用量？ 在一种情况下，我们观察到300个线程的使用情况，其中包含3个可用性组和10个数据库。SQL Server 2014 SP1。 我们的潜在客户包括辅助副本上的备份，主副本上的高活动性，辅助副本上的报告。 AG位于VMware的数据中心中。总共16个调度程序，通常的工作线程在200个范围内。服务器上的max_dop为2。 3个AG，10个DB，每个4个副本-主，2个只读，1个不可读。 1个辅助同步，2个异步 大型多主机群集上的32个物理核心上有16个vcore。 没有多余的准备。 其他较小的VM 4-8内核位于同一位置，但不会按CPU 我们观察到工作线程数量激增，导致拒绝服务。我们假设工作线程归因于AG，因为只有那些工作线程才能超过限制。 在上下文中阅读的来自SQL Server Premier现场工程师博客的以下链接没有给我完整的答案： 监视SQL Server 2012 AlwaysOn可用性组工作线程消耗 我的实际工作线程是否超出了sp_configure“最大工作线程”值？
1
无法截断事务日志log_reuse_wait_desc-AVAILABILITY_REPLICA
今天早上，我被我们的数据库之一的事务日志已满警报惊醒。该服务器是Alwayson群集，也是事务复制订阅服务器。我检查了log_reuse_wait_desc，它显示了logbackup。某人四天前不小心禁用了日志备份作业，我重新启用了日志备份作业，日志被清除。从凌晨4点开始，我想我将在那天早上晚些时候去上班，因为日志已经增长到400GB，所以请顺便去。 上午10点-我在办公室，我在缩小之前检查日志使用率，大约是16％。我很惊讶，检查显示复制的log_reuse_wait_desc。我很困惑，因为这是一个复制订户。然后，我们看到该数据库已启用CDC，并认为这可能是原因，因此禁用了CDC，现在log_reuse_wait_desc显示了AVAILABILITY_REPLICA。 同时，日志使用量仍在稳定增长，目前为17％。我检查了Alwayson仪表板，并检查了已发送和重做队列，两者实际上都为零。我不确定为什么日志重用显示为AVAILABILITY_REPLICA并且无法清除日志。 知道为什么会这样吗？
3
当您的Always On群集丢失仲裁时该怎么办？
我正在查看我们公司的灾难恢复程序，当我在网上寻找“始终在线群集”丢失仲裁的解决方案时，可以进行比较。在搜寻结果的第一篇SE帖子之前，我在Google搜索结果中浏览了三页，该主题仅涉及群集丢失，仲裁丢失等主题。 尽管每个人都认为失败的仲裁人数是有害的，并且有一些建议可以降低这种潜力，但仍然有可能发生。我正在寻找一个很好的同行评审答案，以解决从Always On群集丢失仲裁中恢复的最佳方法。
2
可用性组侦听器
我正在查看AlwaysOn可用性组。我越看越多，可用性侦听器组似乎是单点故障。监听器实际在哪里运行？一个单独的服务器，即主要的SQL服务器，都是吗？ 假设我在第二个数据中心拥有整个应用程序堆栈。如何配置侦听器，使它们将在两个站点上运行，并且应用程序将指向它们自己的本地副本？ 我确定我在这里遗漏了一些东西，但我不知道。
3
Always On可用性组，始终将用户重定向到只读实例
我们有一个Always On可用性组，其中有一个主服务器和一个已启用读取的辅助服务器。我们的实施团队有一个用户，该用户使用数据库检查他们打算放入数据库的数据的正确性。 用户仅具有读取数据库的权限，但是当用户通过AG Listener连接（通过SSMS）时，他们始终连接到活动节点。 我试图让他们直接访问只读实例，但是它们陷入了困境，在一两天之后，它们又又回到了活动节点上。 SQL Server是否可以通过某种方式说出该用户始终具有只读意图，并将其重定向到那里？ 注意：我尝试在其他连接参数中设置'ApplicationIntent = ReadOnly'，但这似乎没有重定向到辅助节点，也不是理想的解决方案，因为它们不可避免地会忘记为新的启动程序进行设置。 SQL Server 2012 Enterprise，可用性组1个主要的，1个可读性次要的同步提交。 我不打算让用户连接到链接服务器或通过任何其他服务器。用户通过SSMS（没有其他应用程序）直接连接到数据库，并且我希望AG侦听器（或附近的东西）能够将用户定向到辅助节点（如果有）（因为那里只有读取访问权限）无需用户做任何事情就可以访问主数据库，因为用户在计算机之间移动并且会忘记添加应用程序意图。另外，我发现将其添加到其他连接参数并不总是将您定向到辅助节点。
1
可用性组可以提供无缝的故障转移（没有查询失败）吗？
我一直在测试SQL Server 2012中的“可用性组”功能，发现主服务器故障转移到辅助服务器时大约有15秒的停机时间。在此期间执行的所有SQL查询都将失败，直到完成故障转移转换为止。 有什么办法可以将其降低到0秒并防止在故障转移过渡期间查询失败？ 换句话说，是否有一种方法可以使故障期间运行的所有查询都重定向到主服务器而不是失败...，并且有任何方法可以使新的数据库连接立即连接到辅助服务器，而不会失败在故障转移过渡期间连接？ 我目前在可用性组中设置了2台服务器。
1
使用的数据库镜像协议TCP端口。一种默认，一种动态？
在SQL Server Always On可用性组™的主/辅助副本上执行以下查询时 SELECT DISTINCT local_tcp_port,protocol_type,num_reads,num_writes FROM sys.dm_exec_connections WHERE local_net_address is not null; 显示两个用于数据库镜像协议的本地tcp端口，5022＆63420 Server Name local_tcp_port protocol_type num_reads num_writes ServerName 5022 Database Mirroring 102942598 5 ServerName 63420 Database Mirroring 5 89655349 该5022端口是预期的，因为它是配置为镜像端点的端口。 另一个似乎是一个动态端口，为什么使用这个端口？ 它可能与以下事实有关：一个显示大量的读取（5022），而另一个显示大量的写入（63420）。 内部版本：13.0.5264.1
3
在只读副本上长时间运行的查询会占用主数据库上的时间
我有一个4节点AG设置，如下所示： 所有节点的VM硬件配置： Microsoft SQL Server 2017企业版（RTM-CU14）（KB4484710） 16个vCPU 356 GB RAM（长话短说...） 最大并行度：1（根据应用程序供应商的要求） 并行成本阈值：50 服务器最大内存（MB）：338944（331 GB） AG配置： 节点1：主节点或同步提交不可读的辅助节点，配置为自动故障转移 节点2：主节点或同步提交不可读的辅助节点，配置为自动故障转移 节点3：具有异步提交的可读辅助集，配置为手动故障转移 节点4：具有异步提交的可读辅助节点集，配置为手动故障转移 有疑问的查询： 此查询没有什么疯狂的，它提供了应用程序内各种队列中未完成工作项的摘要。您可以从下面的执行计划链接之一查看代码。 主节点上的执行行为： 在主要节点上执行时，执行时间通常约为1秒标记。这是执行计划，以下是从主节点从STATISTICS IO和STATISTICS TIME捕获的统计信息： (347 rows affected) Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, …
4
“ AlwaysOn”不总是“ Always On”吗？
我们创建了Windows故障转移群集，然后添加了两个SQL Server实例作为SQL Server故障转移群集的节点。 我们在SQL Configuration Manager中将服务器设置为使用“ AlwaysOn可用性组”。 为了测试故障转移，我加载并运行了一个长查询，然后通过使用故障转移群集管理器停止活动节点上的群集服务来关闭活动节点。 查询在没有连接的情况下中断，服务器在节点耗尽并新节点接管之前的20秒钟内显示为不可用。 我做错了吗？我应该如何配置它，以确保几乎没有连接丢失？ AlwaysOn是否不总是开启？
1
AlwaysON从2014年迁移到2016年
我喜欢2014年的20个Listners，大约有500 DBS， 用最少的时间和精力来迁移这些文件的最佳方法是什么 我的想法是：停止访问备份数据库开始还原数据库运行还原时：在2014上删除AOG在2016上创建AOG完成 这似乎很简单，但是使用TB数据将需要一些时间。 已找到此-> 从2014年升级到2016年的AlwaysOn AG的推荐方法， 但是它确实解释了 希望有人能帮忙
1
从2014年升级到2016年的AlwaysOn AG的推荐方法
建议Availability Groups使用一个同步副本从SQL 2014 升级到2016 的建议过程是什么？ 我的理解是，in-place升级并不是数据库专业人员真正喜欢的。有没有办法避免in-place升级Availability Groups？是否有可能将2016年服务器加入现有的2014年可用性组并在其中进行故障转移，然后“杀死”其他实例之一并对其进行升级？（例如，通过在同一主机上并排删除/重新安装SQL） 还有其他应考虑的升级方案吗？ 理想的解决方案是我们始终有2个online副本，并且不需要进行任何in-place升级。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.