В данной статье мы изучим пошаговую настройку группы высокой доступности SQL Server 2016 Standart Edition AlwaysOn для двух узлов.
Для настройки мы возьмем стенд с двумя виртуальными машинами:
- PRD-1CSQL-01 – это будет основной экземпляр, где наши базы будут нормально работать.
- PRD-1CSQL-02 – это будет наш второстепенный, с меньшей мощностью.
В статье мы будем сосредоточены на настройке AlwaysOn, а не на установке SQL Server, поэтому при настройке второго SQL Server убедитесь, что настройки аналогичны с первым и используются те же данные базы данных пользователя, буквы диска и пути диска, что и на основном сервере. Если же использовать разные пути, то всякий раз, когда вы добавляете данные или файл журнала в существующую базу данных, он будет успешным на первичном сервере, но затем не будет работать на реплике, где буквы и дисков отличаются.
Добавляем роль кластера
Группы доступности AlwaysON в SQL Server созданы на основе служб отказоустойчивой кластеризации Windows, необходимо объединить реплики AG в один кластер Windows.
Открываем Диспетчер серверов нажимаем «Управление», «Добавить роль и компоненты», выбираем свой сервер и в списке «Компоненты» устанавливаем флажок
Отказоустойчивая кластеризация:
Можно перейти к следующему этапу после установки данного компонента на всех серверах, которые будут включены в группу доступности.
Объединение серверов в отказоустойчивый кластер
Открываем Диспетчер серверов и нажимаем «Средства» – «Диспетчер отказоустойчивости кластеров».
Нажимаем «Создать кластер…» чтобы запустить мастер:
Вводим имена всех серверов, которые будут участвовать в группе доступности, и нажимаем «Далее».
В следующем окне вводим имя называемого кластера и его уникальный IP-адрес, нажимаем «Далее».
Подтверждаем введенные данные и переходим на этап «Создания нового кластера». После завершения создания, в сводке отразится информация о новом кластере:
Добавление узлов в кластер прошла успешно, можно добавлять дополнительные роли от требуемых задач, а мы переходим к следующему этапу настройки AlwaysOn.
Включаем группы доступности AlwaysOn на каждом сервере
На каждой реплике запускаем диспетчер конфигурации SQL Server, затем перейдем в службы SQL Server, нажимаем ПКМ службу SQL Server и выбираем свойства.
На вкладке AlwaysOn High Aviliability устанавливаем флажок «Включить« и нажимаем «ОК«. Это не вступит в силу пока служба SQL Server не будет перезапущена. Повторяем это на всех серверах SQL.
Создание группы доступности
Запускаем SQL Server Management Studio и начинаем создавать группу доступности.
В нашем случае, мы сделали базу «Base_AlwaysON» её и будем копировать во вторичную реплику. База уже находится в режиме полного восстановления, и выполнена полное резервное копирование, поэтому база уже соответствует требованиям группы доступности AlwaysOn.
В обозревателе объекта нажимаем ПКМ «Высокий уровень доступности Always On» и выбираем «Мастер создания групп доступности».
Есть пару опций, которые требуют объяснения:
Определение уровня работоспособности баз данных – эта функция замечает, когда база данных выходит из сетевого режима, в случае если возникают какие-либо неполадки, и инициирует автоматический переход группы доступности на другой ресурс.
Поддержка DTC для каждой базы данных – координатор распределенных транзакций (DTC) обеспечивает одновременную фиксацию между несколькими SQL-серверами, размещенным на другом оборудовании.
Мы это пропустим, т.к. не требуется в данном случае, и перейдем к следующему окну «Выбор баз данных», где отмечаем все требуемые базы для добавления в группу доступности, базы должны удовлетворять требованиям.
Добавляем вторичную реплику и устанавливаем режим доступности в зависимости от требований.
Режим асинхронной фиксации представляет собой решение аварийного восстановления, которое работает хорошо тогда, когда реплики доступности распределены на значительном расстоянии. Если каждая вторичная реплика доступности работает в режиме асинхронной фиксации, первичная реплика не ждет, пока какая-либо вторичная реплика зафиксирует журнал. Вместо этого сразу же после помещения записи журнала в локальный файл журнала первичная реплика отправляет клиенту подтверждение транзакции. Первичная реплика работает с минимальной задержкой транзакции в отношении вторичной реплики, настроенной для работы в режиме асинхронной фиксации. Если текущая первичная реплика настроена на работу в режиме асинхронной фиксации, то она фиксирует транзакции асинхронно для всех вторичных реплик, независимо от режимов доступности, заданных в каждой из них.
Режим синхронной фиксации отдает предпочтение высокому уровню доступности и защите данных перед производительностью ценой повышенной задержки транзакций. В режиме синхронной фиксации транзакции не отправляют клиенту подтверждение, пока вторичная реплика не зафиксирует журнал на диск. Когда в базе данных-получателе начинается синхронизация данных, вторичная реплика начинает применять записи журнала, поступающие от соответствующей базы данных-источника. Сразу после того, как все записи журнала зафиксированы на диск, база данных-получатель переходит в состояние SYNCHRONIZED. После этого каждая новая транзакция фиксируется вторичной репликой перед помещением записи журнала в локальный файл журнала. Когда все базы данных-получатели данной вторичной реплики синхронизированы, режим синхронной фиксации поддерживает переход на другой ресурс вручную, а также автоматический переход на другой ресурс.
Режим только конфигурации применяется к группам доступности, которые не находятся на отказоустойчивом кластере Windows Server. Реплика в режиме только конфигурации не содержит данных пользователя. В этом режиме реплика базы данных master хранит метаданные конфигурации группы доступности
Выбираем синхронизацию данных.
После завершения работы мастера щелкаем ПКМ на группе доступности в обозревателе объектов и нажимаем «Показать панель мониторинга»:
AlwaysOn настроен, можем запустить отработку отказа, для того чтобы исправить ошибки при их выявлении.
В итоге мы видим что отработка происходит успешно и группа доступности между серверами MS SQL реплицируется.
