我有一个在单个服务器上具有多个 AG 的环境，它们遇到分裂情况，其中一些最终在一个节点上，而另一些最终在另一个节点上（可能是在故障转移事件中）。当维护任务（重新索引、更新等基本范围）在这些节点上执行时，它们只会在各自 AG 的主端上的 read_write 数据库上有效地执行操作。这会导致作业失败，因为数据库在辅助节点上是只读的。因此，在分裂 AG 的情况下，两个节点都会在作业历史记录中显示维护失败。
不用说，很难监控这些集群。我提出了两种可能的管理解决方案。我们要么根据数据库的可更新性属性使用 DBCC 命令为各个数据库编写维护任务脚本，要么仅将自己限制为每台服务器一个 AG。他们不喜欢这两种解决方案。有谁知道我可以保留内置 SQL Server 维护任务并让它们仅针对主数据库的方法？
我担任 DBA 已有大约 2 年了，对于 AlwaysOn 可用性组，我仍然不了解一些微妙之处。首先，据我所知，它们只不过是麻烦，主要是因为我们环境中经常发生的情况。
我们每月为 Windows 打一次补丁，预计服务器会重新启动。大约每月一次，我们会遇到这样一种情况，即具有多个可用性组的集群在集群的节点之间进行自我划分。
如果我要安排备份作业，我通常会从主服务器通过多服务器管理来管理这些作业。我在侦听器的分辨率下执行此操作，因为它连接到可用性组的主节点。问题是，如果我指定“所有数据库”，则整个节点都会尝试备份，无论给定可用性组的主要/次要状态如何。
因此，我们的监控解决方案中会产生大量噪音，因为任何具有分散可用性组的集群都会返回备份失败状态，因为失败发生在尝试进行正常备份（而非仅复制）时二级股份公司。
在这些情况下，我是否必须编写作业脚本才能由可用性组运行？
是否存在仅备份该节点的主要可用性组的设置组合？
我提出了合并组的论点，以便我们可以通过 SERVER 而不是 AG 进行管理。我的老板争辩说我们应该使用 AG 来跨集群进行负载平衡，这样我们就不会为仅用于 HADR 的节点支付 SQL 许可证。我已经提出了这些漫射 AG 可能出错的所有内容，但也许有一些我不知道的事情。
为清楚起见，我知道我们可以将侦听器指向不同的 AG，并且它们将连接到其各自节点的主节点。我似乎无法管理任何类型的通用备份计划，这些计划不会针对这些拆分的 AG 情况产生监控和写入功能冲突。任何人都可以提供的任何清晰度将不胜感激。