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

Область применения: SQL Server 2016 (13.x) и более поздних версий

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

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

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

Версия	Операционная система
Новые возможности SQL Server 2025 (17.x)	Виндоус | Линукс
Новые возможности SQL Server 2022 (16.x)	Виндоус | Линукс
Новые возможности SQL Server 2019 (15.x)	Виндоус | Линукс
Новые возможности SQL Server 2017 (14.x)	Виндоус | Линукс

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

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

Сценарии SQL Server, использующие функции доступности

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

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

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

Внимание

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

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

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

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

Группы доступности (AG) обеспечивают защиту уровня базы данных путем отправки каждой транзакции базы данных в другой экземпляр или реплику, которая содержит копию этой базы данных в специальном состоянии. Вы можете развернуть группу доступности (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 с пакетом обновления 1 или 4.6.2 и более поздних версий), то переход на резервный режим должен выполняться с минимальными последствиями для конечных пользователей. Отработка отказа на вторичную реплику, чтобы сделать ее новой первичной репликой можно настроить автоматически или вручную, и обычно измеряется в секундах.

В следующем списке перечислены некоторые различия в использовании групп доступности (AG) на 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) представил следующие функции и усовершенствования для групп доступности (AGs).

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

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

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

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 2017 (14.x) и более поздних версиях группы доступности должны обрабатывать некоторые метаданные, которые изначально обрабатываются WSFC. Например, существует три типа кластера для группы доступности, которые хранятся в sys.availability_groupscluster_type и cluster_type_desc столбцах:

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

Все группы доступности, требующие высокой доступности, должны использовать базовый кластер, который в случае SQL Server 2017 (14.x) и более поздних версий означает WSFC или агент кластеризации Linux. Для групп AG на основе 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) и более поздних версиях невозможно изменить тип кластера для группы доступности после его создания. Это ограничение означает, что AG не может быть переключен с None на External или WSFC, и наоборот.

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

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

ТРЕБУЮТСЯ_СИНХРОНИЗИРОВАННЫЕ_ПОДЧИНЕННЫЕ_ДЛЯ_ПРИНЯТИЯ

SQL Server 2016 (13.x) увеличила поддержку синхронных реплик с двух до трех в выпуске Enterprise. Тем не менее, если одна вторичная реплика синхронизирована, но у другой возникают проблемы, нет способа управлять поведением, чтобы сообщить первичной реплике либо дожидаться проблемную реплику, либо позволить системе продолжить процесс. В этом сценарии первичная реплика может по-прежнему получать трафик записи, даже если вторичная реплика не находится в синхронизированном состоянии, что приводит к потере данных на вторичной реплике.

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

• Существует три возможных значения: 0, 1и 2.
• Значение - это количество вторичных реплик, которые должны быть синхронизированы, что влияет на потерю данных, доступность группы доступности (AG) и отказоустойчивость.
• Для WSFCs и типа кластера "None" значение по умолчанию — 0, и его можно вручную задать на 1 или 2.
• Для типа кластера external механизм кластера задает это значение по умолчанию, и его можно переопределить вручную. Для трех синхронных реплик значение по умолчанию равно 1.

В Linux вы настраиваете значение для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ресурса группы высокой доступности (AG) в кластере. В 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 только при создании группы доступности.

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

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

После отказа происходит изменение владения, как показано на следующей схеме:

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

FCI проходит через обычный процесс восстановления. Он продвигает любые транзакции, которые необходимо продвинуть вперёд, и откатывает все неполные транзакции. Таким образом, база данных остается согласованной с точки зрения данных до момента сбоя или ручного переключения, поэтому данные не теряются. Базы данных доступны только после завершения восстановления. Время восстановления зависит от многих факторов и, как правило, больше, чем переключение группы доступности (AG) в другой режим работы. Компромисс заключается в том, что при отработки отказа группы доступности могут потребоваться дополнительные задачи, необходимые для использования базы данных, например включение задания агента SQL Server.

Примечание.

Ускорение восстановления базы данных (ADR) может снизить время восстановления. Дополнительные сведения см. в разделе "Ускорение восстановления базы данных".

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

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

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

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

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

Самым большим преимуществом использования доставки журналов является то, что она учитывает человеческую ошибку, так как можно отложить применение журналов транзакций. Например, если кто-то выдает предложение без UPDATE предложения, резервный WHERE режим может не измениться, поэтому вы можете переключиться на это при восстановлении основной системы. Хотя доставку журналов легко настроить, переход с основного сервера на сервер с тёплым резервированием, известный как изменение роли, всегда выполняется вручную. Вы инициируете изменение роли с помощью Transact-SQL и, как АГ, вам необходимо вручную синхронизировать все объекты, не захваченные в журнале транзакций. Необходимо настроить доставку журналов для каждой базы данных, в то время как одна агрегированная группа (AG) может содержать несколько баз данных.

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

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

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

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

Одним из преимуществ групп доступности является настройка высокого уровня доступности и аварийного восстановления с помощью одной функции. Без необходимости обеспечить высокий уровень доступности общего хранилища гораздо проще иметь локальные реплики в одном центре обработки данных для обеспечения высокой доступности и удаленные в других центрах обработки данных для аварийного восстановления с отдельным хранилищем. Наличие дополнительных копий базы данных является компромиссом для обеспечения избыточности. Пример группы доступности (AG), охватывающей несколько центров обработки данных, показан на следующей диаграмме. Одна первичная реплика обеспечивает синхронизацию всех вторичных реплик.

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

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

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

Вы можете использовать FCI для аварийного восстановления. Как и в обычной группе доступности, необходимо расширить базовый механизм кластера для всех местоположений, что увеличивает сложность. Для FCIs также необходимо учитывать общий доступ к хранилищу. Первичные и вторичные сайты нуждаются в доступе к тем же дискам. Чтобы убедиться, что хранилище, используемое FCI, существует на обоих сайтах, используйте внешний метод, например функциональные возможности, предоставляемые поставщиком хранилища на аппаратном уровне. Кроме того, используйте реплику хранилища в Windows Server.

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

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

Миграции и обновления

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

Примечание.

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

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

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

Если вы хотите перейти на новые серверы без изменения конфигурации (включая операционную систему или версию SQL Server), добавьте эти серверы в качестве узлов в существующий базовый кластер, а затем добавьте их в группу доступности. После того как реплика или реплики находятся в нужном состоянии, вручную выполните переключение на новый сервер. Затем удалите старые серверы из AG и вывeдите их из эксплуатации.

Распределенные группы доступности представляют еще один метод для перехода на новую конфигурацию или обновления SQL Server. Так как распределённая группа доступности поддерживает разные базовые группы доступности на различных архитектурах, вы можете перейти с SQL Server 2019 (15.x), работающего на Windows Server 2019, на SQL Server 2025 (17.x), работающего на Windows Server 2025.

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

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

Группы доступности могут обеспечить минимальное время простоя во время обновления базовой ОС, вручную переключив основную реплику на вторичную во время выполнения обновления. С точки зрения операционной системы это более распространено в Windows Server, так как обслуживание базовой ОС может потребовать перезагрузки. Исправление Linux иногда требует перезагрузки, но это менее распространено.

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

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

ФКЗ самостоятельно не могут помочь в традиционной миграции или обновлении. Необходимо настроить группу доступности (AG) или журналирование для баз данных в FCI, а также учитывать все остальные объекты. Тем не менее, FCI в серверах Windows Server по-прежнему является популярным вариантом при необходимости исправления базовых серверов Windows. При запуске аварийного переключения вручную краткий сбой заменяет полное время недоступности экземпляра во время обновления Windows Server.

Вы можете выполнить обновление FCI на текущей системе до более новых версий SQL Server. Дополнительные сведения см. в статье об обновлении экземпляра отказоустойчивого кластера.

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

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

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

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

Другие способы развертывания SQL Server и обеспечение доступности

Существует два других способа развернуть SQL Server в Linux: контейнеры и Azure (или другой поставщик общедоступного облака). Общая потребность в доступности существует независимо от способа развертывания SQL Server. Эти два метода имеют некоторые особые аспекты при работе с SQL Server с высоким уровнем доступности.

Параметры контейнеров SQL Server и высокого уровня доступности и аварийного восстановления

Развертывание контейнеров SQL Server — это способ упрощения подготовки, масштабирования и управления жизненным циклом SQL Server в разных средах. Контейнер — это полный готовый образ SQL Server.

В зависимости от платформы контейнеров, например при использовании оркестратора контейнеров, например Kubernetes, если контейнер потерян, его можно развернуть снова и подключить к общему хранилищу, используемому. Хотя это обеспечивает некоторую устойчивость, существует некоторое время простоя, связанное с восстановлением базы данных, и не является действительно высокодоступным, так как это было бы в случае использования группы доступности или FCI.

Если вы хотите настроить высокий уровень доступности для контейнеров SQL Server, развернутых на платформах Kubernetes или не kubernetes, можно использовать DH2i DxEnterprise в качестве одного из решений кластеризации, на вершине которых можно настроить группу доступности в режиме высокой доступности. Этот параметр предоставляет целевую точку восстановления (RPO) и целевое время восстановления (RTO), ожидаемое из решения высокого уровня доступности.

Развертывание виртуальной машины под управлением Linux

Linux можно развернуть с помощью SQL Server на виртуальных машинах Linux Azure. Как и в случае с локальными установками, поддерживаемая установка требует использования ограждения неработоспособных узлов, внешних для самого агента кластера. Ограждение узла предоставляется с помощью агентов доступности ограждения. Некоторые дистрибутивы поставляют их как часть платформы, а другие полагаются на внешних поставщиков оборудования и программного обеспечения. Ознакомьтесь с предпочитаемым дистрибутивом Linux, чтобы узнать, какие формы ограждения узлов предоставляются таким образом, чтобы поддерживаемое решение можно было развернуть в общедоступном облаке.

Руководства по установке SQL Server на Linux доступны для следующих дистрибутивов:

• Краткое руководство. Установка SQL Server и создание базы данных в Red Hat
• Краткое руководство. Установка SQL Server и создание базы данных в Ubuntu
• Краткое руководство. Установка SQL Server и создание базы данных на SUSE Linux Enterprise Server

Масштабирование чтения

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

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

Примечание.

Вторичные реплики, доступные для чтения, имеются только в версии Enterprise. Каждому экземпляру, на котором размещена реплика с возможностью чтения, требуется лицензия SQL Server.

В SQL Server 2016 (13.x) впервые были введены распределенные группы доступности (AGs), позволяющие масштабировать копий базы данных. Эта функция предоставляет только для чтения копии базы данных не только локально, но и регионально и глобально с минимальной конфигурацией. Эта настройка снижает сетевой трафик и задержку за счет локального выполнения запросов. Каждая первичная реплика AG может инициировать две другие AG, даже если она не является основной копией для записи и чтения, и каждая распределенная AG может поддерживать до 27 копий данных, доступных для чтения.

В SQL Server 2017 (14.x) и более поздних версиях можно создать практически реальное решение, доступное только для чтения, с помощью групп управления доступом, настроенных с типом кластера None. Если ваша цель — использовать AG для читаемых вторичных реплик, а не для обеспечения доступности, этот подход позволяет избежать сложности использования WSFC или внешнего кластерного решения в Linux. Она предоставляет доступные для чтения преимущества группы доступности в более простом методе развертывания.

Единственное основное предупреждение заключается в том, что из-за отсутствия базового кластера с типом кластера None настройка маршрутизации только для чтения немного отличается. С точки зрения SQL Server прослушиватель по-прежнему требуется для маршрутизации запросов, даже если нет кластера. Вместо настройки традиционного прослушивателя используйте IP-адрес или имя первичной реплики. Затем первичная реплика направляет запросы только для чтения.

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

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

Кроссплатформенность и взаимодействие с дистрибутивами Linux

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

Примечание.

Нет сценариев, когда экземпляр отказоустойчивого кластера на основе WSFC (FCI) или группа доступности (AG) работает непосредственно с FCI или AG на основе Linux. Отказоустойчивый кластер Windows Server (WSFC) не может быть расширен узлом Pacemaker и наоборот.

Распределенные группы доступности

Распределенные группы доступности предназначены для охвата конфигураций группы доступности, независимо от того, являются ли эти два базовых кластера под AG двумя разными WSFCs, дистрибутивами Linux или одним в WSFC и другой в Linux. Распределенная группа доступности — это основной метод использования кроссплатформенного решения. Распределенная группа доступности также является основным решением для миграций, таких как преобразование из инфраструктуры SQL Server на основе Windows Server в linux, если это то, что ваша компания хочет сделать. Как отмечалось ранее, группы доступности, и особенно распределенные группы доступности, могли бы минимизировать время, в течение которого приложение было бы недоступно для использования. Пример распределенной группы доступности, охватывающей WSFC и Pacemaker, показан на следующей схеме:

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

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

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

Как и в случае с AG, доставка журналов не работает, если версия SQL Server на исходном сервере является более высокой, чем на целевом сервере.

Итоги

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

Связанный контент

• Что такое группа доступности AlwaysOn?
• Установка отказоустойчивого кластера SQL Server