SQL Server Репликация: Пълно ръководство за администратори на бази данни [2026]

SQL Server Репликацията е набор от технологии за копиране и разпространение на данни и обекти от бази данни от една база данни в друга, след което синхронизиране между базите данни за поддържане на съгласуваност. Тази функция ви позволява да създавате и поддържате множество копия на вашите данни на различни сървъри и местоположения, като по този начин гарантирате наличността и надеждността на данните.

1.2 Цел и ползи от репликацията

SQL Server Репликацията обслужва множество критични бизнес нужди и предоставя значителни предимства за управление на бази данни и разпространение на данни:

Разпределение на данните по местоположения: Репликацията ви позволява да споделяте данни между регионални офиси или глобални локации, подобрявайки оперативната ефективност чрез осигуряване на локален достъп до необходимите данни. Това намалява мрежовата латентност и осигурява по-добра производителност за географски разпределени потребители.
Висока наличност и възстановяване след бедствия: Чрез поддържане на реплики на критични данни на множество сървъри, репликацията осигурява резервиране, което предпазва от хардуерни повреди и бедствия. В случай на повреда на основния сървър, репликираните копия могат да служат като резервни източници, минимизирайки времето за престой и загубата на данни.
Балансиране на натоварването и мащабируемост: Репликацията разпределя операциите по четене между множество сървъри, предотвратявайки превръщането на отделен сървър в пречка. Този подход подобрява производителността на системата и позволява на вашата инфраструктура да се мащабира хоризонтално с нарастването на данните и потребителските изисквания.
Отчитане и анализ в реално време: Прехвърлянето на заявки за отчитане и анализ към репликирани сървъри намалява натоварването на производствените бази данни. Потребителите могат да изпълняват сложни аналитични заявки към данни в почти реално време, без да влияят на операционните системи, което гарантира както производителност, така и актуалност на данните.
Интеграция и консолидация на данни: Репликацията улеснява обединяването на данни от различни източници в един консолидиран изглед. Това е особено ценно за организации с множество клонове, които трябва да обединяват данни в централата си, или за създаване на централизирани хранилища за данни от разпределени операционни системи.

2. SQL Server Архитектура и компоненти на репликацията

SQL Server Архитектурата на репликация се състои от няколко взаимосвързани компонента, които работят заедно, за да разпространяват и синхронизират данни в инфраструктурата на вашата база данни. Този раздел разглежда основните компоненти, включително издатели, дистрибутори, абонати, публикации, статии, абонаменти и агенти, които координират потока от данни между тях:

Издател: Издателят е SQL Server екземпляр, който хоства една или повече бази данни, съдържащи данни за репликация. Той служи като авторитетен източник в топологията на репликация.
Дистрибутор: Дистрибуторът е SQL Server екземпляр, който управлява потока от данни между издатели и абонати. Дистрибуторският екземпляр хоства базата данни за разпространение, която съхранява метаданни за репликация и транзакции.
абонат: Абонатът е SQL Server екземпляр, който получава и съхранява репликирани данни от издатели. Един екземпляр на абонат може да хоства множество бази данни за абонати, всяка от които получава данни от различни публикации.
Публикуван: Публикацията определя какви данни ще бъдат репликирани и как ще бъдат разпространявани до абонатите. Тя групира свързани статии и установява методологията за репликация, която се прилага за всички съдържащи се обекти.
Статия: Статията е основният градивен елемент на репликацията, представляващ отделен обект на база данни, който ще бъде разпространяван до абонати.
Абонамент: Абонаментът установява връзката между публикация и абонат, като определя как и кога данните се доставят до целевата база данни.
агенти: Агентите са специализирани процеси, които извършват действителната работа по преместване и синхронизиране на данни между компонентите за репликация.

3. Видове SQL Server копиране

SQL Server предоставя няколко типа репликация, всеки от които е проектиран за специфични сценарии за разпространение на данни и бизнес изисквания. Разбирането на характеристиките, предимствата и ограниченията на всеки тип е от съществено значение за избора на правилния подход за вашата среда.

3.1 Репликация на моментни снимки

Репликацията на моментни снимки (snapshot replication) прави моментна снимка на данните, които ще бъдат публикувани в определен момент, след което разпространява точното пълно копие на абонатите. Тя не следи за последващи промени, докато не се генерира следващата моментна снимка. Репликацията на моментни снимки е най-простата форма на репликация, което я прави подходяща за сценарии, където данните се променят рядко или където наличието на леко остарели данни е приемливо.

Често срещани случаи на употреба включват разпространение на справочни данни, като ценови листи или валутни курсове, които се актуализират периодично, предоставяне на първоначални набори от данни за хранилища за данни и сценарии, при които пълното обновяване на данните е за предпочитане пред проследяването на отделни промени. Например, една компания може да използва репликация на моментни снимки, за да разпространява актуализирани продуктови каталози до клоновете веднъж дневно.

Основните предимства на репликацията на моментни снимки са нейната простота, ниските изисквания за поддръжка и възможността за репликиране на данни без първични ключове. Тя обаче има значителни недостатъци, включително голямо въздействие при генериране на моментни снимки поради заключване на таблици, висока латентност между актуализациите и неефективност при големи набори от данни или често променящи се данни. Всички модификации, направени на ниво абонати, се губят при прилагането на следващата моментна снимка.

3.2 Транзакционна репликация

Транзакционната репликация доставя промените от издателя до абонатите почти в реално време, като репликира отделните транзакции, когато се случват. Започва с първоначална снимка, за да се установи базовата линия, след което непрекъснато следи дневника на транзакциите за промени в публикуваните статии и ги доставя на абонатите постепенно.

Транзакционната репликация е идеална за сценарии от сървър към сървър, изискващи висока пропускателна способност и ниска латентност. Често срещани случаи на употреба включват подобряване на мащабируемостта и наличността чрез прехвърляне на операциите по четене към абонатни сървъри, поддръжка на складиране на данни и отчитане с данни почти в реално време, интегриране на данни от множество сайтове в централно място и прехвърляне на пакетна обработка към специализирани сървъри. Например, платформа за електронна търговия може да използва транзакционна репликация, за да поддържа синхронизирани данни за инвентара в регионални бази данни.

Предимствата на транзакционната репликация включват ниска латентност при доставка на данни, висока пропускателна способност за големи обеми транзакции и възможност за извършване на нерепликирани модификации при абонатите. Недостатъците включват по-голяма сложност в сравнение с репликацията на моментни снимки, изискването за първични ключове на репликираните таблици и потенциал за прекъсване на репликацията, ако възникнат конфликти, като например нарушения на първичния ключ при абонатите.

3.3 Репликация чрез сливане

Репликацията чрез сливане е специално разработена за среди, където абонатите трябва да работят офлайн или с прекъсваща връзка, след което да синхронизират промените, когато е налична връзка. Този тип репликация позволява данните да се променят независимо както при издателя, така и при абонатите, като се проследяват промените с помощта на тригери и таблици с метаданни и автоматично се сливат модификациите по време на синхронизация.

Репликацията чрез сливане е предназначена за мобилни приложения и разпределени сървърни среди, където се случват автономни промени. Случаите на употреба включват автоматизация на търговския екип, където мобилните потребители работят офлайн и синхронизират по-късно, системи за точки на продажба, които работят независимо и консолидират данни периодично, и разпределени приложения, където множество обекти трябва да актуализират споделени данни. Например, търговска верига може да използва репликация чрез сливане, така че всеки магазин да може да управлява локалните запаси, докато се синхронизира с централната складова система.

Предимствата на репликацията чрез сливане включват поддръжка за автономни абонати, които могат да правят промени, толерантност към прекъсваща мрежова свързаност и гъвкаво разрешаване на конфликти. Недостатъците включват по-голяма сложност при настройката и поддръжката, разходи за производителност от проследяване на метаданни и тригери, добавяне на колони с уникален идентификатор към таблици и потенциал за конфликти, които изискват управление и разрешаване.

3.4 Репликация от тип „peer-to-peer“

Репликацията от типа „peer-to-peer“ е изградена върху транзакционна репликация и позволява на множество сървърни екземпляри (три или повече възела) да действат като равностойни пиърове, като всеки възел служи едновременно като издател и абонат. В тази топология всички възли поддържат идентични копия на данни и могат да обработват както операции за четене, така и за запис, осигурявайки наистина разпределена среда с множество мастери.

Репликацията от типа „peer-to-peer“ е подходяща за приложения, изискващи мащабиране на операции за четене и висока достъпност. Случаите на употреба включват уеб приложения, които разпределят заявки към каталог между множество възли, като същевременно поддържат последователни данни, сценарии, изискващи поддръжка или надстройки без прекъсване чрез отделяне на възлите от мрежата поотделно, и глобални приложения с центрове за данни в различни региони. Например, световна организация за софтуерна поддръжка може да използва репликация от типа „peer-to-peer“ между офиси в различни часови зони, така че всяко местоположение да има локален достъп до актуални данни.

Предимствата на peer-to-peer репликацията включват подобрена производителност при четене чрез мащабиране, по-висока достъпност с множество активни възли и почти реално време на съгласуваност на данните. Недостатъците включват изискването за Enterprise Edition, сложността при управлението на многовъзлови топологии, необходимостта от идентична схема и данни във всички възли и потенциал за конфликти, когато операциите за запис не са правилно разделени.

3.5 Двупосочна репликация

Двупосочната репликация е специфична топология на транзакционна репликация, проектирана специално за среди с два сървъра, където и двата сървъра трябва да обменят промени помежду си. Всеки сървър публикува данни и се абонира за същите данни от другия сървър, създавайки опростен двупосочен поток на синхронизация. Докато peer-to-peer репликацията може да поддържа и два възела, двупосочната репликация осигурява подобрена производителност за този специфичен сценарий.

Двупосочната репликация е подходяща за сценарии, изискващи два активни сървъра със синхронизирани данни, като например конфигурации „активен-активен“ за висока достъпност или географски разпределени приложения, където всеки сайт се нуждае от локален достъп за запис. Топологията изисква внимателно проектиране на приложенията за разделяне на актуализациите на данните и предотвратяване на конфликти.

Предимствата включват оптимизирана производителност за сценарии с два сървъра, по-проста конфигурация в сравнение с peer-to-peer репликацията, синхронизация почти в реално време и по-ниски режийни разходи от репликацията чрез сливане. Недостатъците включват ограничението до точно два сървъра, липсата на вградено разрешаване на конфликти, изискващо внимателно проектиране на приложенията, и необходимостта от подходящи стратегии за разделяне, за да се предотвратят конфликти.

3.6 Абонаменти с възможност за актуализиране

Актуализираните абонаменти разширяват транзакционната репликация, за да позволят на абонатите да правят случайни промени в репликираните данни, които след това се разпространяват обратно към издателя и към други абонати. За разлика от репликацията чрез сливане или peer-to-peer топологиите, проектирани за чести двупосочни актуализации, актуализираните абонаменти са предназначени за сценарии, при които основният поток от данни е еднопосочен (издател към абонати), но абонатите понякога трябва да правят корекции или актуализации.

Актуализиращите се абонаменти са подходящи за сценарии, при които повечето актуализации се извършват при издателя, но са необходими случайни актуализации при абонатите, като например полеви офиси, които основно четат данни, но трябва да правят локални корекции или актуализации. Топологията изисква внимателно планиране, за да се сведат до минимум конфликтите и да се осигури съгласуваност на данните.

Основните предимства включват разрешаването на ограничени операции за запис при абонатите, като същевременно се запазват характеристиките на производителност на транзакционната репликация. Недостатъците включват повишена сложност, потенциал за конфликти, изискващи разрешаване, режийни разходи за производителност от двуфазния протокол за commit в режим на незабавно актуализиране и изискването всички репликирани таблици да имат първични ключове.

3.7 Сравнение на различни видове репликации

Тип репликация	Време за актуализиране	Брой издатели	Посока	Използвайте сценарии
Моментална снимка	Точка във времето	1	One direction (Издател → Абонати)	Рядко променящи се справочни данни (ценови листи, валутни курсове)
Транзакционното	Почти в реално време	1	One direction (Издател → Абонати)	Сценарии с висока производителност (инвентаризация в електронна търговия, складиране на данни, отчитане)
Обединяване	Периодично (при свързване)	1	Двупосочно (Издател ↔ Абонати)	Мобилни приложения, офлайн служители (автоматизация на търговския екип, полеви услуги)
Пеер към партньорската	Почти в реално време	Множество (3 или повече)	Двупосочно (всички възли)	Глобални внедрявания в множество центрове за данни (офиси по целия свят с локален достъп за четене и запис)
Двупосочен	Почти в реално време	2	Двупосочно (и двата сървъра)	Конфигурации с два центъра за данни „активен-активен“ (висока достъпност на два сайта)
Актуализирани абонаменти	Почти в реално време	1	Предимно в едната посока (от време на време се случват и обратни актуализации)	Клонове, които основно четат, но понякога актуализират (локални корекции)

4. Настройка SQL Server копиране

4.1 Предварителни изисквания

4.1.1 Софтуерни изисквания

SQL Server репликацията изисква съвместимост SQL Server версии във всички участници в топологията. Версията на дистрибутора трябва да е равна или по-висока от версията на издателя, а абонатът може да бъде в рамките на две версии на издателя. Например, SQL Server Издателят от 2016 г. може да репликира към SQL Server Абонати от 2012, 2014, 2016, 2017 или 2019 г.

4.1.2 Изисквания за разрешение

Конфигурирането на репликация изисква специфични разрешения на всяко ниво. Членовете на фиксираната сървърна роля sysadmin могат да изпълняват всички задачи за конфигуриране на репликация. За по-подробни разрешения потребителите трябва да са членове на ролята на базата данни db_owner за бази данни на издатели и абонати.

4.2 Стъпка 1: Конфигуриране на разпространението

Конфигурирането на дистрибуцията е първата стъпка в настройката SQL Server репликация.

За да конфигурирате разпределението, използвайки SQL Server Студио за управление:

Свържете се с SQL Server пример в SQL Server Студио за управление.
В Object Explorer щракнете с десния бутон върху копиране папка и изберете Конфигуриране на разпространението.
В съветника за конфигуриране на разпространение щракнете върху Следваща на началната страница.
От Дистрибутор страницата, изберете една от следните опции въз основа на вашите изисквания за топология:
- Местен дистрибуторИзберете „ServerName ще действа като свой собствен дистрибутор;“ SQL Server ще създаде база данни за разпространение и лог“, ако искате издателят и дистрибуторът да работят на един и същ екземпляр (текущия екземпляр). Тази конфигурация е по-лесна за настройване и е подходяща за по-малки среди или когато мрежовата латентност между издателя и дистрибутора би причинила проблеми.
- Дистанционно управление на дистрибутораИзберете „Използване на следния сървър като дистрибутор“ и щракнете върху ДОБАВЯНЕ, да укажете отдалечен дистрибуторски сървър, ако искате да прехвърлите обработката на дистрибуцията към отделен екземпляр. Тази конфигурация подобрява производителността, когато обемите на репликация са големи, като разпределя работното натоварване между множество сървъри. Ще трябва да предоставите името на отдалечения дистрибутор и да укажете парола, която издателят ще използва за свързване с дистрибутора.
Кликнете Следваща за да укажете местоположението на папката за моментни снимки. Използвайте UNC път (като например \\име_на_сървъра\споделяне\папка), а не локален път, за да осигурите достъпност в цялата мрежа.
От База данни за разпространение страница, приемете името на базата данни за разпространение по подразбиране (обикновено „разпределение“) или задайте персонализирано име, след което конфигурирайте местоположенията на данните и лог файловете.
От Publishers страницата, проверете дали текущият сървър е активиран като издател. Ако конфигурирате текущия сървър като дистрибутор, можете да добавите допълнителни издатели, които ще използват този дистрибутор.
Прегледайте действията на съветника и щракнете завършеност за конфигуриране на разпределението.

4.3 Стъпка 2: Създаване на публикация

След конфигуриране на разпространението, следващата стъпка е да се създаде публикация, която определя кои обекти с данни ще бъдат репликирани на абонатите.

За да създадете публикация, използвайки SQL Server Студио за управление:

В Object Explorer разгънете копиране папка.
Щракнете с десния бутон Местни публикации и изберете Нова публикация.
Стартира се Съветникът за нови публикации; щракнете Следваща на началната страница.
Изберете базата данни, която искате да публикувате от База данни за публикации страница. Това автоматично активира публикуването в избраната база данни.
От Тип публикация страницата, изберете типа репликация: Публикация на моментна снимка, Транзакционна публикация, Публикация от типа „peer-to-peer“ или Обединяване на публикацията.
От Статии страницата, разгънете Маси възел и изберете таблици, които да включите като статии.
По желание разгънете съхранени процедури, Прегледиили други типове обекти, за да включите допълнителни статии.
Кликнете Свойства на статията за конфигуриране на филтриране или други настройки, специфични за статията.
От Филтриране на редове от таблицата страница, добавете филтри за редове, ако е необходимо.
От Агент за моментни снимки страница, изберете кога да се създаде моментната снимка: веднага, в определен час или по график.
От Сигурност на агентите страница, укажете контекста на сигурност за агента за моментни снимки.
От Действия на съветника страница, изберете Създаване на публикацията.
Въведете име на публикацията и щракнете завършеност.

4.4 Стъпка 3: Създаване на абонамент

След създаването на публикация, следващата стъпка е да се създадат абонаменти, които свързват публикацията с бази данни на абонати.

Абонаментите могат да бъдат push абонаменти (управлявани от дистрибутора) или pull абонаменти (управлявани от абоната). Ключовите разлики са къде създавате абонамента и кое местоположение на агент избирате, което определя действието на абонамента (push или pull).

За push абонамент (управлява се от Дистрибутора):

От издател сървър, разгънете копиране -> Местни публикации.
Щракнете с десния бутон върху публикацията и изберете Нови абонаменти.

За абонамент за изтегляне (управлява се от Абоната):

От абонат сървър, разгънете копиране, Кликнете с десния бутон Локални абонаменти, и изберете Нови абонаменти.
От Публикация страница, кликнете Какво SQL Server Издател и се свържете със сървъра на издателя.

Общи стъпки на помощника за двата типа абонамент:

В съветника за нов абонамент щракнете върху Следваща на началната страница.
Изберете публикацията и щракнете Следваща.
От Местоположение на дистрибуторския агент страница, изберете местоположението на агента:
- Пус абонаментИзберете „Изпълни всички агенти при дистрибутора“ – дистрибуторът ще изпрати промените към абонатите.
- Изтегляне на абонаментИзберете „Изпълнявай всеки агент при неговия абонат“ – всеки абонат ще изтегля промените от дистрибутора.
От Абонати страница, изберете съществуващи абонатни сървъри или щракнете Добави Subscriber да добавя нови.
За всеки абонат изберете целевата база данни или създайте нова база данни. Забележка: Базата данни за абонаменти трябва да е различна от базата данни за издатели, дори ако се използва същата SQL Server инстанция.
От Сигурност на дистрибуторския агент страницата, щракнете върху бутона със свойства за всеки абонамент, за да конфигурирате контекста на защита.
От График за синхронизация страницата, изберете непрекъсната синхронизация или планирана синхронизация.
От Инициализиране на абонаменти страница, изберете веднага за инициализиране по време на завършване на съветника или При първа синхронизация.
Прегледайте действията на съветника и щракнете завършеност.

5. Мониторинг и управление SQL Server копиране

5.1 Мониторинг на репликацията с Replication Monitor

За да стартирате Replication Monitor:

In SQL Server Студио за управление, разгъване копиране в Object Explorer.
Щракнете с десния бутон копиране и изберете Стартиране на монитор за репликация.
Ако няма регистрирани издатели, щракнете Добавяне на издател в левия панел.
Изберете върху ДОБАВЯНЕ, SQL Server Издател и се свържете със сървъра на издателя.
Издателят се показва в левия панел с разгъващи се възли за публикации и абонаменти.

5.2 Мониторинг на производителността

5.2.1 Закъснение на монитора

Латентността на репликацията е времето за забавяне между промяна, настъпваща при издателя, и прилагането ѝ при абоната. Следете латентността, за да гарантирате, че актуалността на данните отговаря на бизнес изискванията.

Използвайте „Монитор на репликация“, за да видите показателите за латентност в раздела „Всички абонаменти“. Колоната „Латентност“ показва средната латентност в секунди. За транзакционна репликация, маркерите за проследяване предоставят точни измервания на латентността, като вмъкват маркерни транзакции, които се проследяват през канала за репликация.

За да използвате трасиращи маркери:

В „Монитор на репликация“ изберете публикация за транзакции.
Кликнете върху менюто Трасиращи жетони таб.
Кликнете Вмъкване на трасер за инжектиране на маркерна транзакция.
Следете токена, докато пътува от издател до дистрибутор и абонат.
Вижте времето, необходимо за всеки сегмент, за да идентифицирате пречките.

5.2.2 Монитор на пропускателната способност

Пропускателната способност измерва обема на репликираните данни във времето, обикновено изразен като транзакции в секунда или команди в секунда. Следете пропускателната способност, за да гарантирате, че репликацията може да е в крак с активността на издателя.

Въпреки че Replication Monitor предоставя основно състояние на синхронизацията, скоростта на доставка и подробните показатели за пропускателна способност не са видими в графичния потребителски интерфейс. Използвайте T-SQL заявки към базата данни за разпространение, за да наблюдавате пропускателната способност:

USE distribution
GO

-- Direct join to avoid subquery
SELECT TOP 20
    h.time AS [Time],
    a.name AS [Agent Name],
    h.runstatus AS [Status],
    h.delivered_transactions AS [Delivered Transactions],
    h.delivered_commands AS [Delivered Commands],
    h.delivery_rate AS [Delivery Rate (commands/sec)],
    h.delivery_latency AS [Delivery Latency (ms)],
    h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO

Кодове за състояние: 1 = Старт, 2 = В процес на изпълнение, 3 = Успех, 4 = Неактивен, 5 = Повторен опит, 6 = Неуспех. Сравнете скоростта на доставка с честотата на транзакциите на издателя, за да идентифицирате ситуации, в които репликацията изостава. Броячи на производителността в Монитор на производителността на Windows предоставят допълнителни показатели за пропускателна способност за всеки агент за репликация.

5.2.3 Идентифициране на пречките

Затруднения в репликацията могат да възникнат в множество точки от топологията. При издателя, прекомерното време за генериране на моментни снимки или закъсненията на агента за четене на регистрационни файлове може да показват ограничения на ресурсите. Следете процесора, паметта и дисковия входно/изход на издателя по време на дейностите по репликация.

При дистрибутора проверете за натрупващи се транзакции в базата данни за дистрибуция. Големият брой неразпределени команди показва, че дистрибуторът не може да се справи с доставката. Следете ресурсите на сървъра на дистрибутора и помислете за използване на специален отдалечен дистрибутор за сценарии с голям обем.

При абоната, бавното прилагане на промените може да е резултат от недостатъчни ресурси, липсващи индекси или ограничения, които забавят операциите по вмъкване. Следете използването на ресурсите на абоната и производителността на заявките, когато работи агентът за разпространение. Ограниченията на мрежовата честотна лента между компонентите също причиняват затруднения, особено при големи обеми данни.

5.3 Управление на агенти за репликация

5.3.1 Стартиране и спиране на агенти

За да стартирате или спрете агент за репликация:

In SQL Server Студио за управление, разгъване SQL Server Агент -> Работа.
Намерете заданието на агента за репликация (имената обикновено включват информацията за публикацията и абоната).
Щракнете с десния бутон върху заданието и изберете Започнете работа or Спиране на задачата.

5.3.2 Конфигуриране на профили на агенти

Профилите на агентите съдържат набори от параметри, които контролират поведението на агентите. SQL Server предоставя профили по подразбиране, оптимизирани за често срещани сценарии, а вие можете да създавате персонализирани профили за специфични нужди.

За да промените профилите на агенти:

В Object Explorer разгънете копиране.
Щракнете с десния бутон копиране и изберете Имоти на дистрибутора.
Кликнете върху менюто Настройки по подразбиране на профила бутон.
Изберете тип агент (Моментна снимка, Четец на регистрационни файлове, Разпространение или Сливане) от падащото меню.
Изберете профил и щракнете Имоти за да видите стойностите на параметрите.
Кликнете Нов профил за да създадете персонализиран профил въз основа на съществуващ такъв.
Променете параметрите, ако е необходимо, и щракнете OK.

Приложете профил към агент, като редактирате свойствата на абонамента и изберете желания профил от падащото меню „Профил на агент“.

5.3.3 Параметри и настройки на агента

Параметрите на агента фино настройват производителността и поведението. Ключовите параметри за агента за разпространение включват CommitBatchSize (брой транзакции, приложени за едно потвърждаване), CommitBatchThreshold (брой команди преди потвърждаване), SubscriptionStreams (паралелни връзки за по-бърза доставка) и QueryTimeout (време на изчакване за команди).

За агента за четене на регистрационни файлове, важните параметри включват ReadBatchSize (брой транзакции, прочетени на сканиране), ReadBatchThreshold (команди преди доставка) и PollingInterval (забавяне между сканиранията на регистрационни файлове). Настройте тези параметри въз основа на изискванията за обем на транзакциите и латентност.

5.4 Съображения за архивиране и възстановяване

Архивирането на бази данни, участващи в репликацията, изисква специални съображения. За базата данни на издателя, редовните пълни резервни копия и резервните копия на регистрационните файлове на транзакциите са от съществено значение. Маркирайте резервното копие на базата данни за поддръжка на репликация, като използвате опцията WITH REPLICATION, когато архивирате бази данни в транзакционна репликация. Архивирайте редовно базата данни за разпространение, за да защитите конфигурацията на репликацията.

Когато възстановявате база данни на издател на същия сървър със същото име, използвайте опцията WITH KEEP_REPLICATION, за да запазите състоянието на репликация. Тази опция гарантира, че транзакциите, които все още не са обработени от агента за четене на регистрационни файлове, остават маркирани за репликация, което позволява репликацията да продължи автоматично без повторна инициализация на абонаменти.

В сценарии за възстановяване след бедствие, където резервните копия не са налични, повредени са или файловете на базата данни са повредени, може да са необходими специализирани инструменти за възстановяване. DataNumen SQL Recovery може да извлича данни от повредени или недостъпни MDF и NDF файлове, предоставяйки последна мярка, когато стандартните процедури за възстановяване се провалят.

За повече подробности относно SQL Server резервно копие, вижте нашите изчерпателно ръководство.

6. Често задавани въпроси (FAQ)

В: Каква е разликата между моментна снимка и транзакционна репликация?

A: Репликацията на моментни снимки (snapshot replication) прави пълно копие на данните в определен момент и го прилага към абоната, което е подходящо за рядко променящи се данни. Транзакционната репликация започва с първоначална моментна снимка и след това непрекъснато репликира отделните транзакции, когато се случват, осигурявайки синхронизация почти в реално време за често променящи се данни.

В: Мога ли да репликирам между различни SQL Server версии?

О: Да, SQL Server Репликацията поддържа съвместимост на версиите в ограничен диапазон. Версията на дистрибутора трябва да е равна или по-висока от версията на издателя, а абонатът може да бъде в рамките на две версии на издателя. Например, ако издателят е SQL Server 2016 г., абонатът може да бъде SQL Server 2012, 2014, 2016, 2017 или 2019.

В: Как да се справя с конфликти при репликация чрез сливане?

A: Репликацията чрез сливане предоставя вградени механизми за откриване и разрешаване на конфликти. Можете да конфигурирате разрешаващите инструменти за конфликти на ниво статия, като избирате от вградени разрешаващи инструменти или внедрявате персонализирани разрешаващи инструменти за конфликти. Конфликтите обикновено се разрешават с помощта на методи, базирани на приоритет или времеви отпечатък, с опция за регистриране на конфликти за ръчен преглед.

В: Какво е влиянието на репликацията върху производителността?

A: Репликацията влияе върху производителността по няколко начина: издателят изпитва режийни разходи от проследяване на промените и генериране на моментни снимки, дистрибуторът използва ресурси за съхраняване и препращане на транзакции, а мрежовата честотна лента се изразходва по време на пренос на данни. Въздействието варира в зависимост от типа репликация, като репликацията на моментни снимки причинява периодични силно въздействащи импулси, а репликацията на транзакции поддържа по-последователно, но непрекъснато натоварване.

В: Как да защитя моята топология на репликация?

A: Защитете вашата топология на репликация, като внедрите няколко най-добри практики: използвайте удостоверяване на Windows или силно удостоверяване SQL Server удостоверяване, криптиране на връзки чрез TLS, защита на папката със снимки с подходящи NTFS разрешения, конфигурирайте списъка за достъп до публикации (PAL) за контрол на достъпа, използвайте отделни сервизни акаунти с минимално необходими разрешения за всеки агент за репликация и редовно проверявайте настройките за сигурност на репликацията.

В: Мога ли да репликирам към базата данни на Azure SQL?

A: Да, можете да репликирате към база данни Azure SQL, като използвате транзакционна репликация с локална среда. SQL Server или управляван екземпляр на Azure SQL като издател и дистрибутор. Базата данни Azure SQL може да служи като абонат, но не като издател или дистрибутор. Репликацията чрез сливане и репликацията от тип „peer-to-peer“ не се поддържат от базата данни Azure SQL.

В: Как да наблюдавам забавянето на репликацията?

A: Следете забавянето на репликацията, като използвате Replication Monitor в SQL Server Management Studio, което показва показатели за латентност за всеки абонамент. Можете също така да заявявате таблици в базата данни за разпространение, като MSdistribution_history и MSrepl_commands, да използвате броячи на производителността, специфични за агентите за репликация, или да настройвате предупреждения въз основа на прагове на латентност, за да откривате и адресирате проактивно забавянията при синхронизация.

В: Какво се случва, когато абонатът е офлайн?

A: Когато абонатът е офлайн, поведението зависи от типа репликация. При транзакционна репликация транзакциите се натрупват в базата данни за разпространение, докато абонатът се върне онлайн, след което синхронизацията се възобновява. При репликация чрез сливане промените се проследяват и от двете страни и се сливат, когато връзката се възстанови. Настройката за период на съхранение определя колко дълго се съхраняват данните, преди да трябва да бъдат реинициализирани.

В: Как да добавя нови статии към съществуваща публикация?

A: За да добавите нови статии към съществуваща публикация, използвайте SQL Server Management Studio, за да промените свойствата на публикацията и да изберете допълнителни обекти, или използвайте съхранената процедура sp_addarticle. След добавяне на статии, генерирайте нова снимка и реинициализирайте всички абонаменти, за да сте сигурни, че абонатите ще получат новите статии. Някои промени може да изискват реинициализация на абонамента в зависимост от настройките на публикацията.

В: Как да премахна репликация от база данни?

A: Премахнете репликацията от база данни, като първо изтриете всички абонаменти, използвайки sp_dropsubscription, след това премахнете публикацията с sp_droppublication и накрая деактивирате публикуването в базата данни, използвайки sp_replicationdboption. Ако сървърът е дистрибутор, деактивирайте разпространението, използвайки sp_dropdistributor. Винаги архивирайте базите данни, преди да премахнете конфигурацията за репликация.

Въпрос: Каква е разликата между SQL Server Групи за репликация и достъпност на AlwaysOn?

A: Репликацията е решение за разпространение и интеграция на данни, което работи на обектно ниво, докато Винаги включени групи за наличност е решение за висока достъпност и възстановяване след бедствия, което работи на ниво база данни.

7. заключение

SQL Server Репликацията предоставя стабилна рамка за разпространение и синхронизиране на данни между множество бази данни и местоположения. Технологията поддържа различни сценарии чрез различни типове репликация.

Изборът на правилната стратегия за репликация зависи от вашите специфични изисквания. Вземете предвид честотата на промяна на данните, изискванията за латентност, дали абонатите трябва да правят актуализации, мрежовите характеристики и нуждите на абонатите от автономност. Репликацията на моментни снимки работи най-добре за рядко променящи се референтни данни, където латентността не е критична. Транзакционната репликация е подходяща за сценарии с голям обем, изискващи ниска латентност и предимно еднопосочен поток от данни.

Изберете репликация чрез сливане, когато абонатите се нуждаят от автономна работа с офлайн възможности и двупосочна синхронизация. Приложете репликация от тип „peer-to-peer“ за балансиране на натоварването при операции по четене между множество активни възли с почти реално времева съгласуваност. Помислете за хибридни подходи, комбиниращи множество типове репликация за сложни сценарии с разнообразни изисквания.

Източници

За автора

Юан Шенг е старши администратор на бази данни (DBA) с над 10 години опит в SQL Server среди и управление на корпоративни бази данни. Той е разрешил успешно стотици сценарии за възстановяване на бази данни във финансови услуги, здравеопазване и производствени организации.

Юан е специализиран в SQL Server възстановяване на бази данни, решения за висока достъпност и оптимизация на производителността. Неговият богат практически опит включва управление на многотерабайтови бази данни, внедряване на групи за достъпност Always On и разработване на автоматизирани стратегии за архивиране и възстановяване за критично важни бизнес системи.

Чрез техническата си експертиза и практичен подход, Юан се фокусира върху създаването на изчерпателни ръководства, които помагат на администраторите на бази данни и ИТ специалистите да решават сложни задачи. SQL Server предизвикателствата ефикасно. Той е в крак с най-новото SQL Server издания и развиващите се технологии за бази данни на Microsoft, като редовно тества сценарии за възстановяване, за да гарантира, че препоръките му отразяват най-добрите практики в реалния свят.

Имате въпроси относно SQL Server възстановяване или имате нужда от допълнителни насоки за отстраняване на проблеми с базата данни? Юан приветства обратна връзка и предложения за подобряване на тези технически ресурси.