Aar*_*ams 4 sql-server backup availability-groups
我已经成为 DBA 大约 2 年了，我仍然不了解 AlwaysOn 可用性组的一些微妙之处。首先，据我所知，它们只是麻烦，主要是因为我们环境中经常发生的情况。
我们每月打一次 Windows 补丁，预计服务器会重新启动。大约每月一次，我们会遇到这样一种情况，即具有多个可用性组的集群在集群的节点之间进行自我划分。
如果我正在安排备份作业，我通常会通过主服务器的多服务器管理来管理这些作业。我按照侦听器的分辨率执行此操作，因为它连接到可用性组的主节点。问题是，如果我指定“所有数据库”，则无论给定可用性组的主要/次要状态如何，整个节点都会尝试备份。
因此，在我们的监控解决方案中会产生很多干扰，因为任何具有分散可用性组的集群都会返回备份失败状态，因为失败发生在尝试在二级AG。
在这些情况下，我是否必须编写由可用性组运行的作业脚本？
是否存在仅备份该节点主要的可用性组的设置组合？
我已经提出了合并组的论点，以便我们可以通过 SERVER 而不是 AG 进行管理。我的老板认为我们应该使用 AG 来跨集群进行负载平衡，这样我们就不必为仅用于 HADR 的节点支付 SQL 许可证。我已经提出了这些漫反射 AG 可能出错的所有内容，但也许有一些我不知道的东西。
为清楚起见，我知道我们可以将侦听器指向不同的 AG，并且它们将连接到其各自节点的主节点。我似乎无法管理任何类型的通用备份计划，这些计划不会针对这些拆分 AG 情况产生监控和写入功能冲突。任何人都可以提供的任何清晰度将不胜感激。
可用性组感知备份脚本应该存在于可能托管每个数据库的主副本的所有节点上。这允许主动节点执行备份，避免来自数据库处于辅助或只读模式的节点的错误报告。
有几种出色的可用性组感知备份解决方案，例如来自Ola Hallengren或Midnight DBA 的 MinionWare Backup 的解决方案
| 归档时间： |
|
| 查看次数： |
206 次 |
| 最近记录： |