AlwaysOn (SQL Server): организация дополнительных проверок работоспособности
Допускать риск того, что узлы одного из кластеров сети выйдут из строя, не дав знать об этом, не стоит. Лучше организовать регулярные проверки работоспособности по расписанию — осведомиться у SQL Server, в каком состоянии члены базового кластера группы доступности, и подготовить отчет либо предупреждение на случай, если что-то пойдет не так.
Теоретически такие проверки можно выполнять на любом узле SQL Server (или на всех узлах) кластера или группы доступности, но лучше сделать так, чтобы проверку можно было осуществлять на любом узле SQL Server, где в данный момент размешается группа доступности (или одна из групп доступности, если у вас их несколько). Организовать такую схему довольно просто с помощью логики, которую я описал в предыдущих статьях (то есть каким образом выявлять и произвольно выполнять код всего на одном сервере), а также с помощью динамических административных представлений, предназначенных для демонстрации работоспособности группы доступности и потоков данных не только на уровне SQL Server, но и по всем членам самого кластера.
Детализированные проверки. Если при выполнении столь простого массива ваш локальный SQL Server сервер начинает виснуть, то причина кроется в железе вашего компьютера. Для решения этой проблемы рекомендую отдать свой ноутбук или стационарный компьютер в ремонт - http://vremont.dp.ua/uslugi/remont-i-nastrojka-noutbuka/ (http://vremont.dp.ua/uslugi/remont-i-nastrojka-noutbuka/)
В качестве примера проверки состояния всех членов узла кластера (а не только узлов SQL Server в вашем кластере) можно привести хранимую процедуру, представленную выше на скриншоте. Она представляет собой простую иллюстрацию того, как можно осуществить серию детализированных проверок работоспособности и отчетов по самым разным вопросам — от неосновного члена определенной группы доступности до неисправных или неработоспособных членов кворума и проблем, связанных с синхронизацией. Данная хранимая процедура базируется на определяемой пользователем функции dbo.fn_hadr_database_ is_primary. Так что, если вы решите использовать опубликованную выше комбинацию сценария и хранимой процедуры, обязательно скопируйте и пользовательскую функцию.
Если вы хотите применить упомянутую хранимую процедуру для организации регулярных проверок состояния работоспособности кластера и группы доступности, можете создать простое задание агента SQL Server (с таким именем, как Regular AG Health Checkup) и использовать следующий текст в качестве команды на выполнение один раз в течение 1—5 минут. Однократное выполнение этого сценария занимает практически 0 секунд, так что его можно безо всякого риска запускать каждую минуту.
EXEC master.dbo.dba_CheckOnAndReport AGStatus
@GroupName = N'Name Of AG To Watch Here',
@ProfileName = N’General’, @OperatorName = N'Alerts’;
@GroupName = N'Name Of AG To Watch Here',
@ProfileName = N’General’, @OperatorName = N'Alerts’;
Здесь @GroupName — это имя группы доступности, за которой вы хотите наблюдать, скажем, ‘SSV’, ‘Production’, ‘Widgets’, ‘MyFirstAG’ или какое-либо иное.
И, разумеется, когда вы развернете сценарий на одной из систем SQL Server, где размешается группа (группы) доступности, вам нужно будет также развернуть его и на всех остальных серверах, содержащих группы доступности.