Конфигурация за репликация на транзакции на SQL Server

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

Администриране на репликация на транзакции

В предишните ми статии преминахме през инструкциите стъпка по стъпка относно следните елементи:

Конфигуриране на разпространение
Конфигуриране на публикация с опция за моментна снимка
Конфигуриране на абонамент с опция за моментна снимка

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

В тази статия се опитваме да премахнем транзакционната репликация в SQL Server, която конфигурирахме преди това. Ще използваме подхода за архивиране и ще добавяме или премахваме статии от репликация по следния начин:

Прекратете абонамента
Изхвърлете публикацията
Изхвърлете дистрибутора или базата данни за разпространение
Почистете напълно репликацията, ако някоя от горните стъпки не работи правилно
Конфигуриране на репликация с архивиране на база данни
Изхвърлете статии от репликация, като използвате подхода на съветника и T-SQL
Добавете нови статии към репликация, като използвате както съветника, така и T-SQL подхода
Добавете статия за съхранена процедура и проучете разликата между статията в таблицата и статията за съхранената процедура

Прекратете абонамента

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

В SSMS се свържете с екземпляра на издател> Репликация > Местни публикации . Щракнете с десния бутон върху абонамента> Изтриване или Изпускане Абонамент:

SQL Server ще ви помоли да потвърдите действието си:

Кликнете върху Да за да откажете абонамента. Това ще прекрати напълно абонамента.

В текущата ми настройка и издателят, и абонатът са на един и същи екземпляр. Следователно не бяха изпратени заявки за свързване към екземпляра на абоната за валидиране. В случай, че го имаме на друг екземпляр на SQL Server, той ще поиска да се свърже с екземпляра на абоната, за да потвърди, преди да изтрие абоната.

Отпадането на публикация вътрешно използва sp_droppublication процедура и можем да използваме тази процедура за ръчно премахване на публикацията чрез T-SQL подход

Изхвърлете публикацията

След като абонаментът бъде изтрит, можем да продължим и да премахнем Публикацията . Щракнете с десния бутон върху AdventureWorks_Pub и изберете Изтриване от менюто:

Ще видите съобщение с молба да потвърдите това действие. Имайте предвид, че ще изтриете публикацията. Въпреки това, всички записи, които са били репликирани в базата данни на абонатите, няма да бъдат изтрити. Ще трябва да пуснем базата данни ръчно, за да почистим тези репликирани записи. Кликнете върху Да .

Изтриването на публикация вътрешно прилага sp_droppublication процедура.

Изхвърлете дистрибутора или базата данни за разпространение

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

Когато трябва да изтрием базата данни за разпространение, първо трябва да щракнем с десния бутон върху Репликация възел> Деактивиране Публикуване и разпространение .

Ще отвори съветника.

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

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

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

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

В новия прозорец отметнете и двете опции:Деактивиране на публикуването и разпространението и Генерирайте скриптов файл със стъпки...

За да генерирате скриптовия файл, ще трябва да предоставите пътя, където да го съхранявате.

Щракнете върху Напред и прегледайте опциите, избрани в съветника. Проверете и се уверете, че сте избрали всичко правилно.

Щракнете върху Край .

Изтриването на базата данни за разпространение използва вътрешно sp_dropdistributor процедура.

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

Почистете напълно репликацията, ако някоя от горните стъпки не работи правилно

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

exec_spremovedbreplication

Изпълнете тази процедура само ако все още има проблеми с репликацията, след като изпробвате всички други споменати подходи. Съхранена процедура sp_removedbreplication трябва да се изпълни в базата данни на издателя или от основната база данни и с помощта на командата по-долу, след като замените @dbname с името на базата данни на издателя.

exec_spremovedbreplication @dbname

Конфигурирайте репликацията с помощта на подхода за архивиране

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

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

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

Конфигуриране на дистрибутор и публикация

Вижте инструкциите стъпка по стъпка от предишната статия за това как да конфигурирате както разпространението, така и публикацията с помощта на съветника за създаване на публикация. За да научите T-SQL скриптовете, използвани от съветника за създаване на разпространение и публикация, просто генерирайте скриптовете във файл по време на последната стъпка на съветника и не изпълнявайте скриптовете, като премахнете отметката от опцията „Създаване на публикация“, както е показано по-долу .

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

Моля, обърнете внимание на втория коментиран ред – той гласи, че всички стойности на паролата, които въведохме в съветника, са преобразувани в NULL или празен низ от съображения за сигурност. Разгледайте маркирания ред с @password =празни стойности. Заменете това с правилните стойности на паролата, направете същото за други секции с пароли и изпълнете скрипта.

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

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

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

Промяна на свойствата на публикацията, за да активирате създаването на абонамент от пълно или диференциално архивиране

Ако размерът на базата данни е много малък, времето, необходимо за изпращане на първоначалната моментна снимка, ще бъде по-бързо.

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

Ако базата данни е огромна (300 GB или повече). Времето, необходимо за изпращане на първоначалната моментна снимка, ще бъде твърде дълго.
Ако абонатът се намира на различни места с ниска честотна лента на мрежата. Тогава първоначалният процес на моментна снимка ще се извършва в продължение на няколко дни.

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

За да позволим на публикацията да поддържа инициализация от резервни копия, трябва да променим едно от свойствата на публикацията. Може да се направи или чрез SSMS, или чрез T-SQL.

SSMS подход

Щракнете с десния бутон върху AdventureWorks_pub публикация и изберете Свойства :

Кликнете върху Опции за абонамент :

Задайте Вярно за Разрешаване на инициализация от архивни файлове и щракнете върху OK . Това ще ни позволи да инициализираме както от пълно, така и от диференциално архивиране.

T-SQL подход

В T-SQL можем да извикаме процедурата sp_changepublication за да промените това свойство.

Скриптът за промяна на това свойство е по-долу:

USE AdventureWorks
GO
exec sp_changepublication @publication = 'AdventureWorks_pub', @property = 'allow_initialize_from_backup', @value = 'true'

Направете пълен архив на издателя и го възстановете като абонат

Ключов фактор, за да забележите, че трябва да направим пълно архивиране, след като приложим горното свойство Publication. Ако размерът на базата данни е огромен, можем да направим пълно архивиране и да го възстановим в режим ВЪЗСТАНОВЯВАНЕ в екземпляра на абоната и да направим диференциално резервно копие, след като направим горната промяна в конфигурацията, и да го възстановим в базата данни на абоната с режим NORECOVERY.

Конфигурирайте абонамента и започнете да инициализирате от архивиране

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

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

Трябва да направим няколко промени, за да може абонаментът да се инициализира от резервно копие:

Променете @sync_type стойност от автоматично за даинициализирате с архивиране
Посочете правилните пароли за тези, заменени с NULL или празни низове. Тъй като използвах акаунта на услугата на агента в сървъра, не е необходимо да променям пароли.
Добавете параметрите @backupdevicetype и @backupdevicename и посочете пътя до пълно или диференциално архивиране на сървъра на издателя (скриптът ще се изпълни на него).

Когато приключим, нашият скрипт ще изглежда така:

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

Както показва състоянието, заданието на агента за разпространение на SQL Server е създадено и стартирано при създаването на абонамента.

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

Стартирайте монитора за репликация и щракнете с десния бутон върху абоната. Той ще покаже състоянието на репликация:

Както виждаме, всички данни са били успешно инициализирани от архива, без да е необходимо да се изпълнява задачата на Snapshot Agent. Тъй като в базата данни няма активни транзакции, в този момент получаваме съобщението „Няма налични репликирани транзакции“ в монитора на репликацията.

Изхвърлете статии от репликация

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

Използване на съветника

Щракнете с десния бутон върху AdventureWorks_pub Публикация> Свойства . Кликнете върху Статия за да видите списъка със статии, включени в Репликация.

По подразбиране той ще изброява обектите на базата данни във формат OBJECT_NAME (SCHEMA_NAME). За целите на тестването нека пуснем таблицата Person.ContactType от репликацията.

За целта просто премахнете отметката от квадратчето преди ContactType (Лице). SQL Server ще покаже съобщението за предупреждение или потвърждение:

Както се обяснява, ако в момента има налични моментни снимки, това ще ги анулира поради промените в статиите.

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

Сега Person.ContactType таблицата се премахва от репликацията. Всички промени, които се случват на издателя, няма да бъдат изпратени до базата данни за абонати. Можем да тестваме това чрез INSERT/UPDATE/DELETE записи в Person.ContactType таблица.

Използване на T-SQL

Друг начин е да пуснете статия от репликацията с помощта на sp_droparticle процедура.

USE [AdventureWorks]
GO
EXEC sp_droparticle 
  @publication = N'AdventureWorks_pub', 
  @article = N'ContactType',
  @force_invalidate_snapshot = 1;
GO

Добавяне на нови статии към репликация чрез съветник или TSQL подход

В някои случаи (като поддръжка на таблици) може да се наложи да премахнем няколко статии и да ги добавим обратно към репликацията, след като поддръжката приключи.

Успешно се научихме как да премахваме статии от репликация. Нека помислим как да добавяме нови статии към репликация. Ще добавим Person.ContactType маса които премахнахме по-рано обратно към репликация.

Използване на съветника

За да добавите статия в таблицата обратно към репликацията, щракнете с десния бутон върху Публикация > Свойства > Статии . Той ще покаже списъка със статии, налични в публикацията.

Не можахме да намерим Person.ContactType таблица – екранът показва само онези таблици, които са били част от репликацията. За да видите всички налични таблици в базата данни на издателя, махнете отметката Показване само на избрани статии в списъка за да видите всички таблици.

Сега можем да видим Person.ContactType таблицата е изброена.

Както обсъдихме по-рано, всички таблици без първични ключове ще имат червен кръг икона, която показва, че тези таблици не могат да бъдат включени в репликацията чрез Wizard или T-SQL подход.

Проверете ContactType (Person) таблица, за да я добавите обратно към репликацията и щракнете върху OK .

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

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

Нека направим това сега – щракнете с десния бутон върху Публикация > прегледайте агента за моментни снимки състояние.

Кликнете върху Старт за да изпратите моментната снимка за отговарящи на условията статии. Изпратете тези данни в базата данни за разпространение и накрая в базата данни за абонати.

T-SQL подход

Можем да извършим подобни действия с помощта на sp_addarticle процедура.

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

use [AdventureWorks]
GO
exec sp_addarticle @publication = N'AdventureWorks_pub', @article = N'ContactType', @source_owner = N'Person', @source_object = N'ContactType'
, @type = N'logbased', @description = null, @creation_script = null, @pre_creation_cmd = N'drop', @schema_option = 0x000000000803509F
, @identityrangemanagementoption = N'manual', @destination_table = N'ContactType', @destination_owner = N'Person', @vertical_partition = N'false'
, @ins_cmd = N'CALL sp_MSins_PersonContactType'
, @del_cmd = N'CALL sp_MSdel_PersonContactType'
, @upd_cmd = N'SCALL sp_MSupd_PersonContactType'
GO

По-рано забелязахме как репликацията работи за статия в таблица, като прилага 3 процедури, създадени в базата данни на абонатите, за да обработват операциите INSERT/UPDATE и DELETE.

Използвайки подхода на T-SQL, ние знаем как са посочени тези процедури. Ако е необходимо, можем да преименуваме обекти, имена на целеви таблици или процедури по подразбиране. За това ще направим промени в sp_addarticle процедура.

ЗАБЕЛЕЖКА :Ако направим някакви модификации на репликацията, трябва да ги документираме правилно. В противен случай това може да доведе до бедствие по-късно.

Добавете статия за съхранена процедура и проучете разликата между статия за таблица и статия за съхранявана процедура

За да добавим съхранена процедура към репликацията, трябва да отидем на Статии страница и проверете необходимата Съхранена процедура, за да я репликирате. Можем да направим същото за Изгледи , Индексирани изгледи или Дефинирани от потребителя функции също.

За да научите повече за разликата между статии в таблицата срещу изгледи/съхранени процедури/индексирани изгледи/функции, дефинирани от потребителя, можем да добавим по една от всяка статия за всяка категория с помощта на T-SQL:

Добавяне на нова статия за съхранявана процедура към репликация

use [AdventureWorks]
exec sp_addarticle @publication = N'AdventureWorks_pub', @article = N'uspGetBillOfMaterials', @source_owner = N'dbo'
, @source_object = N'uspGetBillOfMaterials', @type = N'proc schema only', @description = null, @creation_script = null
, @pre_creation_cmd = N'drop', @schema_option = 0x0000000008000001, @force_invalidate_snapshot = 1
, @destination_table = N'uspGetBillOfMaterials', @destination_owner = N'dbo'

Добавяне на нова статия за изглед към репликация

use [AdventureWorks]
exec sp_addarticle @publication = N'AdventureWorks_pub', @article = N'vVendorWithContacts', @source_owner = N'Purchasing'
, @source_object = N'vVendorWithContacts', @type = N'view schema only', @description = null, @creation_script = null, @pre_creation_cmd = N'drop'
, @schema_option = 0x0000000008000001, @destination_table = N'vVendorWithContacts', @destination_owner = N'Purchasing'
GO

Добавяне на нова статия с индексиран изглед към репликация

use [AdventureWorks]
exec sp_addarticle @publication = N'AdventureWorks_pub', @article = N'vStateProvinceCountryRegion', @source_owner = N'Person'
, @source_object = N'vStateProvinceCountryRegion', @type = N'indexed view schema only', @description = null, @creation_script = null
, @pre_creation_cmd = N'drop', @schema_option = 0x0000000008000001, @force_invalidate_snapshot = 1
, @destination_table = N'vStateProvinceCountryRegion', @destination_owner = N'Person'

Добавяне на нова статия за дефинирана от потребителя функция към репликация

use [AdventureWorks]
exec sp_addarticle @publication = N'AdventureWorks_pub', @article = N'ufnGetStock', @source_owner = N'dbo', @source_object = N'ufnGetStock'
, @type = N'func schema only', @description = null, @creation_script = null, @pre_creation_cmd = N'drop', @schema_option = 0x0000000008000001
, @force_invalidate_snapshot = 1, @destination_table = N'ufnGetStock', @destination_owner = N'dbo'

Използваме sp_addarticle процедура за добавяне на всякакъв тип артикули към репликацията с необходимите входни параметри и опции, променящи включеното @type параметър.

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

Свойства на статията в таблицата

Сега нека променим свойствата на статията чрез Статии меню в Публикация свойства:

Кликнете върху любимия ни Person.ContactType таблица> Свойства на статия . Ще има опция за промяна на Свойствата на статията само за тази таблица или за всички таблици, включени в репликацията. За тест избираме Задаване на свойства на подчертаната статия в таблица за да видите свойствата на Person.ContactType таблица.

Вижте всички налични опции за тази статия в таблицата:

Копиране на обекти и настройки в абонат и Доставка на извлечение са най-важните настройки за репликацията. Трябва да сме много внимателни, за да променим някой от тези параметри.

Щракнете върху формата за доставка INSERT\UPDATE\DELETE, за да получите опциите по-долу.

Не репликирайте операторите INSERT\UPDATE\DELETE – за да персонализирате репликацията да не изпраща конкретни команди към базата данни на абонатите
Инструкция INSERT\UPDATE\DELETE – за изпращане на оператор INSERT\UPDATE\DELETE директно на абоната, вместо да се реконструират данните от регистрационните файлове на транзакциите
CALL – Изпълнете вградената съхранена процедура, показана по-горе в sp_addarticle за репликиране на данни.
XCALL <съхранена процедура> – Изпълнете разширена съхранена процедура, за да репликирате промените.

Свойства на статия за съхранявана процедура

Щракнете върху Свойства на статията на някоя от съхранените процедури, за да видите Свойства

Едно от ключовите свойства на съхранената процедура е опцията за репликиране – вижте наличните опции по-долу:

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

Преглед на свойствата на статията

Кликнете върху Свойства на статията за всеки изглед, за да получите Свойства :

Индексирани свойства на статията за изглед

Кликнете върху Свойства на статията за всеки един от индексираните изгледи за Свойства :

Свойства на статия за дефинирани от потребителя функции

Щракнете върху Свойства на статията на която и да е дефинирана от потребителя функция за нейните Свойства

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

Заключение

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

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

В следващата ни статия ще разгледаме често срещаните проблеми с репликацията и как да ги разрешим професионално.