Есть AlwaysOn. Есть причина перейти на MS SQL Server 2016

AlwaysОn,  пришедшая в MS  SQL Server с версии 2012, очень хорошая технология,  которая позволяет реализовать высокую доступность баз данных, а так же позволяет частично реализовать балансировку запросов к СУБД, правда только запросов на чтение, но и это уже хорошо.

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

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

Итак, простой, пример:

Имеем Microsoft SQL Server 2014 (SP2) 12.0.5000 в конфигурации AlwaysOn с двумя узлами. Настроен автоматический Failover.

select replica_server_name ,failover_mode_desc 

from sys.availability_replicas

where group_id=(select group_id from sys.availability_groups where name='Group_3')

select t2.replica_server_name,role_desc,synchronization_health_desc  from

sys.dm_hadr_availability_replica_states t1

inner join sys.availability_replicas t2 on t1.replica_id =t2.replica_id

where t1.group_id =(select group_id from sys.availability_groups where name='Group_3')

Есть база данных, файлы которой расположены на диске E:\, к примеру, статус в рабочем состоянии должен быть ONLINE

select name,state_desc from sys.databases where name='AOGroup3'

name                state_desc

AOGroup3          ONLINE

А давайте форматнем диск, к примеру, сделаем имитацию ухода диска в Offline

Что мы видим, База стала в состоянии RECOVERY_PENDING

а в  журнале ошибочка :

Message
Unable to open the physical file "E:\data\AOGroup3.mdf". Operating system error 3: "3(The system cannot find the path specified.)".

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

.

Это один из минусов технологии AlwaysOn, что происходит внутри базы данных процесс RHS, который проверяет кластерные сервисы кластера Windows не отслеживает, у него только есть проверки на уровне службы MS SQL Server: она работает и доступна, нет внутренних ошибок.

Но все меняется, когда пришел MS SQL Server 2016 J.

Теперь, при создании группы доступности, необходимо указать параметр “Database Level Heath Detection”, (я работаю на Microsoft SQL Server 2016 (RTM-CU1)(KB3164674) - 13.0.2149.0):

Либо, кто любит T-SQL:

CREATE AVAILABILITY GROUP [AOGroupDisk]
WITH (AUTOMATED_BACKUP_PREFERENCE = NONE,DB_FAILOVER = ON,….)

Состояние нашей группы все ОК:

В группу я добавил тестовую бд FailoverTest2016.

Далее, еще раз форматнем наш диск E:\, где расположена наша база данных.

Давайте обратимся и сделаем запрос к нашей базе данных, результат:

The database FailoverTest2016 is not accessible.

Смотрим статус нашей группы доступности и базы данных:

select replica_server_name ,failover_mode_desc 

from sys.availability_replicas

where group_id=(select group_id from sys.availability_groups where name='AOGroupDisk')

select t2.replica_server_name,role_desc,synchronization_health_desc  from

sys.dm_hadr_availability_replica_states t1

inner join sys.availability_replicas t2 on t1.replica_id =t2.replica_id

where t1.group_id =(select group_id from sys.availability_groups where name='AOGroupDisk')

select name,state_desc from sys.databases where name='FailoverTest2016'

Что мы видим: произошел Failover  и группа доступности переехала!!!

В журнале MS SQL Server мы имеем:

Error: 41653, Severity: 21, State: 1.
Message
Database 'FailoverTest2016' encountered an error (error type: 2 'DB_SHUTDOWN') causing failure of the availability group 'AOGroupDisk'.  Refer to the SQL Server error log for information about the errors that were encountered.  If this condition persists, contact the system administrator.

Кстати, надеюсь, алерты на Severity: 21 у всех настроены)?!.

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

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

В любом случае мы имеем еще более прекрасное средство высокой доступности баз данных реализованные на Microsoft SQL Server.

Всем высоко доступных баз данных, Пока!

p.s: Если вам нужен администратор MS SQL Server- временно, постоянно,удаленно, на проект или просто сделать аудит, можете обратиться здесь или в комментариях.