1. Panimula sa SQL Server Mataas na availability
Mataas na kakayahang magamit sa SQL Server ay tumutukoy sa kakayahan ng sistema na manatiling gumagana nang may kaunting downtime kapag nahaharap sa mga pagkabigo ng hardware, mga isyu sa software, o planadong pagpapanatili. Hindi maaaring maging labis-labis ang kahalagahan ng mataas na availability. Kapag ang mga database ay hindi na magagamit, ang mga organisasyon ay nahaharap sa agarang mga kahihinatnan, kabilang ang pagkawala ng kita, pagbaba ng produktibidad, at hindi kasiyahan ng customer.
Bagama't ang High Availability (HA) at Disaster Recovery (DR) ay kadalasang ginagamit nang palitan, tinutugunan nila ang iba't ibang sitwasyon ng pagkabigo. Nakatuon ang HA sa pagliit ng downtime na dulot ng mga lokal na pagkabigo tulad ng mga pag-crash ng server o instance, samantalang ang DR ay idinisenyo upang makabangon mula sa malalaking sakuna na nakakaapekto sa isang buong data center o rehiyon.
Dalawang kritikal na sukatan ang gumagabay sa pagpaplano ng HA:
- Tinutukoy ng Recovery Time Objective (RTO) ang pinakamataas na katanggap-tanggap na downtime pagkatapos ng isang pagkabigo.
- Tinutukoy ng Recovery Point Objective (RPO) ang pinakamataas na matitiis na pagkawala ng datos.
Karaniwang sinusukat ang availability sa "siyam": 99.9% (tatlong-siyam) ay nagpapahintulot ng 8.76 na oras ng downtime taun-taon, 99.99% (apat-siyam) ay nagpapahintulot ng 52.6 minuto, at 99.999% (limang-siyam) ay naglilimita sa downtime sa 5.26 minuto lamang bawat taon.
2. SQL Server Pangkalahatang-ideya ng mga Solusyon na Mataas ang Availability
2.1 Mga Kategorya ng mga Solusyon sa HA
SQL Server Ang mga solusyon na may mataas na availability ay maaaring ikategorya ayon sa ilang dimensyon:
- Mga proteksyon sa antas ng instance vs database: Ang mga proteksyon sa antas ng instance tulad ng Failover Cluster Instances ay nagpoprotekta sa buong mga instance kabilang ang lahat ng database at mga object ng server, habang ang mga proteksyon sa antas ng database tulad ng Always On Availability Groups ay nagpoprotekta sa mga partikular na database.
- Paggalaw ng data nang sabay-sabay vs. asynchronous: Tinitiyak ng paggalaw ng data nang sabay-sabay na walang pagkawala ng data ngunit maaaring magdulot ng latency, samantalang ang asynchronous na paggalaw ay nag-o-optimize ng performance ngunit tinatanggap ang posibleng pagkawala ng data.
- Awtomatiko vs. manu-manong failover: Binabawasan ng awtomatikong failover ang downtime nang walang manu-manong interbensyon, habang ang manu-manong failover ay nagbibigay ng mas malawak na kontrol ngunit nangangailangan ng aksyon ng administrator.
2.2 Mga Karaniwang Solusyon sa HA
SQL Server nagbibigay ng walong pangunahing solusyon na may mataas na availability, bawat isa ay tumutugon sa mga partikular na senaryo:
- Laging Nasa Availability Groups
- Mga Nakapaloob na Grupo ng Availability
- Mga Ipinamamahaging Grupo ng Availability
- Mga Instance ng Failover Cluster
- SQL Server Pagtitiklop
- Pagpapadala ng Troso
- Pagha-mirror sa Database
- Pinamamahalaang Link ng Instance
3. Mga Grupo ng Always On Availability
Ang Always On Availability Groups ay kumakatawan sa SQL Serverang pangunahing solusyon sa mataas na availability at disaster recovery sa antas ng database, na ipinakilala noong SQL Server 2012. Nagbibigay-daan ito sa mga grupo ng mga database na magsama-sama bilang isang yunit habang nagbibigay ng nababasang pangalawang replika para sa pag-offload ng query.
Pangunahing tampok
- Suporta para sa hanggang 9 na replika sa kabuuan (1 pangunahin + 8 pangalawa)
- Hanggang 5 replika sa synchronous-commit mode (1 primary + 4 secondary)
- Awtomatikong failover na walang pagkawala ng data sa synchronous mode
- Nababasang mga pangalawang replika para sa pag-offload ng query
- Pag-offload ng backup sa mga pangalawang replika
- Tagapakinig ng Availability Group para sa awtomatikong pagruruta ng koneksyon
- Read-only routing para sa load balancing read queries
- Maraming database ang magkakasamang nabibigo bilang isang grupo
Mga Hakbang sa Pagpapatupad
- I-configure ang Windows Server Failover Clustering (WSFC) o Linux Pacemaker cluster
- Paganahin ang feature na Always On Availability Groups sa lahat ng SQL Server mga pagkakataon
- Tiyaking gumagamit ang mga database ng full recovery model at may mga full backup
- Gumawa ng mga endpoint na nagmi-mirror ng database sa bawat replica
- Gumawa ng Availability Group at magdagdag ng mga database
- I-configure ang mga pangunahin at pangalawang replika gamit ang mga nais na mode
- Gumawa at mag-configure ng Availability Group listener
- I-configure ang read-only routing kung gumagamit ng mga readable secondary
- Subukan ang mga pamamaraan ng failover at beripikahin ang koneksyon ng aplikasyon
Best Para sa
- Mga database na kritikal sa misyon na nangangailangan ng pinakamataas na uptime
- Mga organisasyong nangangailangan ng parehong lokal na HA at heograpikong DR
- Mga kapaligirang nangangailangan ng mga kakayahan sa read-scale
- Mga application na nakikinabang sa pag-offload ng mga reporting query
- Mga database na nangangailangan ng proteksyon laban sa pagkawala ng data
- Mga aplikasyong multi-database na nangangailangan ng koordinadong failover
Mga kalamangan
- Walang pagkawala ng data gamit ang synchronous-commit mode
- Binabawasan ng awtomatikong failover ang downtime (karaniwan ay ilang segundo)
- Binabawasan ng mga nababasang sekundarya ang load sa pangunahin
- Walang kinakailangang ibinahaging imbakan
- Sinusuportahan ang parehong mga platform ng Windows at Linux
- Distribusyon ng heograpiya para sa pagbangon mula sa sakuna
- Maaaring ilipat ang mga operasyon ng backup sa mga sekundarya
- Ang mga string ng koneksyon ng aplikasyon ay nananatiling hindi nagbabago pagkatapos ng failover
Kahinaan
- Nangangailangan ng Enterprise Edition para sa buong functionality
- Standard Edition limitado sa Basic AG (1 database, 1 secondary, walang readable secondary)
- Komplikadong pagsasaayos at pamamahala
- Nangangailangan ng imprastraktura ng clustering (WSFC o Pacemaker)
- Ang mga object sa antas ng instance (mga login, trabaho) ay nangangailangan ng manu-manong pag-synchronize
- Maaaring magdulot ng transaction latency ang synchronous mode
- Mga gastos sa paglilisensya para sa maraming server
Mga sanggunian
- SQL Server Mga Grupo ng Always On Availability: Kumpletong Gabay
- Opisyal na Dokumento ng Microsoft: Pangkalahatang-ideya ng mga grupo ng availability na Always On (SQL Server)
4. Mga Nakapaloob na Grupo ng Availability
Mga Nakapaloob na Availability Group, ipinakilala noong SQL Server 2022, palalawakin ang tradisyonal na Always On Availability Groups sa pamamagitan ng awtomatikong pag-synchronize ng mga object sa antas ng instance sa mga replica, na nag-aalis ng pangangailangan para sa manu-manong pagkopya ng mga login, trabaho, at iba pang mga object sa antas ng server.
Pangunahing tampok
- Awtomatikong pag-synchronize ng mga object sa antas ng instance (mga login, user, role)
- SQL Server Mga trabaho sa ahente na kinopya sa lahat ng mga kopya
- Awtomatikong na-synchronize ang mga pahintulot sa database
- Kasama ang lahat ng kakayahan ng Always On AG
- Pinasimpleng failover na may kumpletong replikasyon ng kapaligiran
- Suporta para sa parehong mga platform ng Windows at Linux
Mga Hakbang sa Pagpapatupad
- Matiyak SQL Server 2022 o mas bago pa sa lahat ng pagkakataon
- I-configure ang imprastraktura ng WSFC o Pacemaker cluster
- Paganahin ang feature na Always On sa lahat ng instance
- Gumawa ng Contained Availability Group gamit ang opsyong CONTAINED
- Magdagdag ng mga database sa nakapaloob na AG
- Gumawa ng mga login at trabaho sa konteksto ng AG
- I-configure ang failover ng listener at test
Best Para sa
- Mga organisasyong nagnanais ng pinasimpleng administrasyon ng AG
- Mga kapaligirang may madalas na pagsubok o operasyon ng failover
- Mga aplikasyon na nangangailangan ng maraming bagay sa antas ng instance
- bago SQL Server Mga deployment para sa 2022+
- Mga pangkat na naghahanap ng pinababang configuration pagkatapos ng failover
Mga kalamangan
- Tinatanggal ang manu-manong pag-synchronize ng mga login at trabaho
- Mas mabilis at mas maaasahang failover
- Nabawasan ang administrative overhead
- Gumagana kaagad ang mga aplikasyon pagkatapos ng failover
- Pinasimpleng mga pamamaraan ng pagbangon mula sa sakuna
- Kasama ang lahat ng tradisyonal na benepisyo ng AG
Kahinaan
- Kinakailangan SQL Server 2022 o mas bago
- Kinakailangan ang Enterprise Edition para sa kumpletong functionality
- Hindi maaaring i-convert ang mga umiiral na tradisyonal na AG sa mga contained AG
- Dapat suportahan ng lahat ng replika ang nakapaloob na tampok na AG
- Karagdagang pagiging kumplikado kumpara sa mga tradisyunal na AG
Mga sanggunian
5. Mga Ipinamamahaging Grupo ng Availability
Mga Distributed Availability Group, ipinakilala noong SQL Server 2016, pinagana ang isang arkitekturang "Availability Group of Availability Groups", na nagkokonekta sa dalawang independiyenteng AG sa magkakahiwalay na kumpol para sa mga advanced na senaryo ng disaster recovery at migration.
Pangunahing tampok
- Nag-uugnay ng dalawang magkakahiwalay na grupo ng kakayahang magamit
- Ang bawat AG ay nagpapanatili ng sarili nitong independiyenteng kumpol
- Suporta para sa iba't ibang platform (Windows hanggang Linux)
- Pagkopya sa pagitan ng mga kumpol nang walang ibinahaging pagiging miyembro ng kumpol
- Ang isang AG ay nagsisilbing pangunahin, ang isa naman ay pangalawa
- Sinusuportahan ang parehong synchronous at asynchronous na mga mode
- Distribusyon ng heograpiya sa iba't ibang rehiyon o kontinente
Mga Hakbang sa Pagpapatupad
- Gumawa at mag-configure ng unang Availability Group (pangunahing DAG)
- Gumawa at mag-configure ng pangalawang Availability Group (pangalawang DAG)
- Gumawa ng distributed AG na nag-uugnay sa dalawang AG
- I-configure ang pag-synchronize ng data sa pagitan ng mga AG
- I-set up ang listener sa bawat AG para sa koneksyon ng application
- I-configure ang mga patakaran sa failover at mga pamamaraan ng pagsubok
- I-verify ang komunikasyon at replikasyon sa pagitan ng mga kumpol
Best Para sa
- Pagbangon mula sa sakuna sa maraming rehiyon na sumasaklaw sa mga independiyenteng sentro ng datos
- Paglipat sa iba't ibang platform mula sa Windows patungong Linux o vice versa
- Mga senaryo ng hybrid cloud na kumokonekta sa on-premises sa Azure
- Mga pangunahing pag-upgrade ng bersyon na nangangailangan ng pinahabang mga palugit ng paglipat
- Mga organisasyong may maraming independiyenteng failover cluster
- Mga pandaigdigang negosyo na nangangailangan ng replikasyon na sumasaklaw sa kontinente
Mga kalamangan
- Pinaghihiwalay ang mga dependency ng cluster sa pagitan ng mga site
- Nagbibigay-daan sa tunay na distribusyon sa heograpiya
- Sinusuportahan ang mga senaryo sa iba't ibang platform
- Ang bawat AG ay maaaring mabigo nang nakapag-iisa
- Mainam para sa mga kumplikadong proyekto ng migrasyon
- Hindi kinakailangan ang imprastraktura ng nakabahaging kumpol
- Maaaring sumaklaw sa iba't ibang domain ng Windows o distribusyon ng Linux
Kahinaan
- Nangangailangan ng Edisyong Enterprise
- Mataas na pagiging kumplikado sa pagsasaayos at pamamahala
- Nangangailangan ng malalim na pag-unawa sa parehong clustering at AG technology
- Mas mahirap i-troubleshoot kaysa sa mga karaniwang AG
- Karagdagang latency para sa mga senaryo sa iba't ibang rehiyon
- Nangangailangan ng maingat na pagpaplano ng mga pamamaraan ng failover
Mga sanggunian
6. Mga Instance ng Failover Cluster (FCI)
Ang mga Failover Cluster Instance ay nagbibigay ng mataas na availability sa antas ng instance gamit ang shared storage at Windows Server Failover Clustering, na nagbibigay-daan sa awtomatikong failover ng isang buong... SQL Server halimbawa kabilang ang lahat ng database at mga bagay sa antas ng server.
Pangunahing tampok
- Proteksyon sa antas ng instance (lahat ng database ay magkakasamang nabibigo)
- Aktibo-passive na konpigurasyon na may nakabahaging imbakan
- Pangalan ng Virtual Network (VNN) para sa transparent na failover
- Awtomatikong failover kapag nabigo ang aktibong node
- Walang pagkawala ng datos (isang kopya ng datos)
- Kasama ang mga bagay sa antas ng server (mga login, trabaho, naka-link na server)
- Sinusuportahan ang lahat SQL Server mga modelo ng pagbawi
Mga Hakbang sa Pagpapatupad
- I-configure ang Windows Server Failover Cluster (WSFC)
- I-set up ang shared storage (SAN, SMB, Storage Spaces Direct)
- I-configure ang mga setting ng cluster quorum
- I-install SQL Server bilang Failover Cluster Instance sa unang node
- Magdagdag ng mga karagdagang node sa FCI
- I-configure ang Pangalan ng Virtual Network at IP address
- Pagsubok sa failover sa pagitan ng mga cluster node
- I-configure ang mga application ng kliyente upang gamitin ang VNN
Best Para sa
- Mga organisasyong may umiiral na imprastraktura ng shared storage
- Mga kapaligirang nangangailangan ng proteksyon sa antas ng instance
- Mataas na lokal na kakayahang magamit sa loob ng iisang data center
- Mga aplikasyon na nangangailangan ng lahat ng database na mag-fail nang sama-sama
- Mga senaryo kung saan dapat protektahan ang mga bagay sa antas ng server
- Mga kapaligirang Windows-only (hindi sinusuportahan ang Linux para sa FCI)
Mga kalamangan
- Kumpletong proteksyon sa antas ng instance
- Garantisado ang walang pagkawala ng data
- Kakayahang awtomatikong mag-failover
- Hindi na kailangang i-synchronize ang mga login o trabaho
- Binabawasan ng isang kopya ng data ang mga gastos sa imbakan
- Sinusuportahan ang lahat ng modelo ng pagbawi
- Hindi nagbago ang mga string ng koneksyon ng aplikasyon pagkatapos ng failover
Kahinaan
- Nangangailangan ng mamahaling imprastraktura ng shared storage
- Ang shared storage ay isang punto ng pagkabigo
- Walang kakayahang magbasa ng iskala (isang aktibong node lamang)
- Limitadong distribusyon sa heograpiya dahil sa mga limitasyon sa imbakan
- Standard Edition limitado sa 2 node
- Windows lamang (walang suporta sa Linux)
- Mas mahabang oras ng failover kumpara sa mga AG (karaniwang minuto)
- Komplikadong pagsasaayos at pamamahala ng imbakan
Mga sanggunian
- SQL Server Failover Cluster: Kumpletong Gabay para sa DBA
- Opisyal na Dokumento ng Microsoft: Mga instance ng cluster ng failover na Always On (SQL Server)
7. SQL Server Pagtitiklop
SQL Server Ang replikasyon ay isang teknolohiya sa pamamahagi ng datos na kumokopya at namamahagi ng datos sa maraming server, na sumusuporta sa iba't ibang topolohiya mula sa simpleng one-way distribution hanggang sa kumplikadong multi-master configurations, bagama't pangunahing ginagamit para sa pag-uulat sa halip na purong high availability solution.
Pangunahing tampok
- Apat na uri ng replikasyon: Snapshot, Transactional, Merge, Peer-to-Peer
- Pagpili ng granular na datos (mga partikular na talahanayan, kolum, hilera)
- Suporta para sa maraming subscriber mula sa iisang publisher
- May mga magagamit na bi-directional at multi-master topology
- Mga opsyon sa pag-iiskedyul at pag-synchronize na may kakayahang umangkop
- Paglutas ng tunggalian para sa replikasyon ng pagsasama
- Mga kakayahan sa pag-filter gamit ang mga predicate na WHERE
Mga Hakbang sa Pagpapatupad
- I-configure ang Distributor server (maaaring hiwalay o pareho sa Publisher)
- Gumawa ng publikasyon sa database ng Publisher
- Pumili ng uri ng replikasyon batay sa mga kinakailangan
- Pumili ng mga artikulo (mga talahanayan, mga view, mga nakaimbak na pamamaraan) na gagayahin
- I-configure ang pag-filter at pagbabago ng data kung kinakailangan
- I-set up ang mga database ng Subscriber
- Gumawa ng mga subscription (push o pull)
- Simulan ang mga subscription gamit ang snapshot
- Subaybayan ang mga ahente ng replikasyon at latency
Best Para sa
- Pamamahagi ng data sa maraming reporting server
- Mga senaryo ng read-scale na may mga workload sa pag-uulat
- Bahagyang pamamahagi ng datos sa mga malalayong lugar
- Pagsasama-sama ng datos mula sa maraming mapagkukunan
- Mga senaryo na paminsan-minsang magkakaugnay (pagkopya ng pagsasama)
- Papel na sumusuporta sa estratehiya sa pagbangon mula sa sakuna
Mga kalamangan
- Butiranang kontrol sa mga kinopyang datos
- Sinusuportahan ang maraming subscriber
- Mga opsyon sa flexible na topolohiya
- Maaaring kopyahin ang mga partikular na talahanayan o kolum
- Binabawasan ng pag-filter ang trapiko sa network
- Sinusuportahan ang heterogeneous na replikasyon (SQL Server sa Orakulo)
- Gumagana sa Standard Edition
Kahinaan
- Walang kakayahang awtomatikong mag-failover
- Komplikadong pagsasaayos at pamamahala
- Potensyal para sa mga conflict sa replikasyon (merge at peer-to-peer)
- Latency sa pag-synchronize ng data
- Ang mga pagbabago sa iskema ay nangangailangan ng maingat na koordinasyon
- Hindi idinisenyo bilang pangunahing solusyon ng HA
- Maaaring maging mahirap ang pag-troubleshoot
- Kinakailangan ng Peer-to-Peer ang Enterprise Edition
Mga sanggunian
- SQL Server Replikasyon: Kumpletong Gabay para sa DBA
- Opisyal na Dokumento ng Microsoft: SQL Server pagtitiklop
8. Pagpapadala ng Troso
Nagbibigay ang Log Shipping ng isang mainit at naka-standby na solusyon sa disaster recovery at high availability sa pamamagitan ng mga awtomatikong proseso ng pag-backup, pagkopya, at pagpapanumbalik ng log ng transaksyon, na nag-aalok ng simple at cost-effective na diskarte sa pagpapanatili ng mga naka-synchronize na secondary database.
Pangunahing tampok
- Mga awtomatikong trabaho sa pag-backup, pagkopya, at pagpapanumbalik gamit ang SQL Agent
- Suporta para sa maraming pangalawang server
- Maaaring i-configure ang mga agwat ng pag-backup at pagpapanumbalik
- Ang STANDBY mode ay nagbibigay-daan sa read-only na access sa mga pangalawang
- Naantalang pagpapanumbalik ng log para sa proteksyon sa pagbawi ng error
- Monitor server para sa sentralisadong pagsubaybay
- Suporta sa compression ng talaan ng transaksyon
Mga Hakbang sa Pagpapatupad
- Tiyaking gumagamit ang pangunahing database ng full recovery model
- Gumawa ng kumpletong backup ng pangunahing database
- Ibalik ang backup sa pangalawang server gamit ang NORECOVERY
- I-configure ang pagpapadala ng log sa pangunahing database
- Tukuyin ang nakabahaging backup folder na naa-access sa lahat ng server
- I-configure ang iskedyul ng trabahong pang-backup sa pangunahin
- I-configure ang mga trabaho sa pagkopya at pagpapanumbalik sa pangalawang posisyon
- Opsyonal na i-configure ang monitor server
- Mga pamamaraan ng failover sa pagsubok
Best Para sa
- Mga solusyon sa pagbangon mula sa sakuna na matipid
- Mga organisasyong may lisensya sa Standard Edition
- Mga senaryo na nakakayanan ang ilang minuto ng pagkawala ng data
- Mga kapaligirang komportable sa manu-manong failover
- Naantalang pagbawi para sa mga pangangailangan sa proteksyon ng error
- Pag-uulat ng mga workload gamit ang STANDBY mode
- Mga simpleng kinakailangan sa DR nang walang kumplikadong imprastraktura
Mga kalamangan
- Simpleng pag-configure at operasyon
- Mababang halaga (suporta sa Standard Edition)
- Sinusuportahan ang maraming pangalawang server
- Pinoprotektahan ng naiko-configure na pagkaantala laban sa mga lohikal na error
- Read-only na pag-uulat sa STANDBY mode
- Tinitiis ang mataas na latency ng network
- Minimal na epekto sa pangunahing server
- Matatag at napatunayang teknolohiya
Kahinaan
- Walang kakayahang awtomatikong mag-failover
- Dapat i-configure nang hiwalay para sa bawat database
- Pagkaantala ng pag-synchronize (minuto hanggang oras)
- Potensyal na pagkawala ng data batay sa pagitan ng pag-backup
- Pinapataas ng manu-manong failover ang RTO
- Kinakailangan SQL Server Ahente na tumatakbo sa lahat ng server
- Hindi maa-access ang mga pangalawang database habang nagre-restore ng log
- Kinakailangan ng mga application ang mga pagbabago sa connection string pagkatapos ng failover
Mga sanggunian
- SQL Server Pagpapadala ng Log: Kumpletong Gabay para sa DBA
- Opisyal na Dokumento ng Microsoft: Tungkol sa pagpapadala ng log (SQL Server)
9. Pag-mirror ng Database
Ang Database Mirroring ay isang hindi na ginagamit na solusyon sa mataas na availability sa antas ng database na hindi pa nakatanggap ng anumang mga pagpapahusay simula noon. SQL Server 2012, bagama't nananatili itong available sa mga kasalukuyang bersyon. Lubos na inirerekomenda ng Microsoft ang paglipat sa Always On Availability Groups para sa lahat ng bagong deployment.
Pangunahing tampok
- Arkitektura ng pangunahing at mirror server
- Opsyonal na witness server para sa awtomatikong failover
- Dalawang paraan ng pagpapatakbo: Mataas na Kaligtasan at Mataas na Pagganap
- Suporta sa sabay-sabay at asynchronous na operasyon
- Kakayahang awtomatikong pag-aayos ng pahina
- Proteksyon sa antas ng database
- Suporta sa pag-encrypt para sa pagpapadala ng data
Mga Hakbang sa Pagpapatupad
- Tiyaking gumagamit ang database ng full recovery model
- Gumawa ng kumpletong backup at ibalik sa mirror server gamit ang NORECOVERY
- Gumawa ng mga mirroring endpoint sa principal at mirror
- I-configure ang mga sertipiko para sa pagpapatotoo
- Magtatag ng sesyon ng pag-mirror sa pagitan ng mga server
- Opsyonal na i-configure ang witness server para sa awtomatikong failover
- Itakda ang operating mode (Mataas na Kaligtasan o Mataas na Pagganap)
- Mga pamamaraan ng failover sa pagsubok
Best Para sa
- Gumagamit na ng Database Mirroring ang mga legacy system
- Pagpapanatili ng mga umiiral na configuration hanggang sa posible ang paglipat
- Walang ibang mga senaryo na inirerekomenda (hindi na ginagamit ang tampok na ito)
Mga kalamangan
- Mabilis na awtomatikong failover sa High Safety mode na may saksi
- Walang pagkawala ng data sa High Safety mode
- Awtomatikong pagkukumpuni ng pahina mula sa kasosyo
- Mas simple kaysa sa Availability Groups para sa iisang database
- Sinusuportahan ang pag-encrypt para sa pagpapadala
- Mga rolling upgrade na may kaunting downtime
Kahinaan
- Hindi na ginagamit simula noon SQL Server 2012 (maaaring alisin)
- Konpigurasyon at failover kada database
- Walang nababasang salamin (walang kakayahang magbasa ng sukat)
- Ang bawat database ay nabibigo nang paisa-isa
- Kinakailangan ang mga pag-update ng connection string pagkatapos ng failover
- Limitado sa dalawang server (principal at mirror)
- Walang mga pagpapahusay o mga bagong tampok
- Inirerekomenda ng Microsoft ang paglipat sa Always On AG
Mga sanggunian
10. Pinamamahalaang Link ng Instance
Ang Managed Instance Link ay lumilikha ng hybrid na koneksyon sa pagitan ng SQL Server at Azure SQL Managed Instance gamit ang distributed availability group technology, na nagbibigay-daan sa halos real-time na pagkopya ng data para sa mga disaster recovery, migration, at mga senaryo ng cloud integration.
Pangunahing tampok
- Malapit sa real-time na replikasyon gamit ang distributed AG technology
- Isang-daan na replikasyon (SQL Server 2016-2019 hanggang Azure)
- Bi-directional na replikasyon na may failback (SQL Server 2022 +)
- Isang database bawat link (maraming link ang sinusuportahan)
- Mga nababasang replika sa Azure SQL Managed Instance
- Opsyon ng replika ng passive DR na walang lisensya
- Online na paglipat na may kaunting downtime
Mga Hakbang sa Pagpapatupad
- Maghanda SQL Server kapaligiran (VPN o ExpressRoute papuntang Azure)
- I-configure ang Azure SQL Managed Instance
- Paganahin ang feature na Always On AG SQL Server
- Gumawa ng endpoint na nagmi-mirror ng database
- Pagpapalitan ng mga sertipiko sa pagitan ng SQL Server at MI
- Gumawa ng Managed Instance Link gamit ang SSMS o mga script
- Patunayan ang replikasyon at pag-synchronize
- I-configure ang read-only routing kung ginagamit para sa read-scale
- Mga pamamaraan ng failover sa pagsubok
Best Para sa
- Hybrid disaster recovery na may cloud-based na pangalawang
- Paglipat online sa Azure SQL Managed Instance
- Pag-offload ng analytics at pag-uulat sa Azure
- Mga organisasyong gumagamit ng hybrid cloud strategy
- Mga senaryo na nangangailangan ng pagsasama ng serbisyo ng Azure
- Pag-optimize ng gastos gamit ang passive DR na walang lisensya
Mga kalamangan
- Pinakamahusay ang performance, minimal ang downtime migration sa Azure
- Tunay na online na paglipat sa antas ng Business Critical
- Bi-directional failover na may SQL Server 2022 +
- Binabawasan ng replika ng passive DR na walang lisensya ang mga gastos
- Pagsasama sa mga serbisyo ng Azure nang walang ganap na paglipat
- Kakayahang magbasa ng iskala gamit ang mga replika ng Azure
- Mga awtomatikong backup sa panig ng Azure
- Distribusyon ng heograpiya sa mga rehiyon ng Azure
Kahinaan
- Isang limitasyon sa database bawat link
- Hindi maaaring gamitin kasama ng mga failover group sa MI
- Hindi kinopya ang mga database ng system
- Ang mga bagay sa antas ng instance ay nangangailangan ng manu-manong pag-synchronize
- SQL Server 2016-2019 one-way lamang (walang failback)
- Mga gastos sa Azure para sa Pinamamahalaang Instance
- Mga kinakailangan sa koneksyon sa network (VPN/ExpressRoute)
- Mga limitasyon sa tampok (mga talahanayan ng file, mga stream ng file na hindi sinusuportahan)
Mga sanggunian
- Pangkalahatang-ideya ng link ng Pinamamahalaang Instance
- Ihanda ang iyong kapaligiran para sa isang link
11. Paghahambing ng mga Solusyong Mataas ang Availability
11.1 Talahanayan ng Paghahambing ng Tampok
| tampok | Laging Nasa AG | May laman na AG | Ipinamamahaging AG | FCI | Pagtitiklop | Pagpapadala ng Troso | Mirroring | MI Link |
|---|---|---|---|---|---|---|---|---|
| Edisyon | Ent/Std | Ent/Std | Napatingin si Ent | Ent/Std | Ent/Std | Ent/Std | Ent/Std | Ent/Std |
| Level Protection | Database | Database+Instance | Database | Pag-institusyon | Database/Mga Bagay | Database | Database | Database |
| Pag-sync ng Data | I-sync/Async | I-sync/Async | I-sync/Async | Ibinahagi | async | async | I-sync/Async | async |
| Awtomatikong Pagkabigo | Oo | Oo | Oo | Oo | Hindi | Hindi | Oo | Hindi |
| Iskalang Basahin | Oo | Oo | Oo | Hindi | Oo | Limitado | Hindi | Oo |
| RTO | Segundo | Segundo | Segundo | minuto | manwal | manwal | Segundo | manwal |
| RPO | Zero/Min | Zero/Min | Zero/Min | Wala | Napakaliit | minuto | Zero/Min | Napakaliit |
| Katayuan ng Suporta | Aktibo | Aktibo | Aktibo | Aktibo | Aktibo | Aktibo | Deprecated | Aktibo |
11.2 Pumili ng Solusyong HA
Kapag pumipili ng solusyon, isaalang-alang ang mga sumusunod na salik:
- Malaki ang epekto ng mga pagsasaalang-alang sa badyet sa pagpili ng solusyon: Ang mga kinakailangan sa Enterprise Edition ay nakakaapekto sa mga gastos sa paglilisensya, habang ang mga pangangailangan sa imprastraktura ay iba-iba mula sa mamahaling shared storage para sa mga FCI hanggang sa mga commodity server para sa Availability Groups.
- Malaki ang pagkakaiba ng pagiging kumplikado: Ang Log Shipping ay nag-aalok ng pinakasimpleng implementasyon, habang ang Distributed Availability Groups ay nangangailangan ng malawak na kadalubhasaan.
- Ang mga kinakailangan sa RTO ang nagtutulak sa mga pagpipilian sa teknolohiya. Mga segundo ng downtime demand na Always On Availability Groups o FCIs na may awtomatikong failover. Ang tolerance sa minuto ay nagbibigay-daan sa mga manu-manong solusyon sa failover tulad ng Log Shipping.
- Ang mga kinakailangan sa RPO ay pantay na mahalaga: ang zero data loss ay nag-uutos ng mga synchronous na solusyon, habang ang minutes tolerance ay nagbibigay-daan sa Log Shipping.
- Ang mga limitasyon sa imprastraktura, mga pangangailangan sa read-scale, mga kinakailangan sa heograpikong distribusyon, at mga senaryo ng cloud hybrid ay pawang nakakaimpluwensya sa pagpili ng pinakamainam na solusyon.
12. Pinakamahuhusay na Kasanayan para sa SQL Server Mataas na availability
12.1 Pagpaplano at Disenyo
Suriin ang mga kinakailangan ng negosyo sa pamamagitan ng maingat na pagsusuri ng RTO at RPO para sa bawat database. Pumili ng mga angkop na solusyon na tumutugma sa mga kinakailangan sa halip na gumamit lamang ng mga pinakasopistikadong opsyon. Magplano para sa parehong lokal na mataas na availability at geographic disaster recovery gamit ang mga layered approach. Idokumento nang komprehensibo ang arkitektura kabilang ang mga network diagram, mga failover procedure, at mga recovery runbook.
12.2 Mga Patnubay sa Pagpapatupad
Regular na subukan ang mga pamamaraan ng failover sa pamamagitan ng mga naka-iskedyul na pagsubok at kunwaring mga pagkabigo upang mapatunayan SQL Server mga solusyon na may mataas na availability at kahandaan ng koponan. Patuloy na subaybayan ang kalusugan at pagganap gamit ang SQL Servermga built-in na tool tulad ng SQL Server Profiler at mga DMV. I-configure ang komprehensibong pag-alerto para sa lag sa pag-synchronize, mga kaganapan sa failover, at pagkasira ng kalusugan. Panatilihin SQL Server mga estratehiya sa pag-backup sa kabila ng pagpapatupad ng HA, dahil ang mga backup ang nananatiling huling linya ng depensa laban sa lohikal na katiwalian at mga aksidenteng pagbura. Panatilihing updated ang mga system gamit ang mga pinagsama-samang update, mga patch ng seguridad, at mga update ng firmware. Patunayan ang mga pamamaraan ng pagbawi nang pana-panahon sa pamamagitan ng mga aktwal na pagpapanumbalik at pagsubok ng application, at alamin kung paano pangasiwaan ang mga senaryo tulad ng mga database na natigil sa recovery mode.
12.3 Pagsubaybay at Pagpapanatili
Gumamit ng mga tool tulad ng SQL Server Aktibo Monitor, SQL Server Subaybayan pagganap, at mga Dynamic Management View nang malawakan para sa pagsubaybay sa kalusugan, at pagpapatakbo DBCC CHECKDB regular na beripikahin ang integridad ng database. Gamitin ang Always On Dashboard para sa visual na pagtatasa ng kalusugan ng Availability Group. Maingat na subaybayan ang synchronization lag, lalo na para sa mga asynchronous replica at Log Shipping. Maingat na subaybayan ang mga failover event gamit ang SQL Server Mga Pinalawak na Kaganapan at suriin ang mga sanhi ng mga padron. Magtatag ng mga baseline ng pagganap para sa normal na operasyon at subaybayan ang mga paglihis na nagpapahiwatig ng mga potensyal na isyu. Magsagawa ng mga regular na pagsusuri sa pagpaplano ng kapasidad upang matiyak na sinusuportahan ng imprastraktura ang lumalaking workload.
13. FAQ
T: Ano ang pagkakaiba sa pagitan ng mataas na availability at disaster recovery sa SQL Server?
A: Binabawasan ng mataas na availability ang downtime para sa mga lokal na pagkabigo sa loob ng isang data center, kadalasan ay may awtomatikong failover at mga RTO sa loob ng ilang segundo o minuto. Pinoprotektahan ng disaster recovery laban sa mga rehiyonal na sakuna, kadalasan ay may manu-manong failover at mas mahahabang RTO ngunit sumasaklaw sa mga kaganapang nakakaapekto sa buong pasilidad.
T: Ano ang pagkakaiba ng High Availability (HA) at Read-Scale Solutions?
A: Tinitiyak ng mga solusyong High Availability na mananatiling naa-access ang mga database sa panahon ng mga pagkabigo, na nakatuon sa uptime at awtomatikong kakayahan sa failover. Pinapabuti ng mga solusyong Read-Scale ang pagganap ng query sa pamamagitan ng pamamahagi ng mga read-only na workload sa maraming replika ng database, na nakatuon sa throughput at mga oras ng pagtugon. Bagama't nagsisilbi ang mga ito ng iba't ibang layunin, ang parehong teknolohiya tulad ng Always On Availability Groups ay maaaring magbigay ng parehong benepisyo nang sabay-sabay: ang mga nababasang pangalawang replika ay nag-aalok ng mga kakayahan sa read-scale habang nagsisilbi ring mga target ng failover para sa mataas na availability.
Q: Alin SQL Server Ang solusyon ba na may mataas na availability ang pinakamainam para sa aking mga pangangailangan?
A: Ang pinakamahusay na solusyon ay nakasalalay sa mga target ng RTO at RPO, badyet, availability ng edisyon, imprastraktura, at kadalubhasaan. Ang Always On Availability Groups ay angkop sa karamihan ng mga senaryo ng enterprise, habang ang Log Shipping ay mahusay na gumagana para sa mga kapaligirang sensitibo sa gastos. Suriin ang mga kinakailangan gamit ang talahanayan ng paghahambing.
T: Kinakailangan ba ng mga Always On Availability Group ang Enterprise Edition?
A: Sinusuportahan ng Standard Edition ang mga Basic Availability Group na may malalaking limitasyon: isang database bawat grupo, isang secondary replica, at walang readable secondary. Ang kumpletong functionality kabilang ang maraming database, walong secondary, at readable replica ay nangangailangan ng Enterprise Edition.
T: Maaari ko bang gamitin ang Log Shipping kasama ang SQL Server Edisyong Pamantayan?
A: Oo, ang Log Shipping ay ganap na sinusuportahan sa Standard Edition, kaya isa itong kaakit-akit at matipid na solusyon sa disaster recovery para sa mga organisasyong walang lisensya sa Enterprise Edition.
T: Ano ang pagkakaiba ng Always On Availability Groups at Database Mirroring?
A: Hindi na ginagamit ang Database Mirroring at gumagana sa indibidwal na antas ng database na walang nababasang pangalawang access. Sinusuportahan ng Always On Availability Groups ang mga grupo ng database, hanggang walong pangalawang database, nababasang mga replika, at pinahusay na pagsubaybay. Inirerekomenda ng Microsoft ang paglipat sa Always On.
T: Paano ako pipili sa pagitan ng mga Failover Cluster Instance at Availability Group?
A: Pumili ng mga FCI para sa proteksyon sa antas ng instance na may imprastraktura ng shared storage. Pumili ng Availability Groups para sa proteksyon sa antas ng database, mga kakayahan sa read-scale, at heograpikong distribusyon nang walang shared storage. Kadalasang pinagsasama ng mga organisasyon ang pareho para sa komprehensibong proteksyon.
T: Maaari ko bang pagsamahin ang maramihang SQL Server mga solusyon na may mataas na availability?
A: Oo, karaniwan ang pagsasama-sama ng mga solusyon. Ang mga FCI ay maaaring magsilbing mga replika ng Availability Group, na nagbibigay ng lokal na HA sa antas ng instance at heograpikong DR sa antas ng database. Maaaring dagdagan ng Log Shipping ang Availability Groups para sa karagdagang remote na proteksyon. Subukan nang lubusan ang mga pinagsamang configuration.
T: Ano ang pagkakaiba sa pagitan ng synchronous at asynchronous na replikasyon?
A: Ang synchronous replication ay naghihintay para sa pangalawang pagkilala bago mag-commit, na ginagarantiyahan ang zero data loss ngunit posibleng magdulot ng latency. Ang asynchronous replication ay nagpapatuloy nang hindi naghihintay, na nag-o-optimize ng performance ngunit lumilikha ng posibleng data loss habang nagfa-failover.
T: Kailangan ko pa ba ng mga backup kung mayroon na ako SQL Server na-configure na ba ang mataas na availability?
A: Oo nga. Ang mataas na availability ay nagpoprotekta laban sa mga pagkabigo ng hardware ngunit hindi nito kayang protektahan laban sa lohikal na katiwalian, mga aksidenteng pagbura, o mga malisyosong aksyon na umuulit sa lahat ng kopya. Ang mga backup ay nananatiling mahalaga para sa mga kinakailangan sa point-in-time na pagbawi at pagsunod.
T: Kailangan ko pa ba ng mga backup kung mayroon na ako SQL Server na-configure na ba ang mataas na availability?
A: Oo nga. Ang mataas na availability ay nagpoprotekta laban sa mga pagkabigo ng hardware ngunit hindi nito kayang protektahan laban sa katiwalian ng database, mga aksidenteng pagbura, o mga malisyosong aksyon. Ang mga backup ay nananatiling mahalaga para sa mga kinakailangan sa point-in-time na pagbawi at pagsunod. Sa mga kaso kung saan ang mga file ng database ay nasira, at ang mga backup ay hindi magagamit o nasira rin, ang mga espesyalisadong Software sa pagkukumpuni ng database ng SQL ay makakatulong sa pagbawi ng data mula sa sirang MDF, NDF, at mga backup file.
T: Ano ang Contained Availability Group at paano ito naiiba sa isang regular na Availability Group?
A: Mga Nakapaloob na Availability Group, ipinakilala noong SQL Server 2022, awtomatikong i-synchronize ang mga object sa antas ng instance tulad ng mga login, trabaho, at metadata. Ang mga Regular Availability Group ay nag-synchronize lamang ng mga object sa database, na nangangailangan ng manu-manong pagkopya ng mga object ng instance.
T: Maaari ko bang kopyahin ang datos mula sa SQL Server sa Azure SQL Managed Instance?
A: Oo, ang Managed Instance Link ay nagbibigay ng hybrid replication sa pagitan ng SQL Server at Azure. SQL Server Sinusuportahan ng 2016-2019 ang one-way replication, habang SQL Server Binibigyang-daan ng 2022+ ang bi-directional replication na may failback para sa disaster recovery, migration, at hybrid scenarios.
T: Ano ang mangyayari sa SQL Server Mga trabaho sa ahente habang nagfa-failover?
A: Sa tradisyonal na Availability Groups, ang mga trabaho ay dapat manu-manong likhain sa mga pangalawang replika. Mga Contained Availability Groups (SQL Server 2022+) awtomatikong nag-synchronize ng mga trabaho. Kasama sa mga Failover Cluster Instance ang mga trabaho bilang bahagi ng proteksyon sa antas ng instance.
14. Konklusyon
SQL Server Nagbibigay ng komprehensibong mga solusyon na may mataas na availability na tumutugon sa iba't ibang pangangailangan mula sa mga database ng departamento hanggang sa mga kritikal na sistema ng negosyo. Ang bawat solusyon ay nag-aalok ng magkakaibang kakayahan at mga kompromiso na dapat maunawaan ng mga administrador ng database para sa matalinong mga desisyon.
Ang Always On Availability Groups ay kumakatawan sa pangunahing teknolohiya para sa mga modernong deployment, kung saan pinapasimple ng Contained Availability Groups ang administrasyon at ang Distributed Availability Groups naman ay nagbibigay-daan sa mga sopistikadong cross-platform scenario. Patuloy na tinutugunan ng Failover Cluster Instances ang mga pangangailangan sa proteksyon sa antas ng instance, habang nananatiling mahalaga ang Log Shipping para sa mga cost-sensitive scenario. Binubuksan ng Managed Instance Link ang mga posibilidad ng cloud hybrid na nagtutugma sa on-premises. SQL Server kasama si Azure.
Ang pagtutugma ng mga solusyon sa mga partikular na pangangailangan ng negosyo ay kumakatawan sa kritikal na salik ng tagumpay. Walang iisang pamamaraan na akma sa lahat. Dapat maingat na suriin ng mga organisasyon ang mga kinakailangan sa RTO at RPO, mga limitasyon sa badyet, mga kakayahan sa imprastraktura, at kadalubhasaan sa administratibo. Kadalasan, pinagsasama ng pinakamahusay na arkitektura ang maraming solusyon para sa komprehensibong proteksyon. Isaalang-alang kung paano naaayon ang iyong diskarte sa HA sa mas malawak na mga plano sa pag-aampon ng cloud, at sumangguni sa mga nakalaang artikulo para sa detalyadong gabay sa pagpapatupad upang matiyak na ang iyong SQL Server Ang imprastraktura ay nagbibigay ng pagiging maaasahan na hinihingi ng iyong negosyo.
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.