В этой статье мы рассмотрим пошаговое руководство по установке и настройке Always On Группы доступности на SQL Server под управлением Windows Server 2019, обсуждение сценариев обхода отказа и некоторые другие связанные темы.
Группы доступности Always On обеспечивают высокую доступность в MIcrosoft SQL Server. Always On появились в выпуске MSSQL 2012.
Особенности групп доступности Always On в SQL Server
Для чего можно использовать группы доступности SQL Server?
- Высокая доступность MS SQL и автоматическое восстановление после отказа;
- Балансировка нагрузки при выполнении SELECT-запросов между узлами (вторичные реплики могут быть доступны для чтения);
- Резервное копирование из вторичных реплик;
- Избыточность данных. Каждая реплика хранит копии базы данных группы доступности.
Always On основана на Кластер отказоустойчивости Windows Server (WSFC). WSFC контролирует узлы группы доступности и обеспечивает автоматическое восстановление после отказа. Начиная с MS SQL Server 2017, Always On можно использовать без WSFC и в Linux также хосты. При создании кластера на базе Linux можно использовать Pacemaker вместо WSFC.
Always On доступен в Стандарт издание, но оно имеет некоторые ограничения:
- Она ограничена 2 репликами (первичной и вторичной);
- Вторичная реплика не может быть использована для чтения данных;
- Вторичная реплика не может использоваться для резервного копирования MS SQL;
- Поддерживается только 1 база данных на группу доступности.
Нет никаких ограничений в Предприятие издание.
Рассмотрим термины.
- Группа доступности Always On это набор реплик и баз данных;
- Реплика это экземпляр SQL Server в группе доступности. Реплика может быть первичной или вторичной. Каждая реплика может содержать одну или несколько баз данных.
Always On основана на WSFC. Каждый узел группы доступности должен быть членом кластера отказоустойчивости Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. Каждая группа доступности может иметь до 8 вторичных реплик.
Если первичная реплика выходит из строя, кластер голосует за новую первичную реплику, а Always On делает одну из вторичных реплик первичной. Поскольку пользователи подключаются к Listener (специальный IP-адрес кластера и соответствующее DNS-имя) при работе с Always On, то снова станет возможным выполнение запросов на запись. Слушатель также отвечает за балансировку SELECT-запросов между вторичными репликами.
Настройка Windows Failover Cluster для группы доступности Always On
Прежде всего, мы должны настроить кластер обхода отказа на всех узлах, используемых Always On.
Вот моя конфигурация:
- 2 виртуальные машины под управлением Windows Server 2019
- 2 экземпляра SQL Server 2019 Enterprise
- Имена хостов узлов — testnode1 и testnode2. Имена экземпляров SQL Server — node1 и node2.
Добавьте Failover Clustering роль с помощью диспетчера сервера или установите ее с помощью PowerShell:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
Установка происходит автоматически, и вам пока не нужно ничего настраивать. Запустите Failover Cluster Manager оснастка (FailoverClusters.SnapInHelper.msc) и создайте новый кластер.
Добавьте имена узлов, которые нужно присоединить к кластеру.
Затем мастер предлагает пройти несколько тестов. Для этого выберите первый пункт.
Укажите имя кластера, выберите сеть и IP-адрес кластера. Имя кластера появится в DNS автоматически; вам не нужно создавать DNS-запись вручную. В моем случае имя кластера ClusterAG.
Снимите флажки с опций Добавьте все подходящие хранилища в кластер , поскольку мы сможем добавить диски позже.
В кластере только два узла, поэтому необходимо настроить Кворум кластера. Кворум кластера является решающим голосом. Например, если один из узлов кластера становится недоступным, кластер должен определить, какие узлы действительно находятся в сети и могут видеть друг друга. Кворум кластера обеспечивает согласованность кластера (Cluster -> More Actions -> Configure Cluster Quorum Settings).
Выберите параметр свидетеля кворума.
Затем выберите тип свидетеля: свидетель файлового ресурса.
Укажите UNC-путь к общей папке. Создайте каталог самостоятельно. Он должен находиться на сервере вне кластера обхода отказа.
При настройке кластера может возникнуть следующая ошибка:
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
Вероятно, учетная запись пользователя, под которой работает кластер, не имеет NTFS-разрешений для доступа к общей папке. По умолчанию кластер работает под учетной записью локального пользователя. Вы можете предоставить права на папку всем компьютерам кластера или изменить учетную запись для службы кластера и предоставить ей соответствующие привилегии.
Базовая конфигурация Windows Failover Cluster завершена.
Настройка группы доступности Always On на MS SQL Server
После установки типичного экземпляра SQL Server вы можете включить и настроить группы доступности Always On Availability Group. Включите их в свойствах экземпляра SQL Server Configuration Manager. Как видно на снимке экрана, SQL Server уже обнаружил, что принадлежит к кластеру WSFC. Проверьте Включить группы доступности Always On и перезапустите службу экземпляра MSSQL. Сделайте то же самое для второго экземпляра.
Запустите SQL Server Management Studio, подключитесь к хосту, нажмите кнопку Always On High Availability, и запустите Мастер создания новой группы доступности.
Укажите имя для группы доступности Always On и выберите Обнаружение состояния на уровне базы данных. С помощью этого параметра Always On сможет обнаружить, когда база данных нездорова.
Выберите базы данных SQL Server для добавления в группу доступности Always On.
Нажмите Добавить реплику и подключите второй SQL-сервер. Таким образом можно добавить до 8 серверов.
- Начальная роль это роль-реплика на момент создания группы. Она может быть как первичной, так и вторичной;
- Автоматическое обход отказа — если база данных становится недоступной, Always On переместит основную роль на другую реплику. Проверьте этот пункт;
- Режим доступности позволяет выбрать синхронную (Synchronous Commit) или асинхронную (Asynchronous Commit) фиксацию. Если вы выберете синхронный режим, транзакции, поступающие в первичную реплику, будут отправляться во все остальные вторичные реплики с синхронным режимом. Первичная реплика завершает транзакцию только после того, как другие реплики запишут ее на диск. Таким образом, потеря данных исключается в случае сбоя первичной реплики. В асинхронном режиме первичная реплика записывает изменения немедленно, не дожидаясь ответа других реплик.
- Вторичная реплика с возможностью чтения это параметр, позволяющий выполнять SELECT-запросы к вторичным репликам. Если значение равно yes, клиенты смогут получить доступ только для чтения, даже если подключаться без
ApplicationIntent=readonly. - Требуются синхронизированные второстепенные задачи для фиксации это количество синхронизированных вторичных реплик для завершения транзакции. Установите его в зависимости от количества реплик, я установлю его равным 1.
Не редактируйте ничего в файле Конечная точка вкладка.
В Параметры резервного копирования На вкладке можно выбрать, откуда будут создаваться резервные копии. Оставьте здесь настройки по умолчанию: Предпочитать вторичный.
Укажите имя, порт и IP-адрес приемника группы доступности.
Оставьте Маршрутизация, доступная только для чтения настройки не изменены.
Выберите тип синхронизации реплики. Я оставляю первый пункт (Автоматический посев) проверено.
Затем ваши настройки должны быть проверены. Если ошибок нет, нажмите Finish, чтобы применить изменения.
В моем случае все тесты прошли успешно, но на шаге Results после установки мастер показал ошибку создания слушателя группы доступности. В журналах событий кластера появилась ошибка EVENTID 1194:
Cluster network name resource failed to create its associated computer object in the domain.
Это означает, что кластер не имеет достаточных разрешений для создания слушателя. В документации говорится, что достаточно предоставить привилегию на создание объектов компьютерного типа объекту вашего кластера. Проще сделать это с помощью делегирования привилегий в AD (или быстрый, но небезопасный вариант — временно добавить объект CLUSTERAG$ в группу Domain Admins).
Поскольку я создал группу доступности, но не создал слушателя, я добавил его вручную. Откройте контекстное меню группы доступности и нажмите Добавить слушатель.
Укажите IP-адрес, порт и DNS-имя приемника.
Убедитесь, что приемник появился в списке Слушатели группы доступности раздел вашей группы Always On.
Таким образом, вы завершили базовую настройку группы доступности Always On.
SQL Server Always On: Проверка работоспособности и обход отказа
Давайте посмотрим на приборную панель группы доступности (Show Dashboard).
Все в порядке, группа создана и работает.
Давайте попробуем сделать узел 2 основным экземпляром вручную. Щелкните правой кнопкой мыши группу доступности и выберите Failover.
Обратите внимание на значение в Готовность к обходу отказа. Без потери данных означает, что данные не будут потеряны.
Подключитесь к узлу2.
Нажмите Готово.
Убедитесь, что узел2 стал первичной репликой (Primary Instance) в группе доступности.
Убедитесь, что приемник работает правильно. Укажите DNS-имя и порт приемника через запятую в SSMS: ag1-listener-1,1445
Выполняйте простые SQL-запросы на вставку, выборку и обновление базы данных.
Затем проверьте автоматическое обход отказа первичной реплики. Просто убейте процесс sqlservr.exe на TESTNODE2.
Проверьте состояние группы доступности на оставшемся узле: TESTNODE1\NODE1.
Кластер автоматически изменил статус testnode1\node1 на primary, поскольку testnode2\node2 стал недоступен.
Проверьте состояние слушателя, поскольку клиенты будут использовать его для подключения.
В моем случае я успешно подключился к слушателю, но при попытке получить доступ к базе данных я получил эту ошибку:
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
Ошибка возникла из-за того, что Требуется синхронизированный вторичный процесс для фиксации опция. Поскольку при настройке мы установили значение 1, Always On не позволяет ему подключиться к базе данных, поскольку у нас осталась только одна первичная реплика.
Установите значение 0 и попробуйте выполнить запрос снова.
Testnode1 сохранил статус первичного экземпляра, а testnode2 стал вторичным. Данные, которые мы изменили на узле testnode1, когда testnode2 был выключен, успешно синхронизировались после включения компьютера.
Итак, мы убедились, что все работает корректно и данные будут доступны для чтения/записи в случае критического сбоя.
Вы можете легко настроить группы доступности Always On. Если вы хотите создать решение по обходу отказа на базе SQL Server, группы доступности отлично справятся с этой задачей.