Непрерывность бизнес-процессов и восстановление базы данных — SQL Server на Linux

Статья
07/15/2024

Область применения: SQL Server

В этой статье представлен обзор решений обеспечения непрерывности бизнес-процессов для обеспечения высокой доступности и аварийного восстановления в SQL Server в Windows и Linux.

Одна из общих задач при развертывании SQL Server заключается в том, чтобы обеспечить доступность всех критически важных экземпляров SQL Server и баз данных в них организации и конечным пользователям согласно их потребностям — хоть исключительно в рабочие часы, хоть круглосуточно. Требуется поддерживать работоспособность бизнеса с минимальными простоями либо вообще без них. Эта концепция также называется непрерывностью бизнес-процессов.

SQL Server 2017 (14.x) представил множество новых функций или улучшений для существующих, некоторые из которых предназначены для доступности. Самым большим дополнением к SQL Server 2017 (14.x) была поддержка SQL Server на Linux дистрибутивов. Полный список новых функций в SQL Server см. в следующих статьях:

В этой статье рассматриваются сценарии доступности в SQL Server 2017 (14.x) и более поздних версиях, а также новые и расширенные функции доступности. К сценариям относятся гибридные, которые смогут охватывать развертывания SQL Server как в Windows Server, так и в Linux, а также те, которые могут увеличить количество доступных для чтения копий базы данных.

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

Сценарии SQL Server с использованием функций доступности

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

Высокая доступность
Аварийное восстановление
Миграции и обновления
Горизонтальное масштабирование доступных для чтения копий одной или нескольких баз данных

В следующих разделах рассматриваются соответствующие функции, которые можно использовать для этого конкретного сценария. Здесь не рассматривается одна функция — репликация SQL Server. Хотя она официально не относится к функциям доступности в рамках AlwaysOn, репликацию SQL Server часто применяют для обеспечения избыточности данных при определенных условиях. Репликация слиянием не поддерживается для SQL Server на Linux. Дополнительные сведения см. в статье Репликация SQL Server на Linux.

Внимание

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

Высокая доступность

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

Группы доступности

В SQL Server 2012 (11.x) группы доступности (AG) обеспечивают защиту на уровне базы данных, отправляя каждую транзакцию базы данных в другой экземпляр или реплику, содержащую копию этой базы данных в специальном состоянии. Группу доступности можно развернуть в выпусках Standard или Enterprise. Экземпляры, участвующие в группе доступности, могут быть автономными или отказоустойчивым экземплярами кластера (FCIs, описанными в следующем разделе). Так как транзакции отправляются в реплику по мере их выполнения, группы доступности рекомендуются, когда существуют требования к более низкой точке восстановления и целям времени восстановления. Перемещение данных между репликами может быть синхронным или асинхронным с выпуском Enterprise, что позволяет до трех реплик (включая основную) как синхронную. Группа доступности имеет одну полную копию базы данных, которая находится на первичной реплике, а все вторичные реплики не могут получать транзакции непосредственно от конечных пользователей или приложений.

Примечание.

AlwaysOn — это зонтичный термин для функций доступности в SQL Server и охватывает как группы управления доступом, так и ФК. AlwaysOn не является именем функции группы доступности.

Перед SQL Server 2022 (16.x) группы управления доступом предоставляют только уровень базы данных, а не защиту на уровне экземпляра. Все, что не записано в журнале транзакций или настроено в базе данных, необходимо вручную синхронизировать для каждой вторичной реплики. Примерами объектов, которые требуется синхронизировать вручную, являются имена для входа на уровне экземпляра, связанные серверы и задания агента SQL Server.

Начиная с SQL Server 2022 (16.x), вы можете управлять объектами метаданных, включая пользователей, имена входа, разрешения и агент SQL Server задания на уровне группы доступности в дополнение к уровню экземпляра. Дополнительные сведения см. в разделе "Содержащиеся группы доступности".

Группа доступности также имеет другой компонент, называемый прослушивателем, который позволяет приложениям и конечным пользователям подключаться без необходимости знать, какой экземпляр SQL Server размещает основную реплику. Каждая группа доступности будет иметь собственный прослушиватель. Хотя реализации прослушивателя немного отличаются в Windows Server и Linux, функции, которые он предоставляет и как он используется, одинаковы. На схеме ниже показана группа доступности на основе Windows Server, использующая отказоустойчивый кластер Windows Server (WSFC). Базовый кластер на уровне операционной системы для обеспечения доступности требуется как в Linux, так и в Windows Server. В примере показана простая конфигурация с двумя серверами или узлами с WSFC в качестве базового кластера.

Схема простой группы доступности.

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

Примечание.

Зеркальное отображение базы данных, которое не рекомендуется использовать в SQL Server 2012 (11.x), недоступно в версии SQL Server linux и не будет добавлено. Клиенты по-прежнему используют зеркальное отображение базы данных должны планировать миграцию в группы доступности, которая является заменой зеркального отображения базы данных.

Когда речь идет о доступности, группы доступности могут предоставлять автоматическую или ручную отработку отказа. Автоматический переход на другой ресурс может произойти, если настроено синхронное перемещение данных, а базы данных в первичной и вторичной репликах находятся в синхронизированном состоянии. Если прослушиватель используется, и приложение использует более позднюю версию платформа .NET Framework (3.5 с обновлением или 4.0 и более поздней), отработка отказа должна обрабатываться с минимальными последствиями для конечных пользователей, если прослушиватель используется. Отработка отказа на вторичную реплику, чтобы сделать ее новой первичной репликой можно настроить автоматически или вручную, и обычно измеряется в секундах.

В приведенном ниже списке перечислены некоторые различия с группами доступности в Windows Server и Linux:

Из-за различий в том, как базовый кластер работает в Linux и Windows Server, все отработки отказа (вручную или автоматически) групп доступности выполняются через кластер в Linux. В развертываниях группы доступности на основе Windows Server необходимо выполнить отработку отказа вручную с помощью SQL Server. Автоматический переход на другой ресурс как в Windows Server, так и в Linux осуществляется с помощью базового кластера.
Для SQL Server на Linux рекомендуемая конфигурация для групп доступности составляет не менее трех реплик. Это вызвано особенностями работы базового кластера.
В Linux общее имя, используемое каждым прослушивателем, определено в DNS, а не в кластере, как в Windows Server.

Начиная с SQL Server 2017 (14.x), существуют некоторые новые возможности и усовершенствования групп доступности.

Типы кластера
REQUIRED_SECONDARIES_TO_COMMIT
Расширенная поддержка координатора распределенных транзакций Майкрософт (DTC) для конфигураций на основе Windows Server
Дополнительные сценарии горизонтального увеличения масштаба для баз данных, доступных только для чтения (описываются далее в этой статье)

Типы кластеров группы доступности

Встроенная форма доступности — кластеризация — в Windows Server реализуется посредством функции под названием "отказоустойчивая кластеризация". Он позволяет создавать WSFC для использования с группой доступности или FCI. Интеграция для групп управления доступом и ЦС обеспечивает библиотеки DLL ресурсов с поддержкой кластера, предоставляемые SQL Server.

SQL Server на Linux поддерживает несколько технологий кластеризации. Корпорация Майкрософт поддерживает компоненты SQL Server, а наши партнеры поддерживают соответствующую технологию кластеризации. Например, наряду с Pacemaker, SQL Server на Linux поддерживает HPE Serviceguard и DH2i DxEnterprise в качестве решения кластера.

Отказоустойчивый кластер под управлением Windows и решение кластера Linux более похожи, чем отличается. Оба решения позволяют выбрать отдельные серверы и объединить их в конфигурацию для обеспечения доступности, а также используют такие концепции, как ресурсы, ограничения (даже если реализованы они по-разному), переход на другой ресурс и т. д.

Например, для поддержки Pacemaker для конфигураций группы доступности и FCI, включая такие вещи, как автоматическая отработка отказа, корпорация Майкрософт предоставляет mssql-server-ha пакет, который аналогичен, но не совсем так же, как и библиотеки DLL ресурсов в WSFC, для Pacemaker. Одно из различий между WSFC и Pacemaker заключается в том, что в Pacemaker нет ресурса сетевого имени, который является компонентом, помогающим абстрагировать имя прослушивателя (или экземпляра отказоустойчивого кластера) в кластере WSFC. DNS предоставляет разрешение имен в Linux.

Из-за разницы в стеке кластера необходимо вносить некоторые изменения для групп доступности, так как SQL Server должен обрабатывать некоторые метаданные, которые изначально обрабатываются WSFC. Одним из таких существенных изменений является введение типа кластера для группы доступности. Он хранится в sys.availability_groups cluster_type столбцах и cluster_type_desc столбцах. Существует три типа кластера:

WSFC
Внешняя.
нет

Все группы доступности, требующие высокой доступности, должны использовать базовый кластер, который в случае SQL Server 2017 (14.x) и более поздних версий означает WSFC или агент кластеризации Linux. Для групп AGs на основе Windows Server, использующих базовый WSFC, тип кластера по умолчанию — WSFC и не требуется задавать. Для групп доступности на основе Linux при создании группы доступности тип кластера должен иметь значение External. Интеграция с внешним решением кластера в Linux настраивается после создания группы доступности, в то время как в WSFC она выполняется во время создания.

Тип кластера None можно использовать как с windows Server, так и с группами AGS Linux. Установка типа кластера в None означает, что группе доступности не требуется базовый кластер. Это означает, что SQL Server 2017 (14.x) является первой версией SQL Server для поддержки групп доступности без кластера, но компромисс заключается в том, что эта конфигурация не поддерживается как решение с высоким уровнем доступности.

Внимание

Начиная с SQL Server 2017 (14.x), после его создания нельзя изменить тип кластера для группы доступности. Это означает, что группа доступности не может быть переключена с None на External или WSFC или наоборот.

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

На снимке экрана ниже показана поддержка различных типов кластеров в SQL Server Management Studio (SSMS). Требуется версия 17.1 или более поздняя. Этот снимок экрана сделан в версии 17.2.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016 (13.x) увеличила поддержку синхронных реплик с двух до трех в выпуске Enterprise. Однако если одна вторичная реплика была синхронизирована, а в другой возникала проблема, не существовало способа сообщить первичной реплике, следует ли дожидаться исправления неправильно работающей реплики или продолжить работу. Это означает, что первичная реплика в какой-то момент будет продолжать получать трафик записи, даже если вторичная реплика не будет синхронизирована, что означает, что на вторичной реплике есть потери данных. Начиная с SQL Server 2017 (14.x), вы можете управлять поведением того, что происходит при синхронных репликах.REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT Этот параметр работает следующим образом:

Существует три возможных значения: 0, 1и 2
Значением является количество вторичных реплик, которые должны быть синхронизированы, что имеет последствия для потери данных, доступности группы доступности и отработки отказа.
Для WSFCs и типа кластера None значение по умолчанию равно 0и может быть вручную установлено 1 или 2
По умолчанию для типа кластера внешнего типа механизм кластера задает это значение, и его можно переопределить вручную. Для трех синхронных реплик значение по умолчанию будет 1.

В Linux значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT для ресурса группы доступности в кластере настроено. В Windows он устанавливается через Transact-SQL.

Значение, которое выше, чем 0 обеспечивает более высокую защиту данных, так как если требуемое количество вторичных реплик недоступно, основной объект не будет доступен до тех пор, пока это не будет разрешено. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT также влияет на поведение отработки отказа, так как автоматическая отработка отказа не может произойти, если правильное количество вторичных реплик не было в правильном состоянии. В Linux значение 0 не разрешает автоматическую отработку отказа, поэтому в Linux при использовании синхронной с автоматической отработкой отказа значение должно быть установлено выше, чем 0 для автоматической отработки отказа. 0 В Windows Server используется поведение в SQL Server 2016 (13.x) и более ранних версиях.

Расширенная поддержка координатора распределенных транзакций Майкрософт

Перед SQL Server 2016 (13.x) единственным способом получения доступности в SQL Server для приложений, требующих распределенных транзакций, которые используют DTC под обложкой, было развертывание FCI. Распределенная транзакция может быть реализована одним из двух способов:

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

SQL Server 2016 (13.x) представила частичную поддержку DTC с группами доступности, которые охватывали последний сценарий. SQL Server 2017 (14.x) завершает историю, поддерживая оба сценария с DTC.

В SQL Server 2017 (14.x) и более поздних версиях поддержка DTC также может быть добавлена в группу доступности после ее создания. В SQL Server 2016 (13.x) поддержка DTC для группы доступности может выполняться только при создании группы доступности.

Экземпляры отказоустойчивого кластера

Функция кластерных установок появилась в SQL Server версии 6.5. Экземпляры отказоустойчивого кластера являются проверенным способом обеспечения доступности для всей установки SQL Server, называемой экземпляром. Это означает, что все в экземпляре, включая базы данных, агент SQL Server задания, связанные серверы и т. д., переместится на другой сервер, если базовый сервер столкнулся с проблемой. Для всех интерфейсов FCIs требуется некоторое общее хранилище, даже если оно предоставляется через сеть. Запускать ресурсы отказоустойчивого кластера и владеть ими одновременно может только один узел. На приведенной ниже схеме первый узел кластера владеет FCI, что также означает, что он владеет общими ресурсами хранилища, связанными с ним, обозначаемым сплошной линией хранилища.

Схема экземпляра отказоустойчивого кластера.

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

Схема экземпляра отказоустойчивого кластера после отработки отказа.

Существует нулевая потеря данных с помощью FCI, но базовое общее хранилище является одной точкой сбоя, так как существует одна копия данных. FCI часто объединяются с другим методом доступности, например доставкой группы доступности или журналов, чтобы иметь избыточные копии баз данных. Реализуемый дополнительный метод должен использовать хранилище, физически отделенное от хранилища экземпляров отказоустойчивого кластера. Когда экземпляр отказоустойчивого кластера переходит на другой узел, он останавливается на одном узле и запускается на другом, что схоже с отключением и включением сервера. Экземпляр отказоустойчивого кластера проходит обычную процедуру восстановления, то есть выполняется накат всех требующих того транзакций, а также откат всех незавершенных транзакций. Таким образом, с точки зрения данных база данных согласована со временем сбоя или ручного перехода на другой ресурс, из-за чего потеря данных отсутствует. Базы данных доступны только после завершения восстановления, поэтому время восстановления будет зависеть от многих факторов и, как правило, будет длиннее, чем отработка отказа группы доступности. Компромисс заключается в том, что при отработки отказа группы доступности могут потребоваться дополнительные задачи, необходимые для использования базы данных, например включение задания агент SQL Server.

Как и группа доступности, fcis абстрактно, какой узел базового кластера размещает его. Экземпляр отказоустойчивого кластера всегда сохраняет свое имя. Приложения и пользователи никогда не подключаются к узлам, при этом используется присвоенное экземпляру отказоустойчивого кластера уникальное имя. FCI может участвовать в группе доступности в качестве одного из экземпляров, на котором размещена первичная или вторичная реплика.

В следующем списке перечислены некоторые различия экземпляров отказоустойчивого кластера в Windows Server и в Linux:

В Windows Server экземпляр отказоустойчивого кластера является частью процесса установки. Экземпляр отказоустойчивого кластера в Linux настраивается после установки SQL Server.
Linux поддерживает всего одну установку SQL Server на узел, поэтому все экземпляры отказоустойчивого кластера будут экземпляром по умолчанию. Windows Server поддерживает до 25 экземпляров отказоустойчивого кластера на кластер WSFC.
Общее имя, используемое экземплярами отказоустойчивого кластера в Linux, определено в DNS и должно совпадать с ресурсом, созданным для экземпляра отказоустойчивого кластера.

доставка журналов;

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

Схема доставки журналов.

Пожалуй, главным преимуществом доставки журналов в некотором роде является учет человеческого фактора. Применение журналов транзакций может быть отложено. Таким образом, если кто-либо выполняет, например, инструкцию UPDATE без предложения WHERE, резервирование может не иметь измененной версии, на которую вы могли бы переключиться во время восстановления основной системы. Хотя настроить доставку журналов довольно легко, переключение с основной системы на резервирование, называемое сменой роли, всегда выполняется вручную. Изменение роли инициируется с помощью Transact-SQL и, как группа доступности, все объекты, не захваченные в журнале транзакций, должны быть синхронизированы вручную. Доставка журналов также должна быть настроена для каждой базы данных, в то время как одна группа доступности может содержать несколько баз данных.

В отличие от группы доступности или FCI доставка журналов не имеет абстракции для изменения роли, которые приложения должны иметь возможность обрабатывать. Можно применять различные методики, такие как DNS-псевдоним (CNAME), но у них всегда есть как преимущества, так и недостатки, например время, требуемое DNS для обновления после переключения.

Аварийное восстановление

Если в первичном расположении доступности происходит катастрофическое событие, например землетрясение или наводнение, организация должна быть готова к переносу своих систем в другое место. В этом разделе мы рассмотрим, как функции доступности SQL Server могут помочь при обеспечении непрерывности бизнес-процессов.