SQL Server Mga Grupo ng Always On Availability: Kumpletong Gabay [2026]

1. Pag-unawa sa mga Grupong Always On Availability

1.1 Ano Ito at Paano Ito Gumagana

Ang Always On Availability Groups (AG) ay isang SQL Server enterprise mataas na kakayahang magamit at solusyon sa disaster-recovery na gumagana sa antas ng database. Pinagsasama-sama ng isang availability group ang isa o higit pang mga database ng user sa isang failover unit at kinokopya ang mga ito sa hanggang walong secondary replica sa pamamagitan ng continuous transaction log shipping. Kapag nabigo ang primary replica, awtomatikong mamamahala ang isang itinalagang synchronous secondary, na nagpapanumbalik ng access sa loob ng ilang segundo nang walang shared storage o manual intervention.

1.2 Mga Grupo ng Always On Availability vs. Mga Instance ng Failover Cluster

SQL Server Kasama sa Always On ang dalawang magkaibang teknolohiya: Availability Groups (AG) at Failover Cluster Instances (FCI):

	Laging Nasa Availability Groups	Mga Instance ng Palaging Naka-on na Failover Cluster
Saklaw ng failover	Antas ng database	Antas ng instance (lahat ng database ay magkakasamang nabibigo)
Pagtitiklop ng data	Replikasyon batay sa log sa bawat pangalawang	Wala — lahat ng node ay nagbabahagi ng parehong imbakan
Nakabahaging imbakan	Hindi kinakailangan	Kinakailangan (Storage Area Network (SAN), iSCSI, S2D, o SMB)
Mga nababasang sekundarya	Oo	Hindi
Disaster bawing	Naka-built-in (mga asynchronous na replika sa iba't ibang site)	Hindi built-in nang walang pagpapares sa AG

Kailan gagamitin ang bawat isa: Gamitin ang FCI kapag kailangan mo ng instance-level failover at mayroon ka nang shared storage infrastructure. Gamitin ang AG kapag kailangan mo ng database-level granularity, readable secondaries, o disaster recovery. Para sa most kumpletong proteksyon, pagsamahin ang pareho: patakbuhin ang bawat replica bilang isang FCI node at i-link ang mga ito sa isang AG.

1.3 Mga Benepisyo at Limitasyon

Benepisyo:

• Awtomatikong failover na may halos zero na Recovery Time Objective (RTO) para sa mga sabay-sabay na replika;
• sero pagkawala ng datos (Recovery Point Objective (RPO) = 0) sa synchronous-commit mode;
• hindi kinakailangan ang shared storage — ang bawat replica ay gumagamit ng independent local storage;
• nababasang mga sekundaryang pag-uulat ng offload at mga backup na workload mula sa pangunahin;
• Sinusuportahan ang parehong lokal na High Availability (HA) at cross-site Disaster Recovery (DR) sa loob ng iisang configuration.

Limitasyon:

• Nangangailangan ng Windows Server Failover Clustering sa lahat ng replica;
• Enterprise Edition para sa kumpletong hanay ng mga tampok (Sinusuportahan ng Standard Edition ang Basic AG na may mga makabuluhang paghihigpit);
• Ang synchronous-commit mode ay nagdaragdag ng latency upang magsulat ng mga operasyon na proporsyonal sa oras ng round-trip ng network;
• Ang mga login, trabaho sa SQL Agent, at mga naka-link na server ay hindi awtomatikong naka-synchronize sa SQL Server 2019 at mas maaga (nalutas noong SQL Server 2022 ay naglalaman ng mga grupo ng kakayahang magamit).

2. Arkitektura ng mga Grupo na Always On Availability

2.1 Mga Pangunahing Bahagi at Konsepto

2.1.1 Mga Database ng Availability

Ang mga database ng availability ay ang mga database ng user na kalahok sa isang availability group. Ang mga database na ito ay dapat matugunan ang mga partikular na kinakailangan: dapat silang gumamit ng full recovery model, magkaroon ng full backup, at umiiral sa primary replica bago idagdag sa isang availability group.

Kapag ang isang database ay sumali sa isang availability group, ito ay nagiging bahagi ng isang naka-synchronize na set na nabibigo bilang isang unit. Lahat ng database sa isang availability group ay may parehong failover state, ibig sabihin kung ang pangunahing replica ay nabigo, lahat ng database ay nabibigo sa parehong pangalawang replica nang sabay-sabay. Tinitiyak nito ang pagkakapare-pareho para sa mga application na umaasa sa maraming magkakaugnay na database.

2.1.2 Mga Replika na Magagamit

Ang mga replika na magagamit ay SQL Server mga pagkakataon na host mga kopya ng mga database ng availability. Ang bawat replica ay nagpapanatili ng sarili nitong pisikal na kopya ng mga database, na naka-synchronize sa pamamagitan ng pagpapadala ng talaan ng talaan ng transaksyon. Ang isang grupo ng availability ay maaaring maglaman ng hanggang siyam na replica: isang pangunahing replica at hanggang walong pangalawang replica.

2.1.3 Pangunahing Replika

Ang pangunahing replika hostAng read-write copy ng mga availability database. Lahat ng pagbabago sa data (INSERT, UPDATE, DELETE) ay nangyayari sa primary replica. Ang mga client application ay kumokonekta sa primary replica para sa lahat ng write operations at, bilang default, para rin sa read operations.

2.1.4 Mga Pangalawang Replika

Mga pangalawang replika host mga read-only na kopya ng mga availability database, na pinapanatili sa pamamagitan ng patuloy na aplikasyon ng mga talaan ng log ng transaksyon na natanggap mula sa pangunahing replika. Ang bawat pangalawang replika ay tumatanggap, nagpapatigas, at naglalapat ng mga talaan ng log upang mapanatiling naka-synchronize ang mga kopya ng database nito sa pangunahin.

2.2 Mga Mode ng Availability

2.2.1 Mode na Synchronous-Commit

Ang synchronous-commit mode ay nagbibigay ng proteksyon laban sa pagkawala ng data sa pamamagitan ng pag-aatas sa pangunahing replica na maghintay para sa kumpirmasyon na ang mga talaan ng talaan ng transaksyon ay na-harden na sa pangalawang replica bago mag-commit ng mga transaksyon. Ang mode na ito ay mahalaga para sa mga high availability configuration kung saan ang pagkawala ng data ay hindi katanggap-tanggap.

2.2.2 Asynchronous-Commit Mode

Pinapahalagahan ng asynchronous-commit mode ang pagganap ng pangunahing replica sa pamamagitan ng pagpapahintulot sa mga transaksyon na mag-commit nang hindi na hinihintay na kilalanin ng mga pangalawang replica ang log hardening. Angkop ang mode na ito para sa mga replica ng disaster recovery o kapag ang network latency ay ginagawang hindi praktikal ang synchronous commit.

Ang kapalit nito ay ang potensyal na pagkawala ng data habang isinasagawa ang failover. Kung mabigo ang pangunahing replica, maaaring hindi pa nakarating ang ilang naka-commit na transaksyon sa pangalawang replica. Ang dami ng potensyal na pagkawala ng data ay depende sa bandwidth ng network, performance ng pangalawang replica, at sa tiyempo ng pagkabigo. Dapat tanggapin ng mga organisasyon ang panganib na ito kapag gumagamit ng asynchronous mode.

2.3 Mga Uri ng Failover

2.3.1 Awtomatikong Pag-failover

Ang awtomatikong failover ay nagbibigay-daan sa availability group na matukoy ang pagkabigo ng pangunahing replica at awtomatikong i-promote ang isang pangalawang replica sa pangunahin nang walang interbensyon ng administrator. Binabawasan ng kakayahang ito ang RTO sa pamamagitan ng pag-aalis ng pangangailangan para sa manu-manong pagtugon sa mga pagkabigo.

Ang awtomatikong failover ay nangangailangan ng synchronous-commit mode upang matiyak na walang pagkawala ng data. Kapag naka-enable, patuloy na minomonitor ng availability group ang kalusugan ng primary replica. Kung ang primary ay hindi tumutugon o nabigo, sisimulan ng Windows Server Failover Cluster ang awtomatikong failover sa isang itinalagang secondary replica.

2.3.2 Manu-manong Pag-failover

Ang manual failover ay nagbibigay-daan sa mga administrator na sadyang ilipat ang pangunahing papel ng replica sa isang pangalawang replica, kadalasan para sa mga layunin ng planadong pagpapanatili o pagsubok. Hindi tulad ng awtomatikong failover, ang manual failover ay nangangailangan ng tahasang aksyon ng administrator upang masimulan.

Mayroong manual failover nang walang pagkawala ng data para sa mga synchronous-commit replica. Sinisimulan ng administrator ang failover sa pamamagitan ng SQL Server Management Studio, Transact-SQL, o PowerShell. Tinatapos ng pangunahing replica ang pagproseso ng mga kasalukuyang transaksyon, ipinapadala ang lahat ng natitirang log record sa tarmaging pangalawa, at naghihintay ng kumpirmasyon bago ilipat ang pangunahing papel.

Maaari ring mangyari ang manual failover sa mga asynchronous-commit replica, ngunit nangangailangan ito ng forced failover na may potensyal na pagkawala ng data. Dapat gamitin lamang ng mga administrator ang forced manual failover sa mga aktwal na senaryo ng sakuna kapag hindi magagamit ang pangunahing replica at katanggap-tanggap ang pagkawala ng data kumpara sa matagal na downtime.

2.3.3 Sapilitang Pag-failover

Ang sapilitang failover ay nagpapahintulot sa failover sa isang asynchronous secondary replica o sa isang secondary na hindi ganap na naka-synchronize, nang may tahasang pagkilala sa potensyal na pagkawala ng data. Ang opsyong ito ay nagsisilbing huling paraan kapag ang pangunahing replica ay hindi magagamit at walang umiiral na naka-synchronize na secondary.

2.4 Pag-synchronize ng Datos

2.4.1 Paano Gumagana ang Pag-synchronize ng Data

Nangyayari ang pag-synchronize ng data sa Always On Availability Groups sa pamamagitan ng patuloy na pagpapadala ng tala ng talaan ng transaksyon mula sa pangunahing replika patungo sa lahat ng pangalawang replika. Tinitiyak ng pag-synchronize na nakabatay sa log na ito ang pagkakapare-pareho habang pinapayagan ang independiyenteng pag-iimbak para sa bawat replika.

2.4.2 Mga Rekord at Pagpapatibay ng Talaan ng Transaksyon

Ang pagpapatigas ng talaan ng transaksyon ay ang kritikal na hakbang kung saan isinusulat ang mga talaan ng log sa matibay na imbakan sa mga pangalawang replika. Tinitiyak ng pagpapatigas na ang mga talaan ng log ay nakaligtas sa mga pagkabigo ng pangalawang replika at maaaring i-replay habang nagre-recover.

2.5 Mga Pangalawang Replika na Nababasa at Nababasa

2.5.1 Pag-alis ng mga Read-Only na Workload

Ang mga nababasang pangalawang replika ay nagbibigay-daan sa mga organisasyon na i-offload ang mga read-intensive workload mula sa pangunahing replika, na nagpapabuti sa pangkalahatang pagganap ng sistema at paggamit ng mapagkukunan. Ang kakayahang ito sa read-scale ay isa sa mga pangunahing bentahe ng mga availability group kumpara sa mga mas lumang high availability solution.

Dapat isaalang-alang ng mga organisasyon ang mga kinakailangan sa read-only workload kapag nagdidisenyo ng mga configuration ng availability group. Maaaring ipamahagi ng maraming readable secondary ang reporting load sa ilang server. Tinutukoy ng mga read-only routing list ang pagkakasunud-sunod kung saan natatanggap ng mga secondary ang mga read-intent na koneksyon, na nagbibigay-daan sa mga estratehiya sa load balancing.

2.5.2 Mga Operasyong Pang-backup sa mga Pangalawang Replika

Ang pagpapatakbo ng mga backup sa mga pangalawang replika ay nakakabawas sa input/output (I/O) at Central Processing Unit (CPU) load sa pangunahing replika, na nagbibigay-daan dito na tumuon sa mga transactional workload. Ang kakayahang ito ay nakakatulong sa mga organisasyon na matugunan ang mga kinakailangan sa backup nang hindi naaapektuhan ang pagganap ng produksyon.

SQL Server Sinusuportahan ang mga kumpletong backup ng database, mga differential backup, at mga backup ng transaction log sa mga pangalawang replika. Maaaring i-configure ang mga kagustuhan sa backup upang mas gusto ang mga pangalawang replika, mas gusto ang pangunahin, pangalawa lamang, o anumang replika. Awtomatikong pumipili ang sistema ng backup ng naaangkop na replika batay sa mga kagustuhang ito at kasalukuyang availability.

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

2.6 Mga Tagapakinig ng Grupo ng Availability

2.6.1 Ano ang isang Tagapakinig?

Ang availability group listener ay isang virtual network name (VNN) at IP address na ginagamit ng mga client application upang kumonekta sa mga database ng availability group. Awtomatikong nire-redirect ng listener ang mga koneksyon sa kasalukuyang primary replica, na inaalis ang pangangailangan para sa mga application na subaybayan kung aling server ang kasalukuyang primary.

2.6.2 Pagruruta ng Koneksyon ng Kliyente

Sinusuportahan ng client connection routing sa pamamagitan ng listener ang parehong read-write at read-only connection intent. Sinusuri ng listener ang connection request at iruruta ito sa naaangkop na replica batay sa intent ng application.

3. Mga Kinakailangan at Paunang Kinakailangan

3.1 Pag-clustering ng Windows Server Failover para sa mga Availability Group

3.1.1 Mga Pangunahing Kaalaman sa Windows Server Failover Clustering

Ang Windows Server Failover Clustering (WSFC) ay nagbibigay ng pundasyon para sa Always On Availability Groups sa pamamagitan ng pamamahala ng cluster membership, health monitoring, at failover orchestration. Hindi tulad ng Failover Cluster Instances, ginagamit lamang ng mga availability group ang WSFC para sa koordinasyon ng cluster, hindi para sa shared storage management.

bawat SQL Server Ang isang instance na kalahok sa isang availability group ay dapat na isang node sa isang WSFC cluster. Pinamamahalaan ng cluster ang quorum voting, node health detection, at availability group resource state. Kapag nabigo ang primary replica, kino-coordinate ng WSFC ang proseso ng failover at ina-update ang mga cluster resources upang maipakita ang bagong primary replica.

3.1.2 Konpigurasyon ng Kurom ng Kumpol

Tinutukoy ng cluster quorum kung aling mga node ang maaaring gumana kapag may mga isyu sa koneksyon sa network, na pumipigil sa mga split-brain scenario kung saan maraming node ang nagsasariling nagsasabing sila ang pangunahin. Tinutukoy ng quorum configuration kung ano ang bumubuo sa boto ng mayorya para sa mga desisyon sa cluster.

Maraming quorum mode ang magagamit para sa mga availability group:

• Gumagamit lamang ang Node Majority ng mga boto ng cluster node at gumagana nang maayos para sa mga cluster na may kakaibang bilang ng mga node.
• Nagdaragdag ang Node at File Share Majority ng boto ng saksi sa file share, na angkop para sa mga even-numbered node cluster.
• Gumagamit ang Node at Disk Majority ng disk witness ngunit hindi gaanong karaniwan para sa mga availability group dahil hindi kinakailangan ang shared storage.

3.1.3 Pagkumpol ng Multi-Subnet

Ang multi-subnet clustering ay nagbibigay-daan sa mga availability group replica na sumaklaw sa iba't ibang network subnet, na sumusuporta sa mga heograpikong distribusyon sa mga data center. Ang kakayahang ito ay mahalaga para sa mga disaster recovery configuration kung saan ang mga replica ay umiiral sa magkakahiwalay na lokasyon.

3.2 SQL Server Mga Kinakailangan sa Edisyon

3.2.1 Mga Tampok ng Edisyong Enterprise

SQL Server Nagbibigay ang Enterprise Edition ng kumpletong functionality ng mga availability group nang walang limitasyon. Sinusuportahan ng Enterprise edition ang hanggang walong secondary replica, readable secondary, automatic seeding, distributed availability group, at lahat ng advanced feature.

3.2.2 Mga Tampok ng Standard Edition (Mga Pangunahing Grupo ng Availability)

SQL Server Sinusuportahan ng 2016 Standard edition at mga mas bagong bersyon ang Basic Availability Groups na may malalaking limitasyon. Nagbibigay ang mga basic availability group ng core high availability functionality sa mas mababang cost, na angkop para sa mga organisasyong may mas simpleng mga kinakailangan.

4. Pag-configure ng mga Grupo ng Always On Availability

4.1 Paghahanda ng Kapaligiran

Bago gumawa ng availability group, dapat na maayos na ihanda ang environment gamit ang mga Active Directory account, mga configuration ng server, at imprastraktura ng network.

4.1.1 Pag-setup ng Domain Controller

Dapat i-configure ang Active Directory domain controller upang suportahan ang availability group cluster at SQL Server mga account ng serbisyo.

1. Mag-log in sa domain controller gamit ang mga kredensyal ng domain administrator.
2. Pagbubukas Server Manager at mag-navigate sa Kagamitan -> Mga Aktibong Direktoryo at Mga Computer.
3. Gumawa ng isang yunit ng organisasyon para sa SQL Server mga bagay kung wala nito.
4. Tiyakin na ang mga computer object para sa lahat ng cluster node ay umiiral sa Active Directory.
5. Tiyaking maayos na na-configure ang mga serbisyo ng Domain Name System (DNS) at tama ang paglutas ng lahat ng pangalan ng server.

4.1.2 Paglikha ng mga Account ng Serbisyo

Gumawa ng mga nakalaang account sa serbisyo ng Active Directory para sa SQL Server mga serbisyo sa bawat node.

1. Pagbubukas Mga Aktibong Direktoryo at Mga Computer sa domain controller.
2. I-right-click ang naaangkop na yunit ng organisasyon at piliin ang bago -> gumagamit.
3. Ilagay ang pangalan ng service account (halimbawa, svc_SQLServer) at itakda ang Pangalan ng pag-login ng gumagamit.
4. I-click ang susunod at maglagay ng malakas na password.
5. piliin Hindi maaaring baguhin ng gumagamit ang password at Hindi kailanman mawawalan ng bisa ang password.
6. I-click ang susunod at pagkatapos ay Tapusin para gumawa ng account.
7. Ulitin para sa anumang karagdagang mga account ng serbisyo na kinakailangan (SQL Server Ahente, SSRS, atbp.).

4.1.3 Pag-configure ng mga Pahintulot ng Administrator

Mga account ng serbisyo at ang mga account na ginamit para i-configure SQL Server dapat mayroong naaangkop na mga pahintulot sa lahat ng cluster node.

1. Mag-log in sa bawat cluster node server.
2. Pagbubukas Computer Management mula sa Start menu o Tagapamahala ng Server.
3. Lumawak Mga Lokal na Gumagamit at Grupo at piliin ang Grupo.
4. I-right-click ang Administrator at piliin ang Mga Katangian.
5. I-click ang Idagdag at ilagay ang pangalan ng account ng serbisyo.
6. I-click ang Suriin ang Mga Pangalan para patunayan ang account, pagkatapos ay i-click ang OK.
7. I-click ang OK para isara ang dialog na Mga Katangian ng Administrator.
8. Ulitin sa lahat ng cluster nodes.

4.2 Pag-install at Pag-configure ng WSFC

Dapat na naka-install at na-configure ang Windows Server Failover Clustering sa lahat ng node bago paganahin ang Always On Availability Groups.

4.2.1 Pag-install ng Tampok na Failover Clustering

I-install ang feature na Failover Clustering sa bawat server na lalahok sa availability group.

1. Pagbubukas Server Manager sa unang node ng kumpol.
2. I-click ang Pamahalaan -> Magdagdag ng Mga Tungkulin at Tampok.
3. I-click ang susunod sa pamamagitan ng mga screen ng pagpapakilala.
4. piliin Pag-install na nakabatay sa tungkulin o nakabatay sa tampok at i-click ang susunod.
5. Piliin ang lokal na server at i-click ang susunod.
6. Laktawan ang screen ng Mga Tungkulin at i-click ang susunod.
7. Sa screen ng Mga Tampok, piliin ang Failover Clustering.
8. I-click ang Magdagdag ng Mga Tampok kapag hiniling na isama ang mga kagamitan sa pamamahala.
9. I-click ang susunod at pagkatapos ay I-install.
10. Maghintay hanggang makumpleto ang pag-install at i-click ang Pagsasara.
11. Ulitin sa lahat ng server na lalahok sa cluster.

4.2.2 Paglikha ng Failover Cluster

Pagkatapos i-install ang feature na Failover Clustering sa lahat ng node, gumawa ng cluster mula sa iisang node.

1. Pagbubukas Tagapamahala ng Kumpol ng Failover mula Server Manager -> Kagamitan.
2. I-click ang Lumikha ng Cluster sa pane ng Mga Pagkilos.
3. I-click ang susunod sa pahinang Bago Ka Magsimula.
4. I-click ang Magtingin at idagdag ang lahat ng server na magiging mga cluster node.
5. I-click ang susunod pagkatapos idagdag ang lahat ng node.
6. Mag-iwan Patakbuhin ang lahat ng pagsubok (inirerekomenda) napili at i-click susunod.
7. Suriin ang mga resulta ng pagsusuri sa pagpapatunay at tugunan ang anumang mga error o babala.
8. I-click ang Tapusin pagkatapos matagumpay na makumpleto ang pagpapatunay.
9. Maglagay ng pangalan para sa cluster at IP address.
10. Alisin ang tsek Idagdag ang lahat ng kwalipikadong storage sa cluster dahil hindi kinakailangan ang shared storage.
11. I-click ang susunod at suriin ang kumpirmasyon.
12. I-click ang Tapusin upang lumikha ng kumpol.

4.2.3 Pagpapatunay sa Konfigurasyon ng Cluster

Patunayan ang configuration ng cluster upang matiyak na ang lahat ng node ay maaaring makipag-ugnayan nang maayos at ang cluster ay gumagana nang tama.

1. In Tagapamahala ng Kumpol ng Failover, i-right-click ang pangalan ng cluster.
2. piliin Patunayan ang Kumpol mula sa menu.
3. I-click ang susunod sa pahinang Bago Ka Magsimula.
4. piliin Patakbuhin ang lahat ng pagsubok (inirerekomenda) at i-click ang susunod.
5. I-click ang susunod para simulan ang mga pagsubok sa pagpapatunay.
6. Suriin ang ulat ng pagpapatunay kapag nakumpleto na ang mga pagsubok.
7. Tugunan ang anumang mga pagkabigo o babala na natukoy sa ulat.
8. I-click ang Tapusin para isara ang wizard.

4.3 Pag-install SQL Server para sa mga Grupong May Availability

I-install SQL Server sa bawat node na lalahok sa availability group gamit ang standalone installation option.

1. Patakbuhin ang SQL Server media para sa pag-install sa unang node.
2. piliin bago SQL Server nag-iisang pag-install.
3. Ilagay ang product key o piliin ang edisyon ng pagsusuri.
4. Tanggapin ang mga tuntunin ng lisensya at i-click ang susunod.
5. Kumpletuhin ang mga kinakailangang pagsusuri at tugunan ang anumang isyu.
6. Sa pahina ng Pagpili ng Tampok, piliin ang Mga Serbisyo ng Database Engine.
7. I-configure ang pangalan ng instance (gamitin ang parehong pangalan ng instance sa lahat ng node).
8. Sa pahina ng Konpigurasyon ng Server, tukuyin ang mga kredensyal ng account ng serbisyo.
9. I-configure ang mga serbisyotarmga uri ng tup bilang Awtomatik.
10. Sa pahina ng Database Engine Configuration, piliin ang authentication mode.
11. Magdagdag ng mga administrator account.
12. I-configure ang mga direktoryo ng data gamit ang mga pare-parehong path sa lahat ng node.
13. Kumpletuhin ang pag-install at i-verify ang tagumpay.
14. Ulitin ang pag-install sa lahat ng iba pang cluster nodes na may magkaparehong mga setting.

4.4 Paganahin ang Tampok na Mga Grupo na May Availability na Laging Naka-on

Pagkatapos i-install SQL Server sa lahat ng node, paganahin ang feature na Always On Availability Groups sa bawat instance.

4.4.1 Pagpapagana sa pamamagitan ng SQL Server Manager ng Pag-configure

paggamit SQL Server Configuration Manager para paganahin ang Always On Availability Groups sa pamamagitan ng graphical interface.

1. Pagbubukas SQL Server Manager ng Pag-configure sa unang node.
2. Lumawak SQL Server Serbisyo sa kaliwang pane.
3. Mag-right-click ang SQL Server halimbawa at piliin Mga Katangian.
4. I-click ang AlwaysOn High Availability Tab.
5. Tsek Paganahin ang Mga Grupo ng Availability na AlwaysOn.
6. Tiyaking tama ang pangalan ng Windows failover cluster.
7. I-click ang OK upang i-save ang mga pagbabago.
8. I-click ang OK sa babala na ang serbisyo ay dapat na itigiltarted.
9. Mag-right-click ang SQL Server serbisyo at pumili Restart.
10. Hintaying mag-res ang serbisyotarhindi matagumpay.
11. Ulitin sa lahat ng cluster nodes.

4.4.2 Pag-enable gamit ang PowerShell

Nagbibigay ang PowerShell ng scripted method para paganahin ang Always On Availability Groups sa maraming node.

1. Buksan ang PowerShell bilang Administrator sa unang node.
2. I-import ang SQL Server Modyul ng PowerShell:

   Import-Module SQLPS -DisableNameChecking

3. Paganahin ang Mga Grupo ng Always On Availability:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Awtomatikong ire-reset ang serbisyotart kapag ginagamit ang parameter na Force.
5. Tiyaking pinagana ang feature:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Ulitin para sa bawat cluster node, na pinapalitan ang naaangkop na pangalan ng server at instance.

4.4.3 Pag-verify na Naka-enable ang Tampok

Tiyaking naka-enable ang Always On Availability Groups sa lahat ng instance bago magpatuloy sa configuration.

1. Kumonekta sa bawat isa SQL Server paggamit ng pagkakataon SQL Server Pamamahala ng Studio.
2. Magbukas ng bagong window ng query at isagawa ang:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Tiyaking ang resulta ay 1 (naka-enable).
4. Suriin na ang SQL Server Lumilitaw ang instance sa Failover Cluster Manager sa ilalim ng mga tungkulin ng cluster.
5. I-verify ang pagkakaroon ng availability group endpoint sa pamamagitan ng pagpapatupad ng:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Kung wala ang endpoint, gagawin ito habang ginagawa ang availability group.

4.5 Paghahanda ng mga Database para sa mga Availability Group

Dapat matugunan ng mga database ang mga partikular na kinakailangan bago maidagdag ang mga ito sa isang availability group.

4.5.1 Mga Kinakailangan sa Modelo ng Pagbawi ng Database

Baguhin ang database recovery model sa FULL sa primary replica bago ito idagdag sa isang availability group.

1. Kumonekta sa pangunahing replika gamit ang SQL Server Pamamahala ng Studio.
2. I-right-click ang database at piliin ang Mga Katangian.
3. Piliin ang Options pahina.
4. Baguhin Modelo ng pagbawi sa Ganap.
5. I-click ang OK upang mai-save ang pagbabago.
6. Bilang kahalili, gamitin ang Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Pagkuha ng Kumpletong Backup ng Database

Gumawa ng kumpletong backup ng database upang maitatag ang backup chain na kinakailangan para sa mga availability group.

1. In SQL Server Management Studio, i-right-click ang database.
2. piliin Gawain -> Back Up.
3. Patunayan Uri ng backup ay nakatakda sa Ganap.
4. Pumili ng backup na destinasyon o magdagdag ng bagong destinasyon.
5. I-click ang OK para maisagawa ang backup.
6. Bilang kahalili, gamitin ang Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Pagkuha ng mga Backup ng Transaction Log

Gumawa ng backup ng transaction log upang matiyak na naitatag na ang log chain at mabawasan ang oras ng pagsisimula.

1. In SQL Server Management Studio, i-right-click ang database.
2. piliin Gawain -> Back Up.
3. Baguhin Uri ng backup sa Log ng Transaksyon.
4. Pumili ng destinasyon para sa backup.
5. I-click ang OK para maisagawa ang backup.
6. Bilang kahalili, gamitin ang Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Paglikha ng Availability Group

Gumawa ng availability group gamit ang isa sa ilang available na paraan depende sa iyong mga kagustuhan at mga kinakailangan sa automation.

4.6.1 Paggamit ng New Availability Group Wizard

Ang New Availability Group Wizard ay nagbibigay ng graphical interface para sa paglikha ng mga availability group.

1. In SQL Server Management Studio, kumonekta sa instance na gagawinost ang pangunahing replika.
2. Lumawak AlwaysOn High Availability sa Object Explorer.
3. I-right-click ang Mga Grupo ng Availability at piliin ang Bagong Availability Group Wizard.
   
4. I-click ang susunod sa pahina ng Panimula.
5. Maglagay ng pangalan para sa availability group at i-click ang susunod.
6. Sa pahina ng Pumili ng mga Database, piliin ang mga database na isasama.
7. Tiyakin na natutugunan ng mga database ang lahat ng mga kinakailangan at i-click ang susunod.
8. Sa pahinang Tukuyin ang mga Replika, i-click ang Magdagdag ng Replika.
9. Kumonekta sa bawat pangalawang replica instance.
10. I-configure ang mga replica property para sa bawat instance (availability mode, failover mode).
11. I-click ang Mga Endpoint tab at suriin ang configuration ng endpoint.
12. I-click ang Mga Kagustuhan sa Pag-backup tab at i-configure ang mga prayoridad sa pag-backup.
13. I-click ang Tagapakinig tab at opsyonal na lumikha ng listener.
14. I-click ang susunod at piliin ang paraan ng pag-synchronize ng data.
15. Suriin ang mga resulta ng pagpapatunay at tugunan ang anumang mga isyu.
16. I-click ang susunod at suriin ang buod.
17. I-click ang Tapusin para gumawa ng grupo ng availability.
18. Subaybayan ang progreso at i-verify ang matagumpay na paglikha.

4.6.2 Paggamit ng Transact-SQL

Gumawa ng mga availability group gamit ang Transact-SQL para sa mga scriptable at repeatable na deployment.

1. Gumawa ng availability group sa pangunahing replica:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Sumali sa pangalawang replika sa grupo ng pagkakaroon:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Sumali sa pangalawang database:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Paggamit ng PowerShell

Nagbibigay ang PowerShell ng mga kakayahan sa scripting para sa paglikha at pamamahala ng availability group.

1. Gumawa ng object ng availability group:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Magdagdag ng mga database:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. I-configure ang mga replica gamit ang mga ninanais na property gamit ang New-SqlAvailabilityReplica cmdlet.
4. Pagsamahin ang mga pangalawang replika gamit ang Join-SqlAvailabilityGroup cmdlet.

4.7 Pagdaragdag ng mga Replica sa Availability Group

I-configure ang mga property na partikular sa replica na kumokontrol kung paano nakikilahok ang bawat instance sa availability group.

4.7.1 Pag-configure ng mga Katangian ng Replica

Magtakda ng mga katangian para sa bawat replica upang tukuyin ang tungkulin at mga kakayahan nito sa loob ng availability group.

1. In SQL Server Management Studio, palawakin AlwaysOn High Availability -> Mga Grupo ng Availability.
2. Palawakin ang grupo ng availability at pagkatapos ay palawakin Mga Replika ng Availability.
   
3. Mag-right-click sa isang replica at piliin ang Mga Katangian.
4. Suriin at baguhin ang mga setting ng koneksyon para sa pangunahin at pangalawang mga tungkulin.
5. I-configure ang mga halaga ng timeout ng sesyon kung kinakailangan.
6. I-click ang OK upang i-save ang mga pagbabago.

4.7.2 Pagtatakda ng mga Availability Mode

I-configure ang availability mode upang kontrolin ang pag-uugali ng pag-synchronize sa pagitan ng mga replica.

1. I-right-click ang grupo ng availability at piliin ang Mga Katangian.
2. Sa Pangkalahatan pahina, pumunta sa Mga Replika ng Availability seksyon.
3. Para sa bawat replika, piliin Kasabay na commit or Asynchronous na commit mula sa pagbagsak.
4. Gumamit ng synchronous commit para sa mga lokal na replika na may mataas na availability.
5. Gumamit ng asynchronous commit para sa mga replica ng disaster recovery na may malayong lokasyon.
6. I-click ang OK upang mai-save ang pagsasaayos.

4.7.3 Pagtatakda ng mga Failover Mode

I-configure ang failover mode para kontrolin kung paano nangyayari ang failover para sa bawat replica.

1. I-right-click ang grupo ng availability at piliin ang Mga Katangian.
2. Sa Pangkalahatan pahina, pumunta sa Mga Replika ng Availability seksyon.
3. Para sa mga sabay-sabay na replika ng commit, piliin ang Awtomatik or manwal mode ng failover.
4. Ang awtomatikong failover ay nangangailangan ng synchronous commit mode at nagbibigay-daan sa unattended failover.
5. Para sa mga asynchronous commit replica, tanging manual failover lamang ang magagamit.
6. Mag-configure ng hanggang tatlong replica para sa awtomatikong failover (isang pangunahin at dalawang sekundarya).
7. I-click ang OK upang ilapat ang mga setting.

4.7.4 Pag-configure ng Mga Kagustuhan sa Pag-backup

Itakda ang mga kagustuhan sa pag-backup upang makontrol kung saan dapat isagawa ang mga operasyon sa pag-backup.

1. I-right-click ang grupo ng availability at piliin ang Mga Katangian.
2. piliin Mga Kagustuhan sa Pag-backup sa kaliwang pane.
3. Pumili ng isa sa mga kagustuhan sa pag-backup:
   • Mas gusto ang Pangalawang Bahagi: Mga backup sa pangalawang lugar kung mayroon, kung hindi man ay pangunahin
   • Pangalawa lamang: Mga backup lamang sa mga pangalawang replika
   • Pangunahin: Mga backup lamang sa pangunahing replika
   • Anumang Replika: Mga backup sa anumang magagamit na replika
4. Magtakda ng mga halaga ng prayoridad sa backup para sa bawat replika (0-100).
5. Ang mas mataas na mga halaga ng prayoridad ay nagpapahiwatig ng mas gustong backup tarmakakakuha ng.
6. I-click ang OK para i-save ang mga kagustuhan.

4.8 Pag-configure ng Listener ng Availability Group

Gumawa ng listener para magbigay ng iisang connection point na awtomatikong magre-redirect sa kasalukuyang primary replica.

4.8.1 Paglikha ng Tagapakinig

Magdagdag ng listener sa availability group para sa pamamahala ng koneksyon ng kliyente.

1. In SQL Server Management Studio, palawakin ang grupo ng availability.
2. I-right-click ang Mga Tagapakinig ng Grupo ng Availability at piliin ang Magdagdag ng Tagapakinig.
   
3. Maglagay ng pangalan ng DNS para sa listener (halimbawa, AG_Listener).
4. Ilagay ang numero ng port (ang default ay 1433).
5. piliin Static IP para sa mode ng network.
6. I-click ang Idagdag para magdagdag ng IP address para sa bawat subnet.
7. Ilagay ang IP address at piliin ang subnet.
8. I-click ang OK upang malikha ang tagapakinig.
9. Tiyaking lumalabas ang listener sa Object Explorer at online ito.

4.8.2 Pag-configure ng mga Setting ng DNS at IP

I-verify ang pagpaparehistro ng DNS at configuration ng network para sa listener.

1. Buksan ang DNS Manager sa domain controller.
2. Tiyaking nakarehistro ang pangalan ng tagapakinig sa lahat ng mga IP address.
3. Subukan ang resolusyon ng DNS mula sa mga makina ng kliyente:

   nslookup ListenerName

4. Tiyaking naibalik ang lahat ng na-configure na IP address.
5. Sa Failover Cluster Manager, palawakin Tungkulin at piliin ang grupo ng availability.
6. Tiyaking online ang mga mapagkukunan ng IP address.
7. Tiyaking online ang mapagkukunan ng pangalan ng network.
   

4.8.3 Pagsubok sa Koneksyon ng Tagapakinig

Tiyakin na ang mga client application ay maaaring kumonekta sa pamamagitan ng listener.

1. Mula sa isang makina ng kliyente, buksan SQL Server Pamamahala ng Studio.
2. Kumonekta gamit ang pangalan ng tagapakinig sa halip na pangalan ng server.
3. Magsagawa ng isang query upang mapatunayan ang koneksyon sa kasalukuyang pangunahing replika:

   SELECT @@SERVERNAME;

4. Subukan ang read-intent routing sa pamamagitan ng pagdaragdag ng ApplicationIntent=ReadOnly sa connection string.
5. I-verify na ang koneksyon ay nagre-redirect sa isang nababasang pangalawang replica.
6. Subukan ang failover sa pamamagitan ng manu-manong pagpalya sa availability group at pag-verify ng muling pagkonekta.

4.9 Mga Paraan ng Pag-synchronize ng Datos

Pumili ng paraan ng pag-synchronize ng data upang simulan ang mga pangalawang replica gamit ang mga kopya ng database.

4.9.1 Awtomatikong Pagtatanim

Ang awtomatikong paghahasik ay naglilipat ng data ng database sa network nang hindi nangangailangan ng manu-manong pag-backup at pag-restore.

1. Habang ginagawa ang availability group, piliin ang Awtomatikong pagtatanim bilang paraan ng pag-synchronize.
   
2. Tiyakin ang koneksyon sa network at sapat na bandwidth sa pagitan ng mga replica.
3. Awtomatikong inililipat ng pangunahing replika ang datos ng database patungo sa mga pangalawang replika.
4. Subaybayan ang progreso ng pagtatanim gamit ang availability group dashboard o mga DMV.
5. Kinakailangan ang awtomatikong pagtatanim SQL Server 2016 o mas bago.
6. Para sa malalaking database, isaalang-alang ang epekto at iskedyul ng network sa mga panahong mababa ang paggamit.

4.9.2 Manu-manong Pagtatanim (Pag-backup at Pag-restore)

Ang manu-manong paghahasik ay kinabibilangan ng pagkuha ng mga backup sa pangunahin at pagpapanumbalik ng mga ito sa pangalawang mga replika.

1. Sa pangunahing replika, kumuha ng kumpletong backup:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Gumawa ng backup ng talaan ng transaksyon:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Sa bawat pangalawang replika, ibalik ang buong backup:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Ibalik ang backup ng log:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Sumali sa database sa availability group:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. I-verify na nagsimula na ang synchronization at naabot na ng database ang SYNCHRONIZED state.

4.9.3 Mga File ng Snapshot ng Database

Gumamit ng mga database snapshot file upang simulan ang mga pangalawang replika mula sa mga umiiral na database file.

1. I-detach o i-backup ang database sa pangunahing replica.
2. Kopyahin ang mga file ng database sa bawat pangalawang replica gamit ang parehong mga path ng file.
3. Sa mga pangalawang replika, ilakip ang database o i-restore nang walang recovery.
4. Tiyaking ang database ay nasa estadong PAGPAPANUMBALIK.
5. Sumali sa database sa availability group.
6. Ang pamamaraang ito ay kapaki-pakinabang para sa napakalaking database kung saan ang paglilipat ng network ay magiging hindi praktikal.

5. FAQ

5.1 Pangkalahatang Tanong

T: Ano ang pagkakaiba ng Always On FCI at Always On AG?

A: Ang mga Always On Failover Cluster Instance ay nagbibigay ng mataas na availability sa antas ng instance gamit ang shared storage, habang ang Always On Availability Groups ay nagbibigay ng mataas na availability sa antas ng database nang walang shared storage. Nag-aalok ang AG ng mga readable secondary at mas flexible na heograpikong distribusyon.

T: Maaari ko bang gamitin ang Always On Availability Groups gamit ang SQL Server Edisyong Pamantayan?

A: Oo, SQL Server Sinusuportahan ng 2016 Standard Edition at mga mas bagong bersyon ang Basic Availability Groups na may mga limitasyon kabilang ang isang database bawat AG, maximum na dalawang replika, at walang nababasang pangalawang suporta.

T: Kailangan ko ba ng shared storage para sa mga Always On Availability Groups?

A: Hindi, ang mga availability group ay hindi nangangailangan ng shared storage. Ang bawat replica ay nagpapanatili ng mga independiyenteng kopya ng mga database sa lokal na storage, na naka-synchronize sa pamamagitan ng pagpapadala ng transaction log.

T: Ano ang pinakamataas na bilang ng mga replika sa isang grupo ng availability?

A: SQL Server Sinusuportahan ng Enterprise Edition ang hanggang siyam na replika (isang pangunahin at walong sekundarya). Ang mga distributed availability group ay maaaring sumuporta ng hanggang 18 kabuuang replika sa dalawang availability group.

5.2 Mga Tanong sa Pag-configure

T: Paano ako pipili sa pagitan ng synchronous at asynchronous commit modes?

A: Gumamit ng synchronous commit para sa mga kinakailangan sa zero data loss sa loob ng parehong data center o mga low-latency network. Gumamit ng asynchronous commit para sa mga malalayong disaster recovery replica kung saan ang synchronous commit ay makakaapekto sa performance.

T: Maaari ko bang paghaluin ang mga synchronous at asynchronous na replica sa iisang availability group?

A: Oo, sinusuportahan ng mga availability group ang magkahalong configuration na may parehong synchronous at asynchronous replicas. Nagbibigay-daan ito sa local high availability na may mga synchronous replicas at distant disaster recovery na may mga asynchronous replicas.

T: Ano ang nangyayari sa aking mga koneksyon habang nagfa-failover?

A: Ang mga umiiral nang koneksyon ay napuputol kapag nangyari ang failover. Ang mga application na may connection retry logic ay awtomatikong kumokonekta muli sa bagong primary sa pamamagitan ng listener. Ang proseso ng failover ay karaniwang nakukumpleto sa loob ng ilang segundo hanggang minuto.

T: Kailangan ko bang i-synchronize ang mga login at trabaho sa mga replica?

A: Sa SQL Server 2019 at mga naunang taon, oo – ang mga login, mga trabaho sa SQL Agent, at mga naka-link na server ay dapat na manu-manong i-synchronize. SQL Server Ipinakikilala ng 2022 ang mga contained availability group na awtomatikong nagsasama ng mga object na ito.

5.3 Mga Tanong sa Pamamahala

T: Maaari ba akong magpatakbo ng mga backup sa mga pangalawang replika?

A: Oo, sinusuportahan ng mga pangalawang replika ang mga full, differential, at transaction log backup. I-configure ang mga kagustuhan sa backup upang i-offload ang mga backup mula sa pangunahing replika at mabawasan ang paggamit ng resource nito.

T: Paano ko i-patch SQL Server na may kaunting downtime?

A: Gumamit ng mga rolling upgrade sa pamamagitan ng pag-patch muna ng mga secondary replica, pagkatapos ay pagsasagawa ng manual failover sa isang patched secondary, at panghuli ay pag-patch sa dating primary. Binabawasan nito ang downtime sa tagal ng failover.

T: Maaari ba akong magdagdag ng mga database sa isang umiiral na grupo ng availability?

A: Oo, maaaring idagdag ang mga database sa mga tumatakbong availability group. Ang database ay dapat nasa full recovery model na may full backup, at ang mga secondary replica ay dapat i-seed gamit ang automatic seeding o manual backup and restore.

T: Ano ang awtomatikong pagtatanim at dapat ko ba itong gamitin?

A: Ang awtomatikong paghahasik ay naglilipat ng datos ng database sa network upang simulan ang mga pangalawang replika nang walang manu-manong pag-backup. Gamitin ito para sa mas maliliit na database o kapag sapat ang bandwidth ng network. Para sa napakalaking database, maaaring mas mabilis ang manu-manong paghahasik.

T: Saan ko dapat patakbuhin ang DBCC CHECKDB sa isang availability group?

A: Dapat mong patakbuhin ang DBCC CHECKDB sa mga pangalawang replika upang mabawasan ang load sa pangunahing replika. Ang mga pagsusuri sa pagkakapare-pareho ng database ay maaaring isagawa laban sa mga pangalawang database nang hindi naaapektuhan ang pagganap ng pangunahing replika.

Para sa karagdagang detalye tungkol sa DBCC CHECKDB, tingnan ang aming kumpletong gabay.

5.4 Mga Tanong sa Pag-troubleshoot

T: Bakit nasa HINDI NAG-SYNCHRONIZE ang estado ng aking database?

A: Kabilang sa mga karaniwang sanhi ang mga isyu sa koneksyon sa network, nasuspinde na paggalaw ng data, hindi sapat na espasyo sa disk sa mga pangalawang replika, o mga problema sa endpoint. Suriin ang deskripsyon ng kalusugan ng synchronization at SQL Server mga log ng error para sa mga partikular na detalye. Kung ang pangalawang database ay nagpasok ng isang estado ng pagbawi o mga palabas nakabinbin ang pagbawi, tingnan ang mga naka-link na gabay para sa tarnakakuha ng mga pag-aayos.

T: Paano ko mapipilit ang failover kung hindi available ang primary?

A: Kumonekta sa isang pangalawang replica at isagawa ang ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Kinikilala nito ang potensyal na pagkawala ng data at agad na isinusulong ang pangalawa patungong pangunahin.

T: Bakit hindi makakonekta ang mga kliyente sa aking tagapakinig?

A: Tiyaking online ang listener sa Failover Cluster Manager, matagumpay ang pagpaparehistro ng DNS, maaabot ng mga kliyente ang lahat ng IP ng listener, at pinapayagan ng mga panuntunan ng firewall ang trapiko papunta sa port ng listener.

T: Ano ang ibig sabihin ng malaking redo queue?

A: Ang isang malaking redo queue ay nagpapahiwatig na ang pangalawang replica ay hindi maaaring mag-apply ng mga log record nang kasing bilis ng pagdating ng mga ito. Maaaring ipahiwatig nito ang mga bottleneck sa disk I/O, mga limitasyon sa CPU, o pagharang mula sa mga read-only na query sa pangalawang.

T: Ano ang dapat kong gawin kung ang isang sakuna ay nakakaapekto sa lahat ng mga replica at ang aking mga backup ay nasira rin?

A: Ang pinakamasamang senaryo na ito, habang labis na rare, maaaring mangyari dahil sa mga pag-atake ng ransomware, malawakang pagkabigo ng imbakan, o sunod-sunod na mga sakuna. Ang iyong pangunahing depensa ay ang pag-iwas: mapanatili ang mga replica na ipinamahagi sa heograpiya, mag-imbak ng mga backup sa magkakahiwalay na lokasyon, at
regular na subukan ang iyong mga pamamaraan sa disaster recovery. Kung mabigo ang lahat ng karaniwang opsyon sa recovery, isang espesyalisadong Kagamitan sa pagbawi ng datos ng SQL maaaring subukang kumuha ng data mula sa mga sirang MDF file bilang huling hakbang sa emergency.

5.5 Paglilisensya at Cost Tanong

T: Paano lisensyado ang Always On Availability Groups?

A: SQL Server Ang paglilisensya ay nakadepende sa modelo ng edisyon at pag-deploy. Ang mga availability group ng Enterprise Edition ay nangangailangan ng mga lisensya ng Enterprise sa lahat ng replica. Ang mga passive secondary replica ay maaaring maging kwalipikado para sa libreng paglilisensya sa ilalim ng ilang partikular na kundisyon.

Q: Maaari ba akong gumamit SQL Server Edisyon ng Developer para sa mga grupo ng kakayahang magamit?

A: Oo, kasama sa Developer Edition ang lahat ng feature ng Enterprise Edition kabilang ang buong suporta para sa availability groups. Gayunpaman, ito ay may lisensya lamang para sa development at testing, hindi para sa production use.

T: Nangangailangan ba ng mga karagdagang lisensya ang mga readable secondary?

A: Ang paglilisensya ay depende sa sitwasyon. Ang mga passive secondary para sa disaster recovery ay karaniwang hindi nangangailangan ng mga lisensya. Ang mga aktibong secondary na nagseserbisyo ng mga read-only workload ay karaniwang nangangailangan ng mga lisensya, bagama't iba-iba ang mga partikular na termino.

T: Mayroon bang libreng paraan para makakuha ng mataas na availability gamit ang SQL Server?

A: SQL Server Hindi sinusuportahan ng Express Edition ang mga availability group. SQL Server Sinusuportahan ng Standard Edition ang mga Basic Availability Grouptarmay ting SQL Server 2016, na nagbibigay ng pangunahing mataas na kakayahang magamit sa Standard Edition licensing costs.

T: Ano ang mga Distributed Availability Group?

A: Ang mga distributed availability group ay isang espesyal na uri ng availability group na sumasaklaw sa dalawang magkahiwalay na availability group, na nagbibigay-daan sa mga senaryo na lumalampas sa mga kakayahan ng mga tradisyonal na availability group. Ipinakilala noong SQL Server Noong 2016, tinutugunan ng mga distributed availability group ang mga kinakailangan sa scaling at geographic distribution.

6. Konklusyon

6.1 Buod ng Mga Pangunahing Punto

SQL Server Ang Always On Availability Groups ay kumakatawan sa pangunahing solusyon ng Microsoft para sa high availability at disaster recovery para sa mga mission-critical database. Nagbibigay sila ng failover sa antas ng database nang walang mga kinakailangan sa shared storage, nababasang secondary replica para sa pag-offload ng mga workload, at flexible na heograpikong distribusyon para sa komprehensibong proteksyon ng data. Para sa mga organisasyong nagpapatakbo pa rin ng mga solusyon tulad ng pagpapadala ng troso or pagtitiklop, ang mga availability group ay nag-aalok ng mas matatag at mas simpleng landas ng pag-upgrade sa paraang operasyonal.

6.2 Kailan Gagamitin ang Always On Availability Groups

Pumili ng mga grupo ng availability kapag nangangailangan ng mataas na availability sa antas ng database na may mga kakayahan sa awtomatikong failover. Ang mga organisasyong nangangailangan ng proteksyon laban sa pagkawala ng data para sa mga kritikal na database ay nakikinabang mula sa mga synchronous commit replica na may awtomatikong failover. Ang mga application na nangangailangan ng mga kakayahan sa read-scale ay gumagamit ng mga nababasang pangalawang replica upang ipamahagi ang mga workload ng query.

6.3 Pagkuha ng Starnaaayon sa Iyong Implementasyon

Simulan ang pagpaplano ng availability group sa pamamagitan ng pagtatasa ng mga kinakailangan sa negosyo kabilang ang RTO, RPO, at mga limitasyon sa badyet. Idokumento ang kasalukuyang imprastraktura ng database, mga dependency ng application, at mataas na mga kakulangan sa availability. Magdisenyo ng arkitektura ng availability group na tumutugon sa mga kinakailangan habang nananatili sa loob ng mga limitasyon ng mapagkukunan.

Mga sanggunian

• Opisyal na Dokumento ng Microsoft: Ano ang isang grupo ng availability na Always On?
• Opisyal na Dokumento ng Microsoft: Pagkuha ng Starkasama ang mga Always On Availability Group
• Opisyal na Dokumento ng Microsoft: Mga ipinamamahaging grupo ng kakayahang magamit

---

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.