Eug*_*e P 5 sql-server availability-groups
有人可以指出我的 MS 文章或博客文章，其中详细解释了 AlwaysOn 可用性组辅助副本如何在辅助服务器长时间停机后赶上主要副本吗？
我使用 AAG 进行了以下测试（异步、手动故障转移、只读配置）。A）在连续插入主要实例期间杀死次要实例并在几分钟后启动次要实例。AAG 仪表板在二次重启后几乎立即变成绿色，并开始赶上主，直到两个实例的行数变得相同。没有完成事务日志备份。B) 与 A) 相同，但在测试期间从主服务器完成的事务日志很少。
问题是：
1）用于保存传输日志块（发送到辅助副本）的日志缓存/消息传递框架等的大小是多少
2) 是否可以配置/增加上述结构（日志缓存/发送队列等 - 无论用作 AAG 复制的传输）大小（类似于增加日志传输中的 tran 日志备份保留期，例如）？
3）当我在测试 B 中备份（截断）tran 日志时，次要副本自动与主要同步，用于查找主要和次要之间的行差异（显然不是 tran 日志，因为它被截断）然后同步?
4) 这个自动追赶过程是如何工作的，它的局限性是什么？
没有“缓存”。只是日志。主要日志是消息传递框架。主要写入日志文件，次要接收副本。连接后，辅助节点立即收到日志，主节点可以自由地重用日志。当断开连接时，主节点被禁止截断日志并且必须附加到它。当重新连接时，辅助节点接收到它错过的日志，并且主节点可以自由地再次重用日志，不再需要追加（增长）。
您在主服务器上进行日志备份不会改变任何内容。当需要为断开连接的辅助节点保留日志时，备份不会截断日志。
没有“消息”要发送到辅助节点以使其保持更新。辅助节点只是在数据库上运行恢复，仅此而已，应用从主数据库接收的日志。Write Ahead 协议保证无论从数据库中“恢复”的内容都与主数据库中的任何内容相同。
有一些优化（例如，当连接时，主服务器通常从内存而不是从磁盘发送日志）并且在日志流之外发送了一堆额外的控制消息，但这些细节分散了核心问题的注意力：次要只是运行恢复应用从主要收到的日志，并且主要必须保留所述日志，直到它被次要确认。
您的困惑源于认为备份已截断主服务器上的日志，因此必须有另一种机制来同步。这是不正确的，因为备份实际上并没有截断日志。
小智 4
如果辅助数据库已启动并正在运行，则当日志块刷新到磁盘时（因为它已满或提交），记录将被推送到主数据库上的日志写入器和主数据库上的日志扫描器（日志读取器）进程。主要同时。然后，日志扫描器与辅助服务器通信，然后辅助服务器将事务从主服务器上的日志扫描器拉取到辅助服务器并处理日志记录。主日志写入器不会推送事务，它只是与辅助日志写入器进行通信，它只是为了查看它是否已启动，以便它知道不必将副本标记为“未同步”。
当辅助数据库未启动时，日志编写器无法与辅助数据库通信，因此它将其标记为“未同步”，并将记录存储在主数据库的 tran 日志中。如果您查看 sys.databases.log_reuse_wait_desc 列，它应该显示 AVAILABILITY_REPLICA，这意味着主数据库挂在所有记录上。
一旦辅助节点启动，它将与主节点通信以请求日志扫描，然后处理事务并使用进度消息与主节点通信以指示强化的 LSN，大概主节点正在调整其 MinLSN，这反过来意味着MinLSN 之前的记录将在检查点发生时被删除，因此当您进行日志备份时，VLF 将被截断释放空间。
但简短的回答是，如果您的辅助设备发生故障，您需要尽可能大的日志文件，只要它发生故障。一旦备份并在某个时间同步，如果日志很大并且您不希望它那么大，您可能需要从始终在线组中删除数据库以缩小日志。