SQL Server Replikointi: Täydellinen opas tietokannan pääkäyttäjälle [2026]

SQL Server Replikointi on joukko tekniikoita, joilla kopioidaan ja jaetaan tietoja ja tietokantaobjekteja tietokannasta toiseen ja synkronoidaan sitten tietokantojen välillä yhtenäisyyden säilyttämiseksi. Tämän ominaisuuden avulla voit luoda ja ylläpitää useita kopioita tiedoistasi eri palvelimilla ja sijainneissa, mikä varmistaa tietojen saatavuuden ja luotettavuuden.

1.2 Replikoinnin tarkoitus ja hyödyt

SQL Server replikointi palvelee useita kriittisiä liiketoimintatarpeita ja tarjoaa merkittäviä etuja tietokannan hallintaan ja tiedon jakeluun:

Tiedon jakelu eri sijainneissa: Replikoinnin avulla voit jakaa tietoja alueellisten toimistojen tai maailmanlaajuisten sijaintien välillä, mikä parantaa toiminnan tehokkuutta varmistamalla paikallisen pääsyn tarvittaviin tietoihin. Tämä vähentää verkon viivettä ja tarjoaa paremman suorituskyvyn maantieteellisesti hajautetuille käyttäjille.
High Availability ja katastrofien jälkeinen palautuminen: Ylläpitämällä kriittisten tietojen kopioita useilla palvelimilla replikointi tarjoaa redundanssia, joka suojaa laitteistovikoilta ja katastrofeilta. Ensisijaisen palvelimen vikaantumisen sattuessa replikoidut kopiot voivat toimia varalähteinä, mikä minimoi käyttökatkoksia ja tietojen menetystä.
Kuormituksen tasapainotus ja skaalautuvuus: Replikointi jakaa lukutoiminnot useille palvelimille, estäen yksittäisen palvelimen muodostumisen pullonkaulaksi. Tämä lähestymistapa parantaa järjestelmän suorituskykyä ja mahdollistaa infrastruktuurisi skaalautumisen horisontaalisesti datan ja käyttäjien vaatimusten kasvaessa.
Reaaliaikainen raportointi ja analyysi: Raportointi- ja analytiikkakyselyiden siirtäminen replikoiduille palvelimille vähentää tuotantotietokantojen kuormitusta. Käyttäjät voivat suorittaa monimutkaisia analyyttisiä kyselyitä lähes reaaliaikaista dataa vasten vaikuttamatta operatiivisiin järjestelmiin, mikä varmistaa sekä suorituskyvyn että datan ajantasaisuuden.
Tietojen integrointi ja yhdistäminen: Replikointi helpottaa eri lähteistä peräisin olevan datan yhdistämistä yhdeksi konsolidoiduksi näkymäksi. Tämä on erityisen arvokasta organisaatioille, joilla on useita sivukonttoreita ja joiden on koottava dataa pääkonttorissa, tai keskitettyjen tietovarastojen luomiseksi hajautetuista operatiivisista järjestelmistä.

2. SQL Server Replikointiarkkitehtuuri ja komponentit

SQL Server Replikointiarkkitehtuuri koostuu useista toisiinsa kytkeytyneistä komponenteista, jotka toimivat yhdessä jakaakseen ja synkronoidakseen tietoja tietokantainfrastruktuurissasi. Tässä osiossa tarkastellaan ydinkomponentteja, kuten julkaisijoita, jakelijoita, tilaajia, julkaisuja, artikkeleita, tilauksia ja agentteja, jotka koordinoivat tiedonkulkua niiden välillä:

Kustantaja: Julkaisija on SQL Server instanssi, joka isännöi yhtä tai useampaa replikoitavaa tietoa sisältävää tietokantaa. Se toimii replikointitopologian auktoritatiivisena lähteenä.
Jakelija: Jakelija on SQL Server instanssi, joka hallitsee tiedonkulkua julkaisijoiden ja tilaajien välillä. Jakeluinstanssi isännöi jakelutietokantaa, joka tallentaa replikoinnin metatiedot ja tapahtumat.
Tilaaja: Tilaaja on SQL Server instanssi, joka vastaanottaa ja tallentaa replikoitua dataa julkaisijoilta. Yksi tilaajainstanssi voi isännöidä useita tilaajatietokantoja, joista jokainen vastaanottaa dataa eri julkaisuista.
julkaistu: Julkaisu määrittelee, mitä tietoja replikoidaan ja miten ne jaetaan tilaajille. Se ryhmittelee toisiinsa liittyvät artikkelit yhteen ja määrittää replikointimenetelmän, jota sovelletaan kaikkiin sisällytettyihin objekteihin.
Artikla: Artikkeli on replikoinnin perusrakenneosa, joka edustaa yksittäistä tietokantaobjektia, joka jaetaan tilaajille.
Rekisteröityminen: Tilaus määrittää julkaisun ja tilaajan välisen suhteen ja määrittää, miten ja milloin tiedot toimitetaan kohdetietokantaan.
agents: Agentit ovat erikoistuneita prosesseja, jotka suorittavat varsinaisen työn eli tiedon siirtämisen ja synkronoinnin replikointikomponenttien välillä.

3. Tyypit SQL Server replikointi

SQL Server tarjoaa useita replikointityyppejä, joista jokainen on suunniteltu tiettyihin tiedonjakeluskenaarioihin ja liiketoimintavaatimuksiin. Kunkin tyypin ominaisuuksien, etujen ja rajoitusten ymmärtäminen on olennaista oikean lähestymistavan valitsemiseksi ympäristöösi.

3.1 Tilannevedoksen replikointi

Tilannevedoksen replikointi ottaa tilannevedoksen julkaistavasta datasta tiettynä ajankohtana ja jakaa sitten täydellisen kopion tilaajille. Se ei valvo myöhempiä muutoksia ennen kuin seuraava tilannevedos on luotu. Tilannevedoksen replikointi on yksinkertaisin replikointimuoto, joten se sopii tilanteisiin, joissa data muuttuu harvoin tai joissa hieman vanhentuneen datan käyttö on hyväksyttävää.

Yleisiä käyttötapauksia ovat viitetietojen, kuten hinnastojen tai valuuttakurssien, jakaminen säännöllisesti päivittyvinä, alustavien tietojoukkojen tarjoaminen tietovarastoille ja tilanteet, joissa täydellinen tietojen päivitys on parempi kuin yksittäisten muutosten seuraaminen. Esimerkiksi yritys voi käyttää tilannevedosten replikointia jakaakseen päivitetyt tuoteluettelot sivukonttoreille kerran päivässä.

Tilannevedosten replikoinnin tärkeimmät edut ovat sen yksinkertaisuus, vähäinen ylläpitovaatimus ja kyky replikoida tietoja ilman ensisijaisia avaimia. Sillä on kuitenkin merkittäviä haittoja, kuten suuri vaikutus tilannevedosten luomiseen taulukkolukkojen vuoksi, suuri viive päivitysten välillä ja tehottomuus suurten tietojoukkojen tai usein muuttuvan tiedon käsittelyssä. Tilaajille tehdyt muutokset menetetään, kun seuraava tilannevedos otetaan käyttöön.

3.2 Transaktionaalinen replikointi

Transaktioiden replikointi toimittaa muutokset julkaisijalta tilaajille lähes reaaliajassa replikoimalla yksittäisiä tapahtumia niiden tapahtuessa. Se alkaa alustavalla tilannevedoksella lähtötilanteen määrittämiseksi, minkä jälkeen se seuraa jatkuvasti tapahtumalokia julkaistujen artikkeleiden muutosten varalta ja toimittaa ne tilaajille vähitellen.

Transaktioreplikointi on ihanteellinen palvelinten välisiin skenaarioihin, jotka vaativat suurta läpimenoaikaa ja pientä viivettä. Yleisiä käyttötapauksia ovat skaalautuvuuden ja saatavuuden parantaminen siirtämällä lukutoimintoja tilaajapalvelimille, tietovarastoinnin ja raportoinnin tukeminen lähes reaaliaikaisella tiedolla, useiden toimipisteiden tietojen integrointi keskitettyyn sijaintiin ja eräkäsittelyn siirtäminen dedikoiduille palvelimille. Esimerkiksi verkkokauppa-alusta voi käyttää transaktioreplikointia synkronoitujen varastotietojen ylläpitämiseen alueellisissa tietokannoissa.

Transaktioreplikaation etuja ovat pieni viive tiedonsiirrossa, korkea läpimenoaika suurilla tapahtumamäärillä ja mahdollisuus tehdä replikoimattomia muutoksia tilaajien luona. Haittoja ovat suurempi monimutkaisuus tilannevedosreplikaatioon verrattuna, replikoitujen taulukoiden ensisijaisten avainten vaatimus ja replikaation katkeamisen mahdollisuus, jos tilaajien luona esiintyy ristiriitoja, kuten ensisijaisten avainten rikkomuksia.

3.3 Yhdistämisen replikointi

Yhdistämisen replikointi on suunniteltu erityisesti ympäristöihin, joissa tilaajien on työskenneltävä offline-tilassa tai satunnaisella yhteydellä ja synkronoitava muutokset, kun yhteys on käytettävissä. Tämä replikointityyppi mahdollistaa tietojen muuttamisen sekä julkaisijan että tilaajien osalta erikseen, muutosten seurannan triggerien ja metatietotaulukoiden avulla sekä muutosten automaattisen yhdistämisen synkronoinnin aikana.

Yhdistettyjen järjestelmien replikointi on suunniteltu mobiilisovelluksille ja hajautetuille palvelinympäristöille, joissa tapahtuu itsenäisiä muutoksia. Käyttötapauksia ovat myyntivoiman automatisointi, jossa mobiilikäyttäjät työskentelevät offline-tilassa ja synkronoivat tiedot myöhemmin, itsenäisesti toimivat kassajärjestelmät, jotka yhdistävät tietoja säännöllisesti, sekä hajautetut sovellukset, joissa useiden toimipisteiden on päivitettävä jaettuja tietoja. Esimerkiksi vähittäiskauppaketju voi käyttää yhdistävien järjestelmien replikointia, jotta jokainen myymälä voi hallita paikallista varastoa samalla kun se synkronoituu keskusvarastojärjestelmän kanssa.

Yhdistämisen replikoinnin etuihin kuuluvat tuki itsenäisille tilaajille, jotka voivat tehdä muutoksia, ajoittaisen verkkoyhteyden sietokyky ja joustava ristiriitojen ratkaisu. Haittoja ovat monimutkaisempi asennus ja ylläpito, suorituskyvyn lisäkustannukset metatietojen ja käynnistimien seurannasta, yksilöllisten tunnisteiden sarakkeiden lisääminen taulukoihin sekä mahdolliset ristiriidat, jotka vaativat hallintaa ja ratkaisua.

3.4 Vertaisverkon replikointi

Vertaisreplikointi perustuu transaktioreplikointiin ja mahdollistaa useiden palvelininstanssien (kolme tai useampia solmuja) toiminnan tasavertaisina vertaisina, jolloin jokainen solmu toimii samanaikaisesti sekä julkaisijana että tilaajana. Tässä topologiassa kaikki solmut ylläpitävät identtisiä kopioita tiedoista ja voivat käsitellä sekä luku- että kirjoitustoimintoja, mikä tarjoaa aidosti hajautetun moni-isäntäympäristön.

Vertaisverkkoreplikointi sopii sovelluksiin, jotka vaativat lukutoimintojen skaalautumista ja korkeaa käytettävyyttä. Käyttötapauksia ovat verkkosovellukset, jotka jakavat luettelokyselyitä useille solmuille säilyttäen samalla yhdenmukaisen datan, skenaariot, jotka vaativat ylläpitoa tai päivityksiä ilman käyttökatkoksia ottamalla solmut offline-tilaan yksi kerrallaan, ja globaalit sovellukset, joiden datakeskukset sijaitsevat eri alueilla. Esimerkiksi maailmanlaajuinen ohjelmistotukiorganisaatio voi käyttää vertaisverkkoreplikointia eri aikavyöhykkeillä sijaitsevien toimistojen välillä, jotta jokaisella sijainnilla on paikallinen pääsy ajankohtaisiin tietoihin.

Vertaisverkon replikoinnin etuihin kuuluvat parantunut lukuteho skaalautumisen ansiosta, korkeampi saatavuus useiden aktiivisten solmujen kanssa ja lähes reaaliaikainen datan yhdenmukaisuus. Haittoja ovat Enterprise Editionin vaatimus, monimutkainen monisolmuisten topologioiden hallinta, identtisten skeemojen ja datan tarve kaikissa solmuissa sekä mahdolliset konfliktit, kun kirjoitusoperaatioita ei ole osioitu oikein.

3.5 Kaksisuuntainen replikointi

Kaksisuuntainen replikointi on erityinen transaktioreplikointitopologia, joka on suunniteltu erityisesti kahden palvelimen ympäristöihin, joissa molempien palvelimien on vaihdettava muutoksia keskenään. Kumpikin palvelin julkaisee tietoja ja tilaa samat tiedot toiselta palvelimelta, mikä luo yksinkertaisen kaksisuuntaisen synkronointityönkulun. Vaikka vertaisreplikointi voi myös tukea kahta solmua, kaksisuuntainen replikointi tarjoaa paremman suorituskyvyn tässä nimenomaisessa tilanteessa.

Kaksisuuntainen replikointi sopii tilanteisiin, joissa tarvitaan kaksi aktiivista palvelinta synkronoiduilla tiedoilla, kuten aktiivinen-aktiivinen-kokoonpanoissa korkean käytettävyyden saavuttamiseksi tai maantieteellisesti hajautetuissa sovelluksissa, joissa jokainen sijainti tarvitsee paikallisen kirjoitusoikeuden. Topologia vaatii huolellista sovellussuunnittelua tietojen päivitysten osittamiseksi ja konfliktien estämiseksi.

Etuihin kuuluvat optimoitu suorituskyky kahden palvelimen skenaarioissa, yksinkertaisempi konfigurointi vertaisverkkoreplikointiin verrattuna, lähes reaaliaikainen synkronointi ja alhaisempi yleiskulutus kuin yhdistämisreplikoinnissa. Haittoihin kuuluvat rajoitus kahteen palvelimeen, huolellista sovellussuunnittelua vaativan sisäänrakennetun konfliktinratkaisun puute ja asianmukaisten osiointistrategioiden tarve konfliktien estämiseksi.

3.6 Päivitettävät tilaukset

Päivitettävät tilaukset laajentavat transaktioreplikaatiota siten, että tilaajat voivat tehdä satunnaisia muutoksia replikoituun dataan, jotka sitten leviävät takaisin julkaisijalle ja muille tilaajille. Toisin kuin yhdistämisreplikaatio tai vertaisverkkojen topologiat, jotka on suunniteltu usein tapahtuviin kaksisuuntaisiin päivityksiin, päivitettävät tilaukset on tarkoitettu tilanteisiin, joissa ensisijainen tiedonkulku on yksisuuntainen (julkaisijalta tilaajille), mutta tilaajien on toisinaan tehtävä korjauksia tai päivityksiä.

Päivitettävät tilaukset sopivat tilanteisiin, joissa useimmat päivitykset tapahtuvat julkaisijan luona, mutta satunnaisia päivityksiä tarvitaan tilaajien luona, kuten kenttätoimistoissa, jotka ensisijaisesti lukevat tietoja, mutta joiden on tehtävä paikallisia korjauksia tai päivityksiä. Topologia vaatii huolellista suunnittelua ristiriitojen minimoimiseksi ja tietojen yhtenäisyyden varmistamiseksi.

Tärkeimpiä etuja ovat rajoitettujen kirjoitustoimintojen salliminen tilaajille samalla, kun transaktionaalisen replikoinnin suorituskykyominaisuudet säilyvät. Haittoja ovat lisääntynyt monimutkaisuus, ratkaisua vaativien konfliktien mahdollisuus, kaksivaiheisen vahvistusprotokollan aiheuttama suorituskykylisä välittömässä päivitystilassa ja vaatimus, että kaikilla replikoiduilla taulukoilla on oltava ensisijaiset avaimet.

3.7 Erilaisten replikaatiotyyppien vertailu

Replikointityyppi	Päivitysaika	Julkaisijoiden määrä	Suunta	Käytä skenaarioita
Kuva	Ajankohta	1	Yksi suunta (Julkaisija → Tilaajat)	Harvoin muuttuvat viitetiedot (hinnastot, valuuttakurssit)
kaupallisen	Lähes reaaliaikainen	1	Yksi suunta (Julkaisija → Tilaajat)	Suuren läpimenon skenaariot (verkkokaupan varasto, tietovarastointi, raportointi)
mennä	Säännöllinen (kun yhteys on muodostettu)	1	Kaksisuuntainen (julkaisija ↔ tilaajat)	Mobiilisovellukset, offline-työntekijät (myyntivoiman automatisointi, kenttäpalvelut)
Peer-to-Peer	Lähes reaaliaikainen	Useita (3 tai enemmän)	Kaksisuuntainen (kaikki solmut)	Globaalit usean datakeskuksen käyttöönotot (toimistot eri puolilla maailmaa, joilla on paikallinen luku- ja kirjoitusoikeus)
Kaksisuuntainen	Lähes reaaliaikainen	2	Kaksisuuntainen (molemmat palvelimet)	Kahden datakeskuksen aktiivinen-aktiivinen-kokoonpanot (kahden sijainnin korkea käytettävyys)
Päivitettävät tilaukset	Lähes reaaliaikainen	1	Pääasiassa yhteen suuntaan (satunnaisia käänteisiä päivityksiä)	Sivutoimistot, jotka pääasiassa lukevat, mutta päivittävät toisinaan (paikalliset korjaukset)

4. Asennus SQL Server replikointi

4.1 Edellytykset ja vaatimukset

4.1.1 Ohjelmistovaatimukset

SQL Server replikointi vaatii yhteensopivan SQL Server versioita kaikissa topologian osallistujissa. Jakelijan version on oltava yhtä suuri tai uudempi kuin julkaisijan versio, ja tilaajalla voi olla kaksi versiota julkaisijasta. Esimerkiksi SQL Server Vuoden 2016 kustantaja voi kopioida SQL Server Vuosien 2012, 2014, 2016, 2017 tai 2019 tilaajat.

4.1.2 Lupavaatimukset

Replikoinnin määrittäminen vaatii tiettyjä käyttöoikeuksia kullakin tasolla. Järjestelmänvalvojan kiinteän palvelimen roolin jäsenet voivat suorittaa kaikki replikoinnin määritystehtävät. Tarkempien käyttöoikeuksien saamiseksi käyttäjien on oltava db_owner-tietokannan roolin jäseniä julkaisijan ja tilaajan tietokannoissa.

4.2 Vaihe 1: Jakelun määrittäminen

Jakelun määrittäminen on ensimmäinen vaihe asennuksessa SQL Server replikointi.

Jakelun määrittäminen käyttämällä SQL Server Management Studio:

Yhdistä SQL Server esimerkiksi SQL Server ManagementStudio.
Napsauta hiiren kakkospainikkeella Objektienhallinnassa replikointi kansio ja valitse Jakelun määrittäminen.
Napsauta ohjatussa jakelun määrittämistoiminnossa seuraava tervetulosivulla.
On Jakelija -sivulla jokin seuraavista vaihtoehdoista topologiavaatimustesi perusteella:
- Paikallinen jakelijaValitse ”PalvelimenNimi toimii omana jakelijanaan”. SQL Server luo jakelutietokannan ja lokin”, jos haluat julkaisijan ja jakelijan toimivan samassa instanssissa (nykyisessä instanssissa). Tämä kokoonpano on yksinkertaisempi asentaa ja sopii pienempiin ympäristöihin tai tilanteisiin, joissa julkaisijan ja jakelijan välinen verkon viive aiheuttaisi ongelmia.
- EtäjakelijaValitse ”Käytä seuraavaa palvelinta jakelijana” ja napsauta Lisää määrittääksesi etäjakelijapalvelimen, jos haluat siirtää jakelun käsittelyn erilliseen instanssiin. Tämä määritys parantaa suorituskykyä, kun replikointimäärät ovat suuria, jakamalla työkuorman useille palvelimille. Sinun on annettava etäjakelijan nimi ja määritettävä salasana, jota julkaisija käyttää yhteyden muodostamiseen jakelijaan.
Napauta seuraava määrittääksesi tilannevedoksen kansion sijainnin. Käytä UNC-polkua (kuten \\palvelimennimi\jako\kansio) paikallisen polun sijaan varmistaaksesi käytettävyyden verkossa.
On Jakelutietokanta -sivulla oletusarvoinen jakelutietokannan nimi (yleensä ”jakelu”) tai määritä mukautettu nimi ja määritä sitten tietojen ja lokitiedostojen sijainnit.
On Publishers -sivulla, että nykyinen palvelin on otettu käyttöön julkaisijana. Jos määrität nykyisen palvelimen jakelijaksi, voit lisätä muita julkaisijoita, jotka käyttävät tätä jakelijaa.
Tarkista ohjatun ohjatun toiminnon toiminnot ja napsauta Suorittaa loppuun jakelun määrittämiseksi.

4.3 Vaihe 2: Julkaisun luominen

Jakelun määrittämisen jälkeen seuraava vaihe on luoda julkaisu, joka määrittää, mitkä dataobjektit replikoidaan tilaajille.

Julkaisun luominen käyttämällä SQL Server Management Studio:

Laajenna Objektienhallinnassa replikointi kansio.
Napsauta hiiren kakkospainikkeella Paikalliset julkaisut ja valitse Uusi julkaisu.
Uuden julkaisun ohjattu luonti käynnistyy; napsauta seuraava tervetulosivulla.
Valitse julkaistavaksi haluamasi tietokanta valikosta Julkaisutietokanta sivu. Tämä mahdollistaa automaattisesti julkaisemisen valitussa tietokannassa.
On Julkaisutyyppi sivulla, valitse replikointityyppi: Snapshot-julkaisu, Transaktiojulkaisu, Vertaisverkkojulkaisutai Yhdistä julkaisu.
On Artikkeli sivu, laajenna taulukot solmu ja valitse artikkeleiksi sisällytettävät taulukot.
Laajenna halutessasi tallennettuja, Näyttökerrattai muita objektityyppejä lisäartikkeleiden lisäämiseksi.
Napauta Artikkelin ominaisuudet suodatuksen tai muiden artikkelikohtaisten asetusten määrittämiseksi.
On Suodata taulukon rivit sivulla, lisää tarvittaessa rivisuodattimia.
On Tilannevedosagentti -sivulla voit valita, milloin tilannekuva luodaan: välittömästi, tiettynä ajankohtana tai aikataulun mukaisesti.
On Agentin turvallisuus -sivulla Snapshot Agentin suojauskonteksti.
On Velhon toiminnot sivu, valitse Luo julkaisu.
Anna julkaisun nimi ja napsauta Suorittaa loppuun.

4.4 Vaihe 3: Luo tilaus

Julkaisun luomisen jälkeen seuraava vaihe on luoda tilauksia, jotka yhdistävät julkaisun tilaajatietokantoihin.

Tilaukset voivat olla push-tilauksia (joita hallinnoi jakelija) tai pull-tilauksia (joita hallinnoi tilaaja). Keskeiset erot ovat paikka, jossa luot tilauksen, ja valitsemasi agentin sijainti, mikä määrää tilauksen toiminnon (push- tai pull-tilaus).

Push-tilausta varten (jakelijan hallinnoima):

On kustantaja palvelin, laajenna replikointi -> Paikalliset julkaisut.
Napsauta julkaisua hiiren kakkospainikkeella ja valitse Uudet tilaukset.

Pull-tilausta varten (Tilaajan hallinnoima):

On tilaaja palvelin, laajenna replikointi, oikealla painikkeella Paikalliset tilaukset, ja valitse Uudet tilaukset.
On Julkaisu -sivulla Löytää SQL Server julkaisija ja muodosta yhteys julkaisijan palvelimeen.

Yhteiset ohjatun toiminnon vaiheet molemmille tilaustyypeille:

Napsauta Uusi tilaus -ohjauksessa seuraava tervetulosivulla.
Valitse julkaisu ja napsauta seuraava.
On Jakeluagentin sijainti sivulla, valitse agentin sijainti:
- Push-tilausValitse ”Suorita kaikki agentit jakelijan luona” – jakelija lähettää muutokset tilaajille.
- Pull-tilausValitse ”Suorita jokainen agentti sen tilaajalla” – jokainen tilaaja hakee muutokset jakelijalta.
On tilaajat sivulla, valitse olemassa olevat tilaajapalvelimet tai napsauta Lisää tilaaja lisätäksesi uusia.
Valitse kullekin tilaajalle kohdetietokanta tai luo uusi tietokanta. Huomautus: Tilaustietokannan on oltava eri kuin julkaisijan tietokanta, vaikka käytettäisiin samaa SQL Server ilmentymä.
On Jakeluagentin turvallisuus -sivulla napsauta kunkin tilauksen ominaisuuspainiketta määrittääksesi suojauskontekstin.
On Synkronointiaikataulu -sivulla valitse jatkuva synkronointi tai ajoitettu synkronointi.
On Alusta tilaukset sivu, valitse Heti alustaa ohjatun toiminnon valmistumisen aikana tai Ensimmäisellä synkronoinnilla.
Tarkista ohjatun ohjatun toiminnon toiminnot ja napsauta Suorittaa loppuun.

5. Seuranta ja hallinta SQL Server replikointi

5.1 Replikaation valvonta Replication Monitorilla

Replikoinnin valvonnan käynnistäminen:

In SQL Server Management Studio, laajenna replikointi Objektienhallinnassa.
Napsauta hiiren kakkospainikkeella replikointi ja valitse Käynnistä replikoinnin valvonta.
Jos kustantajia ei ole rekisteröity, napsauta Lisää julkaisija vasemmanpuoleisessa ruudussa.
Valita Lisää SQL Server julkaisija ja muodosta yhteys julkaisijan palvelimeen.
Julkaisija näkyy vasemmassa ruudussa, ja siinä on laajennettavat solmut julkaisuille ja tilauksille.

5.2 Suorituskyvyn seuranta

5.2.1 Näytön latenssi

Replikoinnin latenssi on aikaviive julkaisijan luona tapahtuvan muutoksen ja tilaajan luona tapahtuvan muutoksen välillä. Seuraa latenssia varmistaaksesi, että datan tuoreus vastaa liiketoiminnan vaatimuksia.

Käytä Replikoinnin valvontaa tarkastellaksesi latenssimittareita Kaikki tilaukset -välilehdellä. Latenssi-sarake näyttää keskimääräisen latenssin sekunteina. Transaktioiden replikoinnissa jäljitystunnukset tarjoavat tarkkoja latenssimittauksia lisäämällä merkkitapahtumia, joita seurataan replikointiputken läpi.

Jäljitystunnusten käyttö:

Valitse Replication Monitorissa transaktiojulkaisu.
Valitse Tracer-tokenit Tab.
Napauta Lisää merkki injektoida markkeritapahtuma.
Seuraa tokenia sen matkalla julkaisijalta jakelijalle ja tilaajalle.
Tarkastele kunkin segmentin pullonkaulojen tunnistamiseen kuluvaa aikaa.

5.2.2 Näytön läpimenonopeus

Läpivirtaus mittaa ajan kuluessa replikoidun datan määrää, joka tyypillisesti ilmaistaan tapahtumina sekunnissa tai komentoina sekunnissa. Seuraa läpivirtausta varmistaaksesi, että replikointi pysyy julkaisijan toiminnan tahdissa.

Vaikka replikoinnin valvonta näyttää synkronoinnin perustilan, toimitusnopeus ja yksityiskohtaiset läpäisykyvyn mittarit eivät näy graafisessa käyttöliittymässä. Käytä T-SQL-kyselyitä jakelutietokantaa vastaan läpäisykyvyn valvontaan:

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

Tilakoodit: 1 = Aloitettu, 2 = Keskeneräinen, 3 = Onnistui, 4 = Vapaa, 5 = Uudelleenyritys, 6 = Epäonnistui. Vertaa toimitusnopeutta julkaisijan tapahtumanopeuksiin tunnistaaksesi tilanteet, joissa replikointi on jäänyt jälkeen. Suorituskykylaskurit Windowsin suorituskyvyn valvonta tarjota lisää läpäisykyvyn mittareita kullekin replikointiagentille.

5.2.3 Tunnista pullonkaulat

Replikoinnin pullonkauloja voi esiintyä useissa kohdissa topologiassa. Julkaisijalla liian pitkä tilannevedoksen luontiaika tai lokinlukija-agentin viiveet voivat viitata resurssirajoituksiin. Valvo julkaisijan suorittimen, muistin ja levyn I/O:n käyttöä replikoinnin aikana.

Tarkista jakelijan luona kertyvät tapahtumat jakelutietokannassa. Suuri määrä jakamattomia komentoja osoittaa, että jakelija ei pysty pysymään toimituksen vauhdissa. Valvo jakelijan palvelinresursseja ja harkitse erillisen etäjakelijan käyttöä suurten volyymien tilanteissa.

Tilaajalla muutosten hidas käyttöönotto voi johtua riittämättömistä resursseista, puuttuvista indekseistä tai rajoituksista, jotka hidastavat lisäystoimintoja. Valvo tilaajan resurssien käyttöä ja kyselyiden suorituskykyä, kun jakeluagentti on käynnissä. Myös komponenttien väliset verkon kaistanleveyden rajoitukset aiheuttavat pullonkauloja, erityisesti suurilla tietomäärillä.

5.3 Replikointiagenttien hallinta

5.3.1 Käynnistä- ja pysäytysagentit

Replikointiagentin käynnistäminen tai pysäyttäminen:

In SQL Server Management Studio, laajenna SQL Server Agentti -> Työpaikat.
Paikanna replikointiagenttityö (nimet sisältävät yleensä julkaisun ja tilaajatiedot).
Napsauta työtehtävää hiiren kakkospainikkeella ja valitse Aloita työ or Lopeta työ.

5.3.2 Agenttiprofiilien määrittäminen

Agenttiprofiilit sisältävät parametrijoukkoja, jotka ohjaavat agentin toimintaa. SQL Server tarjoaa yleisiin tilanteisiin optimoituja oletusprofiileja, ja voit luoda mukautettuja profiileja tiettyihin tarpeisiin.

Agenttiprofiilien muokkaaminen:

Laajenna Objektienhallinnassa replikointi.
Napsauta hiiren kakkospainikkeella replikointi ja valitse Jakelijan ominaisuudet.
Valitse Profiilin oletusasetukset painiketta.
Valitse agentin tyyppi (tilannevedos, lokinlukija, jakelu tai yhdistäminen) avattavasta valikosta.
Valitse profiili ja napsauta Kiinteistöt parametriarvojen tarkastelemiseksi.
Napauta Uusi profiili luodaksesi mukautetun profiilin olemassa olevan perusteella.
Muokkaa parametreja tarpeen mukaan ja napsauta OK.

Voit lisätä profiilin agentille muokkaamalla tilauksen ominaisuuksia ja valitsemalla haluamasi profiilin Agenttiprofiili-alasvetovalikosta.

5.3.3 Agentin parametrit ja asetukset

Agentin parametrit hienosäätävät suorituskykyä ja toimintaa. Distribution Agentin keskeisiä parametreja ovat CommitBatchSize (kommenttia kohden käytettyjen tapahtumien määrä), CommitBatchThreshold (kommenttien määrä ennen committia), SubscriptionStreams (rinnakkaisyhteydet nopeampaa toimitusta varten) ja QueryTimeout (komentojen aikakatkaisu).

Lokilukuagentin tärkeitä parametreja ovat ReadBatchSize (luettujen tapahtumien määrä skannausta kohden), ReadBatchThreshold (komennot ennen toimitusta) ja PollingInterval (viive lokiskannausten välillä). Säädä näitä parametreja tapahtumien määrän ja viivevaatimusten perusteella.

5.4 Varmuuskopiointiin ja palautukseen liittyviä huomioitavia asioita

Replikointiin liittyvien tietokantojen varmuuskopiointi vaatii erityishuomioita. Julkaisijan tietokannan säännölliset täydelliset ja tapahtumalokien varmuuskopiot ovat välttämättömiä. Merkitse tietokannan varmuuskopiointi replikointitukea varten käyttämällä WITH REPLICATION -vaihtoehtoa, kun varmuuskopioit tietokantoja transaktionaalisessa replikoinnissa. Varmuuskopioi jakelutietokanta säännöllisesti replikointikokoonpanon suojaamiseksi.

Kun palautat julkaisijan tietokannan samalle palvelimelle samalla nimellä, käytä WITH KEEP_REPLICATION-asetusta replikoinnin tilan säilyttämiseksi. Tämä asetus varmistaa, että lokinlukuagentin vielä käsittelemättömät tapahtumat pysyvät merkittyinä replikointia varten, jolloin replikointi voi jatkua automaattisesti ilman tilausten uudelleenalustusta.

Katastrofien jälkeisissä palautustilanteissa, joissa varmuuskopiot eivät ole käytettävissä, ne ovat vioittuneet tai tietokantatiedostot ovat vaurioituneet, saatetaan tarvita erikoistuneita palautustyökaluja. DataNumen SQL Recovery voi poimia tietoja vioittuneista tai käyttökelvottomista MDF- ja NDF-tiedostoista, mikä tarjoaa viimeisenä keinona toimivan vaihtoehdon, kun tavalliset palautusmenetelmät epäonnistuvat.

Lisätietoja SQL Server varmuuskopio, katso kattava opas.

6. Usein kysytyt kysymykset (FAQ)

K: Mitä eroa on tilannekuvalla ja transaktionaalisella replikoinnilla?

A: Tilannevedosten replikointi ottaa täydellisen kopion tiedoista tiettynä ajankohtana ja soveltaa sitä tilaajaan, mikä sopii harvoin muuttuvalle tiedolle. Transaktioiden replikointi alkaa alustavasta tilannevedoksesta ja replikoi sitten jatkuvasti yksittäisiä tapahtumia niiden tapahtuessa, mikä tarjoaa lähes reaaliaikaisen synkronoinnin usein muuttuvalle tiedolle.

K: Voinko kopioida eri laitteiden välillä SQL Server versiot?

A: Kyllä, SQL Server replikointi tukee versioyhteensopivuutta rajoitetulla alueella. Jakelijan version on oltava yhtä suuri tai uudempi kuin julkaisijan versio, ja tilaajalla voi olla kaksi versiota julkaisijasta. Esimerkiksi, jos julkaisija on SQL Server Vuonna 2016 tilaaja voi olla SQL Server 2012, 2014, 2016, 2017 tai 2019.

K: Miten käsittelen ristiriitoja yhdistämisen replikoinnissa?

A: Yhdistämisen replikointi tarjoaa sisäänrakennettuja ristiriitojen havaitsemis- ja ratkaisumekanismeja. Voit määrittää ristiriitojen ratkaisijoita artikkelitasolla valitsemalla sisäänrakennettuja ratkaisijoita tai ottamalla käyttöön mukautettuja ristiriitojen ratkaisijoita. Ristiriidat ratkaistaan tyypillisesti prioriteettipohjaisilla tai aikaleimapohjaisilla menetelmillä, ja ristiriidat voidaan kirjata manuaalista tarkistusta varten.

K: Mitkä ovat replikoinnin suorituskykyvaikutukset?

A: Replikointi vaikuttaa suorituskykyyn monella tapaa: julkaisijalle aiheutuu lisäkustannuksia muutosten seurannasta ja tilannevedosten luomisesta, jakelija käyttää resursseja tapahtumien tallentamiseen ja välittämiseen, ja tiedonsiirron aikana kuluu verkon kaistanleveyttä. Vaikutus vaihtelee replikointityypin mukaan: tilannevedosten replikointi aiheuttaa ajoittain suuria kuormituspurskeita ja tapahtumien replikointi ylläpitää johdonmukaisempaa mutta jatkuvaa kuormitusta.

K: Miten suojaan replikointitopologiani?

A: Suojaa replikointitopologiasi ottamalla käyttöön useita parhaita käytäntöjä: käytä Windows-todennusta tai vahvaa SQL Server todennus, yhteyksien salaus TLS:llä, tilannevedoskansion suojaaminen asianmukaisilla NTFS käyttöoikeudet, määritä julkaisujen käyttöoikeusluettelo (PAL) käyttöoikeuksien hallintaa varten, käytä erillisiä palvelutilejä, joilla on kullekin replikointiagentille vaadittavat vähimmäiskäyttöoikeudet, ja tarkista replikoinnin suojausasetukset säännöllisesti.

K: Voinko replikoida Azure SQL -tietokantaan?

V: Kyllä, voit replikoida Azure SQL -tietokantaan käyttämällä transaktioreplikaatiota paikallisessa järjestelmässä. SQL Server tai Azure SQL Managed Instance julkaisijana ja jakelijana. Azure SQL Database voi toimia tilaajana, mutta ei julkaisijana tai jakelijana. Yhdistämisreplikointia ja vertaisreplikointia ei tueta Azure SQL Databasessa.

K: Miten voin seurata replikoinnin viivettä?

A: Tarkkaile replikoinnin viivettä replikoinnin valvonnalla SQL Server Management Studio, joka näyttää kunkin tilauksen latenssimittarit. Voit myös tehdä kyselyitä jakelutietokannan taulukoista, kuten MSdistribution_history ja MSrepl_commands, käyttää replikointiagenttien erityisiä suorituskykylaskureita tai määrittää hälytyksiä latenssikynnysten perusteella synkronointiviiveiden ennakoivaan havaitsemiseen ja korjaamiseen.

K: Mitä tapahtuu, kun tilaaja on offline-tilassa?

A: Kun tilaaja on offline-tilassa, toiminta riippuu replikointityypistä. Transaktioreplikoinnissa tapahtumat kerääntyvät jakelutietokantaan, kunnes tilaaja palaa online-tilaan, minkä jälkeen synkronointi jatkuu. Yhdistämisreplikoinnissa muutoksia seurataan molemmilla puolilla ja yhdistetään, kun yhteys palautuu. Säilytysajan asetus määrittää, kuinka kauan tietoja säilytetään ennen kuin ne on alustettava uudelleen.

K: Miten lisään uusia artikkeleita olemassa olevaan julkaisuun?

A: Lisää uusia artikkeleita olemassa olevaan julkaisuun käyttämällä SQL Server Management Studiossa voit muokata julkaisun ominaisuuksia ja valita lisää objekteja tai käyttää sp_addarticle-tallennettua proseduuria. Kun olet lisännyt artikkelit, luo uusi tilannekuva ja alusta kaikki tilaukset uudelleen varmistaaksesi, että tilaajat vastaanottavat uudet artikkelit. Jotkin muutokset saattavat edellyttää tilauksen uudelleenalustusta julkaisuasetuksista riippuen.

K: Miten poistan replikoinnin tietokannasta?

A: Poista replikointi tietokannasta poistamalla ensin kaikki tilaukset käyttämällä sp_dropsubscription-metodia, poistamalla sitten julkaisu käyttämällä sp_droppublication-metodia ja lopuksi poistamalla julkaisu käytöstä tietokannassa käyttämällä sp_replicationdboption-metodia. Jos palvelin on jakelija, poista jakelu käytöstä käyttämällä sp_dropdistributor-metodia. Varmuuskopioi aina tietokannat ennen replikointimääritysten poistamista.

K: Mitä eroa on SQL Server Replikointi ja AlwaysOn-käytettävyysryhmät?

A: Replikointi on objektitasolla toimiva tiedon jakelu- ja integrointiratkaisu, Aina käytettävissä olevat ryhmät on korkean käytettävyyden ja katastrofien jälkeisen palautumisen ratkaisu, joka toimii tietokantatasolla.

7. Päätelmä

SQL Server Replikointi tarjoaa vankan kehyksen tiedon jakamiseen ja synkronointiin useiden tietokantojen ja sijaintien välillä. Teknologia tukee erilaisia skenaarioita erilaisten replikointityyppien kautta.

Oikean replikointistrategian valinta riippuu erityisvaatimuksistasi. Ota huomioon datan muutostiheys, latenssivaatimukset, tilaajien päivitysten tarve, verkon ominaisuudet ja tilaajien autonomian tarpeet. Tilannevedosten replikointi toimii parhaiten harvoin muuttuville viitetiedoille, joissa latenssi ei ole kriittinen. Transaktioreplikointi sopii suuren volyymin skenaarioihin, jotka vaativat matalaa latenssia ja ensisijaisesti yksisuuntaista datavirtaa.

Valitse yhdistämisreplikointi, kun tilaajat tarvitsevat itsenäistä toimintaa offline-ominaisuuksilla ja kaksisuuntaisella synkronoinnilla. Toteuta vertaisverkkoreplikointi kuormituksen tasaamiseksi lukutoiminnoissa useiden aktiivisten solmujen välillä lähes reaaliaikaisesti yhdenmukaisesti. Harkitse hybridilähestymistapoja, jotka yhdistävät useita replikointityyppejä monimutkaisissa skenaarioissa, joissa on vaihtelevia vaatimuksia.

Viitteet

kirjailijasta

Yuan Sheng on kokenut tietokannan ylläpitäjä (DBA), jolla on yli 10 vuoden kokemus alalta SQL Server ympäristöissä ja yritystietokantojen hallinnassa. Hän on onnistuneesti ratkaissut satoja tietokantojen palautustilanteita rahoituspalveluissa, terveydenhuollossa ja valmistusorganisaatioissa.

Yuan on erikoistunut SQL Server tietokannan palautus, korkean käytettävyyden ratkaisut ja suorituskyvyn optimointi. Hänen laajaan käytännön kokemukseensa kuuluu usean teratavun tietokantojen hallinta, Always On Availability Groupsin käyttöönotto sekä automatisoitujen varmuuskopiointi- ja palautusstrategioiden kehittäminen kriittisille liiketoimintajärjestelmille.

Teknisen asiantuntemuksensa ja käytännönläheisen lähestymistapansa avulla Yuan keskittyy luomaan kattavia oppaita, jotka auttavat tietokannan ylläpitäjiä ja IT-ammattilaisia ratkaisemaan monimutkaisia ongelmia. SQL Server haastaa tehokkaasti. Hän pysyy ajan tasalla uusimmista SQL Server julkaisuja ja Microsoftin kehittyviä tietokantateknologioita, testaten säännöllisesti palautusskenaarioita varmistaakseen, että hänen suosituksensa vastaavat todellisia parhaita käytäntöjä.

Onko sinulla kysyttävää SQL Server palautus tai tarvitsetko lisäohjeita tietokannan vianmääritykseen? Yuan toivottaa sinut tervetulleeksi palautetta ja ehdotuksia näiden teknisten resurssien parantamiseksi.