В конфигурации SQL Server Always ON - будет ли резервная копия журнала транзакций в конфигурации Nul breaks Always On?
Представьте, что в SQL 2012 AO участвуют два узла. Это тестовый экземпляр. Во время одной из операций по перестроению индекса журнал был очень большой (250 ГБ). Мы не можем поддержать это из-за нехватки места. Что если мы сделаем резервную копию Tlog для Nul (просто чтобы уменьшить его) - это сломает Always On?
1 ответ
AlwaysOn - это общий (маркетинговый) термин, который охватывает как группы доступности (AG), так и экземпляры отказоустойчивого кластера (FCI). Из контекста, я полагаю, вы спрашиваете об AGs?
И для FCI, и для AG краткий ответ один и тот же: выполнение резервного копирования журнала транзакций (независимо от места назначения) не нарушит ваши возможности высокой доступности. Тем не менее, я призываю вас НИКОГДА не делать резервные копии в NUL:, если вы не заботитесь о данных в вашей базе данных. Создание резервной копии журнала в NUL: (независимо от того, использовали ли вы AG, FCI или ни того, ни другого), вы нарушите цепочку резервного копирования журнала и предотвратите восстановление на определенный момент времени.
Если вы используете группу доступности, SQL Server не использует резервные копии журнала транзакций для синхронизации между узлами. Он использует сам журнал транзакций и поэтому не очистит журнал транзакций, если есть данные журнала, которые необходимо синхронизировать с другим узлом. То есть: если ваша синхронизация AG отстает, ваш журнал транзакций будет продолжать заполняться / увеличиваться до тех пор, пока синхронизация не начнется, независимо от количества выполненных операций резервного копирования журнала транзакций.
Есть несколько причин, по которым ваш журнал транзакций может продолжать расти, и синхронизация AG является лишь одной из этих причин. Если SQL Server не может повторно использовать журнал транзакций из-за несинхронизированных транзакций в AG, log_reuse_wait_desc колонка в sys.databases покажет значение "AVAILABILITY_REPLICA".
Возвращаясь к вашей основной проблеме: перестройка индекса сделала ваш журнал транзакций действительно очень большим.
Когда вы выполняете ALTER INDEX...REBUILDSQL Server создает весь новый индекс (операция с размером данных) и должен иметь возможность откатить создание индекса, если оно завершится ошибкой или будет уничтожено до завершения. Таким образом, вы можете увидеть log_reuse_wait_desc колонка в sys.databases отображается как "ACTIVE_TRANSACTION" во время очень большой и продолжительной перестройки индекса. Само восстановление не позволит вам повторно использовать журнал и приведет к его росту.