SQL Server 2012 AlwaysOn и резервные копии. Часть 1 - Разгрузка работы на реплику. Перевод статьи

Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 1 - Offloading the work to a replica".

Одним из величайших аспектов SQL Server AlwaysOn является возможность разгрузить работу резервного копирования и проверку целостности в реплику. Это действительно может помочь сохранить ресурсы на вашей основной рабочей нагрузке приложения. Я собираюсь сосредоточиться главным образом на резервных копиях журнала транзакций в этой статье, так как резервное копирование журнала лучше всего использовать для того, чтобы проиллюстрировать эту новую функцию. Одним из ключевых элементов включения этой резервной способности является цепочка одного журнала, которая поддерживается по всем репликам. Проиллюстрирую это, показывая log_reuse_wait_desc sys.databases и выходные данные инструкции DBCC SQLPERF('logspace').

Моя среда имеет 3 экземпляра, участвующих в группе доступности со старой доброй базой данных AdventureWorks. У меня есть основной экземпляр (SQL1), синхронная реплика, установленная в нечитаемый режим (SQL2) и асинхронная реплика, которая является читаемой (SQL3). Причиной, по которой я выбрал эту конкретную конфигурацию, является хорошее сочетание sync/async и читаемое/не читаемое для тестирования.

Обратите внимание на то, что я недавно выполнил полный бэкап из SQL1, но есть некоторые транзакции в журнале транзакций. Помните, что журнал транзакций не усекается при полном резервном копировании! Буду продолжать повторять следующую таблицу после каждой команды, чтобы показать вам, как журнал остается тем же самым среди реплик

Обратите внимание, что поскольку SQL2 не установлен для чтения, выходные данные для этой базы данных не будут отображаться в DBCC SQLPERF('logspace').

Теперь будем выполнять команды резервного копирования журнала транзакций на SQL2.

Несмотря на то, что эта реплика не для чтения, мы по-прежнему можем делать резервное копирование журнала транзакций отсюда.

Хотя в точности использованное место слегка отличается по ряду различных причин, вы можете увидеть, что выполнение резервного копирования журнала транзакций на одной из баз данных очистило журнал для них всех.

Теперь я сгенерировал немного больше активности в базе, чтобы в журналы транзакций попало больше данных. Я также устанавливаю реплику на SQL2 для чтения, чтобы мы могли получить некоторые выходные от DBCC SQLPERF('logspace'). Вы можете увидеть, что отражено в статистике ниже

Теперь давайте возьмем резервную копию журнала транзакций от SQL3 и посмотрим, как выглядит наш вывод

Так что теперь вы можете видеть, что вы можете взять резервные копии журналов транзакций из любой реплики и это все часть одной цепочки журнала транзакций. Когда журнал усекается на одной реплике, это отражается на других.

Важная вещь, которую следует иметь в виду, это то, что хотя есть одна цепочка журнала, существует не одна msdb по всем репликам. Вы заметите, что только резервные копии из данного экземпляра будут отображаться в таблицах резервного копирования базы данных msdb. Хотя это кажется довольно очевидным, важно отметить, что вы действительно должны быть осторожны в том, что вы знаете, где происходит резервное копирование. Если вам необходимо восстановиться, вам нужно будет собрать воедино необходимые файлы для завершения цепочки журналов. В моем примере, где я взял полный бэкап на SQL1, и первый бэкап журнала транзакций на SQL2, msdb на SQL2 ничего не знала о полной резервной копии, которая была сделана на SQL1. Для борьбы с этим, рекомендуется убедиться в том, что все резервные копии направляются в одно и то же местоположение файлов.

Я также хочу отметить, что существуют некоторые ограничения. Например, полные резервные копии реплик должны быть "copy_only" резервными копиями. Если вы просто выполняете полный бэкап и бэкап журнала транзакций, это будет влиять только на то, что надо убедиться, что вы добавили "copy_only" в команду бэкапа. Ключевым моментом к этому является, что "copy_only" полный бэкап не может служить разностной резервной копией базы. Кроме того, разностные резервные копии не могут быть выполнены с реплик. Это может быть разочарованием, если вы надеялись выполнять разностные бэкапы из реплики. Обычно полные и разностные резервные копии выполняются во время низких нагрузок приложений, в любом случае, поэтому это не должно быть слишком большой проблемой.