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

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

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

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

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

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

selectreplica_server_name ,failover_mode_desc

fromsys.availability_replicas

where group_id=(select group_id fromsys.availability_groups wherename='Group_3')

select t2.replica_server_name,role_desc,synchronization_health_desc from

sys.dm_hadr_availability_replica_states t1

innerjoinsys.availability_replicas t2 ont1.replica_id =t2.replica_id

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

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

select name,state_desc fromsys.databaseswhere 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не отслеживает, у него только есть проверки на уровне службы MSSQLServer: она работает и доступна, нет внутренних ошибок.

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

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

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

CREATEAVAILABILITYGROUP [AOGroupDisk]
WITH (AUTOMATED_BACKUP_PREFERENCE=NONE,DB_FAILOVER =ON,….)

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

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

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

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

The database FailoverTest2016 is not accessible.

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

selectreplica_server_name ,failover_mode_desc

fromsys.availability_replicas

wheregroup_id=(select group_id fromsys.availability_groups where name='AOGroupDisk')

select t2.replica_server_name,role_desc,synchronization_health_desc from

sys.dm_hadr_availability_replica_states t1

innerjoinsys.availability_replicas t2 on t1.replica_id =t2.replica_id

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

select name,state_desc fromsys.databaseswhere name='FailoverTest2016'

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

В журнале MSSQLServerмы имеем:

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из-за редко используемой базы в группе, где несколько баз данных, с другой стороны и может быть плохо.

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

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

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

Latest Images

Trending Articles

Latest Images