问始终关注侦听器行为-从组中移除DBs

EN

我们的计划是从主要实例上的AGs中删除数据库，但让侦听器就位，因此应用程序仍然应该通过VIP/DNS连接到DBs。我们不能暂停运动，因为停运可能很长，MS建议运动暂停一段时间。

我不会从可用性组中删除主节点上的数据库。

但是，我将从可用性组中删除受影响的次要副本。移除它们将完成两件事：

1. 由于这些是辅助副本，数据库将返回到restoring状态。这将在未来有所帮助。
2. 允许主副本和未受影响的辅助副本保留在可用性组中，并继续进行日志备份和重用。

在从AG中移除次要副本期间，继续正常地进行日志备份。这将促进日志的重用，使其不会失控。将这些日志备份保持在方便的位置，并随时准备执行。

一旦受影响的次要副本不再受影响，则复制在辅助副本退出AG时所进行的所有日志备份，并将日志备份应用于这些数据库。在应用日志备份时，通过在每个日志还原上选择WITH NORECOVERY，确保数据库处于还原状态。

最后，挂起日志备份，并恢复在恢复旧日志备份时采取的任何最终备份。这将使先前删除的二级副本上的数据库与主副本和任何其他二级副本的时间框架相同。

一旦应用了最后的日志备份，并且数据库仍然处于恢复状态，则将副本添加回AG。当发生这种情况时，由于数据库仍处于恢复状态，并且已恢复到最后一次日志备份，AG将能够无问题地加入副本和数据库。在很短的时间内，复制品将需要赶上。

二级副本和数据库重新连接后，恢复正常的日志备份。

这将是理想的过程，因为它保持AG不变(对于任何未受影响的次要副本)，继续利用侦听器为您的应用程序，仍然可以提供HA和在某种程度上DR取决于副本可用，继续允许日志备份和重用，保持透明的最终用户。

您的事务日志文件有多大？我准备试着让他们断开连接，如果没有重新索引，批量操作等继续在停机期间，如果你可以100%的信心，它将只有6个小时。

在我的经验中，OLTP事务日志的增长通常是适度的，如果您的t-日志是一个合理的大小，您应该会没事的。

虽然很难进行测试，因为正常的OLTP事务吞吐量是很难模拟的，尽管用于重放的分析可能是测量它的一种方法。