Транзакционна репликация на SQL сървър е една от най-често използваните техники за репликация, използвана за копиране или разпространение на данни в множество дестинации. В предишната статия обсъдихме репликацията на SQL Server, типовете репликация и основните вътрешни елементи за това как работи транзакционната репликация. Сега ще се потопим в Advanced Internals за това как работи транзакционната репликация на SQL Server.
Архитектура за репликация на транзакции
Преди да започнем, препоръчвам ви да опресните знанията си с предишната ми статия тук.
Нека започнем, като разгледаме архитектурата на транзакционната репликация на SQL Server, показана по-долу от документацията на Microsoft.
В База данни за издатели , създайте публикация включващ списък с статии (Таблици , Прегледи и т.н.), които трябва да репликирате на Абоната база данни. След като статиите са активирани за репликация, всички промени, които се случват в тези статии, ще бъдат маркирани за репликация в базата данни на регистрационните файлове на транзакциите на издателя.
Транзакционната репликация на SQL Server може да бъде инициализирана от Издателя до Дистрибутор и след това до Абонат база данни чрез Snapshot Agent или Пълен Резервни копия . Агентът за моментни снимки може да извърши Инициализация чрез Съветника за конфигуриране на репликация . Пълното архивиране се поддържа само чрез изрази на T-SQL.
Агентът за четене на журнали сканира дневника на транзакциите на базата данни на издателя, за да открие проследените промени, маркирани за репликация. Той игнорира други промени, записани в регистрационните файлове на транзакциите, и копира промените в данните от транзакционния дневник в базата данни за разпространение.
Базата данни за разпространение може да бъде или в Publisher или Subscriber, или може да бъде в друг независим екземпляр на SQL Server. Обърнете внимание на следните неща:
- Агентът за четене на журнали работи непрекъснато от сървъра на дистрибутора, за да сканира за нови команди, маркирани за репликация. Ако обаче не искате да работите непрекъснато и вместо това искате да работите по график, можем да променим SQL заданието на агента за четене на журнали, което ще бъде създадено.
- Агентът за четене на журнали взема всички записи, които са маркирани за репликация, от регистрационния файл на транзакциите в пакети и ги изпраща в базата данни за разпространение.
- Агентът за четене на журнали улавя само ангажименти транзакции от регистрационния файл на транзакциите на базата данни на издателя. Така че всички продължителни заявки в базата данни на издателя могат директно да повлияят на репликацията, тъй като тя чака активната транзакция да завърши.
Агентът за разпространение взема всички неразпределени нови команди от базата данни за разпространение и ги прилага към базата данни за абонамент чрез Push или Издърпайте Механизъм .
- Натиснете абонамент – Дистрибутор поема собствеността да прилага промени от базата данни за разпространение към абоната.
- Изтеглете абонамент – Абоната базата данни поема собственост, за да извлича промени от базата данни за разпространение към абоната.
След като записите се разпространят успешно от Разпределение към базата данни на абонатите, те ще бъдат маркирани като Разпределени и също така маркирани за изтриване от базата данни за разпространение .
Една от основните задачи за поддръжка на репликация е Почистване на разпространението :Заданието за разпространение се изпълнява на всеки 10 минути, за да изтрие разпределените записи от базата данни за разпространение, за да поддържа размера на базата данни за разпространение под контрол.
Следователно нашата цел за настоящата статия е да проучим следните теми:
- База данни за разпространение
- Агенти за репликация
- Агент за моментни снимки
- Агент за четене на журнали
- Агент по разпространение
- Профили на агента за репликация
- Работа за поддръжка на репликация
- Закъснение на репликация и маркери за проследяване
- Помощна програма TableDiff
- Сигнали за агент на SQL сървър
База данни за разпространение на SQL сървър
База данни за разпространение е системна база данни, създадена при конфигуриране на репликация. Това е сърцето на репликацията, тъй като по-голямата част от процеса се изчерпва от база данни за разпространение.
Поради естеството на базата данни за разпространение, ние можем да извършваме само ограничени операции върху нея, като архивиране и възстановяване. Не можем да го пуснем директно като потребителски бази данни.
За огромна база данни с много данни, които се репликират, трябва да предприемем няколко специални мерки за подобряване на производителността на репликация:
По подразбиране базата данни за разпространение се създава по пътеката за инсталиране по подразбиране, конфигурирана в SQL Server . Ако не е конфигуриран, той ще бъде създаден на C : устройство или в папките за инсталиране на SQL Server. Препоръчваме ви да преместите базата данни за разпространение на по-бързо съхранение/диск, за да подобрите производителността.
Началният размер на файла и Автоматичен растеж на базата данни за разпространение ще се настрои в съответствие с началния размер на файла и настройките за автоматично нарастване на базата данни на модела. Конфигурирайте първоначалния размер на файла на по-добра стойност, като 10 GB в случай на репликация на база данни, натоварена с транзакции. Свойствата Autogrowth трябва да са до 512 MB или 1 GB както за данни, така и за регистрационни файлове. Тогава няма да има голяма фрагментация на данните и регистрационните файлове.
Конфигурирайте Ежедневно или Рутинни задания за архивиране да включите базата данни за разпространение за справочни цели или за отстраняване на неизправности в случай на повреда или загуба на данни.
Конфигурирайте Ежедневната реорганизация на индекса или Поддръжка работни места за да включите базата данни за разпространение. Базата данни включва огромни вмъквания на данни в MSrepl_transactions и MSrepl_commands таблици.
Забележка:Непрекъснатото анкетиране на тези 2 таблици и ИЗТРИВАНЕ от тях след успешно изпращане на данни към базата данни на абоната увеличава риска от фрагментация. Възстановяването на тези таблици по график може да подобри производителността на базата данни за разпространение.
За да видите и промените някой от атрибутите на базата данни за разпространение, свързани с репликация, щракнете с десния бутон върху Репликация > Свойства на дистрибутора :
Кликнете върху елипса бутон вдясно, за да видите повече подробности за изброените отделни опции.
Обърнете внимание, промяната на всички параметри може да повлияе на производителността на базата данни за разпространение. Следователно внедрявайте промените само след като прецените внимателно всички параметри, които искате да промените.
Задържане на транзакции определя колко данни трябва да се съхраняват в базата данни за разпространение. Минималните и максималните стойности могат да бъдат посочени в часове или дни.
Стойността за запазване на транзакциите, зададена на 0 часа, показва, че след като записите бъдат успешно репликирани в базата данни на абонатите, те могат да бъдат изтрити от базата данни за разпространение. Ако увеличите тази стойност, размерът на базата данни за разпространение ще се увеличи. Следователно трябва да го планираме съответно.
Запазване на историята определя периода на задържане за съхраняване на данните за историята на ефективността на транзакционната репликация. По подразбиране е 48 часа.
Зада пуснете база данни за разпространение , трябва да Деактивираме публикацията свързан с тази конкретна база данни за разпространение и след това я пуснете, като използвате един от двата метода. Единият е комбинация от Деактивиране на публикуването и съветника за разпространение. Друг използва sp_dropdistributor или sp_dropdistributiondb процедури. Съветникът вътрешно използва тези 2 процедури за деактивиране на разпространението и премахване на базата данни за разпространение.
Агенти за репликация на SQL сървър
Агенти за репликация са самостоятелни програми, отговорни за проследяване на промените в данните от издателя и разпространението на тези промени в базите данни на дистрибутори и абонати. Те се изпълняват като задачи на SQL Server Agent.
Първо, нека видим местоположението на тези самостоятелни програми.
За да конфигурираме репликацията, трябва да имаме компонентите за репликация инсталиран чрез инсталатора на SQL Server. Когато приключим, можем да видим свързаните с агента за репликация самостоятелни програми, налични в инсталационния път:
C:\Program Files\Microsoft SQL Server\130\COM
В моя случай версията на SQL Server е 2016. Следователно, тя е под 130 в пътя.
За всеки агент за репликация можем да видим наличната съответната самостоятелна програма:
- DISTRIB.exe – Агент за разпространение
- Logread.exe – Агент за четене на журнали
- Qrdrsvc.exe – Обслужващ агент за четене на опашки
- Replmerg.exe – Обединяващ агент за репликация
- Snapshot.exe – Snapshot Agent
- Tablediff.exe – Помощна програма за сравняване на таблици. Можем да разгледаме повече подробности по-късно в тази статия.
Сега, когато знаем за какво отговарят тези самостоятелни програми и къде се намират, можем да разберем как се изпълняват чрез задания на агент на SQL Server.
Тъй като се занимаваме с транзакционна репликация на SQL Server, ще преминем през заданията на агента за моментни снимки, агента за четене на журнали и агента за разпространение (същата логика важи за всички други агенти).
Агент за моментни снимки
Snapshot Agent работи от сървъра, който държи базата данни за разпространение. Той подготвя схемата и първоначалните данни на всички статии, включени в публикация на издател, създава файловете за моментни снимки в папката за моментни снимки и записва подробностите за синхронизиране в базата данни за разпространение.
От дистрибуцията MSSnapshot_agents таблица, можем да идентифицираме заданието на агент на SQL Server, което извършва дейностите на агента за моментни снимки. Всяка публикация включва специална задача на SQL Server Agent, която трябва да се грижи за отговорностите на агента за моментна снимка.
Разгънете SQL Server Agent и отворете името на заданието, споменато по-горе. Той ще покаже подробностите и Категорията име – REPL-Snapshot
Кликнете върху Стъпката за да видите дейности, извършвани от агента за моментна снимка.
Щракнете върху някоя отделна стъпка, за да видите информацията за задачата на агента за моментна снимка.
Стъпка 1 регистрира запис в таблицата с историята всеки път, когато агентът за моментна снимка стартира, като използва sp_MSadd_snapshot_history процедура.
Таблицата, която съдържа историята на детайлите, изпълнявани от агента за моментна снимка, е MSsnapshot_history таблица в базата данни за разпространение.
Той ще съответства на Преглед на състоянието на агента за моментна снимка диалогов прозорец.
Преминете към Стъпка 2 – Изпълнете агент . Това ще стартира задачата на Snapshot Agent .
Под Командата , не можахме да намерим никакви T-SQL изрази или заявки. Имаше изброени само някои параметри. Така че отговорът се крие в маркирания раздел на горната илюстрация. Показва, че Job Step Type е Моментна снимка на репликация която стартира самостоятелната програма snapshot.exe за изпълнение на отговорностите на агента за моментни снимки.
За повече подробности относно snapshot.exe вижте тази статия в MSDN. Също така ще разгледаме подробности, докато отстраняваме проблемите, свързани с репликацията, по-късно.
Накрая преминаваме към Стъпка 3 – последната стъпка на работа. Той улавя всички неочаквани изключвания на Agent Jobs и ги извежда.
Агент за четене на журнали
Всеки път, когато публикацията е конфигурирана в база данни, всички промени, които се случват с тези статии, се маркират за репликация в дневника на транзакциите. Агентът за четене на журнали чете тези промени в данните чрез logread.exe и ги съхранява в базата данни за разпространение чрез 2 отделни процеса:
- Прочетете регистрационните файлове на транзакциите – използва sp_replcmds разширена съхранена процедура за сканиране за промени в данните от издателя. Тъй като тази съхранена процедура препраща към DLL файлове, вътрешните елементи за това как точно Microsoft чете регистрационните файлове не са идентифицирани. Въпреки това можем да опитаме недокументирани функции като fn_dblog() и fn_dump_dblog() за да разберете как работи регистрационният файл на транзакциите.
- Запис в базата данни за разпространение – използва sp_MSadd_replcmds съхранена процедура в базата данни за разпространение, за да запише двоичните данни, прочетени от регистрационните файлове на транзакциите на базата данни на издателя. Той записва подробностите за транзакцията в MSrepl_transactions таблица и отделни команди към MSrepl_commands маса.
За всяка публикувана база данни е достъпно само едно задание за SQL Server агент на Log Reader. Можете да идентифицирате името му, както е показано по-долу:
Разгънете SQL Server Agent и отворете горното задание на агент за четене на журнали, за да видите стъпките. Той ще покаже заданието Категория под Четец на регистрационни файлове за репликация.
Кликнете върху Стъпки за да видите отделни стъпки, извършени от агента за четене на журнали. Както при заданието на агента за моментни снимки, можем да видим 3 еквивалентни стъпки за заданието агент за четене на журнали.
Стъпка 1 извиква sp_MSadd_logreader_history процедура за регистриране на съобщенията от историята на състоянието на стартиране на агента за четене на журнали в MSloreader_history таблица.
Стъпка 2 стартира процеса на Log Reader Agent с помощта на самостоятелната програма logread.exe .
Можете да намерите повече подробности за logread.exe в съответната статия в MSDN. По-късно ще разгледаме и критичните конфигурационни параметри на агента за четене на журнали.
Стъпка 3 улавя внезапно изключване на заданието на агент за четене на журнали.
Агент по разпространение
Агентът за разпространение (DISTRIB.exe) беше използван от Transactional and Snapshot Replication за прилагане на първоначалните Snapshot файлове и инкрементални или прилагане на наличните чакащи транзакции от базата данни за разпространение към базата данни за абонати.
Този агент работи от дистрибуторския сървър за Push абонаменти и абонатния сървър за Pull абонаментите. За да намерим името на задачата на агент на SQL Server, която изпълнява отговорностите на агента за разпространение, можем да изпълним конкретната заявка, както е показано по-долу:
Разгънете заданието SQL Server Agent и го отворете, за да видите повече информация и категорията, присвоена на разпространението на репликация.
Кликнете върху Стъпки – ще видите стъпките, подобни на изложените по-рано стъпки на задачите на Snapshot и Log Reader Agent.
Стъпка 1 извиква sp_MSadd_distribution_history процедура за регистриране на съобщенията от историята на състоянието при стартиране на агента за четене на журнали в MSdistribution_history таблица.
Стъпка 2 стартира процеса на агент за разпространение (DISTRIB.exe) с параметрите по подразбиране.
За повече подробности относно DISTRIB.exe, обърнете се към статията на MSDN. Освен това ще разгледаме критичните конфигурационни параметри на агента за разпространение в следващите статии.
Стъпка 3 улавя подробности за внезапното спиране на заданието на агента за разпространение.
Профили на агента за репликация
От Свойства на дистрибутора , можем да получим опцията за преглед на Профилите на агента за репликация . Оставете профилите на агента на стойностите по подразбиране и ги променяйте само при необходимост за целите на отстраняване на неизправности.
Кликнете върху По подразбиране на профила за да видите стойностите по подразбиране, конфигурирани за всички агенти за репликация, налични на сървъра.
Изберете Агенти за разпространение раздел и щракнете върху елипса бутон до профила на агент по подразбиране за да видите конфигурираните стойности. Вижте илюстрацията по-долу:
Вижте профила на агент по подразбиране на Агентите за моментни снимки читател Агент:
Профил на агент по подразбиране за Четец на дневници Агент:
Задачи за поддръжка на репликация
Освен агенти за репликация, имаме Работни места за поддръжка на репликация .
Това са задания на агент на SQL Server, създадени при конфигуриране на транзакционната репликация на SQL Server. Те са на разположение, за да гарантират, че репликацията на транзакциите работи правилно.
Някои работни места по поддръжка на репликация са от съществено значение за репликацията на транзакции. Нека ги прегледаме.
- Почистване на разпространението: Разпространение – изпълнява sp_MSdistribution_cleanup процедура за изтриване на команди за репликация от MSrepl_transactions и MSrepl_commands маси. Почистването се извършва в базата данни за разпространение след успешно изпращане на команди към базата данни на абонатите въз основа на стойността на периода на задържане на транзакциите, конфигурирана в базата данни за разпространение. По подразбиране това задание се изпълнява на всеки 10 минути в базата данни за разпространение. Променете тези стойности само след задълбочена оценка.
- Агент Изчистване на историята:разпространение – изпълнява sp_MShistory_cleanup процедура в базата данни за разпространение за почистване на исторически записи, по-стари от периода на запазване на историята, конфигуриран в тази база данни. По подразбиране е конфигуриран за 48 дни и се изпълнява на всеки 10 минути. Ако искате да промените тези стойности, обмислете внимателно всички аспекти.
- Изтекла Почистване на абонамента – изпълнява sp_expired_subscription_cleanup процедура в главната база данни, за да премахнете тези абонаменти, които са изтекли или са били неактивни за дълго време. По подразбиране тази процедура се изпълнява веднъж на ден.
Закъснение на репликация и маркери за проследяване
Забавяне на репликация е времето, необходимо от процеса на репликация за проследяване на всякакви промени, случващи се в публикувани статии от базата данни на издателя, докато бъде доставена успешно на абоната чрез дистрибутор.
Закъснението на репликация се измерва в милисекунди. Целевата стойност от 0 (репликация в реално време) до много ниска стойност (идеални случаи). Това е една от ключовите мерки за наблюдение на производителността на репликацията.
Можем да проверим забавянето на репликацията с помощта на монитора на репликацията или специалните sp_replcounters процедура.
Тъй като Мониторът за репликация има опресняване скорост, може да има леки отклонения от наблюдаваните стойности. За да преодолеем леките отклонения при изчисляване на латентността на репликацията, Tracer Tokens ни идват на помощ.
Кликнете върху Tracer Tokens раздел (вижте изображението по-горе), за да изпратите нов набор от тестови команди от издателя. След това го измерете, когато достигне базата данни на дистрибутора и кога е изпратен до базата данни на абонатите. Кликнете върху Insert Tracer за изпращане на маркери за проследяване от базата данни на издателя:
След като записите бъдат успешно получени в Subscriber, можем да проследим общото забавяне на репликацията за текущата ни настройка. В нашия случай това е 9 секунди:4 секунди от издател до дистрибутор и 5 секунди от дистрибутор до абонат.
Помощна програма Tablediff
Помощна програма Tablediff(tablediff.exe) ще бъде инсталиран в пътя C:\Program Files\Microsoft SQL Server\130\COM след като инсталираме компонентите за репликация.
Помощната програма TableDiff сравнява 2 таблици за несближаване. Това означава, че можем да сравним 2 таблици и да идентифицираме разликите между тях. След това синхронизира таблицата на местоназначението в сравнение с таблицата източник, като генерира специални скриптове INSERT/UPDATE/DELETE. Повече подробности можете да намерите в официалната документация.
Тъй като транзакционната репликация на SQL Server не се интересува от ръчни промени в базата данни на абонатите, тази помощна програма може да помогне за синхронизирането на тези видове таблици, когато и когато е необходимо. Той обаче няма съветник или потребителски интерфейс – можете да получите достъп до него само чрез командния ред или от пакетни файлове.
Други инструменти могат да направят сравнението и синхронизацията по-лесни. dbForge Compare Bundle за SQL Server проверява за несъответствията в базите данни и конкретни таблици ги идентифицира и анализира. Той също така генерира необходимите скриптове, за да ги синхронизира. Той предлага визуален интерфейс и куп опции за бързо и лесно изпълнение на задачите.
Сигнали за агент на SQL сървър
Всички ключови компоненти, свързани с агентите за репликация, се намират като работни места под заданията на агент на SQL Server. Следователно е от решаващо значение да се следи как задачите на SQL Server Agent функционират непрекъснато, за да се гарантира, че репликацията работи без проблеми. Най-често срещаните проблеми са по-долу:
- Проблем с разрешенията при изпълнение на която и да е от заданията на агента за репликация
- Проблем с разрешенията при изпълнение на която и да е от заданията за поддръжка на репликация.
- Проблем с разрешенията за достъп до базата данни на издатели, разпространение или абонати.
- Агентът на SQL Server не е конфигуриран да стартира автоматично при рестартиране на сървъра.
- Няколко други проблеми с данните, свързани с репликацията, като конфликти, липсващи данни и т.н.
Ето защо трябва да имаме подходящ механизъм за предупреждение, за да уведомим незабавно DBA или друго лице за всеки проблем.
За да предупредим администраторите на база данни или други хора в случай на неуспехи или грешки в работата, трябва да конфигурираме Database Mail да изпраща имейл сигнали. Това позволява на DBA да отговори наведнъж и да отстрани проблема. Ще обсъдим как да конфигурираме пощата и сигналите на базата данни в отделна статия по-късно.
Докато конфигурирате репликация, SQL Server по подразбиране създава по-долу набор от сигнали. Можете лесно да ги конфигурирате за необходимите критерии. Той също така гарантира изпращането на известия до необходимите хора за незабавни действия.
Заключение
Благодаря, че прегледахте друга огромна статия за репликацията. Надявам се, че помогна да се изяснят вътрешните елементи на транзакционната репликация и подробностите за базата данни за разпространение, агентите за репликация и самостоятелните програми, отговорни за тях. Също така идентифицирахме закъснението на репликация, сигналите и маркерите за проследяване.
Сега можем да се гмурнем по-дълбоко и да се научим как да третираме и разрешаваме професионално проблеми с репликацията. Очаквайте следващата статия!
