Ако внедрявате групи за наличност на SQL Server, един от важните аспекти на успешното внедряване е наблюдението на синхронизирането на базите данни на вторични реплики с първичната реплика. Има множество начини за наблюдение на синхронизирането на репликата в група за наличност и тази публикация ще покаже всеки от тях и ще обясни техните предимства и недостатъци,
Един от най-лесните начини за наблюдение на състоянието на групата наличност, всеки от сървърите реплики и базите данни за наличност е чрез вграденото табло за управление в Management Studio. Въпреки това, оформлението по подразбиране на таблото за управление не предоставя много подробности и ще трябва да бъде персонализирано, за да показва допълнителна информация за сървърите за реплики, както и базите данни за наличност. Допълнителни колони могат да бъдат добавени към оформлението чрез връзката Добавяне/Премахване на колони на таблото за управление или чрез контекстното меню с десния бутон на мишката върху някоя от съществуващите заглавки на колони, както е показано по-долу:
Персонализиране на таблото за управление на AG в SSMS
За базите данни за наличност, наблюдението на размера на опашката за изпращане на регистрационни файлове (KB), скоростта на изпращане на регистрационни файлове (KB/сек), приблизителната загуба на данни (време), прогнозното време за възстановяване (секунди) и производителността на синхронизиране (секунди) ще ви даде по-добро разбиране за това как данните се движат към репликите и цялостното здраве на базите данни за наличност. Например на екранната снимка по-долу промених конфигурацията на VM мрежата за SQL03, така че да има по-висока латентност и по-ниска пропускателна способност, което се отразява на синхронизирането на базите данни:
Тук можем да видим, че има близо шест минути потенциална загуба на данни за SQL03 и 505 MB неизпратен дневник, който се изпраща със скорост от 7 MB/сек към вторичния (което в този случай е асинхронен вторичен) . Докато SQL02 в момента е настигнат и няма загуба на данни като синхронен вторичен в конфигурацията.
Алтернатива на таблото за управление на групата за наличност е директното запитване на DMV, откъдето таблото за управление извлича информацията си като източник. Следната заявка показва текущото състояние и показатели за синхронизиране за всяка база данни в група за наличност:
SELECT ar.replica_server_name, adc.database_name, ag.name AS ag_name, drs.is_local, drs.is_primary_replica, drs.synchronization_state_desc, drs.is_commit_participant, drs.synchronization_health_desc, drs.recovery_lsn, drs.truncation_lsn, drs.last_sent_lsn, drs.last_sent_time, drs.last_received_lsn, drs.last_received_time, drs.last_hardened_lsn, drs.last_hardened_time, drs.last_redone_lsn, drs.last_redone_time, drs.log_send_queue_size, drs.log_send_rate, drs.redo_queue_size, drs.redo_rate, drs.filestream_send_rate, drs.end_of_log_lsn, drs.last_commit_lsn, drs.last_commit_time FROM sys.dm_hadr_database_replica_states AS drs INNER JOIN sys.availability_databases_cluster AS adc ON drs.group_id = adc.group_id AND drs.group_database_id = adc.group_database_id INNER JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id INNER JOIN sys.availability_replicas AS ar ON drs.group_id = ar.group_id AND drs.replica_id = ar.replica_id ORDER BY ag.name, ar.replica_server_name, adc.database_name;
Чрез запитване на DMV директно върху основната реплика е лесно да получите актуална информация, без да чакате периода на опресняване на таблото за управление в Management Studio. Това е било полезно няколко пъти, докато се консултирате с клиенти, които са имали повреда на връзката между центровете за данни или където свързаността е била прекъсната за поддръжка за определен период от време, а вторичните реплики са в процес на наваксване, след като връзката бъде възстановена .
Последният естествен инструмент за наблюдение на синхронизацията на групата наличност е Performance Monitor, използващ обекта за производителност SQLServer:Replika на база данни. Таблицата по-долу показва съответните броячи на производителност и техните описания от Books Online (https://msdn.microsoft.com/en-us/library/ff878356(v=sql.110).aspx):
| Име на брояча | Описание |
|---|---|
| Получени файлови байтове/сек | Количество данни на FILESTREAM, получени от вторичната реплика за вторичната база данни през последната секунда. |
| Регистрационни байтове, получени/сек. | Количество регистрационни записи, получени от вторичната реплика за базата данни през последната секунда. |
| Остава дневник за отмяна | Количеството килобайти за влизане, оставащи за завършване на фазата на отмяна. |
| Опашка за изпращане на журнал | Количество регистрационни записи в регистрационните файлове на първичната база данни, в килобайти, които все още не са изпратени до вторичната реплика. Тази стойност се изпраща на вторичната реплика от първичната реплика. Размерът на опашката не включва FILESTREAM файлове, които се изпращат на вторичен. |
| Опашка за възстановяване | Количество регистрационни записи в регистрационните файлове на вторичната реплика, която все още не е преработена. |
| Повторно блокирано/сек | Брой пъти, когато нишката за повторно изпълнение е блокирана при заключвания, държани от читателите на базата данни. |
| Повторете оставащи байтове | Количеството килобайти за влизане, които остават за преработка, за да завърши фазата на връщане. |
| Преработени байтове/сек | Количество регистрационни записи, преработени във вторичната база данни през последната секунда. |
| Общ регистрационен файл, изискващ отмяна | Общо килобайтове регистрационни файлове, които трябва да бъдат отменени. |
Едно от предизвикателствата и ограниченията при използването на Performance Monitor за наблюдение на средата е, че обектът е валиден само за екземпляр на SQL Server, който хоства вторична реплика. Това означава, че трябва да добавите броячите от всяка вторична реплика в Performance Monitor, за да получите пълен поглед върху това, което се случва с всички вторични бази данни, където както таблото за управление на AG в Management Studio, така и DMV заявката към първичната реплика предоставят информация за всички вторични бази данни на едно място.
Като алтернатива на вградените функции за наблюдение на синхронизирането на групата за наличност, можете също да използвате инструменти на трети страни като SQL Sentry Performance Advisor, който включва наблюдение на групите за наличност като стандартна функция. Можете да прочетете повече за тази функция в тази публикация в блога от Грег Гонзалес, който за първи път представи функцията във версия 7.5 на продукта.
Табло за управление на Performacnce Advisor AG
Разделът Replicas в Performance Advisor позволява всеки от вторичните сървъри за реплики да бъде разширен, за да се покажат лесно базите данни и техните текущи данни за синхронизиране. Оформлението по подразбиране на матрицата на възел/група на WSFC в горната част на таблото за управление също дава здравна информация за състоянието на опашката за изпращане на първичната реплика, състоянието на опашката за повторно изпълнение на вторичната реплика и потока от данни между всеки от сървърите на репликата. В този пример можем да видим, че опашката за изпращане на регистрационни файлове на основния в момента изпраща голямо количество данни от SQL01 до SQL03, въз основа на ширината на линията между сървърите, след като проблемите със свързаността между SQL01 и SQL03 бяха коригирани в околната среда. Диаграмата вдясно показва скоростта, с която данните се прехвърлят от SQL01, заедно с текущия размер на опашката за изпращане на журнал, тъй като това е репликата, избрана от лявата страна. Щракването върху един от другите сървъри за реплики в оформлението на WSFC възел/групова матрица също ще промени диаграмата, за да съответства на показателите за ефективност на тази конкретна реплика от дясната страна.
Има много начини за наблюдение на производителността на синхронизирането на данни между реплики сървъри в група за наличност в SQL Server. Вграденото табло за управление на групата наличност в Management Studio съдържа изобилие от информация, която е лесна за достъп, след като знаете как да персонализирате оформлението, за да показва най-важната информация на таблото. Възможно е също така да се използват DMV директно от основния сървър за реплики, за да се наблюдава ефективността на синхронизирането на данни с помощта на Transact-SQL, а инструменти на трети страни като SQL Sentry включват и наблюдение на синхронизирането на данни. Въпреки че Performance Monitor може да предостави същата информация, фактът, че броячите на производителността са достъпни само от вторичния сървър реплика, прави малко повече работа, за да получите пълен изглед на цялата среда.
