Ранее мне прислали интересный вопрос о том, почему человек видит множество VLF (виртуальных файлов журнала) в журнале со статусом = 2 (что означает «активный») после очистки (также известной как «усечение») журнала, при том что log_reuse_wait_desc показывает NOTHING.
Я немного покопался и всё, что смог найти, — это старая запись в блоге от 2013 года, которая демонстрирует это поведение и упоминает, что оно происходит при зеркальном отображении и в группах доступности. Я не слышал об этом поведении раньше, но предположил причину и подтвердил её с командой SQL Server.
Когда вторичная реплика AG (группы доступности) должна быть добавлена, на тот момент времени максимальный LSN (номер последовательности журнала для самой последней записи журнала), присутствующий в восстановленной копии базы данных, которая станет вторичной репликой, должен быть частью «активного» журнала на первичной реплике AG (т.е. этот LSN должен находиться в VLF на первичной реплике, имеющем статус = 2). Если это не так, вам необходимо восстановить ещё одну резервную копию журнала на будущей новой вторичной реплике и снова попытаться выполнить процесс присоединения к AG. Повторяйте, пока не получится. Можно представить, как для очень загруженной системы, генерирующей множество записей журнала и с частым резервным копированием журнала (которое очищает журнал на первичной реплике), может быть сложно «догнать» вторичную реплику, чтобы позволить ей присоединиться к AG, или может потребоваться временно остановить резервное копирование журнала на первичной реплике (что потенциально открывает окно для увеличения потери данных в случае аварии).
Чтобы упростить весь этот процесс, когда база данных является первичной репликой AG, при очистке журнала VLF не переходят в статус = 0; они остаются «активными» со статусом = 2. Как это помогает? Ну, тот факт, что намного больше VLF остаются «активными» на первичной реплике AG, означает, что с большей вероятностью максимальный LSN новой вторичной реплики всё ещё будет частью «активного» журнала на первичной реплике, и присоединение к AG завершится успешно без необходимости повторять процесс восстановления-повторной-попытки-присоединения снова и снова.
Примечание: диспетчер журнала знает, что эти VLF на самом деле «псевдоактивные», и может повторно использовать их, как если бы они были «неактивными», если журнал совершит полный цикл (см. Поговорим ещё о циклической природе журнала транзакций), так что регулярные операции на первичной реплике AG не прерываются.
Это умный маленький механизм, который кто-то придумал, чтобы сделать жизнь администратора баз данных немного проще, а настройку групп доступности менее проблематичной.
И теперь вы знаете — очистка журнала не всегда устанавливает статус VLF в ноль.
Комментариев нет:
Отправить комментарий