请给我一些建议。
我已经为我的 SQL 2019 可用性组配置了自动种子设定。我的两个集群节点各有 8GB RAM 和 4 个处理器。实例中较小的数据库已成功添加到 AG，没有任何问题。但是，当我尝试将其添加到 AG 时，一个30GB 的数据库不断警告数据和日志文件的可用磁盘空间不足。数据文件存储有大约 70GB 的空闲空间，日志存储大约有 74GB 的空闲空间。
我忽略该消息并继续将数据库添加到 AG，并得到如下不同的行为：
有时它似乎已成功添加到 AG，因为 SSMS 仪表板显示 AG 健康。然而，sys.dm_server_hadr_automatic_seeding DMV 有时在一个节点上显示播种状态为已完成（failure_state_desc = NULL），而另一个节点失败（failure_state_desc = 检查是否需要播种）。有时两个节点都失败了。
有几次我有一个 SQL 转储错误日志
有一次，它似乎成功了，但我无法在 SSMS 中刷新辅助节点连接，并得到了一个 SQL 转储错误日志
在所有情况下，我都发现任务管理器中的内存使用率飙升至超过 4GB。我的 SQL Server 配置的最大内存约为 5GB。
请注意，此新部署的旧系统不使用 AG 技术，它使用更小的磁盘空间来存储数据和日志文件，并在其旧版本的 SQL 上成功运行。
请问我的问题：
- 是否已知自动播种会占用大量内存和/或磁盘空间？
- 如果是这样，如果我仍然想使用自动播种，有什么办法可以解决这个问题吗？
- 我应该查看节点的规格还是最好使用手动播种？
我已经对这个问题做了很多研究，但如果有人能够提供一些建议，我将不胜感激。
谢谢
取决于你对“很多”的定义。自动播种在主服务器上进行 VDI 备份，并将恢复流式传输到（每个）播种辅助服务器。备份使用缓冲池之外的隐藏调度程序和内存。因此，迂腐地，自动播种本身不会，但是底层进程的一部分会。
如果您有一个微型服务器（我个人认为 8 GB 和 4 个 CPU 是一个非常小的服务器），那么这将占用比大型服务器（例如 24 个内核和 128 GB 内存）更大的总体资源百分比。
此外，自动播种可以同时运行 5 个会话，这意味着如果您有 5 个或更多的数据库需要播种，这些数据库都将运行备份和恢复，这意味着您的系统需要能够处理那么多的并发项目。
不是真的，不。我敢打赌，如果你给服务器更多的磁盘空间 + cpu + 内存，它就会很好地播种。
我不相信我们可以回答这个问题。我们不知道为什么它们的大小是这样的，或者可能会涉及哪些潜在的选择或决定。例如，是否存在许可成本、基础设施限制、没有足够的并发工作负载来证明等等。