Группы доступности (Availability Groups) Always On в SQL Server 2017

В данной статье я представлю концепции групп доступности Always On, необходимые для настройки и управления одной или более группами доступности в SQL Server 2017.

Группы доступности поддерживают реплицируемое окружение для дискретного набора пользовательских баз данных, известных как базы данных доступности (Availability Database). Можно создавать группы доступности для высокой доступности (High Availability, HA) или масштабирования чтения (Read-Scale). Высоко доступная группа доступности – это группа баз данных, которые обрабатывают отказы. Масштабирующая чтение группа доступности – это группа баз данных, которые копируются между экземплярами SQL Server для распределения рабочих нагрузок, связанных только с чтением (Read-Only). Группа доступности поддерживает один набор основных (Primary) баз данных и от одной до восьми вторичных (Secondary) баз данных. Вторичные базы данных – это не резервные копии (Backups), в связи с этим необходимо продолжать делать резервные копии баз данных и журналов транзакций на регулярной основе.

Примечание.

Можно создавать резервные копии любого типа на основной базе данных. В качестве альтернативы можно создавать резервные копии журнала (Log Backups) и полные резервные копии в режиме чистой копии (Copy-only Full Backup) на вторичных базах данных.

Каждый набор баз данных доступности размещается репликой доступности (Availability Replica). Существует два типа реплик доступности: одна основная реплика (Primary Replica), которая размещает одну основную базу данных и от одной до восьми вторичных реплик (Secondary Replicas), каждая из которых размещает набор из вторичных баз данных и выступает в качестве потенциальной цели при обработке отказа в группе доступности. Аварийное переключение группы доступности происходит на уровни реплики доступности. Реплика доступности предоставляет устойчивость только на уровне базы данных для набора баз в одной группе доступности. Аварийное переключение не вызывается ошибками базы данных, такими как подозрительное поведение базы данных в связи с потерей файла данных или повреждение журнала транзакций.

Основная реплика делает основную базу данных доступной для подключения клиентов с доступом на чтение-запись. Также основная реплика отправляет записи журнала транзакций каждой из основных баз данных до каждой вторичной базы данных. Этот процесс называется синхронизацией данных (Data Synchronization), и он происходит на уровне базы данных. Каждая вторичная реплика кэширует записи журнала транзакций (фиксирует журналы) и затем примеряет их к соответствующей вторичной базе данных. Синхронизация данных происходит между основной базой данных и каждой связанной с ней вторичной, независимо от остальных баз данных. Таким образом, одна вторичная база данных может быть приостановлена (Suspended) или выйти из строя, при этом не оказывая никакого воздействия на другие вторичные базы данных. Точно также и основная база данных может быть приостановлена (Suspended) или выйти из строя, не оказывая никакого воздействия на остальные основные базы данных.

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

SQL Server 2017 представил две различные архитектуры для групп доступности. Группы доступности Always On предоставляют высокую доступность, аварийное восстановление и балансировку масштабируемого чтения. Такие группы доступности требуют диспетчера кластера (Cluster Manager). Другая архитектура – это масштабирующая чтение группа доступности. Масштабирующая чтение группа доступности предоставляет реплики для рабочих нагрузок чтения, но не обеспечивает высокую доступность. Масштабирующие чтение группы доступности не требуют диспетчера кластера.

Развертывание групп доступности для высокой доступности на Windows Server требуют установки роли отказоустойчивого кластера (Failover Cluster). Каждая реплика доступности должна находится на отдельном узле того же отказоустойчивого кластера. Единственное исключение возможно при миграции в другой отказоустойчивый кластер, группа доступности может временно располагаться в двух кластерах. В Linux в качестве диспетчера кластера можно использовать Pacemaker.

В конфигурации высокой доступности роль кластера создаётся для каждой создаваемой группы доступности. Отказоустойчивый кластер ведет мониторинг роли для оценки здоровья основной реплики. Кворум для групп доступности Always On базируется на всех узлах в отказоустойчивом кластере независимо от расположения основной реплики. По сравнению с зеркалированием баз данных (Database Mirroring) в группах доступности Always On нет роли наблюдателя (Witness).

Следующая иллюстрация демонстрирует группу доступности, которая содержит одну основную реплику и четыре вторичные.

Базы данных доступности (Availability Databases).

Чтобы добавить базу данных в группу доступности, база данных должна находиться в запущенном режиме (Online) и быть доступной для чтения-записи на экземпляре сервера, который размещает основную реплику. При добавлении базы данных, она присоединяется к группе доступности в качестве основной базы данных, при этом оставаясь доступной для клиентов. Никакой вторичной базы не существует до тех под пока резервная копия новой основной базы данных не будет восстановлена на экземпляре сервера, который размещает вторичную реплику (с использованием опции NO RECOVERY). Новая вторичная база данных будет находится в состоянии восстановления (RESTORING) до тех пор, пока она присоединена к группе доступности.

Примечание.

База данных доступности (Availability Database) иногда называется репликой базы данных (Database Replica) в Transact-SQL, PowerShell и SQL Server Management Objects (SMO). Например, термин «Database Replica» используется в именах динамических представлениях управления (DMV) Always On, которые возвращают информацию о базах данных доступности:

• sys.dm_hadr_database_replica_states
• sys.dm_hadr_database_replica_cluster_states

Однако, в SQL Server Books Online, термин "Replica" обычно относится к репликам доступности. Например, «Primary Replica» и «Secondary Replica» всегда относятся к репликам доступности.

Реплики доступности (Availability Replicas).

Каждая группа доступности определяет набор из двух партнеров отказоустойчивости, известных как реплики доступности. Реплики доступности – это компоненты групп доступности. Для отдельной группы доступности, реплики доступности должны быть размещены на разных экземплярах SQL Server расположенных на разных узлах отказоустойчивого кластера. На каждом таком экземпляре сервера должна быть включена поддержка Always On.

Определенный экземпляр может размещать только одну реплику доступности для группы доступности. Однако, каждый экземпляр может быть использован для нескольких групп доступности. Экземпляр может быть самостоятельным экземпляром (Stand-alone Instance) или экземпляром отказоустойчивого кластера (FCI) SQL Server. Для обеспечения устойчивости на уровне сервера, необходимо использовать экземпляры отказоустойчивого кластера.

Каждой реплике доступности назначается начальная роль: основная или вторичная, в дальнейшем она наследуется базами данных доступности, принадлежащим к этой реплике. Роль реплики определяет возможный тип доступа к размещаемым базам данных: чтение и запись (Read-Write) или только чтение (Read Only). Одной реплике назначается роль основной, и она размещает базы данных доступные для чтения-записи, которые известны как основные базы данных. Как минимум одной иной реплике назначается вторичная роль. Вторичная реплика размещает базы данных доступные только для чтения, они в свою очередь называются вторичные базы данных.

Примечание.

Когда роль реплики доступности переопределяется, например, в процессе обработки отказа, ее базы данных временно находятся в состоянии NOT SYNCHRONIZED. Их роль устанавливается в RESOLVING до тех пор, пока роль реплики доступности не будет определена. Если некоторая реплика доступности в результате процесса определения получает основную роль, ее базы данных становятся основными базами данных. Если реплика доступности в результате определения получает вторичную роль ее базы данных становятся вторичными базами данных.

Режимы доступности (Availability Modes).

Режим доступности – это свойство каждой реплики доступности. Режим доступности определяет будет ли основная реплика ожидать успешного завершения транзакции на базе данных, пока ее вторичная реплика записывает записи журнала транзакций на диск (сохраняет журнал). Группы доступности Always On поддерживают два режима завершения транзакций: Асинхронный режим (Asynchronous-commit) и Синхронный режим (Synchronous-commit).

Асинхронный режим (Asynchronous-commit).

В асинхронном режиме основная реплика завершает транзакцию не дожидаясь подтверждения, что вторичная реплика сохранила журнал. Асинхронный режим (Asynchronous-commit) минимизирует время ожидания транзакций на вторичной базе данных, но позволяет ей задержку относительно состояния основной базы данных, что делает возможным потерю части данных.

Синхронный режим (Synchronous-commit).

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

Типы аварийного переключения (Types of Failover).

В контексте сессии между основной и вторичной репликами, основная и вторичная роли взаимозаменяемы в процессе обработки отказа. В процессе обработки отказа целевая вторичная реплика получает основную роль, становясь новой основной репликой. Новая основная реплика переводит свою базу данных в запущенное состояние (Online) в качестве основной базы данных, а пользовательские приложения получают возможность подключения к ней. Когда бывшая основная реплика вновь становится доступна, она переходит на вторичную роль, становясь вторичной репликой. Бывшая основная база данных становится вторичной, и синхронизация данных продолжается.

Существует три формы аварийного переключения (Failover): автоматическое (Automatic), ручное (Manual) и принудительное (Forced) с возможной потерей данных. Форма или формы поддерживаемого аварийного переключения определенной вторичной реплики зависят от ее режима доступности и, для синхронного режима, от режима отказоустойчивости на основной и целевой вторичной репликах.

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

Запланированное ручное аварийное переключение (Planned Manual Failover) без потери данных.

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

Автоматическое аварийное переключение (Automatic Failover) без потери данных.

Автоматическое аварийное переключение происходит в ответ на ошибку, которая заставляет синхронизированную вторичную реплику переключиться на основную роль (с гарантированной защитой данных). Когда бывшая основная реплика станет доступна, она переключится на вторичную роль. Автоматическое аварийное переключение требует, чтобы основная и целевая вторичная реплики были запущены в синхронном режиме с автоматическим режимом отказоустойчивости. Дополнительно, вторичная реплика должна быть синхронизирована, отказоустойчивый кластер должен иметь кворум и удовлетворять условиям, указанным в гибкой политике отказоустойчивости (Flexible Failover Policy) группы доступности.

Примечание.

Экземпляры отказоустойчивого кластера (FCI) SQL Server не поддерживают автоматическое аварийное переключение групп доступности, любая реплика доступности, разрешенная в экземпляре отказоустойчивого кластера (FCI) может быть сконфигурирована только для ручного (Manual) аварийного переключения.

Принудительное аварийное переключение (Automatic Failover) с возможной потерей данных.

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

Примечание.

При вызове команды принудительного (Forced) аварийного переключения на синхронизированной вторичной реплике, она будет себя вести также, как при запланированном ручном (Manual) аварийном переключении.

Клиентские подключения (Client Connections).

Можно предоставить возможность клиентских подключений к основной реплике группы доступности, создав прослушиватель (Listener) группы доступности. Прослушиватель группы доступности предоставляет набор ресурсов, которые подключены к группе доступности, для направления клиентских подключений к соответствующей реплике доступности.

Прослушиватель группы доступности связывается с уникальным именем DNS, которое обслуживается, как виртуальное сетевое имя (Virtual Network Name, VNN). Прослушивателю назначается один или более виртуальных IP-адресов (VIP) и номер TCP-порта.

Примечание.

Если группа доступности обрабатывает только две реплики доступности и не сконфигурирована для предоставления доступа на чтение к вторичной реплике, клиенты могут подключаться к основной реплике при помощи строки подключения - зеркалирования баз данных (Database Mirroring Connection String). Данный подход может быть полезен в качестве временного решения после миграции базы данных из зеркалирования баз данных в группы доступности Always On. Перед добавлением дополнительной вторичной реплики, необходимо создать прослушиватель группы доступности и обновить настройки приложения на использование сетевого имени прослушивателя.

Активные вторичные реплики (Active Secondary Replicas).

Группы доступности Always On поддерживают активные вторичные реплики.

Резервное копирование на вторичных репликах.

Вторичные реплики поддерживают выполнение резервного копирования журналов транзакций и резервное копирование чистой копии всей базы данных, файла или файловой группы. Можно настроить группу доступности, таким образом, чтобы указать предпочтение, где должно выполняться резервное копирование. Важно понимать, что данное предпочтение не применяется принудительно SQL Server, таким образом не оказывает влияния на обычные резервные копии. Интерпретация данного предпочтения зависит от логики, если она необходима, ее можно использовать в заданиях резервного копирования для каждой из баз данных в определенной группе доступности. Для отдельной реплики доступности можно указать приоритет для выполнения резервного копирования на данной реплике по отношению к остальным репликам в той же группе доступности.

Доступные для чтения вторичные реплики.

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

Если группа доступности на данный момент обладает прослушивателем и одной или несколькими вторичными репликами, доступными для чтения, SQL Server может маршрутизировать связанные с чтением запросы соединения к одной из них (Read-only Routing).

Период ожидания сессии (Session-Timeout Period).

Период ожидания сессии – это свойство реплики доступности, которое определяет, как долго соединение с другой репликой доступности может оставаться не активным, перед тем как соединение закроется. Основная и вторичная реплики прозванивают (Ping) друг друга для того, чтобы убедиться, что они остаются активными. Получение звонка от другой реплики во время ожидания определяет, что соединение остается открытым и экземпляр сервера доступен для коммуникаций. Получая звонок от другой реплики, реплика доступности сбрасывает счетчик ожидания сессии на соединении.

Период ожидания сессии избавляет реплику от неопределенного ожидания до получения звонка от другой реплики. Если звонок не получен от другой реплики в рамках периода ожидания сессии, время ожидания реплики истекает, и она закрывает свои соединения и переходит в отключенное состояние (DISCONNECTED). Даже если отключенная реплика сконфигурирована в синхронном режиме, транзакции не ожидают такую реплику для повторного подключения и синхронизации.

По умолчанию период ожидания сессии для каждой реплики доступности составляет 10 секунд. Значение можно настраивать с минимальным порогом в 5 секунд. Обычно, рекомендуется устанавливать период ожидания сессии в 10 секунд или более. Установка периода в значение меньше 10 секунд может привести высоконагруженную систему к ошибочному объявлению отказа.

Примечание.

При разрешении роли, период ожидания сессии не применяется, так как прозвон не происходит.

Автоматическое восстановление странц (Automatic Page Repair).

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

P.S. Я уже записал веб-каст о настройке группы доступности Always On в SQL Server 2017 на базе Windows Server 2019, совсем скоро я его опубликую.

Если вы незнакомы с развертыванием экземпляров SQL Server в отказоустойчивом кластере (FCI), то познакомиться с ними можно в веб-касте: «Установка кластерного экземпляра SQL Server 2014 с CSV».