SQL Server Replikācija: Pilnīgs ceļvedis datubāzes administratoram [2026]

SQL Server Replikācija ir tehnoloģiju kopums datu un datubāzes objektu kopēšanai un izplatīšanai no vienas datubāzes uz citu, pēc tam sinhronizējot starp datubāzēm, lai saglabātu konsekvenci. Šī funkcija ļauj izveidot un uzturēt vairākas datu kopijas dažādos serveros un atrašanās vietās, nodrošinot datu pieejamību un uzticamību.

1.2 Replikācijas mērķis un priekšrocības

SQL Server Replikācija apmierina vairākas kritiskas biznesa vajadzības un sniedz ievērojamas priekšrocības datubāzes pārvaldībai un datu izplatīšanai:

Datu izplatīšana dažādās atrašanās vietās: Replikācija ļauj koplietot datus reģionālajos birojos vai globālās atrašanās vietās, uzlabojot darbības efektivitāti, nodrošinot lokālu piekļuvi nepieciešamajiem datiem. Tas samazina tīkla latentumu un nodrošina labāku veiktspēju ģeogrāfiski izkliedētiem lietotājiem.
Augsta pieejamība un katastrofu seku likvidēšana: Saglabājot kritiski svarīgu datu kopijas vairākos serveros, replikācija nodrošina redundanci, kas aizsargā pret aparatūras kļūmēm un katastrofām. Primārā servera kļūmes gadījumā replikētās kopijas var kalpot kā rezerves avoti, samazinot dīkstāves laiku un datu zudumu.
Slodzes līdzsvarošana un mērogojamība: Replikācija sadala lasīšanas operācijas vairākos serveros, novēršot, ka viens serveris kļūst par sašaurinājumu. Šī pieeja uzlabo sistēmas veiktspēju un ļauj jūsu infrastruktūrai horizontāli mērogoties, pieaugot datu un lietotāju prasībām.
Reāllaika pārskati un analīze: Atskaišu veidošanas un analītikas vaicājumu pārvietošana uz replicētiem serveriem samazina ražošanas datubāzu slodzi. Lietotāji var izpildīt sarežģītus analītiskus vaicājumus, izmantojot gandrīz reāllaika datus, neietekmējot operētājsistēmu darbību, tādējādi nodrošinot gan veiktspēju, gan datu svaigumu.
Datu integrācija un konsolidācija: Replikācija atvieglo datu apvienošanu no dažādiem avotiem vienā konsolidētā skatā. Tas ir īpaši vērtīgi organizācijām ar vairākām filiālēm, kurām ir jāapkopo dati galvenajā mītnē, vai centralizētu datu noliktavu izveidei no izkliedētām operatīvajām sistēmām.

2. SQL Server Replikācijas arhitektūra un komponenti

SQL Server Replikācijas arhitektūra sastāv no vairākiem savstarpēji savienotiem komponentiem, kas darbojas kopā, lai izplatītu un sinhronizētu datus visā jūsu datubāzes infrastruktūrā. Šajā sadaļā ir aplūkoti galvenie komponenti, tostarp izdevēji, izplatītāji, abonenti, publikācijas, raksti, abonementi un aģenti, kas koordinē datu plūsmu starp tiem:

Izdevējs: Izdevējs ir SQL Server piemērs, ka hosts ir viena vai vairākas datubāzes, kurās ir replikējamie dati. Tā kalpo kā autoritatīvs avots replikācijas topoloģijā.
Izplatītājs: Izplatītājs ir SQL Server instance, kas pārvalda datu plūsmu starp izdevējiem un abonentiem. Izplatītāja instance hosts izplatīšanas datubāze, kurā tiek glabāti replikācijas metadati un transakcijas.
Abonents: Abonents ir SQL Server instance, kas saņem un uzglabā replicētus datus no izdevējiem. Viena abonenta instance var darbotiesost vairākas abonentu datubāzes, katra no kurām saņem datus no dažādām publikācijām.
publikācija: Publikācijā ir definēts, kādi dati tiks replicēti un kā tie tiks izplatīti abonentiem. Tajā tiek grupēti saistītie raksti un noteikta replicēšanas metodoloģija, kas attiecas uz visiem ietvertajiem objektiem.
Pants: Raksts ir replikācijas pamatelements, kas attēlo atsevišķu datubāzes objektu, kas tiks izplatīts abonentiem.
Abonēšana: Abonements nosaka attiecības starp publikāciju un abonentu, definējot, kā un kad dati tiek piegādāti mērķa datubāzei.
Pārstāvji: Aģenti ir specializēti procesi, kas veic faktisko datu pārvietošanas un sinhronizācijas darbu starp replikācijas komponentiem.

3. Veidi SQL Server Reprodukcija

SQL Server piedāvā vairākus replikācijas veidus, katrs no tiem ir paredzēts konkrētiem datu izplatīšanas scenārijiem un biznesa prasībām. Lai izvēlētos pareizo pieeju jūsu videi, ir svarīgi izprast katra veida raksturlielumus, priekšrocības un ierobežojumus.

3.1 Momentuzņēmuma replikācija

Momentuzņēmumu replikācija veic publicējamo datu momentuzņēmumu noteiktā laikā un pēc tam izplata precīzu pilno kopiju abonentiem. Tā neuzrauga turpmākās izmaiņas, kamēr netiek ģenerēts nākamais momentuzņēmums. Momentuzņēmumu replikācija ir vienkāršākā replikācijas forma, tāpēc tā ir piemērota situācijām, kad dati mainās reti vai kad ir pieņemami nedaudz novecojuši dati.

Bieži sastopami lietošanas gadījumi ietver atsauces datu, piemēram, cenrāžu vai valūtas kursu, kas periodiski tiek atjaunināti, izplatīšanu, sākotnējo datu kopu nodrošināšanu datu noliktavām un scenārijus, kuros pilnīga datu atsvaidzināšana ir vēlamāka par atsevišķu izmaiņu izsekošanu. Piemēram, uzņēmums varētu izmantot momentuzņēmumu replikāciju, lai reizi dienā izplatītu atjauninātus produktu katalogus filiālēm.

Momentuzņēmumu replikācijas galvenās priekšrocības ir tās vienkāršība, zemās uzturēšanas prasības un spēja replicēt datus bez primārajām atslēgām. Tomēr tai ir ievērojami trūkumi, tostarp liela ietekme momentuzņēmumu ģenerēšanas laikā tabulu bloķēšanas dēļ, liels latentums starp atjauninājumiem un neefektivitāte lielu datu kopu vai bieži mainīgu datu gadījumā. Jebkuras izmaiņas, kas veiktas abonentu vietnēs, ir lost kad tiek lietots nākamais momentuzņēmums.

3.2 Transakciju replikācija

Transakciju replikācija nodrošina izmaiņas no izdevēja abonentiem gandrīz reāllaikā, replikējot atsevišķas transakcijas, tiklīdz tās notiek. Tā sākas ar sākotnēju momentuzņēmumu, lai noteiktu bāzes līniju, pēc tam nepārtraukti uzrauga transakciju žurnālu, lai noteiktu publicēto rakstu izmaiņas, un pakāpeniski piegādā tās abonentiem.

Transakciju replikācija ir ideāli piemērota serveru savstarpējas darbības scenārijiem, kuros nepieciešama augsta caurlaidspēja un zema latentuma pakāpe. Bieži sastopamie lietošanas gadījumi ietver mērogojamības un pieejamības uzlabošanu, nododot lasīšanas darbības abonentu serveriem, atbalstot datu glabāšanu un atskaišu veidošanu ar gandrīz reāllaika datiem, integrējot datus no vairākām vietnēm centrālā atrašanās vietā un nododot partiju apstrādi īpaši paredzētiem serveriem. Piemēram, e-komercijas platforma var izmantot transakciju replikāciju, lai uzturētu sinhronizētus krājumu datus reģionālajās datubāzēs.

Transakciju replikācijas priekšrocības ietver datu piegādi ar zemu latentumu, augstu caurlaidspēju lieliem transakciju apjomiem un iespēju veikt nereplicējamas modifikācijas abonentu līmenī. Trūkumi ietver lielāku sarežģītību salīdzinājumā ar momentuzņēmumu replikāciju, prasību pēc primārajām atslēgām replicētās tabulās un replikācijas pārtraukšanas iespējamību konfliktu, piemēram, primāro atslēgu pārkāpumu, gadījumā abonentu līmenī.

3.3 Apvienošanas replikācija

Apvienoto replikāciju īpaši izstrādāja vidēm, kurās abonentiem ir jāstrādā bezsaistē vai ar periodisku savienojumu, un pēc tam jāsinhronizē izmaiņas, kad savienojums ir pieejams. Šis replikācijas veids ļauj mainīt datus gan izdevēja, gan abonentu līmenī neatkarīgi, izsekojot izmaiņām, izmantojot trigerus un metadatu tabulas, un automātiski apvienojot izmaiņas sinhronizācijas laikā.

Apvienošanas replikācija ir paredzēta mobilajām lietojumprogrammām un izkliedētām serveru vidēm, kur notiek autonomas izmaiņas. Lietošanas gadījumi ietver pārdošanas spēka automatizāciju, kur mobilo ierīču lietotāji strādā bezsaistē un sinhronizē vēlāk, pārdošanas vietas sistēmas, kas darbojas neatkarīgi un periodiski konsolidē datus, un izkliedētas lietojumprogrammas, kur vairākām vietām ir jāatjaunina koplietotie dati. Piemēram, mazumtirdzniecības ķēde var izmantot apvienošanas replikāciju, lai katrs veikals varētu pārvaldīt vietējo krājumu, vienlaikus sinhronizējot ar centrālās noliktavas sistēmu.

Apvienošanas replikācijas priekšrocības ietver atbalstu autonomiem abonentiem, kas var veikt izmaiņas, toleranci pret neregulāru tīkla savienojamību un elastīgu konfliktu risināšanu. Trūkumi ietver lielāku sarežģītību iestatīšanā un uzturēšanā, veiktspējas izmaksas, kas rodas metadatu un aktivizētāju izsekošanas dēļ, unikālo identifikatoru kolonnu pievienošanu tabulām un iespējamus konfliktus, kuriem nepieciešama pārvaldība un risināšana.

3.4 Vienādranga replikācija

Vienādranga replikācija ir balstīta uz transakciju replikāciju un ļauj vairākām servera instancēm (trīs vai vairāk mezgliem) darboties kā līdzvērtīgiem līdziniekiem, katram mezglam vienlaikus kalpojot gan kā publicētājam, gan abonentam. Šajā topoloģijā visi mezgli uztur identiskas datu kopijas un var apstrādāt gan lasīšanas, gan rakstīšanas darbības, nodrošinot patiesi izkliedētu vairāku galveno mezglu vidi.

Vienādranga replikācija ir piemērota lietojumprogrammām, kurām nepieciešama lasīšanas operāciju mērogošana un augsta pieejamība. Lietošanas gadījumi ietver tīmekļa lietojumprogrammas, kas izplata kataloga vaicājumus vairākos mezglos, vienlaikus saglabājot konsekventus datus, scenārijus, kuriem nepieciešama apkope vai jaunināšana bez dīkstāves, atsevišķi izslēdzot mezglus, un globālas lietojumprogrammas ar datu centriem dažādos reģionos. Piemēram, pasaules mēroga programmatūras atbalsta organizācija var izmantot vienādranga replikāciju birojos dažādās laika joslās, lai katrai atrašanās vietai būtu lokāla piekļuve pašreizējiem datiem.

Vienādranga replikācijas priekšrocības ietver uzlabotu lasīšanas veiktspēju, izmantojot mērogošanu, augstāku pieejamību ar vairākiem aktīviem mezgliem un gandrīz reāllaika datu konsekvenci. Trūkumi ietver prasību pēc Enterprise Edition, sarežģītību vairāku mezglu topoloģiju pārvaldībā, nepieciešamību pēc identiskas shēmas un datiem visos mezglos un iespējamus konfliktus, ja rakstīšanas operācijas nav pareizi sadalītas.

3.5 Divvirzienu replikācija

Divvirzienu replikācija ir specifiska transakciju replikācijas topoloģija, kas īpaši izstrādāta divu serveru vidēm, kur abiem serveriem ir jāapmainās ar izmaiņām savā starpā. Katrs serveris publicē datus un abonē tos pašus datus no otra servera, radot vienkāršu divvirzienu sinhronizācijas plūsmu. Lai gan vienādranga replikācija var atbalstīt arī divus mezglus, divvirzienu replikācija nodrošina uzlabotu veiktspēju šajā konkrētajā scenārijā.

Divvirzienu replikācija ir piemērota scenārijiem, kuros nepieciešami divi aktīvi serveri ar sinhronizētiem datiem, piemēram, aktīvi-aktīvas konfigurācijas augstas pieejamības nodrošināšanai vai ģeogrāfiski izkliedētas lietojumprogrammas, kur katrai vietnei ir nepieciešama lokāla rakstīšanas piekļuve. Topoloģija prasa rūpīgu lietojumprogrammu izstrādi, lai sadalītu datu atjauninājumus un novērstu konfliktus.

Priekšrocības ietver optimizētu veiktspēju divu serveru scenārijiem, vienkāršāku konfigurēšanu salīdzinājumā ar vienādranga replikāciju, gandrīz reāllaika sinhronizāciju un zemākas izmaksas nekā apvienošanas replikācijai. Trūkumi ietver ierobežojumu līdz tieši diviem serveriem, iebūvētas konfliktu risināšanas trūkumu, kas prasa rūpīgu lietojumprogrammu izstrādi, un nepieciešamību pēc atbilstošām sadalīšanas stratēģijām, lai novērstu konfliktus.

3.6 Atjaunināmi abonementi

Atjaunināmi abonementi paplašina transakciju replikāciju, lai abonenti varētu laiku pa laikam veikt izmaiņas replicētajos datos, kas pēc tam tiek izplatītas atpakaļ izdevējam un citiem abonentiem. Atšķirībā no apvienošanas replikācijas vai vienādranga topoloģijām, kas paredzētas biežiem divvirzienu atjauninājumiem, atjaunināmie abonementi ir paredzēti scenārijiem, kuros galvenā datu plūsma ir vienvirziena (no izdevēja abonentiem), bet abonentiem laiku pa laikam ir jāveic labojumi vai atjauninājumi.

Atjaunināmi abonementi ir piemēroti scenārijiem, kuros most Atjauninājumi notiek izdevēja līmenī, taču neregulāri atjauninājumi ir nepieciešami arī abonentu līmenī, piemēram, lauka birojos, kas galvenokārt lasa datus, bet kuriem ir jāveic lokāli labojumi vai atjauninājumi. Topoloģijai nepieciešama rūpīga plānošana, lai samazinātu konfliktus un nodrošinātu datu konsekvenci.

Galvenās priekšrocības ietver ierobežotu rakstīšanas operāciju atļaušanu abonentiem, vienlaikus saglabājot transakciju replikācijas veiktspējas raksturlielumus. Trūkumi ietver paaugstinātu sarežģītību, potenciālus konfliktus, kas jāatrisina, veiktspējas izmaksas no divfāžu apstiprināšanas protokola tūlītējas atjaunināšanas režīmā un prasību, ka visām replicētajām tabulām ir jābūt primārajām atslēgām.

3.7 Dažādu replikāciju veidu salīdzinājums

Replikācijas veids	Atjaunināšanas laiks	Izdevēju skaits	Vadība	Izmantojiet scenārijus
momentuzņēmums	Laika brīdis	1	Viens virziens (Izdevējs → Abonenti)	Reti mainīgi atsauces dati (cenrāži, valūtas kursi)
Darījuma	Gandrīz reāllaikā	1	Viens virziens (Izdevējs → Abonenti)	Augstas caurlaidspējas scenāriji (e-komercijas inventārs, datu glabāšana, pārskatu veidošana)
Apvienot	Periodiski (kad ir izveidots savienojums)	1	Divvirzienu (Izdevējs ↔ Abonenti)	Mobilās lietotnes, bezsaistes darbinieki (pārdošanas automatizācija, lauka pakalpojumi)
Peer-to-Peer	Gandrīz reāllaikā	Vairāki (3 vai vairāk)	Divvirzienu (visi mezgli)	Globālas vairāku datu centru izvietošanas (biroji visā pasaulē ar lokālu lasīšanas un rakstīšanas piekļuvi)
Divvirzienu	Gandrīz reāllaikā	2	Divvirzienu (abi serveri)	Divu datu centru aktīvas-aktīvas konfigurācijas (divu vietņu augsta pieejamība)
Atjaunināmi abonementi	Gandrīz reāllaikā	1	Galvenokārt vienā virzienā (neregulāri apgriezti atjauninājumi)	Filiāles, kas galvenokārt lasa, bet reizēm atjaunina (vietējie labojumi)

4. Iestatīšana SQL Server Reprodukcija

4.1 Priekšnosacījumi un prasības

4.1.1 Programmatūras prasības

SQL Server replikācijai nepieciešama saderība SQL Server versijas visiem topoloģijas dalībniekiem. Izplatītāja versijai ir jābūt vienādai vai jaunākai par izdevēja versiju, un abonents var būt divu izdevēja versiju robežās. Piemēram, SQL Server 2016. gada izdevējs var atkārtot SQL Server 2012., 2014., 2016., 2017. vai 2019. gada abonenti.

4.1.2 Atļauju prasības

Replikācijas konfigurēšanai katrā līmenī ir nepieciešamas noteiktas atļaujas. Sistēmas administratora fiksētā servera lomas dalībnieki var veikt visus replikācijas konfigurācijas uzdevumus. Lai iegūtu detalizētākas atļaujas, lietotājiem ir jābūt db_owner datubāzes lomas dalībniekiem izdevēja un abonenta datubāzēs.

4.2 1. darbība. Izplatīšanas konfigurēšana

Izplatīšanas konfigurēšana ir pirmais iestatīšanas solis SQL Server replikācija.

Lai konfigurētu izplatīšanu, izmantojot SQL Server Vadības studija:

Izveidojiet savienojumu ar SQL Server piemēram, SQL Server Vadības studija.
Objektu pārlūkā ar peles labo pogu noklikšķiniet uz Reprodukcija mapi un atlasiet Izplatīšanas konfigurēšana.
Izplatīšanas konfigurēšanas vednī noklikšķiniet uz Nākamā sveiciena lapā.
Gada izplatītājs lapā izvēlieties vienu no tālāk norādītajām opcijām, pamatojoties uz topoloģijas prasībām:
- Vietējais izplatītājsAtlasiet “Servera_nosaukums darbosies kā savs izplatītājs”; SQL Server izveidos izplatīšanas datubāzi un žurnālu”, ja vēlaties, lai izdevējs un izplatītājs darbotos vienā un tajā pašā instancē (pašreizējā instancē). Šo konfigurāciju ir vienkāršāk iestatīt, un tā ir piemērota mazākām vidēm vai gadījumiem, kad tīkla latentums starp izdevēju un izplatītāju radītu problēmas.
- Attālinātais izplatītājsAtlasiet “Izmantot šo serveri kā izplatītāju” un noklikšķiniet uz Pievienot lai norādītu attālinātu izplatītāja serveri, ja vēlaties novirzīt izplatīšanas apstrādi uz atsevišķu instanci. Šī konfigurācija uzlabo veiktspēju, ja replikācijas apjomi ir lieli, sadalot darba slodzi vairākos serveros. Jums būs jānorāda attālā izplatītāja nosaukums un jānorāda parole, ko izdevējs izmantos, lai izveidotu savienojumu ar izplatītāju.
Noklikšķiniet Nākamā lai norādītu momentuzņēmuma mapes atrašanās vietu. Lai nodrošinātu pieejamību visā tīklā, izmantojiet UNC ceļu (piemēram, \\servera_nosaukums\koplietošanas\mape), nevis lokālu ceļu.
Gada Izplatīšanas datubāze lapā pieņemiet noklusējuma izplatīšanas datubāzes nosaukumu (parasti “distribution”) vai norādiet pielāgotu nosaukumu un pēc tam konfigurējiet datu un žurnālfailu atrašanās vietas.
Gada Izdevēji lapā pārbaudiet, vai pašreizējais serveris ir iespējots kā izdevējs. Ja konfigurējat pašreizējo serveri kā izplatītāju, varat pievienot papildu izdevējus, kas izmantos šo izplatītāju.
Pārskatiet vedņa darbības un noklikšķiniet uz apdare lai konfigurētu izplatīšanu.

4.3 2. solis: publikācijas izveide

Pēc izplatīšanas konfigurēšanas nākamais solis ir izveidot publikāciju, kas nosaka, kuri datu objekti tiks replicēti abonentiem.

Lai izveidotu publikāciju, izmantojot SQL Server Vadības studija:

Objektu pārlūkā izvērsiet Reprodukcija mapi.
Right-click Vietējās publikācijas un izvēlieties Jauna publikācija.
Jauno publikāciju vednistarts; klikšķis Nākamā sveiciena lapā.
Atlasiet datubāzi, kuru vēlaties publicēt, no saraksta. Publikāciju datubāze lapa. Tas automātiski iespējo publicēšanu atlasītajā datubāzē.
Gada Publikācijas veids lapā atlasiet replikācijas veidu: Momentuzņēmuma publikācija, Darījumu publikācija, Vienādranga publikācija, vai Apvienot publikāciju.
Gada Raksti lapu, izvērsiet Galdi mezglu un atlasiet tabulas, kuras iekļaut kā rakstus.
Pēc izvēles izvērst Saglabātās procedūras, Viewsvai citus objektu tipus, lai iekļautu papildu rakstus.
Noklikšķiniet Raksta īpašības lai konfigurētu filtrēšanu vai citus ar rakstu saistītus iestatījumus.
Gada Filtrēt tabulas rindas lapā pievienojiet rindu filtrus, ja nepieciešams.
Gada Momentuzņēmumu aģents lapā izvēlieties, kad izveidot momentuzņēmumu: nekavējoties, noteiktā laikā vai pēc grafika.
Gada Aģenta drošība lapā norādiet momentuzņēmumu aģenta drošības kontekstu.
Gada Burvja darbības lapa, atlasiet Izveidojiet publikāciju.
Norādiet publikācijas nosaukumu un noklikšķiniet uz apdare.

4.4 3. solis: Izveidojiet abonementu

Pēc publikācijas izveides nākamais solis ir abonementu izveide, kas savieno publikāciju ar abonentu datubāzēm.

Abonementi var būt push abonementi (ko pārvalda izplatītājs) vai pull abonementi (ko pārvalda abonents). Galvenās atšķirības ir vieta, kur jūs izveidojat abonementu, un kuru aģenta atrašanās vietu jūs izvēlaties, kas nosaka abonementa darbību (push vai pull).

Push abonementam (pārvalda Izplatītājs):

Gada izdevējs serveris, paplašināt Reprodukcija -> Vietējās publikācijas.
Ar peles labo pogu noklikšķiniet uz publikācijas un atlasiet Jauni abonementi.

Pull abonementam (pārvalda Abonents):

Gada abonents serveris, paplašināt Reprodukcija, ar peles labo pogu noklikšķiniet Vietējie abonementiun izvēlieties Jauni abonementi.
Gada publicēšana lapā, noklikšķiniet uz Adrese SQL Server izdevējs un izveidojiet savienojumu ar izdevēja serveri.

Bieži sastopamās vedņa darbības abiem abonēšanas veidiem:

Jaunā abonementa vednī noklikšķiniet uz Nākamā sveiciena lapā.
Atlasiet publikāciju un noklikšķiniet uz Nākamā.
Gada Izplatīšanas aģenta atrašanās vieta lapā izvēlieties aģenta atrašanās vietu:
- Push abonementsAtlasiet “Palaist visus aģentus pie izplatītāja” — izplatītājs veiks izmaiņas abonentiem.
- Pull abonementsAtlasiet “Palaist katru aģentu pie tā abonenta” — katrs abonents iegūs izmaiņas no izplatītāja.
Gada Abonenti lapā atlasiet esošos abonentu serverus vai noklikšķiniet uz Pievienot pasūtītāju lai pievienotu jaunus.
Katram abonentam atlasiet mērķa datubāzi vai izveidojiet jaunu datubāzi. Piezīme: Abonēšanas datubāzei ir jāatšķiras no izdevēja datubāzes, pat ja tiek izmantota tā pati datubāze. SQL Server piemērs
Gada Izplatīšanas aģenta drošība lapā noklikšķiniet uz katra abonementa rekvizītu pogas, lai konfigurētu drošības kontekstu.
Gada Sinhronizācijas grafiks lapā izvēlieties nepārtraukto sinhronizāciju vai plānoto sinhronizāciju.
Gada Inicializēt abonementus lapa, atlasiet Nekavējoties inicializēt vedņa pabeigšanas laikā vai Pirmās sinhronizācijas laikā.
Pārskatiet vedņa darbības un noklikšķiniet uz apdare.

5. Uzraudzība un pārvaldība SQL Server Reprodukcija

5.1 Replikācijas uzraudzība ar Replication Monitor

Lai palaistu replikācijas monitoru:

In SQL Server Vadības studija, izvērst Reprodukcija objektu pārlūkā.
Right-click Reprodukcija un izvēlieties Palaist replikācijas monitoru.
Ja nav reģistrētu izdevēju, noklikšķiniet uz Pievienot izdevēju kreisajā rūtī.
izvēlēties Pievienot SQL Server izdevējs un izveidojiet savienojumu ar izdevēja serveri.
Izdevējs tiek parādīts kreisajā rūtī ar izvēršamiem mezgliem publikācijām un abonementiem.

5.2 Veiktspējas uzraudzība

5.2.1 Monitora latentums

Replikācijas latentums ir laika aizture starp izmaiņu veikšanu izdevēja pusē un šo izmaiņu piemērošanu abonenta pusē. Uzraugiet latentumu, lai nodrošinātu, ka datu jaunums atbilst biznesa prasībām.

Izmantojiet Replication Monitor, lai skatītu latentuma rādītājus cilnē All Subscriptions. Latentuma kolonnā ir redzama vidējā latentuma vērtība sekundēs. Transakciju replikācijai izsekošanas marķieri nodrošina precīzus latentuma mērījumus, ievietojot marķieru transakcijas, kas tiek izsekotas visā replikācijas procesā.

Lai izmantotu izsekošanas žetonus:

Replikācijas monitorā atlasiet transakciju publikāciju.
Noklikšķiniet Marķiera žetoni Tab.
Noklikšķiniet Ievietot marķieri lai ievadītu marķiera darījumu.
Uzraugiet žetonu tā ceļojumā no izdevēja pie izplatītāja un abonenta.
Apskatiet laiku, kas katram segmentam nepieciešams, lai identificētu sastrēgumus.

5.2.2 Monitora caurlaidspēja

Caurlaidspēja mēra laika gaitā replicēto datu apjomu, kas parasti tiek izteikts kā transakcijas sekundē vai komandas sekundē. Uzraugiet caurlaidspēju, lai nodrošinātu, ka replikācija var neatpalikt no publicētāja aktivitātes.

Lai gan replikācijas monitors nodrošina pamata sinhronizācijas statusu, piegādes ātrums un detalizēta caurlaidspējas metrika nav redzama grafiskajā lietotāja saskarnē. Izmantojiet T-SQL vaicājumus izplatīšanas datubāzē, lai uzraudzītu caurlaidspēju:

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

Statusa kodi: 1 = Start, 2 = Notiek apstrāde, 3 = Izdevās, 4 = Dīkstāvē, 5 = Mēģinājums vēlreiz, 6 = Neizdevās. Salīdziniet piegādes ātrumu ar izdevēja darījumu ātrumu, lai noteiktu situācijas, kurās replikācija atpaliek. Veiktspējas skaitītāji Windows veiktspējas monitors nodrošināt papildu caurlaidspējas rādītājus katram replikācijas aģentam.

5.2.3 Vājvietu identificēšana

Replikācijas sastrēgumi var rasties vairākos topoloģijas punktos. Izdevēja vietā pārmērīgs momentuzņēmumu ģenerēšanas laiks vai žurnāla lasītāja aģenta aizkaves var norādīt uz resursu ierobežojumiem. Replikācijas darbību laikā uzraugiet izdevēja centrālo procesoru, atmiņu un diska ievadizvadi.

Izplatītāja datubāzē pārbaudiet, vai uzkrājas transakcijas. Liels skaits neizplatītu komandu norāda, ka izplatītājs nespēj nodrošināt piegādi. Uzraugiet izplatītāja servera resursus un apsveriet iespēju izmantot īpašu attālinātu izplatītāju liela apjoma scenārijiem.

Abonenta līmenī lēna izmaiņu piemērošana var būt saistīta ar nepietiekamiem resursiem, trūkstošiem indeksiem vai ierobežojumiem, kas palēnina ievietošanas darbības. Uzraugiet abonenta resursu izmantošanu un vaicājumu veiktspēju, kad darbojas izplatīšanas aģents. Tīkla joslas platuma ierobežojumi starp komponentiem rada arī sastrēgumus, īpaši lieliem datu apjomiem.

5.3 Replikācijas aģentu pārvaldība

5.3.1 Start un Stop aģenti

Uz start vai apturēt replikācijas aģentu:

In SQL Server Vadības studija, izvērst SQL Server Aģents -> Darbs.
Atrodiet replikācijas aģenta uzdevumu (nosaukumos parasti ir iekļauta publikācija un abonenta informācija).
Ar peles labo pogu noklikšķiniet uz darba un atlasiet Start Darbs or Apturēt darbu.

5.3.2 Aģenta profilu konfigurēšana

Aģentu profili satur parametru kopas, kas kontrolē aģentu darbību. SQL Server nodrošina noklusējuma profilus, kas ir optimizēti bieži sastopamiem scenārijiem, un jūs varat izveidot pielāgotus profilus īpašām vajadzībām.

Lai modificētu aģenta profilus:

Objektu pārlūkā izvērsiet Reprodukcija.
Right-click Reprodukcija un izvēlieties Izplatītāja īpašības.
Noklikšķiniet Profila noklusējuma iestatījumi poga.
Nolaižamajā izvēlnē atlasiet aģenta veidu (momentuzņēmums, žurnālu lasītājs, izplatīšana vai apvienošana).
Atlasiet profilu un noklikšķiniet uz īpašības lai skatītu parametru vērtības.
Noklikšķiniet Jauns profils lai izveidotu pielāgotu profilu, pamatojoties uz esošu.
Mainiet parametrus pēc nepieciešamības un noklikšķiniet uz OK.

Lietojiet aģentam profilu, rediģējot abonementa rekvizītus un atlasot vēlamo profilu nolaižamajā izvēlnē Aģenta profils.

5.3.3 Aģenta parametri un iestatījumi

Aģenta parametri precīzi noregulē veiktspēju un darbību. Izplatīšanas aģenta galvenie parametri ietver CommitBatchSize (transakciju skaits, kas tiek lietots vienā apstiprinājumā), CommitBatchThreshold (komandu skaits pirms apstiprinājuma), SubscriptionStreams (paralēlie savienojumi ātrākai piegādei) un QueryTimeout (komandu taimauts).

Žurnālu lasītāja aģentam svarīgi parametri ir ReadBatchSize (nolasīto transakciju skaits skenēšanas laikā), ReadBatchThreshold (komandas pirms piegādes) un PollingInterval (aizkave starp žurnālu skenēšanām). Pielāgojiet šos parametrus atkarībā no transakciju apjoma un latentuma prasībām.

5.4 Dublēšanas un atjaunošanas apsvērumi

Replikācijā iesaistīto datubāzu dublēšanai ir nepieciešami īpaši apsvērumi. Izdevēja datubāzei ir svarīgi regulāri veikt pilnas un transakciju žurnāla dublējumkopijas. Atzīmējiet datubāzes dublējumkopiju replikācijas atbalstam, izmantojot opciju WITH REPLICATION, dublējot datubāzes transakciju replikācijā. Regulāri dublējiet izplatīšanas datubāzi, lai aizsargātu replikācijas konfigurāciju.

Atjaunojot izdevēja datubāzi tajā pašā serverī ar tādu pašu nosaukumu, izmantojiet opciju WITH KEEP_REPLICATION, lai saglabātu replikācijas stāvokli. Šī opcija nodrošina, ka darījumi, ko žurnāla lasītāja aģents vēl nav apstrādājis, paliek atzīmēti replikācijai, ļaujot replikācijai turpināties automātiski, nereinicializējot abonementus.

Katastrofu atkopšanas gadījumos, kad dublējumkopijas nav pieejamas, ir bojātas vai datubāzes faili ir bojāti, var būt nepieciešami specializēti atkopšanas rīki. DataNumen SQL Recovery var iegūt datus no bojātiem vai nepieejamiem MDF un NDF failiem, nodrošinot pēdējo līdzekli, ja standarta atjaunošanas procedūras neizdodas.

Lai iegūtu sīkāku informāciju par SQL Server rezerves kopiju, skatiet mūsu visaptveroša rokasgrāmata.

6. Bieži uzdotie jautājumi (BUJ)

J: Kāda ir atšķirība starp momentuzņēmumu un transakciju replikāciju?

A: Momentuzņēmuma replikācija paņem pilnīgu datu kopiju noteiktā laika brīdī un piemēro to abonentam, kas ir piemērots reti mainīgiem datiem. Transakciju replikācijatarts ar sākotnējo momentuzņēmumu un pēc tam nepārtraukti replicē atsevišķas transakcijas, tiklīdz tās notiek, nodrošinot gandrīz reāllaika sinhronizāciju bieži mainīgiem datiem.

J: Vai varu replicēt starp dažādiem SQL Server versijas?

A: Jā, SQL Server Replikācija atbalsta versiju saderību ierobežotā diapazonā. Izplatītāja versijai jābūt vienādai vai jaunākai par izdevēja versiju, un abonentam var būt divas izdevēja versijas. Piemēram, ja izdevējs ir SQL Server 2016. gadā abonents var būt SQL Server 2012., 2014., 2016., 2017. vai 2019. gadā.

J: Kā rīkoties ar konfliktiem apvienošanas replikācijā?

A: Apvienošanas replikācija nodrošina iebūvētus konfliktu noteikšanas un risināšanas mehānismus. Konfliktu risinātājus var konfigurēt raksta līmenī, izvēloties no iebūvētiem risinātājiem vai ieviešot pielāgotus konfliktu risinātājus. Konflikti parasti tiek risināti, izmantojot uz prioritāti vai laika zīmogu balstītas metodes, ar iespēju reģistrēt konfliktus manuālai pārskatīšanai.

J: Kāda ir replikācijas ietekme uz veiktspēju?

A: Replikācija ietekmē veiktspēju vairākos veidos: izdevējam rodas papildu slodzes, izsekošanai mainoties un momentuzņēmumiem ģenerējot, izplatītājs izmanto resursus transakciju glabāšanai un pārsūtīšanai, un tīkla joslas platums tiek patērēts datu pārsūtīšanas laikā. Ietekme atšķiras atkarībā no replikācijas veida, momentuzņēmumu replikācijai izraisot periodiskus augstas ietekmes uzliesmojumus, bet transakciju replikācijai saglabājot konsekventāku, bet nepārtrauktu slodzi.

J: Kā es varu nodrošināt savu replikācijas topoloģiju?

A: Nodrošiniet savu replikācijas topoloģiju, ieviešot vairākas labākās prakses: izmantojiet Windows autentifikāciju vai spēcīgu SQL Server autentifikāciju, savienojumu šifrēšanu, izmantojot TLS, momentuzņēmumu mapes aizsardzību ar atbilstošiem NTFS atļaujas, konfigurējiet publikāciju piekļuves sarakstu (PAL), lai kontrolētu piekļuvi, izmantojiet atsevišķus pakalpojumu kontus ar minimālām nepieciešamajām atļaujām katram replikācijas aģentam un regulāri pārbaudiet replikācijas drošības iestatījumus.

J: Vai varu replicēt uz Azure SQL datubāzi?

A: Jā, jūs varat replicēt uz Azure SQL datubāzi, izmantojot transakciju replikāciju ar lokālu risinājumu. SQL Server vai Azure SQL pārvaldīto instanci kā izdevēju un izplatītāju. Azure SQL datubāze var darboties kā abonents, bet ne kā izdevējs vai izplatītājs. Apvienotā replikācija un vienādranga replikācija netiek atbalstīta ar Azure SQL datubāzi.

J: Kā es varu uzraudzīt replikācijas aizkavi?

A: Replikācijas aizkaves uzraudzība, izmantojot replikācijas monitoru SQL Server Management Studio, kas parāda katra abonementa latentuma rādītājus. Varat arī vaicāt izplatīšanas datubāzes tabulas, piemēram, MSdistribution_history un MSrepl_commands, izmantot replikācijas aģentiem specifiskus veiktspējas skaitītājus vai iestatīt brīdinājumus, pamatojoties uz latentuma sliekšņiem, lai proaktīvi noteiktu un novērstu sinhronizācijas aizkaves.

J: Kas notiek, ja abonents ir bezsaistē?

A: Kad abonents ir bezsaistē, darbība ir atkarīga no replikācijas veida. Transakciju replikācijas gadījumā transakcijas uzkrājas izplatīšanas datubāzē, līdz abonents atgriežas tiešsaistē, pēc tam sinhronizācija tiek atsākta. Apvienotās replikācijas gadījumā izmaiņas tiek izsekotas abās pusēs un apvienotas, kad tiek atjaunots savienojums. Saglabāšanas perioda iestatījums nosaka, cik ilgi dati tiek glabāti, pirms tie ir atkārtoti jāinicializē.

J: Kā pievienot jaunus rakstus esošai publikācijai?

A: Lai esošai publikācijai pievienotu jaunus rakstus, izmantojiet SQL Server Management Studio, lai modificētu publikācijas rekvizītus un atlasītu papildu objektus, vai izmantojiet saglabāto procedūru sp_addarticle. Pēc rakstu pievienošanas ģenerējiet jaunu momentuzņēmumu un atkārtoti inicializējiet visus abonementus, lai nodrošinātu, ka abonenti saņem jaunos rakstus. Dažām izmaiņām var būt nepieciešama abonementa atkārtota inicializācija atkarībā no publikācijas iestatījumiem.

J: Kā noņemt replikāciju no datubāzes?

A: Lai noņemtu replikāciju no datubāzes, vispirms dzēsiet visus abonementus, izmantojot sp_dropsubscription, pēc tam atmetiet publikāciju, izmantojot sp_droppublication, un visbeidzot atspējojiet publicēšanu datubāzē, izmantojot sp_replicationdboption. Ja serveris ir izplatītājs, atspējojiet izplatīšanu, izmantojot sp_dropdistributor. Pirms replikācijas konfigurācijas noņemšanas vienmēr dublējiet datubāzes.

J: Kāda ir atšķirība starp SQL Server Replikācija un AlwaysOn pieejamības grupas?

A: Replikācija ir datu izplatīšanas un integrācijas risinājums, kas darbojas objekta līmenī, vienlaikus Vienmēr pieejamības grupas ir augstas pieejamības un katastrofu atkopšanas risinājums, kas darbojas datubāzes līmenī.

7. secinājums

SQL Server Replikācija nodrošina stabilu sistēmu datu izplatīšanai un sinhronizēšanai vairākās datubāzēs un atrašanās vietās. Tehnoloģija atbalsta dažādus scenārijus, izmantojot dažādus replikācijas veidus.

Pareizās replikācijas stratēģijas izvēle ir atkarīga no jūsu īpašajām prasībām. Apsveriet datu maiņas biežumu, latentuma prasības, to, vai abonentiem ir jāveic atjauninājumi, tīkla raksturlielumus un abonentu autonomijas vajadzības. Momentuzņēmumu replikācija vislabāk darbojas reti mainīgiem atsauces datiem, kur latentums nav kritisks. Transakciju replikācija ir piemērota liela apjoma scenārijiem, kam nepieciešama zema latentuma un galvenokārt vienvirziena datu plūsma.

Izvēlieties apvienošanas replikāciju, ja abonentiem nepieciešama autonoma darbība ar bezsaistes iespējām un divvirzienu sinhronizāciju. Ieviesiet vienādranga replikāciju slodzes līdzsvarošanai lasīšanas operācijās vairākos aktīvos mezglos ar gandrīz reāllaika konsekvenci. Apsveriet hibrīdas pieejas, apvienojot vairākus replikācijas veidus sarežģītos scenārijos ar atšķirīgām prasībām.

Atsauces

par autoru

Juaņs Šens ir vecākais datubāzes administrators (DBA) ar vairāk nekā 10 gadu pieredzi SQL Server vides un uzņēmumu datubāzu pārvaldību. Viņš ir veiksmīgi atrisinājis simtiem datubāzu atkopšanas scenāriju finanšu pakalpojumu, veselības aprūpes un ražošanas organizācijās.

Juaņa specializējas SQL Server datubāzu atjaunošana, augstas pieejamības risinājumi un veiktspējas optimizācija. Viņa plašā praktiskā pieredze ietver vairāku terabaitu datubāzu pārvaldību, Always On pieejamības grupu ieviešanu un automatizētu dublēšanas un atkopšanas stratēģiju izstrādi kritiski svarīgām biznesa sistēmām.

Izmantojot savu tehnisko pieredzi un praktisko pieeju, Juans koncentrējas uz visaptverošu rokasgrāmatu izveidi, kas palīdz datubāzu administratoriem un IT speciālistiem risināt sarežģītus jautājumus SQL Server efektīvi izaicina. Viņš seko līdzi jaunākajām tendencēm SQL Server laidieniem un Microsoft attīstītajām datubāzu tehnoloģijām, regulāri testējot atkopšanas scenārijus, lai nodrošinātu, ka viņa ieteikumi atspoguļo labāko praksi reālajā pasaulē.

Ir jautājumi par SQL Server atkopšanai vai nepieciešama papildu palīdzība datubāzes problēmu novēršanā? Juans laipni aicina atsauksmes un ieteikumi lai uzlabotu šos tehniskos resursus.