SQL Server Группы доступности Always On [Руководство на 2026 год]

Группы доступности Always On (AG) — это SQL Server Предприятие высокая доступность и решение для аварийного восстановления, работающее на уровне базы данных. Группа доступности объединяет одну или несколько пользовательских баз данных в единый блок резервирования и реплицирует их на восемь вторичных реплик посредством непрерывной передачи журналов транзакций. При отказе основной реплики автоматически включается назначенная синхронная вторичная реплика, восстанавливая доступ за считанные секунды без использования общего хранилища или ручного вмешательства.

1.2 Группы постоянной доступности против экземпляров отказоустойчивого кластера

SQL Server Технология Always On включает в себя две отдельные технологии: группы доступности (Availability Groups, AG) и экземпляры отказоустойчивого кластера (Failover Cluster Instances, FCI):

	Группы доступности Always On	Экземпляры отказоустойчивого кластера с постоянной доступностью
Область действия механизма отказоустойчивости	Уровень базы данных	На уровне экземпляра (все базы данных переключаются одновременно при сбое)
Репликация данных	Репликация на основе журналов событий на каждый вторичный сервер.	Нет — все узлы используют одно и то же хранилище.
Общее хранилище	Не требуется	Требуется (сеть хранения данных (SAN), iSCSI, S2D или SMB)
Читаемые вторичные материалы	Да	Нет
Аварийное восстановление	Встроенная функция (асинхронные реплики между площадками)	Не интегрируется без сопряжения с AG.

Когда использовать каждый из них: Используйте FCI, когда вам требуется отказоустойчивость на уровне экземпляров и у вас уже есть общая инфраструктура хранения данных. Используйте AG, когда вам требуется детализация на уровне базы данных, читаемые вторичные хранилища или аварийное восстановление. Для most Для полной защиты объедините оба подхода: запускайте каждую реплику как узел FCI и объединяйте их в группу доступности (AG).

1.3 Преимущества и ограничения

Бенефиты:

Автоматическое переключение на резервный сервер с практически нулевым целевым временем восстановления (RTO) для синхронных реплик;
нулевая потеря данных (целевая точка восстановления (RPO) = 0) в режиме синхронной фиксации;
Общее хранилище не требуется — каждая реплика использует независимое локальное хранилище;
Доступные для чтения вторичные серверы разгружают основной сервер от задач формирования отчетов и резервного копирования;
Поддерживает как локальную высокую доступность (HA), так и межсайтовое аварийное восстановление (DR) в рамках одной конфигурации.

Ограничения:

Требуется кластеризация с отказоустойчивостью Windows Server на всех репликах;
Версия Enterprise Edition предоставляет полный набор функций (версия Standard Edition поддерживает Basic AG со значительными ограничениями);
Режим синхронной фиксации добавляет задержку к операциям записи, пропорциональную времени обмена данными по сети;
В этой системе автоматические учетные записи, задания SQL Agent и связанные серверы не синхронизируются. SQL Server 2019 год и ранее (решено в SQL Server В 2022 году были доступны группы.

2. Архитектура групп постоянной доступности (Always On Availability Groups)

2.1 Основные компоненты и концепции

2.1.1 Базы данных доступности

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

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

2.1.2 Наличие реплик

Доступность реплик: SQL Server случаи, которые host копии баз данных доступности. Каждая реплика поддерживает свою собственную физическую копию баз данных, синхронизированную посредством передачи записей журнала транзакций. Группа доступности может содержать до девяти реплик: одну основную реплику и до восьми вторичных реплик.

2.1.3 Первичная реплика

Первичная реплика hostЭто копия базы данных доступности, доступная для чтения и записи. Все изменения данных (INSERT, UPDATE, DELETE) происходят на основной реплике. Клиентские приложения подключаются к основной реплике для всех операций записи и, по умолчанию, также для операций чтения.

2.1.4 Вторичные реплики

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

2.2 Режимы доступности

2.2.1 Режим синхронной фиксации

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

2.2.2 Асинхронный режим фиксации

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

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

2.3 Типы отказоустойчивости

2.3.1 Автоматическое переключение при сбое

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

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

2.3.2 Ручное переключение при отказе

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

Для реплик с синхронной фиксацией доступна функция ручного переключения без потери данных. Администратор инициирует переключение через SQL Server Management Studio, Transact-SQL или PowerShell. Основная реплика завершает обработку текущих транзакций и отправляет все оставшиеся записи журнала на основную реплику. tarполучает второстепенную роль и ждет подтверждения, прежде чем передать основную роль.

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

2.3.3 Принудительное переключение на резервный канал

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

2.4 Синхронизация данных

2.4.1 Как работает синхронизация данных

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

2.4.2 Записи журнала транзакций и усиление защиты

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

2.5 Масштаб чтения и доступные для чтения вторичные реплики

2.5.1 Перенос рабочих нагрузок только для чтения

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

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

2.5.2 Операции резервного копирования на вторичных репликах

Выполнение резервного копирования на вторичных репликах снижает нагрузку на ввод/вывод (I/O) и центральный процессор (ЦП) основной реплики, позволяя ей сосредоточиться на транзакционных задачах. Эта возможность помогает организациям выполнять требования к резервному копированию без ущерба для производительности производственной среды.

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

Для более подробной информации о SQL Server резервная копия, см. наш полное руководство.

2.6 Слушатели групп доступности

2.6.1 Что такое слушатель?

Слушатель группы доступности — это виртуальное сетевое имя (VNN) и IP-адрес, которые клиентские приложения используют для подключения к базам данных групп доступности. Слушатель автоматически перенаправляет соединения на текущую основную реплику, устраняя необходимость для приложений отслеживать, какой сервер в данный момент является основным.

2.6.2 Маршрутизация клиентских соединений

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

3. Предпосылки и требования

3.1 Кластеризация отказоустойчивости Windows Server для групп доступности

3.1.1 Основы отказоустойчивой кластеризации Windows Server

Кластеризация отказоустойчивости Windows Server (WSFC) обеспечивает основу для групп доступности Always On, управляя членством в кластере, мониторингом состояния и оркестрацией отказоустойчивости. В отличие от экземпляров отказоустойчивых кластеров, группы доступности используют WSFC только для координации кластера, а не для управления общим хранилищем.

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

3.1.2 Конфигурация кворума кластера

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

Для групп доступности доступно несколько режимов кворума:

Метод Node Majority использует только голоса узлов кластера и хорошо работает для кластеров с нечетным числом узлов.
Функция Node and File Share Majority добавляет голосование свидетеля по общему файловому ресурсу, что подходит для кластеров с четным числом узлов.
В режиме Node and Disk Majority используется дисковый свидетель, но он реже применяется в группах доступности, поскольку не требует общего хранилища.

3.1.3 Кластеризация с использованием нескольких подсетей

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

3.2 SQL Server Требования к изданию

3.2.1 Функции корпоративной версии

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

3.2.2 Функции стандартной версии (базовые группы доступности)

SQL Server В версиях Standard 2016 и более поздних поддерживается базовая поддержка групп доступности, но со значительными ограничениями. Базовые группы доступности обеспечивают основные функции высокой доступности при более низкой стоимости.ostПодходит для организаций с более простыми требованиями.

4. Настройка групп доступности Always On

4.1 Подготовка окружающей среды

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

4.1.1 Настройка контроллера домена

Контроллер домена Active Directory должен быть настроен для поддержки кластера групп доступности. SQL Server учетные записи служб.

Войдите в контроллер домена, используя учетные данные администратора домена.
Открыто Диспетчер серверов , а затем перейдите в Инструменты -> Пользователи и компьютеры Active Directory.
Создайте организационное подразделение для SQL Server объекты, если таковых не существует.
Убедитесь, что объекты компьютеров для всех узлов кластера существуют в Active Directory.
Убедитесь, что службы системы доменных имен (DNS) правильно настроены и все имена серверов разрешаются корректно.

4.1.2 Создание учетных записей служб

Создайте выделенные учетные записи службы Active Directory для SQL Server сервисы на каждом узле.

Открыто Пользователи и компьютеры Active Directory на контроллере домена.
Щелкните правой кнопкой мыши по соответствующему организационному подразделению и выберите Новое -> Информация о пользователе.
Введите имя учетной записи службы (например, svc_SQLServer) и задайте параметры. Имя пользователя для входа.
Нажмите Следующая и введите надежный пароль.
Выберите Пользователь не может изменить пароль и Пароль никогда не истекает.
Нажмите Следующая , а затем Завершить для создания учетной записи.
Повторите то же самое для всех дополнительных учетных записей сервиса, которые необходимы (SQL Server Агент, SSRS и т. д.).

4.1.3 Настройка прав администратора

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

Войдите на каждый сервер узла кластера.
Открыто Управление компьютером из Начать меню или Диспетчер серверов.
Расширьте Локальные пользователи и группы и Группы.
Щелкните правой кнопкой мыши Администраторы и Основные свойства.
Нажмите Добавить и введите имя учетной записи службы.
Нажмите Проверить имена Чтобы подтвердить учетную запись, нажмите... OK.
Нажмите OK чтобы закрыть диалоговое окно «Свойства администратора».
Повторите эти действия на всех узлах кластера.

4.2 Установка и настройка WSFC

Перед включением групп доступности Always On необходимо установить и настроить отказоустойчивую кластеризацию Windows Server на всех узлах.

4.2.1 Установка функции отказоустойчивой кластеризации

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

Открыто Диспетчер серверов на первом узле кластера.
Нажмите Управление -> Добавьте роли и функции.
Нажмите Следующая через вступительные экраны.
Выберите Установка на основе ролей или функций и нажмите Следующая.
Выберите локальный сервер и нажмите Следующая.
Пропустите экран «Роли» и нажмите Следующая.
На экране «Функции» выберите Отказоустойчивая кластеризация.
Нажмите Добавить функции когда вас попросят включить инструменты управления.
Нажмите Следующая , а затем Установите.
Дождитесь завершения установки и нажмите Закрыто.
Повторите эти действия на всех серверах, которые будут участвовать в кластере.

4.2.2 Создание отказоустойчивого кластера

После установки функции отказоустойчивой кластеризации на всех узлах создайте кластер с одного из узлов.

Открыто Менеджер отказоустойчивого кластера от Диспетчер серверов -> Инструменты.
Нажмите Создать кластер на панели Действия.
Нажмите Следующая на странице «Перед началом работы».
Нажмите Вставить и добавить все серверы, которые будут узлами кластера.
Нажмите Следующая после добавления всех узлов.
Оставлять Запустите все тесты (рекомендуется). выбрано и нажмите Следующая.
Проанализируйте результаты валидационных тестов и устраните все ошибки или предупреждения.
Нажмите Завершить после успешного завершения проверки.
Введите имя кластера и IP-адрес.
Снимите галочку с Добавьте все подходящие хранилища в кластер. поскольку общее хранилище не требуется.
Нажмите Следующая и проверьте подтверждение.
Нажмите Завершить для создания кластера.

4.2.3 Проверка конфигурации кластера

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

In Менеджер отказоустойчивого кластераЩелкните правой кнопкой мыши по имени кластера.
Выберите Проверка кластера из меню.
Нажмите Следующая на странице «Перед началом работы».
Выберите Запустите все тесты (рекомендуется). и нажмите Следующая.
Нажмите Следующая начать валидационные тесты.
Ознакомьтесь с отчетом о проверке после завершения тестов.
Устраните все выявленные в отчете неисправности или предупреждения.
Нажмите Завершить закрыть мастер.

НИКОГДА Не Устанавливать SQL Server для групп доступности

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

Запустите SQL Server установочные носители на первом узле.
Выберите Новое SQL Server автономная установка.
Введите ключ продукта или выберите ознакомительную версию.
Примите условия лицензии и нажмите Следующая.
Проведите все необходимые проверки и устраните все выявленные проблемы.
На странице выбора функций выберите Службы ядра базы данных.
Настройте имя экземпляра (используйте одно и то же имя экземпляра на всех узлах).
На странице «Конфигурация сервера» укажите учетные данные сервисной учетной записи.
Настройте службу starтипы tup как Автоматический.
На странице «Конфигурация ядра базы данных» выберите режим аутентификации.
Добавить учетные записи администратора.
Настройте каталоги данных, используя согласованные пути на всех узлах.
Завершите установку и подтвердите успешное завершение.
Повторите установку на всех остальных узлах кластера с идентичными настройками.

4.4 Включение функции групп постоянной доступности

После установки SQL Server На всех узлах включите функцию «Группы доступности Always On» для каждого экземпляра.

4.4.1 Включение через SQL Server Configuration Manager

Используйте SQL Server Менеджер конфигурации позволяет включить группы доступности Always On через графический интерфейс.

Открыто SQL Server Configuration Manager на первом узле.
Расширьте SQL Server Услуги в левой панели.
Щелкните правой кнопкой мыши SQL Server экземпляр и выбрать Основные свойства.
Нажмите Высокая доступность AlwaysOn меню.
Проверка Включить группы доступности AlwaysOn.
Убедитесь, что имя отказоустойчивого кластера Windows указано правильно.
Нажмите OK для сохранения изменений.
Нажмите OK с предупреждением о том, что услуга должна быть предоставлена повторно.tarТед.
Щелкните правой кнопкой мыши SQL Server обслуживание и выберите Restart.
Подождите, пока служба разрешится.tarуспешно.
Повторите эти действия на всех узлах кластера.

4.4.2 Включение через PowerShell

PowerShell предоставляет скриптовый метод для включения групп доступности Always On на нескольких узлах.

Откройте PowerShell от имени администратора на первом узле.
Импортируйте SQL Server Модуль PowerShell:
```
Import-Module SQLPS -DisableNameChecking
```

Включите группы доступности Always On:

Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

Сервис автоматически перезапустится.tart при использовании параметра Force.

Убедитесь, что функция включена:

Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

Повторите эти действия для каждого узла кластера, заменив соответствующие имена сервера и экземпляра.

4.4.3 Проверка включения функции

Перед продолжением настройки убедитесь, что функция Always On Availability Groups включена на всех экземплярах.

Подключиться к каждому SQL Server экземпляр с использованием SQL Server Студия управления.
Откройте новое окно запроса и выполните:
```
SELECT SERVERPROPERTY('IsHadrEnabled')
```
Убедитесь, что результат равен 1 (включено).
Убедитесь, что SQL Server Этот экземпляр отображается в диспетчере отказоустойчивых кластеров в разделе ролей кластера.
Убедитесь в существовании конечной точки группы доступности, выполнив следующую команду:
```
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
```
Если конечная точка не существует, она будет создана при создании группы доступности.

4.5 Подготовка баз данных для групп доступности

Перед добавлением в группу доступности базы данных должны соответствовать определенным требованиям.

4.5.1 Требования к модели восстановления базы данных

Перед добавлением основной реплики в группу доступности измените модель восстановления базы данных на «Полное» (FULL).

Подключитесь к основной реплике, используя SQL Server Студия управления.
Щелкните правой кнопкой мыши по базе данных и выберите Основные свойства.
Выберите Настройки стр.
Изменить Модель восстановления в Длинный.
Нажмите OK для сохранения изменений.
В качестве альтернативы можно использовать Transact-SQL:
```
ALTER DATABASE DatabaseName SET RECOVERY FULL;
```

4.5.2 Создание полных резервных копий базы данных

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

In SQL Server В Management Studio щелкните правой кнопкой мыши по базе данных.
Выберите Задач -> Поддерживать.
проверить Тип резервного копирования на Длинный.
Выберите место назначения для резервного копирования или добавьте новое место назначения.
Нажмите OK для выполнения резервного копирования.
В качестве альтернативы можно использовать Transact-SQL:
```
BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';
```

4.5.3 Создание резервных копий журнала транзакций

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

In SQL Server В Management Studio щелкните правой кнопкой мыши по базе данных.
Выберите Задач -> Поддерживать.
Изменить Тип резервного копирования в Журнал транзакций.
Выберите место назначения резервной копии.
Нажмите OK для выполнения резервного копирования.
В качестве альтернативы можно использовать Transact-SQL:
```
BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';
```

4.6 Создание группы доступности

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

4.6.1 Использование мастера создания новой группы доступности

Мастер создания новых групп доступности предоставляет графический интерфейс для их создания.

In SQL Server В Management Studio подключитесь к экземпляру, который будет...ost основная копия.
Расширьте Высокая доступность AlwaysOn в обозревателе объектов.
Щелкните правой кнопкой мыши Группы доступности и Мастер создания новой группы доступности.
Нажмите Следующая на странице «Введение».
Введите название для группы доступности и нажмите Следующая.
На странице «Выбор баз данных» выберите базы данных, которые необходимо включить.
Убедитесь, что базы данных соответствуют всем предварительным требованиям, и нажмите кнопку. Следующая.
На странице «Указать количество реплик» нажмите Добавить реплику.
Подключитесь к каждому вторичному экземпляру реплики.
Настройте свойства реплики для каждого экземпляра (режим доступности, режим отказоустойчивости).
Нажмите Endpoints Вкладка и просмотр конфигурации конечной точки.
Нажмите Настройки резервного копирования Вкладка и настройка приоритетов резервного копирования.
Нажмите слушатель Добавьте вкладку и, при необходимости, создайте обработчик событий.
Нажмите Следующая и выберите метод синхронизации данных.
Проанализируйте результаты проверки и устраните все выявленные проблемы.
Нажмите Следующая и ознакомьтесь с резюме.
Нажмите Завершить для создания группы доступности.
Отслеживайте ход выполнения и подтверждайте успешное создание.

4.6.2 Использование Transact-SQL

Создавайте группы доступности с помощью Transact-SQL для развертывания с возможностью написания скриптов и повторного выполнения операций.

Создайте группу доступности на основной реплике:

CREATE AVAILABILITY GROUP AG_Name
FOR DATABASE DatabaseName
REPLICA ON
  'PrimaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
  'SecondaryServer\Instance' WITH
    (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
     AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
     FAILOVER_MODE = AUTOMATIC,
     SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

Присоедините вторичную реплику к группе доступности:
```
ALTER AVAILABILITY GROUP AG_Name JOIN;
```
Присоединиться к дополнительной базе данных:
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```

4.6.3 Использование PowerShell

PowerShell предоставляет возможности написания сценариев для создания и управления группами доступности.

Создайте объект группы доступности:

$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

Добавить базы данных:

Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

Настройте реплики с заданными свойствами с помощью командлета New-SqlAvailabilityReplica.
Для подключения вторичных реплик используйте командлет Join-SqlAvailabilityGroup.

4.7 Добавление реплик в группу доступности

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

4.7.1 Настройка свойств реплики

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

In SQL Server Студия управления, развернуть Высокая доступность AlwaysOn -> Группы доступности.
Разверните группу доступности, а затем разверните Наличие реплик.
Щелкните правой кнопкой мыши по копии и выберите Основные свойства.
Проверьте и измените параметры подключения для основной и дополнительной ролей.
При необходимости настройте значения времени ожидания сессии.
Нажмите OK для сохранения изменений.

4.7.2 Настройка режимов доступности

Настройте режим доступности для управления поведением синхронизации между репликами.

Щелкните правой кнопкой мыши группу доступности и выберите Основные свойства.
В Общие страницу, перейдите на Наличие реплик .
Для каждой копии выберите Синхронная фиксация or Асинхронная фиксация из выпадающего списка.
Для обеспечения высокой доступности локальных реплик используйте синхронную фиксацию транзакций.
Используйте асинхронную фиксацию для географически удаленных реплик восстановления после катастрофы.
Нажмите OK для сохранения конфигурации.

4.7.3 Настройка режимов отказоустойчивости

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

Щелкните правой кнопкой мыши группу доступности и выберите Основные свойства.
В Общие страницу, перейдите на Наличие реплик .
Для синхронных реплик фиксации выберите Автоматический or Ручной режим резервирования.
Для автоматического переключения на резервный сервер требуется режим синхронной фиксации и обеспечивает возможность переключения в автоматическом режиме.
Для реплик с асинхронной фиксацией доступен только ручной механизм переключения при сбое.
Настройте до трех реплик для автоматического переключения при сбое (одну основную и две резервные).
Нажмите OK применить настройки.

4.7.4 Настройка параметров резервного копирования

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

Щелкните правой кнопкой мыши группу доступности и выберите Основные свойства.
Выберите Настройки резервного копирования в левой панели.
Выберите один из вариантов резервного копирования:
- Предпочитаю среднее образованиеРезервные копии создаются на вторичном сервере, если он доступен, в противном случае — на основном.
- Только вторичныйРезервные копии создаются только на вторичных репликах.
- первичнаяРезервные копии создаются только на основной реплике.
- Любая репликаРезервные копии на любой доступной реплике.
Установите значения приоритета резервного копирования для каждой реплики (0-100).
Более высокие значения приоритета указывают на предпочтительное резервное копирование. tarполучает.
Нажмите OK чтобы сохранить настройки.

4.8 Настройка прослушивателя группы доступности

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

4.8.1 Создание слушателя

Добавьте прослушиватель в группу доступности для управления подключениями клиентов.

In SQL Server В Management Studio разверните группу доступности.
Щелкните правой кнопкой мыши Слушатели группы доступности и Добавить слушателя.
Введите DNS-имя для прослушивателя (например, AG_Listener).
Введите номер порта (по умолчанию 1433).
Выберите Статический IP для сетевого режима.
Нажмите Добавить добавить IP-адрес для каждой подсети.
Введите IP-адрес и выберите подсеть.
Нажмите OK для создания слушателя.
Убедитесь, что обработчик событий отображается в обозревателе объектов и находится в сети.

4.8.2 Настройка параметров DNS и IP-адреса

Проверьте регистрацию DNS и сетевую конфигурацию для прослушивателя.

Откройте диспетчер DNS на контроллере домена.
Убедитесь, что имя слушателя зарегистрировано для всех IP-адресов.
Проверка разрешения DNS-имен с клиентских машин:
```
nslookup ListenerName
```
Убедитесь, что возвращены все настроенные IP-адреса.
В диспетчере отказоустойчивого кластера разверните роли и выберите группу доступности.
Убедитесь, что ресурсы IP-адреса находятся в сети.
Убедитесь, что ресурс сетевого имени находится в сети.

4.8.3 Проверка подключения слушателя

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

С клиентского компьютера откройте SQL Server Студия управления.
Для подключения используйте имя прослушивателя вместо имени сервера.
Выполните запрос для проверки соединения с текущей основной репликой:
```
SELECT @@SERVERNAME;
```
Проверьте маршрутизацию запросов на чтение, добавив ApplicationIntent=ReadOnly в строку подключения.
Проверьте перенаправление соединения на доступную для чтения вторичную реплику.
Проверьте работу системы аварийного переключения, вручную переключив группу доступности и убедившись в повторном подключении.

4.9 Методы синхронизации данных

Выберите метод синхронизации данных для инициализации вторичных реплик копиями базы данных.

4.9.1 Автоматический посев

Автоматическая загрузка данных в базу данных осуществляется по сети без необходимости ручного резервного копирования и восстановления.

При создании группы доступности выберите Автоматический посев в качестве метода синхронизации.
Обеспечьте сетевое соединение и достаточную пропускную способность между репликами.
Основная реплика автоматически передает данные базы данных на вторичные реплики.
Отслеживайте ход процесса посева с помощью панели мониторинга групп доступности или динамических представлений управления (DMV).
Для автоматического посева требуется SQL Server 2016 или позже.
При работе с большими базами данных следует учитывать влияние на сеть и планировать работу в периоды низкой загрузки.

4.9.2 Ручная инициализация (резервное копирование и восстановление)

Ручная инициализация системы включает в себя создание резервных копий на основном сервере и их восстановление на вторичных репликах.

На основной реплике сделайте полную резервную копию:
```
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
```
Создайте резервную копию журнала транзакций:
```
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
```
На каждой вторичной реплике восстановите полную резервную копию:
```
RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
```

Восстановите резервную копию журнала:

RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

Присоединить базу данных к группе доступности:
```
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
```
Убедитесь, что синхронизация началась и база данных достигла состояния SYNCHRONIZED.

4.9.3 Файлы моментальных снимков базы данных

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

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

5. Вопросы-Ответы

Общие вопросы 5.1

В: В чем разница между Always On FCI и Always On AG?

A: Экземпляры отказоустойчивого кластера Always On обеспечивают высокую доступность на уровне экземпляров с использованием общего хранилища, в то время как группы доступности Always On обеспечивают высокую доступность на уровне базы данных без общего хранилища. Группы доступности предлагают читаемые вторичные экземпляры и более гибкое географическое распределение.

В: Можно ли использовать группы доступности Always On с SQL Server Стандартное издание?

A: Да, SQL Server В версиях Standard Edition 2016 и более поздних поддерживается базовая группа доступности с ограничениями, включая одну базу данных на группу доступности, максимум две реплики и отсутствие поддержки чтения вторичных баз данных.

В: Нужно ли мне общее хранилище для групп доступности Always On?

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

В: Каково максимальное количество реплик в группе доступности?

A: SQL Server Версия Enterprise Edition поддерживает до девяти реплик (одну основную и восемь резервных). Распределенные группы доступности могут поддерживать до 18 реплик в общей сложности в рамках двух групп доступности.

5.2 Вопросы по настройке

В: Как выбрать между синхронным и асинхронным режимами фиксации транзакций?

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

В: Можно ли использовать синхронные и асинхронные реплики в одной группе доступности?

A: Да, группы доступности поддерживают смешанные конфигурации с синхронными и асинхронными репликами. Это обеспечивает локальную высокую доступность с синхронными репликами и удаленное аварийное восстановление с асинхронными репликами.

В: Что происходит с моими соединениями во время переключения на резервный канал?

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

В: Нужно ли синхронизировать учетные записи и задания между репликами?

A: В SQL Server В 2019 году и ранее — да, учетные записи, задания SQL Agent и связанные серверы необходимо синхронизировать вручную. SQL Server В 2022 году были введены группы доступности, которые автоматически включают эти объекты.

5.3 Вопросы управления

В: Можно ли создавать резервные копии на вторичных репликах?

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

В: Как установить патч? SQL Server с минимальным временем простоя?

A: Используйте поэтапное обновление, сначала устанавливая патчи на вторичные реплики, затем выполняя ручное переключение на обновленную вторичную реплику и, наконец, устанавливая патчи на бывшую основную реплику. Это сводит время простоя к продолжительности переключения.

В: Можно ли добавить базы данных в существующую группу доступности?

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

В: Что такое автоматический посев и следует ли его использовать?

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

В: Где в группе доступности следует запускать команду DBCC CHECKDB?

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

Для получения более подробной информации о DBCC CHECKDB см. наш полное руководство.

5.4 Вопросы по устранению неполадок

В: Почему моя база данных находится в состоянии «НЕ СИНХРОНИРУЕТСЯ»?

A: К распространенным причинам относятся проблемы с сетевым подключением, приостановка передачи данных, недостаточно места на диске на вторичных репликах или проблемы с конечными точками. Проверьте описание состояния синхронизации и SQL Server Подробности см. в журналах ошибок. Если во вторичной базе данных произошла ошибка... состояние восстановления или шоу ожидается восстановлениеСм. соответствующие руководства. tarБыли найдены исправления.

В: Как принудительно переключиться на резервный сервер, если основной сервер недоступен?

A: Подключитесь к вторичной реплике и выполните команду ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Это подтвердит потенциальную потерю данных и немедленно повысит статус вторичной реплики до основной.

В: Почему клиенты не могут связаться с моим собеседником?

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

В: Что означает большая очередь повторного выполнения?

A: Большая очередь повторного выполнения указывает на то, что вторичная реплика не может применять записи журналов так быстро, как они поступают. Это может свидетельствовать о проблемах с дисковым вводом-выводом, ограничениях ЦП или блокировке запросов только для чтения на вторичной реплике.

В: Что мне делать, если в результате катастрофы пострадали все реплики, и мои резервные копии также повреждены?

А: Этот наихудший сценарий, хотя и крайне... rarНапример, это может произойти из-за атак программ-вымогателей, масштабных сбоев в работе хранилищ или каскадных катастроф. Ваша основная защита — это профилактика: поддерживайте географически распределенные реплики, храните резервные копии в разных местах и
Регулярно проверяйте свои процедуры аварийного восстановления. Если все стандартные варианты восстановления окажутся неэффективными, используйте специализированный метод. Инструмент для восстановления данных SQL В качестве экстренной меры, применяемой в крайнем случае, можно попытаться извлечь данные из поврежденных файлов MDF.

5.5 Лицензирование и Cost вопросы

В: Как осуществляется лицензирование групп доступности Always On?

A: SQL Server Лицензирование зависит от версии и модели развертывания. Для групп доступности Enterprise Edition требуются лицензии Enterprise на всех репликах. Пассивные вторичные реплики могут получить бесплатное лицензирование при определенных условиях.

В: Могу ли я использовать SQL Server Версия для разработчиков, предназначенная для групп доступности?

A: Да, версия Developer Edition включает в себя все функции версии Enterprise Edition, в том числе полную поддержку групп доступности. Однако лицензия на нее предназначена только для разработки и тестирования, а не для использования в производственной среде.

В: Требуются ли дополнительные лицензии для читаемых вторичных файлов?

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

В: Существует ли бесплатный способ обеспечить высокую доступность? SQL Server?

A: SQL Server Express Edition не поддерживает группы доступности. SQL Server Стандартная версия поддерживает базовые группы доступности.tarтинг с SQL Server 2016 год, обеспечение базовой высокой доступности при лицензировании Standard Edition.osts.

В: Что такое распределенные группы доступности?

A: Распределенные группы доступности — это особый тип групп доступности, охватывающий две отдельные группы доступности, что позволяет реализовать сценарии, превосходящие возможности традиционных групп доступности. Введены в SQL Server В 2016 году группы по распределенной доступности рассмотрели требования к масштабируемости и географическому распределению.

6. Заключение

6.1 Краткое изложение ключевых моментов

SQL Server Группы доступности Always On представляют собой ведущее решение Microsoft для обеспечения высокой доступности и аварийного восстановления критически важных баз данных. Они обеспечивают переключение на уровне базы данных без необходимости использования общего хранилища, читаемые вторичные реплики для переноса рабочих нагрузок и гибкое географическое распределение для комплексной защиты данных. Для организаций, которые все еще используют такие решения, как... доставка журналов or копированиеГруппы доступности предлагают более надежный и оперативный способ обновления.

6.2 Когда следует использовать группы доступности Always On

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

6.3 Получение Starразработано с учетом ваших пожеланий.

Начните планирование групп доступности с оценки бизнес-требований, включая RTO, RPO и бюджетные ограничения. Задокументируйте текущую инфраструктуру баз данных, зависимости приложений и пробелы в обеспечении высокой доступности. Разработайте архитектуру групп доступности, которая отвечает требованиям, оставаясь при этом в рамках ресурсных ограничений.

Референсы

Официальный документ Microsoft: Что такое группа доступности "Всегда онлайн"?
Официальный документ Microsoft: Получение Starподключено к группам доступности Always On
Официальный документ Microsoft: Распределенные группы доступности

Об авторе

Юань Шэн старший администратор баз данных (DBA) с более чем 10-летним опытом работы в SQL Server сред и управления корпоративными базами данных. Он успешно реализовал сотни сценариев восстановления баз данных в финансовых, медицинских и производственных организациях.

Юань специализируется на SQL Server Восстановление баз данных, решения для обеспечения высокой доступности и оптимизация производительности. Его обширный практический опыт включает управление многотерабайтными базами данных, внедрение групп Always On Availability Groups и разработку автоматизированных стратегий резервного копирования и восстановления для критически важных бизнес-систем.

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

Есть вопросы о SQL Server Восстановление или требуется дополнительное руководство по устранению неполадок в базе данных? Юань приветствует отзывы и предложения для улучшения этих технических ресурсов.

SQL Server Группы доступности Always On: Полное руководство [2026]

1. Понимание групп постоянной доступности (Always On Availability Groups)

1.1 Что это такое и как это работает