SQL Server Replikasyon: Kumpletong Gabay para sa DBA [2026]

SQL Server Ang replikasyon ay isang hanay ng mga teknolohiya para sa pagkopya at pamamahagi ng data at mga bagay sa database mula sa isang database patungo sa isa pa, pagkatapos ay pag-synchronize sa pagitan ng mga database upang mapanatili ang pagkakapare-pareho. Ang tampok na ito ay nagbibigay-daan sa iyong lumikha at magpanatili ng maraming kopya ng iyong data sa iba't ibang mga server at lokasyon, na tinitiyak ang pagkakaroon at pagiging maaasahan ng data.

1.2 Layunin at mga Benepisyo ng Replikasyon

SQL Server Ang replikasyon ay nagsisilbi sa maraming kritikal na pangangailangan sa negosyo at nagbibigay ng mga makabuluhang bentahe para sa pamamahala ng database at pamamahagi ng data:

Pamamahagi ng Datos sa Iba't Ibang Lokasyon: Ang replikasyon ay nagbibigay-daan sa iyo na magbahagi ng data sa mga rehiyonal na tanggapan o pandaigdigang lokasyon, na nagpapabuti sa kahusayan sa pagpapatakbo sa pamamagitan ng pagtiyak ng lokal na pag-access sa kinakailangang data. Binabawasan nito ang latency ng network at nagbibigay ng mas mahusay na pagganap para sa mga gumagamit na nakabahagi sa heograpiya.
Mataas na availability at Pagbangon Mula sa Sakuna: Sa pamamagitan ng pagpapanatili ng mga replika ng mahahalagang datos sa maraming server, ang replikasyon ay nagbibigay ng redundancy na nagpoprotekta laban sa mga pagkabigo at sakuna ng hardware. Sa kaso ng pagkabigo ng pangunahing server, ang mga replikadong kopya ay maaaring magsilbing mga fallback source, na nagpapaliit sa downtime at pagkawala ng datos.
Pagbabalanse ng Karga at Kakayahang Iskalahin: Ipinamamahagi ng replikasyon ang mga operasyon sa pagbasa sa maraming server, na pumipigil sa anumang server na maging isang bottleneck. Pinahuhusay ng pamamaraang ito ang pagganap ng system at nagbibigay-daan sa iyong imprastraktura na lumawak nang pahalang habang lumalaki ang data at mga pangangailangan ng user.
Real-Time na Pag-uulat at Analytics: Ang paglilipat ng mga query sa pag-uulat at analytics sa mga kinopyang server ay nakakabawas sa bigat ng mga database ng produksyon. Maaaring magpatakbo ang mga user ng mga kumplikadong analytical query laban sa halos real-time na data nang hindi naaapektuhan ang mga operational system, na tinitiyak ang parehong performance at pagiging bago ng data.
Pagsasama-sama at Pagsasama-sama ng Datos: Pinapadali ng replikasyon ang pagsasama-sama ng datos mula sa iba't ibang pinagmulan patungo sa iisang pinagsama-samang pananaw. Ito ay partikular na mahalaga para sa mga organisasyong may maraming sangay na tanggapan na kailangang pagsama-samahin ang datos sa punong-tanggapan, o para sa paglikha ng mga sentralisadong bodega ng datos mula sa mga distributed operational system.

2. SQL Server Arkitektura at mga Bahagi ng Replikasyon

SQL Server Ang arkitektura ng replikasyon ay binubuo ng ilang magkakaugnay na bahagi na nagtutulungan upang ipamahagi at i-synchronize ang data sa iyong imprastraktura ng database. Sinusuri ng seksyong ito ang mga pangunahing bahagi, kabilang ang mga publisher, distributor, subscriber, publikasyon, artikulo, subscription, at mga ahente na nag-uugnay sa daloy ng data sa pagitan nila:

Publisher: Ang isang tagapaglathala ay isang SQL Server halimbawa na hostIsa o higit pang mga database na naglalaman ng datos na gagayahin. Ito ay nagsisilbing awtoritatibong mapagkukunan sa topolohiya ng replikasyon.
Distributor: Ang isang distributor ay isang SQL Server isang pagkakataon na namamahala sa daloy ng datos sa pagitan ng mga publisher at subscriber. Ang pagkakataon ng distributor ayostang database ng distribusyon, na nag-iimbak ng metadata ng replikasyon at mga transaksyon.
Subscriber: Ang isang subscriber ay isang SQL Server instance na tumatanggap at nag-iimbak ng mga kinopyang data mula sa mga publisher. Ang isang subscriber instance ay maaaringost maraming database ng subscriber, na bawat isa ay tumatanggap ng datos mula sa iba't ibang publikasyon.
publication: Tinutukoy ng isang publikasyon kung anong datos ang rereplikahin at kung paano ito ipamamahagi sa mga subscriber. Pinagsasama-sama nito ang mga kaugnay na artikulo at itinatatag ang metodolohiya ng replikasyon na naaangkop sa lahat ng nakapaloob na bagay.
Artikulo: Ang isang artikulo ay ang pangunahing bloke ng pagbuo ng replikasyon, na kumakatawan sa isang indibidwal na bagay ng database na ipapamahagi sa mga subscriber.
subscription: Itinatatag ng isang subscription ang ugnayan sa pagitan ng isang publikasyon at isang subscriber, na tumutukoy kung paano at kailan inihahatid ang data sa database ng destinasyon.
Mga Ahente: Ang mga ahente ay mga espesyal na proseso na nagsasagawa ng aktwal na gawain ng paglipat at pag-synchronize ng data sa pagitan ng mga bahagi ng replikasyon.

3. Mga uri ng SQL Server Pagtitiklop

SQL Server ay nagbibigay ng ilang uri ng replikasyon, bawat isa ay idinisenyo para sa mga partikular na senaryo ng pamamahagi ng data at mga kinakailangan sa negosyo. Ang pag-unawa sa mga katangian, bentahe, at limitasyon ng bawat uri ay mahalaga para sa pagpili ng tamang pamamaraan para sa iyong kapaligiran.

3.1 Replikasyon ng Snapshot

Ang snapshot replication ay kumukuha ng snapshot ng data na ilalathala sa isang partikular na oras, pagkatapos ay ipinamamahagi ang eksaktong kumpletong kopya sa mga subscriber. Hindi nito sinusubaybayan ang mga kasunod na pagbabago hanggang sa mabuo ang susunod na snapshot. Ang snapshot replication ang pinakasimpleng anyo ng replication, kaya angkop ito para sa mga sitwasyon kung saan ang data ay madalang na nagbabago o kung saan katanggap-tanggap ang pagkakaroon ng medyo luma na data.

Kabilang sa mga karaniwang gamit ang pamamahagi ng mga sangguniang datos tulad ng mga listahan ng presyo o mga halaga ng palitan na pana-panahong nag-a-update, pagbibigay ng mga paunang dataset para sa mga bodega ng datos, at mga sitwasyon kung saan mas mainam ang kumpletong pag-refresh ng datos kaysa sa pagsubaybay sa mga indibidwal na pagbabago. Halimbawa, maaaring gamitin ng isang kumpanya ang snapshot replication upang mamahagi ng mga na-update na katalogo ng produkto sa mga sangay na tanggapan isang beses araw-araw.

Ang mga pangunahing bentahe ng snapshot replication ay ang pagiging simple nito, mababang pangangailangan sa pagpapanatili, at kakayahang kopyahin ang data nang walang primary keys. Gayunpaman, mayroon itong mga makabuluhang disbentaha kabilang ang mataas na epekto kapag ang mga snapshot ay nabuo dahil sa mga table lock, mataas na latency sa pagitan ng mga update, at kawalan ng kahusayan para sa malalaking dataset o madalas na nagbabagong data. Anumang mga pagbabago na ginawa sa mga subscriber ay lost kapag inilapat ang susunod na snapshot.

3.2 Replikasyon sa Transaksyon

Ang transactional replication ay naghahatid ng mga pagbabago mula sa publisher patungo sa mga subscriber nang halos real-time sa pamamagitan ng pagkopya ng mga indibidwal na transaksyon habang nangyayari ang mga ito. Nagsisimula ito sa isang paunang snapshot upang maitatag ang baseline, pagkatapos ay patuloy na sinusubaybayan ang transaction log para sa mga pagbabago sa mga nailathalang artikulo at unti-unting inihahatid ang mga ito sa mga subscriber.

Ang transactional replication ay mainam para sa mga sitwasyong server-to-server na nangangailangan ng mataas na throughput at mababang latency. Kabilang sa mga karaniwang gamit ang pagpapabuti ng scalability at availability sa pamamagitan ng paglilipat ng mga read operation sa mga subscriber server, pagsuporta sa data warehousing at pag-uulat gamit ang halos real-time na data, pagsasama ng data mula sa maraming site patungo sa isang sentral na lokasyon, at paglilipat ng batch processing sa mga dedicated server. Halimbawa, maaaring gumamit ang isang e-commerce platform ng transactional replication upang mapanatili ang naka-synchronize na data ng imbentaryo sa mga rehiyonal na database.

Kabilang sa mga bentahe ng transactional replication ang mababang latency data delivery, mataas na throughput para sa malalaking volume ng transaksyon, at ang kakayahang gumawa ng mga hindi kinokopyang pagbabago sa mga subscriber. Kabilang sa mga disbentahe ang mas mataas na pagiging kumplikado kumpara sa snapshot replication, ang pangangailangan para sa mga primary key sa mga kinokopyang talahanayan, at ang potensyal na masira ang replication kung sakaling magkaroon ng mga conflict tulad ng mga paglabag sa primary key sa mga subscriber.

3.3 Pagsasama ng Replikasyon

Ang merge replication ay partikular na idinisenyo para sa mga kapaligiran kung saan kailangang magtrabaho ang mga subscriber offline o may paulit-ulit na koneksyon, pagkatapos ay i-synchronize ang mga pagbabago kapag available ang koneksyon. Ang uri ng replication na ito ay nagbibigay-daan sa data na mabago sa parehong publisher at subscriber nang nakapag-iisa, sinusubaybayan ang mga pagbabago gamit ang mga trigger at metadata table, at awtomatikong pinagsasama ang mga pagbabago habang nag-synchronize.

Ang merge replication ay dinisenyo para sa mga mobile application at distributed server environment kung saan nagaganap ang mga autonomous na pagbabago. Kabilang sa mga use case ang sales force automation kung saan ang mga mobile user ay nagtatrabaho offline at nag-synchronize sa ibang pagkakataon, mga point-of-sale system na gumagana nang nakapag-iisa at nagsasama-sama ng data nang pana-panahon, at mga distributed application kung saan maraming site ang kailangang mag-update ng shared data. Halimbawa, maaaring gumamit ang isang retail chain ng merge replication upang mapamahalaan ng bawat tindahan ang lokal na imbentaryo habang nag-synchronize sa central warehouse system.

Kabilang sa mga bentahe ng merge replication ang suporta para sa mga autonomous subscriber na maaaring gumawa ng mga pagbabago, tolerance para sa intermittent network connectivity, at flexible conflict resolution. Kabilang sa mga disbentahe ang mas mataas na pagiging kumplikado sa pag-setup at pagpapanatili, performance overhead mula sa pagsubaybay sa metadata at mga trigger, ang pagdaragdag ng mga uniqueidentifier column sa mga table, at potensyal para sa mga conflict na nangangailangan ng pamamahala at resolusyon.

3.4 Replikasyon ng Peer-to-Peer

Ang peer-to-peer replication ay nakabatay sa transactional replication at nagbibigay-daan sa maraming server instance (tatlo o higit pang node) na kumilos bilang pantay na mga kapantay, kung saan ang bawat node ay nagsisilbing parehong publisher at subscriber nang sabay-sabay. Sa topology na ito, lahat ng node ay nagpapanatili ng magkaparehong kopya ng data at maaaring pangasiwaan ang parehong read at write operations, na nagbibigay ng isang tunay na distributed multi-master environment.

Ang peer-to-peer replication ay angkop para sa mga application na nangangailangan ng scale-out ng mga read operation at mataas na availability. Kabilang sa mga use case ang mga web application na namamahagi ng mga catalog query sa maraming node habang pinapanatili ang pare-parehong data, mga senaryo na nangangailangan ng maintenance o upgrade nang walang downtime sa pamamagitan ng pag-offline ng mga node nang paisa-isa, at mga pandaigdigang application na may mga data center sa iba't ibang rehiyon. Halimbawa, ang isang pandaigdigang organisasyon ng suporta sa software ay maaaring gumamit ng peer-to-peer replication sa mga opisina sa iba't ibang time zone upang ang bawat lokasyon ay may lokal na access sa kasalukuyang data.

Kabilang sa mga bentahe ng peer-to-peer replication ang pinahusay na read performance sa pamamagitan ng scale-out, mas mataas na availability na may maraming aktibong node, at halos real-time na data consistency. Kabilang sa mga disbentahe ang pangangailangan para sa Enterprise Edition, pagiging kumplikado sa pamamahala ng mga multi-node topology, ang pangangailangan para sa magkaparehong schema at data sa lahat ng node, at potensyal para sa mga conflict kapag ang mga write operation ay hindi maayos na nahati.

3.5 Replikasyon na Bidireksyonal

Ang bidirectional replication ay isang partikular na transactional replication topology na sadyang idinisenyo para sa mga two-server environment kung saan ang parehong server ay kailangang makipagpalitan ng mga pagbabago sa isa't isa. Ang bawat server ay nagpa-publish ng data at nag-subscribe sa parehong data mula sa kabilang server, na lumilikha ng isang simpleng two-way synchronization flow. Bagama't ang peer-to-peer replication ay maaari ring sumuporta sa dalawang node, ang bidirectional replication ay nagbibigay ng pinahusay na performance para sa partikular na senaryo na ito.

Angkop ang bidirectional replication para sa mga senaryo na nangangailangan ng dalawang aktibong server na may naka-synchronize na data, tulad ng mga active-active configuration para sa mataas na availability o mga application na ipinamahagi sa heograpiya kung saan ang bawat site ay nangangailangan ng lokal na write access. Ang topology ay nangangailangan ng maingat na disenyo ng application upang hatiin ang mga update ng data at maiwasan ang mga conflict.

Kabilang sa mga bentahe ang na-optimize na pagganap para sa mga senaryo ng two-server, mas simpleng configuration kumpara sa peer-to-peer replication, halos real-time synchronization, at mas mababang overhead kaysa sa merge replication. Kabilang sa mga disbentahe ang limitasyon sa eksaktong dalawang server, kawalan ng built-in na resolusyon ng conflict na nangangailangan ng maingat na disenyo ng application, at ang pangangailangan para sa wastong mga estratehiya sa partitioning upang maiwasan ang mga conflict.

3.6 Mga Naa-update na Subscription

Pinalalawak ng mga updateable subscription ang transactional replication upang payagan ang mga subscriber na gumawa ng paminsan-minsang mga pagbabago sa kinopyang data na pagkatapos ay ipapalaganap pabalik sa publisher at sa iba pang mga subscriber. Hindi tulad ng merge replication o peer-to-peer topology na idinisenyo para sa madalas na bidirectional updates, ang mga updateable subscription ay inilaan para sa mga senaryo kung saan ang pangunahing daloy ng data ay one-way (publisher papunta sa mga subscriber) ngunit paminsan-minsan ay kailangang gumawa ng mga pagwawasto o pag-update ang mga subscriber.

Ang mga naa-update na subscription ay angkop para sa mga sitwasyon kung saan most May mga update na nagaganap sa publisher ngunit kinakailangan ang paminsan-minsang mga update sa mga subscriber, tulad ng mga field office na pangunahing nagbabasa ng data ngunit kailangang gumawa ng mga lokal na pagwawasto o pag-update. Ang topolohiya ay nangangailangan ng maingat na pagpaplano upang mabawasan ang mga conflict at matiyak ang pagkakapare-pareho ng data.

Kabilang sa mga pangunahing bentahe ang pagpapahintulot sa limitadong mga operasyon sa pagsulat sa mga subscriber habang pinapanatili ang mga katangian ng pagganap ng transactional replication. Kabilang sa mga disbentahe ang pagtaas ng pagiging kumplikado, potensyal para sa mga conflict na nangangailangan ng resolusyon, performance overhead mula sa two-phase commit protocol sa agarang pag-update mode, at ang kinakailangan na ang lahat ng mga kinopyang talahanayan ay may mga pangunahing susi.

3.7 Paghahambing ng Iba't Ibang Uri ng Replikasyon

Uri ng Replikasyon	I-update ang Oras	Bilang ng Tagapaglathala	Direksyon	Gumamit ng Mga Eksena
Retrato	Ituro ang oras	1	Isang direksyon (Tagapaglathala → Mga Subscriber)	Madalang na pagbabago ng datos ng sanggunian (mga listahan ng presyo, mga halaga ng palitan)
Transactional	Malapit sa real-time	1	Isang direksyon (Tagapaglathala → Mga Subscriber)	Mga senaryo ng mataas na throughput (imbentaryo ng e-commerce, data warehousing, pag-uulat)
Pagsamahin	Pana-panahon (kapag nakakonekta)	1	Bidirectional (Tagapaglathala ↔ Mga Subscriber)	Mga mobile application, mga offline na manggagawa (automation ng sales force, mga serbisyo sa field)
Peer-to-Peer	Malapit sa real-time	Maramihan (3 o higit pa)	Bidirectional (lahat ng node)	Mga pandaigdigang pag-deploy ng multi-datacenter (mga tanggapan sa buong mundo na may lokal na read-write access)
Patawad	Malapit sa real-time	2	Bidirectional (parehong server)	Mga aktibong-aktibong configuration na may dalawang datacenter (mataas na availability ng dalawahang site)
Mga Naa-update na Subscription	Malapit sa real-time	1	Pangunahing isang direksyon (paminsan-minsang mga reverse update)	Mga sangay na pangunahing nagbabasa ngunit paminsan-minsang nag-a-update (mga lokal na pagwawasto)

4. Pag-set up SQL Server Pagtitiklop

4.1 Mga Kinakailangan at Paunang Kinakailangan

4.1.1 Mga Kinakailangan sa Software

SQL Server ang replikasyon ay nangangailangan ng tugmang SQL Server mga bersyon sa lahat ng kalahok sa topolohiya. Ang bersyon ng distributor ay dapat na katumbas o mas mataas kaysa sa bersyon ng publisher, at ang subscriber ay maaaring nasa loob ng dalawang bersyon ng publisher. Halimbawa, ang isang SQL Server Maaaring kopyahin ng publisher ng 2016 ang SQL Server Mga subscriber noong 2012, 2014, 2016, 2017, o 2019.

4.1.2 Mga Kinakailangan sa Pahintulot

Ang pag-configure ng replication ay nangangailangan ng mga partikular na pahintulot sa bawat antas. Ang mga miyembro ng sysadmin fixed server role ay maaaring magsagawa ng lahat ng mga gawain sa pag-configure ng replication. Para sa mas detalyadong mga pahintulot, ang mga user ay kailangang maging miyembro ng db_owner database role para sa mga publisher at subscriber database.

4.2 Hakbang 1: I-configure ang Distribusyon

Ang pag-configure ng distribusyon ang unang hakbang sa pag-set up SQL Server replikasyon

Para i-configure ang distribusyon gamit ang SQL Server Management Studio:

Kumonekta sa SQL Server halimbawa sa SQL Server Pamamahala ng Studio.
Sa Object Explorer, i-right-click ang Pagtitiklop folder at piliin I-configure ang Distribusyon.
Sa I-configure ang Distribution Wizard, i-click ang susunod sa pahina ng pagbati.
Sa tagapamahagi pahina, pumili ng isa sa mga sumusunod na opsyon batay sa iyong mga kinakailangan sa topolohiya:
- Lokal na Distributor: Piliin ang “Ang ServerName ay magsisilbing sarili nitong Distributor;” SQL Server ay lilikha ng database ng distribusyon at mag-log” kung gusto mong tumakbo ang publisher at distributor sa iisang instance (Ang kasalukuyang instance). Mas madaling i-set up ang configuration na ito at angkop para sa mas maliliit na kapaligiran o kapag ang network latency sa pagitan ng publisher at distributor ay magdudulot ng mga isyu.
- Malayuang TagapamahagiPiliin ang “Gamitin ang sumusunod na server bilang Distributor” at i-click ang Idagdag para tukuyin ang isang remote distributor server kung gusto mong ilipat ang distribution processing sa isang hiwalay na instance. Pinapabuti ng configuration na ito ang performance kapag mataas ang replication volume sa pamamagitan ng pamamahagi ng workload sa maraming server. Kakailanganin mong ibigay ang pangalan ng remote distributor at tukuyin ang password na gagamitin ng publisher para kumonekta sa distributor.
I-click ang susunod para tukuyin ang lokasyon ng snapshot folder. Gumamit ng UNC path (tulad ng \\servername\share\folder) sa halip na isang local path para matiyak ang accessibility sa buong network.
Sa Database ng Pamamahagi pahina, tanggapin ang default na pangalan ng database ng distribusyon (karaniwang "distribusyon") o tukuyin ang isang custom na pangalan, pagkatapos ay i-configure ang mga lokasyon ng data at log file.
Sa Mga publisher pahina, i-verify na ang kasalukuyang server ay pinagana bilang isang publisher. Kung iko-configure mo ang kasalukuyang server bilang isang distributor, maaari kang magdagdag ng mga karagdagang publisher na gagamit ng distributor na ito.
Suriin ang mga aksyon ng wizard at i-click ang Tapusin para i-configure ang distribusyon.

4.3 Hakbang 2: Gumawa ng Publikasyon

Pagkatapos i-configure ang distribution, ang susunod na hakbang ay ang paglikha ng isang publikasyon na tumutukoy kung aling mga data object ang irereplicate sa mga subscriber.

Para lumikha ng publikasyon gamit ang SQL Server Management Studio:

Sa Object Explorer, palawakin ang Pagtitiklop folder.
I-right-click ang Mga Lokal na Publikasyon at piliin ang Bagong Publikasyon.
Ang Bagong Wizard ng Publikasyontarts; i-click susunod sa pahina ng pagbati.
Piliin ang database na gusto mong i-publish mula sa Database ng Publikasyon pahina. Awtomatiko nitong pinapagana ang pag-publish sa napiling database.
Sa Uri ng Lathalain pahina, piliin ang uri ng replikasyon: Publikasyon ng snapshot, Transaksyonal na publikasyon, Peer-to-Peer na publikasyon, O Pagsamahin ang publikasyon.
Sa artikulo pahina, palawakin ang Mga Table node at pumili ng mga talahanayan na isasama bilang mga artikulo.
Opsyonal na palawakin Mga Pamamaraan na nakaimbak, views, o iba pang uri ng bagay para maisama ang mga karagdagang artikulo.
I-click ang Mga Katangian ng Artikulo para i-configure ang pag-filter o iba pang mga setting na partikular sa artikulo.
Sa Mga Hilera ng Talahanayan ng Filter pahina, magdagdag ng mga filter ng hilera kung kinakailangan.
Sa Ahente ng Snapshot pahina, piliin kung kailan gagawin ang snapshot: kaagad, sa isang partikular na oras, o sa isang iskedyul.
Sa Seguridad ng Ahente pahina, tukuyin ang konteksto ng seguridad para sa Snapshot Agent.
Sa Mga Aksyon ng Wizard pahina, piliin Gumawa ng publikasyon.
Magbigay ng pangalan ng publikasyon at i-click ang Tapusin.

4.4 Hakbang 3: Gumawa ng Subscription

Pagkatapos gumawa ng publikasyon, ang susunod na hakbang ay ang paggawa ng mga subscription na nagkokonekta sa publikasyon sa mga database ng subscriber.

Ang mga subscription ay maaaring push subscriptions (pinamamahalaan ng distributor) o pull subscriptions (pinamamahalaan ng subscriber). Ang mga pangunahing pagkakaiba ay kung saan mo ginagawa ang subscription at kung aling lokasyon ng ahente ang pipiliin mo, na siyang nagtatakda ng aksyon ng subscription (push o pull).

Para sa Push Subscription (pinamamahalaan ng Distributor):

Sa tagapaglathala server, palawakin Pagtitiklop -> Mga Lokal na Publikasyon.
I-right-click ang publikasyon at piliin ang Bagong Mga Suskrisyon.

Para sa Pull Subscription (pinamamahalaan ng Subscriber):

Sa suskritor server, palawakin Pagtitiklop, pag-click sa kanan Mga Lokal na Subscription, at piliin Bagong Mga Suskrisyon.
Sa Publikasyon page, i-click ang Mahanap SQL Server Tagapaglathala at kumonekta sa server ng publisher.

Mga karaniwang hakbang ng wizard para sa parehong uri ng subscription:

Sa Bagong Subscription Wizard, i-click ang susunod sa pahina ng pagbati.
Piliin ang publikasyon at i-click ang susunod.
Sa Lokasyon ng Ahente ng Pamamahagi pahina, piliin ang lokasyon ng ahente:
- Subscription sa pushPiliin ang “Patakbuhin ang lahat ng ahente sa Distributor” – ipo-push ng Distributor ang mga pagbabago sa mga subscriber.
- Hilahin ang subscriptionPiliin ang “Patakbuhin ang bawat ahente sa Subscriber nito” – kukunin ng bawat subscriber ang mga pagbabago mula sa Distributor.
Sa Subscriber pahina, piliin ang mga kasalukuyang server ng subscriber o i-click ang Idagdag Sukritor para magdagdag ng mga bago.
Para sa bawat subscriber, piliin ang database ng destinasyon o lumikha ng bagong database. tandaan: Dapat na iba ang database ng subscription sa database ng publisher, kahit na pareho ang gamit nito SQL Server halimbawa.
Sa Seguridad ng Ahente ng Pamamahagi pahina, i-click ang button na mga property para sa bawat subscription upang i-configure ang konteksto ng seguridad.
Sa Iskedyul ng Pag-synchronize pahina, piliin ang tuloy-tuloy na pag-synchronize o naka-iskedyul na pag-synchronize.
Sa Simulan ang mga Subscription pahina, piliin Kaagad para simulan habang nakumpleto ang wizard o Sa unang pag-synchronize.
Suriin ang mga aksyon ng wizard at i-click ang Tapusin.

5. Pagsubaybay at Pamamahala SQL Server Pagtitiklop

5.1 Pagsubaybay sa Replikasyon gamit ang Replication Monitor

Para ilunsad ang Replication Monitor:

In SQL Server Management Studio, palawakin Pagtitiklop sa Object Explorer.
I-right-click ang Pagtitiklop at piliin ang Ilunsad ang Replication Monitor.
Kung walang nakarehistrong publisher, i-click ang Magdagdag ng Tagapaglathala sa kaliwang pane.
Piliin Idagdag SQL Server Tagapaglathala at kumonekta sa server ng publisher.
Lumilitaw ang publisher sa kaliwang pane na may mga expandable node para sa mga publikasyon at subscription.

5.2 Pagsubaybay sa Pagganap

5.2.1 Latency ng Monitor

Ang replication latency ay ang pagkaantala ng oras sa pagitan ng pagbabagong nagaganap sa publisher at ang pagbabagong iyon ay inilalapat sa subscriber. Subaybayan ang latency upang matiyak na ang pagiging bago ng data ay nakakatugon sa mga kinakailangan ng negosyo.

Gamitin ang Replication Monitor upang tingnan ang mga sukatan ng latency sa tab na Lahat ng Subscription. Ipinapakita ng column na Latency ang average na latency sa segundo. Para sa transactional replication, ang mga tracer token ay nagbibigay ng mga tumpak na sukat ng latency sa pamamagitan ng paglalagay ng mga transaksyon ng marker na sinusubaybayan sa pamamagitan ng pipeline ng replication.

Para gumamit ng mga tracer token:

Sa Replication Monitor, pumili ng transactional publication.
I-click ang Mga Token ng Tracer Tab.
I-click ang Ipasok ang Tracer para mag-inject ng marker transaction.
Subaybayan ang token habang naglalakbay ito mula sa publisher patungo sa distributor patungo sa subscriber.
Tingnan ang oras na ginugol para sa bawat segment upang matukoy ang mga bottleneck.

5.2.2 Pagsubaybay sa Kapasidad

Sinusukat ng throughput ang dami ng data na kinokopya sa paglipas ng panahon, karaniwang ipinapahayag bilang mga transaksyon bawat segundo o mga utos bawat segundo. Subaybayan ang throughput upang matiyak na makakasabay ang replikasyon sa aktibidad ng publisher.

Bagama't nagbibigay ang Replication Monitor ng pangunahing katayuan ng synchronization, ang delivery rate at detalyadong throughput metrics ay hindi makikita sa GUI. Gumamit ng mga T-SQL query laban sa distribution database upang masubaybayan ang throughput:

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

Mga status code: 1 = Start, 2 = Kasalukuyang ginagawa, 3 = Magtagumpay, 4 = Idle, 5 = Subukan muli, 6 = Nabigo. Ihambing ang rate ng paghahatid laban sa mga rate ng transaksyon ng publisher upang matukoy ang mga sitwasyon kung saan nahuhuli ang replikasyon. Ang mga counter ng pagganap ay nasa Windows Performance Monitor magbigay ng karagdagang mga sukatan ng throughput para sa bawat ahente ng replikasyon.

5.2.3 Tukuyin ang mga Bottleneck

Maaaring mangyari ang mga bottleneck sa replikasyon sa maraming punto sa topolohiya. Sa publisher, ang labis na oras ng pagbuo ng snapshot o mga pagkaantala sa Log Reader Agent ay maaaring magpahiwatig ng mga limitasyon sa mapagkukunan. Subaybayan ang CPU, memory, at disk I/O sa publisher habang isinasagawa ang mga aktibidad sa replikasyon.

Sa distributor, tingnan kung may mga naiipong transaksyon sa database ng distribusyon. Ang malaking bilang ng mga hindi naipamahaging utos ay nagpapahiwatig na hindi kayang sabayan ng distributor ang paghahatid. Subaybayan ang mga mapagkukunan ng server ng distributor at isaalang-alang ang paggamit ng isang nakalaang remote distributor para sa mga sitwasyong may mataas na dami ng serbisyo.

Sa subscriber, ang mabagal na paglalapat ng mga pagbabago ay maaaring magresulta mula sa hindi sapat na mga mapagkukunan, nawawalang mga index, o mga limitasyon na nagpapabagal sa mga operasyon ng pag-insert. Subaybayan ang paggamit ng mapagkukunan ng subscriber at pagganap ng query kapag tumatakbo ang Distribution Agent. Ang mga limitasyon sa bandwidth ng network sa pagitan ng mga bahagi ay nagdudulot din ng mga bottleneck, lalo na para sa malalaking volume ng data.

5.3 Pamamahala ng mga Ahente ng Replikasyon

5.3.1 StarMga Ahente ng t at Stop

Kay start o ihinto ang isang ahente ng replikasyon:

In SQL Server Management Studio, palawakin SQL Server ahente -> Trabaho.
Hanapin ang trabaho bilang replication agent (karaniwang kasama sa mga pangalan ang impormasyon ng publikasyon at subscriber).
I-right-click ang trabaho at piliin ang StarTrabaho or Itigil ang Trabaho.

5.3.2 I-configure ang mga Profile ng Ahente

Ang mga profile ng ahente ay naglalaman ng mga hanay ng parameter na kumokontrol sa pag-uugali ng ahente. SQL Server nagbibigay ng mga default na profile na na-optimize para sa mga karaniwang sitwasyon, at maaari kang lumikha ng mga custom na profile para sa mga partikular na pangangailangan.

Para baguhin ang mga profile ng ahente:

Sa Object Explorer, palawakin Pagtitiklop.
I-right-click ang Pagtitiklop at piliin ang Mga Ari-arian ng Distributor.
I-click ang Mga Default ng Profile button.
Pumili ng uri ng ahente (Snapshot, Log Reader, Distribution, o Merge) mula sa dropdown.
Pumili ng profile at i-click ang Mga Katangian para tingnan ang mga halaga ng parameter.
I-click ang Bagong Profile para lumikha ng custom na profile batay sa isang umiiral na profile.
Baguhin ang mga parameter kung kinakailangan at i-click OK.

Maglagay ng profile sa isang ahente sa pamamagitan ng pag-edit ng mga katangian ng subscription at pagpili ng ninanais na profile mula sa dropdown na Profile ng Ahente.

5.3.3 Mga Parameter at Setting ng Ahente

Pinupino ng mga parameter ng ahente ang pagganap at pag-uugali. Kabilang sa mga pangunahing parameter para sa Distribution Agent ang CommitBatchSize (bilang ng mga transaksyong inilapat sa bawat commit), CommitBatchThreshold (bilang ng mga command bago ang commit), SubscriptionStreams (mga parallel na koneksyon para sa mas mabilis na paghahatid), at QueryTimeout (timeout para sa mga command).

Para sa Log Reader Agent, kabilang sa mahahalagang parameter ang ReadBatchSize (mga transaksyong nabasa bawat scan), ReadBatchThreshold (mga command bago ang paghahatid), at PollingInterval (pagkaantala sa pagitan ng mga log scan). Ayusin ang mga parameter na ito batay sa dami ng transaksyon at mga kinakailangan sa latency.

5.4 Mga Pagsasaalang-alang sa Pag-backup at Pag-restore

Ang pag-backup ng mga database na kasangkot sa replikasyon ay nangangailangan ng mga espesyal na konsiderasyon. Para sa database ng publisher, mahalaga ang regular na pag-backup ng buo at transaction log. Markahan ang backup ng database para sa suporta sa replikasyon gamit ang opsyong WITH REPLICATION kapag nagba-backup ng mga database sa transactional replication. Regular na i-backup ang distribution database upang protektahan ang configuration ng replikasyon.

Kapag ibinabalik ang isang database ng publisher sa parehong server na may parehong pangalan, gamitin ang opsyong WITH KEEP_REPLICATION upang mapanatili ang estado ng replikasyon. Tinitiyak ng opsyong ito na ang mga transaksyong hindi pa napoproseso ng Log Reader Agent ay mananatiling minarkahan para sa replikasyon, na nagpapahintulot sa replikasyon na awtomatikong magpatuloy nang hindi muling sinisimulan ang mga subscription.

Sa mga senaryo ng disaster recovery kung saan hindi magagamit ang mga backup, sira, o nasira ang mga file ng database, maaaring kailanganin ang mga espesyal na tool sa pagbawi. DataNumen SQL Recovery maaaring kumuha ng data mula sa mga sirang o hindi maa-access na MDF at NDF file, na nagbibigay ng huling opsyon kapag nabigo ang mga karaniwang pamamaraan ng pagpapanumbalik.

Para sa karagdagang mga detalye sa SQL Server backup, tingnan ang aming kumpletong gabay.

6. Mga Madalas Itanong (FAQ)

T: Ano ang pagkakaiba ng snapshot at transactional replication?

A: Ang snapshot replication ay kumukuha ng kumpletong kopya ng data sa isang partikular na punto ng panahon at inilalapat ito sa subscriber, na angkop para sa madalang na pagbabago ng data. Mga transactional replicationtarts na may paunang snapshot at pagkatapos ay patuloy na kinokopya ang mga indibidwal na transaksyon habang nangyayari ang mga ito, na nagbibigay ng halos real-time na synchronization para sa madalas na nagbabagong data.

T: Maaari ko bang kopyahin sa pagitan ng iba't ibang SQL Server bersyon?

A: Oo, SQL Server Sinusuportahan ng replikasyon ang compatibility ng bersyon sa loob ng limitadong saklaw. Ang bersyon ng distributor ay dapat na katumbas o mas mataas kaysa sa bersyon ng publisher, at ang subscriber ay maaaring nasa loob ng dalawang bersyon ng publisher. Halimbawa, kung ang publisher ay SQL Server 2016, ang subscriber ay maaaring SQL Server 2012, 2014, 2016, 2017, o 2019.

T: Paano ko haharapin ang mga conflict sa merge replication?

A: Ang merge replication ay nagbibigay ng built-in na mga mekanismo sa pagtukoy at paglutas ng conflict. Maaari mong i-configure ang mga conflict resolver sa antas ng artikulo, pumili mula sa mga built-in na resolver o pagpapatupad ng mga custom na resolver ng conflict. Karaniwang nilulutas ang mga conflict gamit ang mga pamamaraang nakabatay sa priority o timestamp, na may opsyong mag-log ng mga conflict para sa manu-manong pagsusuri.

T: Ano ang mga epekto sa pagganap ng replikasyon?

A: Ang replikasyon ay nakakaapekto sa pagganap sa ilang paraan: ang publisher ay nakakaranas ng overhead mula sa pagsubaybay sa mga pagbabago at pagbuo ng mga snapshot, ang distributor ay gumagamit ng mga mapagkukunan upang mag-imbak at magpasa ng mga transaksyon, at ang bandwidth ng network ay nakonsumo habang naglilipat ng data. Ang epekto ay nag-iiba depende sa uri ng replikasyon, kung saan ang replikasyon ng snapshot ay nagdudulot ng pana-panahong high-impact bursts at ang transactional replication ay nagpapanatili ng mas pare-pareho ngunit patuloy na load.

T: Paano ko mase-secure ang aking replication topology?

A: I-secure ang iyong topolohiya ng replikasyon sa pamamagitan ng pagpapatupad ng ilang pinakamahuhusay na kasanayan: gumamit ng Windows Authentication o strong SQL Server pagpapatotoo, i-encrypt ang mga koneksyon gamit ang TLS, i-secure ang snapshot folder gamit ang naaangkop NTFS mga pahintulot, i-configure ang Publication Access List (PAL) para kontrolin ang access, gumamit ng magkakahiwalay na service account na may kaunting kinakailangang pahintulot para sa bawat replication agent, at regular na i-audit ang mga setting ng seguridad ng replication.

T: Maaari ko bang kopyahin ito sa Azure SQL Database?

A: Oo, maaari kang mag-replicate sa Azure SQL Database gamit ang transactional replication sa isang on-premises SQL Server o Azure SQL Managed Instance bilang publisher at distributor. Ang Azure SQL Database ay maaaring magsilbing subscriber ngunit hindi bilang publisher o distributor. Ang merge replication at peer-to-peer replication ay hindi sinusuportahan ng Azure SQL Database.

T: Paano ko masusubaybayan ang replication lag?

A: Subaybayan ang replication lag gamit ang Replication Monitor sa SQL Server Management Studio, na nagpapakita ng mga sukatan ng latency para sa bawat subscription. Maaari ka ring mag-query sa mga talahanayan ng database ng distribusyon tulad ng MSdistribution_history at MSrepl_commands, gumamit ng mga counter ng pagganap na partikular sa mga ahente ng replication, o mag-set up ng mga alerto batay sa mga threshold ng latency upang maagap na matukoy at matugunan ang mga pagkaantala sa pag-synchronize.

T: Ano ang mangyayari kapag ang isang subscriber ay offline?

A: Kapag offline ang isang subscriber, ang kilos ay nakadepende sa uri ng replikasyon. Para sa transactional replication, naiipon ang mga transaksyon sa distribution database hanggang sa bumalik online ang subscriber, pagkatapos ay magpapatuloy ang synchronization. Para sa merge replication, sinusubaybayan ang mga pagbabago sa magkabilang panig at pinagsasama kapag naibalik na ang koneksyon. Tinutukoy ng setting ng retention period kung gaano katagal itatago ang data bago ito kailangang muling simulan.

T: Paano ako magdadagdag ng mga bagong artikulo sa dati nang publikasyon?

A: Para magdagdag ng mga bagong artikulo sa isang umiiral na publikasyon, gamitin ang SQL Server Management Studio para baguhin ang mga property ng publikasyon at pumili ng mga karagdagang object, o gamitin ang sp_addarticle stored procedure. Pagkatapos magdagdag ng mga artikulo, bumuo ng bagong snapshot at muling simulan ang lahat ng mga subscription upang matiyak na matatanggap ng mga subscriber ang mga bagong artikulo. Ang ilang mga pagbabago ay maaaring mangailangan ng muling pagsisimula ng subscription depende sa mga setting ng publikasyon.

T: Paano ko aalisin ang replikasyon mula sa isang database?

A: Alisin ang replikasyon mula sa isang database sa pamamagitan ng pagbura muna ng lahat ng subscription gamit ang sp_dropsubscription, pagkatapos ay pag-alis ng publikasyon gamit ang sp_droppublication, at panghuli ay i-disable ang pag-publish sa database gamit ang sp_replicationdboption. Kung ang server ay isang distributor, i-disable ang distribution gamit ang sp_dropdistributor. Palaging i-back up ang mga database bago alisin ang configuration ng replikasyon.

Q: Ano ang pagkakaiba ng SQL Server Mga Grupo ng Replikasyon at Availability ng AlwaysOn?

A: Ang replikasyon ay isang solusyon sa pamamahagi at integrasyon ng datos na gumagana sa antas ng object, habang Laging Nasa Availability Groups ay isang solusyon para sa mataas na availability at disaster recovery na gumagana sa antas ng database.

7. Konklusyon

SQL Server Ang replikasyon ay nagbibigay ng isang matibay na balangkas para sa pamamahagi at pag-synchronize ng data sa maraming database at lokasyon. Sinusuportahan ng teknolohiya ang iba't ibang mga senaryo sa pamamagitan ng iba't ibang uri ng replikasyon.

Ang pagpili ng tamang estratehiya sa pagkopya ay nakadepende sa iyong mga partikular na pangangailangan. Isaalang-alang ang dalas ng pagbabago ng data, mga kinakailangan sa latency, kung kailangan bang gumawa ng mga update ang mga subscriber, mga katangian ng network, at mga pangangailangan sa awtonomiya ng subscriber. Ang snapshot replication ay pinakamahusay na gumagana para sa madalang na pagbabago ng reference data kung saan hindi kritikal ang latency. Ang transactional replication ay angkop sa mga sitwasyong may mataas na volume na nangangailangan ng mababang latency at pangunahin na one-way na daloy ng data.

Piliin ang merge replication kapag ang mga subscriber ay nangangailangan ng autonomous na operasyon na may mga offline na kakayahan at bidirectional synchronization. Ipatupad ang peer-to-peer replication para sa load balancing read operations sa maraming aktibong node na may halos real-time consistency. Isaalang-alang ang hybrid approach na pinagsasama ang maraming uri ng replication para sa mga kumplikadong senaryo na may magkakaibang pangangailangan.

Mga sanggunian

Tungkol sa Author

Yuan Sheng ay isang senior database administrator (DBA) na may higit sa 10 taong karanasan sa SQL Server kapaligiran at pamamahala ng database ng enterprise. Matagumpay niyang nalutas ang daan-daang mga sitwasyon sa pagbawi ng database sa mga serbisyong pinansyal, pangangalaga sa kalusugan, at mga organisasyon sa pagmamanupaktura.

Dalubhasa si Yuan sa SQL Server pagbawi ng database, mga solusyon sa mataas na kakayahang magamit, at pag-optimize ng pagganap. Kasama sa kanyang malawak na karanasan sa hands-on ang pamamahala ng mga multi-terabyte na database, pagpapatupad ng Always On Availability Groups, at pagbuo ng mga automated na backup at mga diskarte sa pagbawi para sa mission-critical na mga sistema ng negosyo.

Sa pamamagitan ng kanyang teknikal na kadalubhasaan at praktikal na diskarte, nakatuon si Yuan sa paglikha ng mga komprehensibong gabay na tumutulong sa mga administrator ng database at mga propesyonal sa IT na malutas ang kumplikado SQL Server mga hamon nang mahusay. Nananatili siyang napapanahon sa pinakabago SQL Server mga release at mga umuunlad na teknolohiya ng database ng Microsoft, na regular na sumusubok sa mga senaryo sa pagbawi upang matiyak na ang kanyang mga rekomendasyon ay sumasalamin sa mga pinakamahusay na kagawian sa totoong mundo.

May mga katanungan tungkol sa SQL Server pagbawi o kailangan ng karagdagang gabay sa pag-troubleshoot ng database? bati ni Yuan puna at mungkahi para sa pagpapabuti ng mga teknikal na mapagkukunang ito.