SQL Server 2012 AlwaysOn и резервные копии. Часть 2 - Настройка резервного копирования и автоматизация резервного копирования. Перевод статьи

SQL 2012 AlwaysOn and Backups - Part 2 - Configuring Backup Preferences and Automating BackupsДанный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 2 - Configuring Backup Preferences and Automating Backups.

В предыдущем посте я показал, что можно выполнить резервное копирование из ваших реплик. Мысль, которую вы, возможно, подумали — "Хорошо, это здорово. Но как я узнаю, что это экземпляр реплики, и он не стал основным? Что делать, если для выполнения резервного копирования я хочу использовать конкретный экземпляр реплики, но позволить другому экземпляру иметь возможность сделать это в случае, если тот не доступен?" К счастью команда по продукту продумала такие вопросы и создала некоторые параметры конфигурации для настройки резервного копирования.

Самый простой способ, чтобы начать описывать эти настройки, заключается в том, чтобы обратиться к графическому интерфейсу в окне Availability Group Properties на вкладке Backup Preferences:

SQL Server 2012 Availability Group Properties - Backup Preferences

Как видим, здесь есть много вариантов. Я не буду вдаваться во все из них, так как они описаны здесь. Хотя, чтобы проиллюстрировать, как вы можете создать комбинацию из вариантов, я опишу мои установки, как показано выше. Если вы помните из моего предыдущего поста у меня 3 реплики. SQL1 является основной, SQL2 является синхронной репликой и SQL3 является асинхронной репликой. Глядя на мои параметры резервного копирования, вы можете увидеть, что SQL2 будет первым выбором для резервного копирования, поскольку в мох настройках используется значение "Prefer Secondary" и SQL2 имеет наивысший приоритет резервного копирования.

Теперь давайте подумаем, что произойдет, если SQL2 станет основным. Поскольку SQL1 имеет второй самый высокий приоритет резервного копирования, это теперь вторичная реплика. Он будет предпочтительным местом для резервного копирования. Причиной того, что у меня здесь есть SQL3, выбранный как последний вариант для резервного копирования, является то, что это асинхронная реплика, которая может позволить потерю данных и обычно может находиться в отдалённом сетевом расположении. Я даже мог бы полностью исключить эту реплику! Как понимаете, здесь существует множество комбинаций.

Также, обратите внимание, что эти параметры могут быть установлены через GUI, через команду ALTER AVAILABILITY GROUP через T-SQL, так же, как и PowerShell-командлет Set-SqlAvailabilityReplica.

Имейте в виду, что ключевое слово здесь PREFERENCES (Предпочтения). Не существует принуждения к этим предпочтениям. Например, ничто не мешает мне делать резервную копию журнала транзакций с реплики на SQL3. Вы все еще можете вручную пытаться сделать любое резервное копирование, которое вы хотите, непосредственно с любой реплики. Итак, с какой целью можно использовать все эти варианты? Одно простое слово ... АВТОМАТИЗАЦИЯ!. Вы хотите, чтобы резервное копирование произошло, где вы хотите, когда вы хотите, и не хотите думать об этом каждый день! Это то, где эти предпочтения спасают!

В моем примере я не хочу думать о том, что резервные копии начинают создаваться на SQL1 вместо SQL2, если группа доступности отработает отказ. Я лишь хочу, чтобы это произошло! Это та часть, где мы можем поговорить об автоматизации.

Ключевым здесь является новая функция sys.fn_hadr_backup_is_preferred_replica. При вызове этой функции с именем базы данных в качестве входного параметра, она возвращает 0, если текущий экземпляр не является предпочтительным расположением бэкапа и 1, если является. Вот где магия, люди! Поэтому для того, чтобы автоматизировать процессы резервного копирования, так чтобы они происходили в нужном месте, вам нужно установить задания на всех экземплярах, где они могли бы случиться. Можно использовать новую функцию, чтобы определить, то, следует ли выполнять резервное копирование. Вы можете создать что-то, вроде такого сценария...

Example of using T-SQL sys.fn_hadr_backup_is_preferred_replica

Таким образом ваши запланированные задания будут выполняться на каждом экземпляре. Задание (Job) будет выполнять резервное копирование в зависимости от статуса предпочитаемой реплики.

Вы скажете "Эх, но я ненавижу писать собственные сценарии"? Не беспокойтесь, нужный функционал уже встроен в планы обслуживания базы данных автоматически. Есть флажок, чтобы выключить эту функцию... Вы установите флажок, только в случае, если хотите игнорировать настройки резервного копирования и резервное копирование на этом компьютере, независимо от того, в каком состоянии находится реплика.

SQL Server Maintenance Plan Wizard

Я знаю много людей, которые используют сценарии резервного копирования от Ола Халленгрен. Текущая версия этого скрипта резервного копирования также использует эту функцию. Я не проверял, но я уверен, что и многие сторонние продукты для резервного копирования также используют эту функцию.

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

Ниже приведены некоторые ключевые моменты:

  • Есть много настроек резервного копирования. Читайте "BOL" и вникайте в настройки. Проверьте параметры, которые планируется развернуть во всех ваших сценариях перехода на другой ресурс. Таким образом, вы можете убедиться, что ваша конфигурация делает то, что вы от нее ожидаете.
  • Есть предпочтения, которые принудительно не применяются. Используйте sys.fn_hadr_is_preferred_replica в вашем решении резервного копирования для обеспечения предпочтений. Планы обслуживания базы данных используют ее автоматически.
  • Вам нужно будет настроить задания (jobs) на любом экземпляре, который, как вы ожидаете, возможно станет выполнять резервное копирование.
  • Я уже кратко упомянул об этом в своем последнем посте, но лучше всего вести запись всех резервных копий в одну и ту же сетевую папку. Это сделает поиск файлов всех ваших резервных копий намного легче.

В следующей части об AlwaysOn я расскажу немного о том, как ваши решения резервного копирования могут повлиять на восстановление.

Только один комментарий Комментировать

  1. Обратная ссылка: SQL 2012 AlwaysOn и резервные копии. Восстановление. Перевод /

Добавить комментарий