SQL Server Always On: Täydellinen opas tietokannan ylläpitäjälle [2026]

SQL Server Always On on Microsoftin kattava korkean käytettävyyden ja katastrofien palautumisratkaisu, joka esiteltiin SQL Server 2012. Se edustaa merkittävää edistysaskelta aiempiin teknologioihin, kuten tietokannan peilaukseen ja lokien lähettämiseen, verrattuna, varmistaen jatkuvan pääsyn tietoihin ja minimoiden samalla seisokkiajat ja tietojen menetyksen.

1.2 Miksi yritykset tarvitsevat aina saatavilla olevia ratkaisuja

Nykypäivän digitaalitaloudessa tietokannan käyttökatkokset johtavat suoraan tulonmenetyksiin, maineen heikkenemiseen ja määräystenmukaisuusongelmiin. Organisaatiot tarvitsevat korkean käytettävyyden ratkaisuja, jotka takaavat lähes jatkuvan käyttöajan ja suojaavat samalla erilaisilta vikatilanteilta.

Perinteiset varmuuskopiointi- ja palautusmenetelmät eivät riitä nykyaikaisten yritysten tarpeisiin. Kun kriittinen tietokanta vikaantuu, yritykset eivät pysty käyttämään varmuuskopioista palauttamiseen tarvittavia tunteja. Always On -ratkaisut tarjoavat automaattisen vikasietoisuuden, joka voi palauttaa palvelun sekunneissa tai minuuteissa tuntien sijaan, mikä vähentää merkittävästi järjestelmävikojen vaikutusta.

Peruskäytettävyyden lisäksi yritysten on siirrettävä lukuintensiivisiä työkuormia tuotantotietokannoista, suoritettava ylläpitoa ilman käyttökatkoksia ja suojauduttava toimipaikkatason katastrofeilta. SQL Server Always On vastaa kaikkiin näihin vaatimuksiin yhtenäisen arkkitehtuurin avulla, joka skaalautuu pienistä käyttöönotoista globaalisti hajautettuihin järjestelmiin.

1.3 Keskeiset käsitteet: RTO, RPO, HA ja DR

Palautumisajan tavoite (RTO) määrittää virheen jälkeisen käyttökatkoksen hyväksyttävän enimmäiskeston – kuinka nopeasti tietokannan on oltava takaisin toimintakunnossa.

Recovery Point Objective (RPO) määrittelee ajassa mitatun suurimman hyväksyttävän datahävikin – kuinka paljon äskettäin tallennettua dataa yrityksellä on varaa menettää.

Korkea saatavuus (HA) keskittyy minimoimaan rutiininomaisten vikojen, kuten laitteistovikojen tai ohjelmistokaatumisten, aiheuttamat seisokit samassa datakeskuksessa.

Disaster Recovery (DR) käsittelee katastrofaalisia tapahtumia, jotka vaikuttavat koko toimipisteisiin, säilyttäen kopioita tiedoista maantieteellisesti erillisissä paikoissa. HA keskittyy käyttökatkosten minimoimiseen, kun taas DR keskittyy varmistamaan tietosuojan ja liiketoiminnan jatkuvuuden vakavien häiriöiden aikana.

SQL Server Always On tukee sekä HA- että DR-toimintoja yhden yhtenäisen arkkitehtuurin sisällä. Synkroninen vahvistustila tarjoaa RPO = 0 ja automaattisen vikasietoisuuden lähes nolla RTO:ta varten; asynkroninen vahvistustila hyväksyy mahdollisen datan menetyksen vastineeksi pienemmästä viiveestä etäkohteiden välillä.

1.4 Aina käytössä olevat ratkaisut

SQL Server Always On tarjoaa kolme käyttöönottovaihtoehtoa, joista jokainen sopii erilaisiin saatavuus- ja infrastruktuurivaatimuksiin. Tämä opas kattaa kaikki kolme:

Aina käytettävissä olevat saatavuusryhmät (AG): Tietokantatason korkea käytettävyys ja palautus katastrofien jälkeen ilman jaettua tallennustilaa.
Always On -viansietoklusterin instanssit (FCI): Instanssitason korkea käytettävyys jaetun tallennustilan avulla.
AG + FCI yhteensä: Kaksikerroksinen suojaus, joka yhdistää instanssitason ja tietokantatason vikasietoisuuden maksimaalisen vikasietoisuuden saavuttamiseksi.

2. Aina saatavilla olevat ryhmät

Always On -saatavuusryhmät (AG) on tietokantatason korkean käytettävyyden ja katastrofien palautusratkaisu, joka replikoi joukon käyttäjätietokantoja jopa kahdeksaan toissijaiseen replikaan jatkuvan tapahtumalokin toimituksen avulla.

2.1 Tärkeimmät ominaisuudet

Tietokantatason vikasietoisuus: yksittäiset tietokannat tai ryhmät voivat suorittaa vikasietoisuuden riippumatta SQL Server esimerkki;
jopa yhdeksän replikaa (yksi ensisijainen, kahdeksan toissijaista) Enterprise Editionissa;
synkroninen vahvistustila ei-hävikkisille tiedoille; asynkroninen vahvistustila etäisille DR-replikoille;
automaattinen vikasietoisuus synkronisille replikoille, kun ensisijainen replika ei ole käytettävissä;
luettavat toissijaiset kopiot raportoinnin ja varmuuskopiointityökuormien purkamiseen;
saatavuusryhmän kuuntelija tarjoaa yhden yhteyspäätepisteen, joka reitittää automaattisesti nykyiseen ensisijaiseen pääkäyttäjään.

2.2 Käyttöönoton vaiheet

Valmistele Active Directory -palvelutilit ja määritä käyttöoikeudet kaikissa solmuissa;
Asenna ja validoi Windows Serverin vikasietoklusterointi kaikille osallistuville palvelimille;
asentaa SQL Server itsenäisenä instanssina jokaisella solmulla käyttäen yhdenmukaisia polkuja ja asetuksia;
ota Always On Availability Groups -ominaisuus käyttöön SQL Server Konfiguraatioiden hallinta tai PowerShell;
aseta tietokannat täyteen palautusmalliin ja ota täydelliset varmuuskopiot ja lokitiedostojen varmuuskopiot;
luo saatavuusryhmä, lisää replikoita ja määritä saatavuus- ja vikasietotilat;
siemennä toissijaisia kopioita automaattisella siemennäytöllä tai manuaalisella varmuuskopioinnilla ja palautuksella;
Luo saatavuusryhmän kuuntelija ja tarkista asiakasyhteys.

Täydellisen vaiheittaisen oppaan löydät osoitteesta Always On -saatavuusryhmien täydellinen opas.

2.3 Paras

Kriittiset tietokannat, jotka eivät vaadi datan menetystä ja automaattista vikasietoisuutta;
työkuormat, jotka tarvitsevat luettavia toissijaisia tiedostoja raportointia tai varmuuskopioiden purkamista varten;
useissa toimipisteissä toteutettavat käyttöönotot katastrofien palautumista varten;
ympäristöissä, joissa ei ole olemassa jaettua tallennusinfrastruktuuria.

2.4 Hyödyt

Jaettua tallennustilaa ei tarvita — jokainen replika käyttää erillistä paikallista tallennustilaa;
tukee sekä HA:ta että DR:ää yhdessä kokoonpanossa;
luettavat toissijaiset osat vähentävät ensisijaisen osaston työmäärää;
Tietokantatason tarkkuus mahdollistaa erilaiset vikasietokäytännöt tietokantaryhmää kohden.

2.5 Miinukset

Vaatii Enterprise Editionin kaikkien ominaisuuksien käyttöön (vakioversio tukee Basic AG:tä merkittävin rajoituksin);
synkroninen vahvistustila lisää kirjoituslatenssin, joka on verrannollinen verkon edestakaiseen matkaan;
kirjautumiset, SQL Agent -työt ja linkitetyt palvelimet vaativat manuaalisen synkronoinnin SQL Server 2019 ja sitä vanhemmat;
Kaikkien replikoiden on sijaittava saman Windows Serverin vikasietoklusterin solmuissa.

2.6 Viitteet

Microsoftin virallinen dokumentti: Mikä on Always On -käytettävyysryhmä?
Microsoftin virallinen dokumentti: Always On -saavutettavuusryhmien käytön aloittaminen

3. Always On -vikasietoklusterin instanssit

Always On -viansietoklusterin instanssit (FCI) tarjoaa instanssitason korkean käytettävyyden suorittamalla yhden SQL Server esiintymä useissa fyysisissä solmuissa, jotka jakavat saman tallennustilan. Kun aktiivinen solmu vikaantuu, SQL Server valmiustilassa oleva instanssi käynnistetään automaattisesti uudelleen, mikä tekee siirtymisestä läpinäkyvää asiakassovelluksille.

3.1 Tärkeimmät ominaisuudet

Instanssitason vikasietoisuus: kaikki instanssin tietokannat siirtyvät vikasietoisuuteen yhdessä yhtenä yksikkönä;
jaettu tallennustila (Storage Area Network (SAN), iSCSI, Storage Spaces Direct tai SMB), johon kaikki solmut pääsevät;
virtuaaliverkon nimi ja virtuaalinen IP-osoite tarjoavat vakaan yhteyspisteen riippumatta siitä, mikä solmu on aktiivinen;
Windows Serverin vikasietoklusterointi hallitsee solmujen kunnonvalvontaa, koorumia ja vikasietoisuuden orkestrointia;
tukee aktiivinen/valmiustila-, aktiivinen/aktiivinen-, N+1- ja N+M-solmukonfiguraatiotyyppejä.

3.2 Käyttöönoton vaiheet

Jaetun tallennustilan valmistelu ja liittäminen kaikkiin klusterisolmuihin;
Asenna vikasietoklusterointiominaisuus ja vahvista klusterin kokoonpano;
luo Windows Serverin vikasietoklusteri ja määritä koorumi;
suorita SQL Server asennus valitsemalla vikasietoklusterivaihtoehdon ja määrittämällä virtuaaliverkon nimen ja jaetut tallennuspolut;
lisää lisää solmuja SQL Server vikasietoklusterin instanssi;
Tarkista vikasietotoiminto testaamalla manuaalista vikasietoa solmujen välillä.

Täydellisen vaiheittaisen oppaan löydät osoitteesta SQL Server Vikasietoklusterin täydellinen opas.

3.3 Paras

Ympäristöt, joissa on olemassa oleva jaettu tallennusinfrastruktuuri (SAN tai iSCSI);
sovellukset, jotka vaativat instanssitason vikasietoisuutta, jossa kaikkien tietokantojen on toimittava yhdessä vikasietoisesti;
skenaariot, joissa asiakkaan läpinäkyvyys on kriittistä eikä sovelluspuolen muutoksia hyväksytä;
organisaatiot, jotka priorisoivat yhden instanssin vikasietomallin yksinkertaisuutta.

3.4 Hyödyt

Automaattinen vikasietoisuus instanssitasolla ilman asiakkaan uudelleenkonfigurointia;
ei datan replikointikuormitusta — kaikki solmut käyttävät samaa tallennustilaa;
ennustettava vikasietoisuus kaikille tietokannoille samanaikaisesti;
tukee joustavia solmukonfiguraatioita (aktiivinen/aktiivinen, N+1, N+M) laitteiston käytön optimoimiseksi.

3.5 Miinukset

Jaettu tallennustila on mahdollinen yksittäinen vikaantumispiste, ellei tallennustila itsessään ole redundantti;
vain yksi solmu toimii SQL Server kerrallaan — ei lukukuormituksen tasapainotusta toissijaisilla solmuilla;
ei sisäänrakennettua katastrofien jälkeistä palautusta ilman pariliitosta saatavuusryhmään;
Jaettu tallennusinfrastruktuuri lisää kustannuksia ja monimutkaisuutta AG:hen verrattuna.

3.6 Viitteet

Microsoftin virallinen dokumentti: Always On -viansietoklusterin instanssit (SQL Server)

4. Yhdistä saatavuusryhmät vikasietoklusterin instanssien kanssa

Organisaatioille, jotka tarvitsevat sekä instanssi- että tietokantatason suojausta, SQL Server tukee saatavuusryhmien replikoiden isännöintiä vikasietoklusterin instanssien (FCI) avulla. Tässä kokoonpanossa jokainen FCI-solmu toimii yhtenä saatavuusreplikana, joten FCI-vikasietoisuus on läpinäkyvä saatavuusryhmälle, kun taas AG-vikasietoisuus tarjoaa tietokantatason suojauksen eri toimipisteissä. Tämä yhdistelmä tarjoaa kattavimman saatavilla olevan korkean käytettävyyden ja katastrofien jälkeisen palautuksen kattavuuden. SQL Server.

4.1 Tärkeimmät ominaisuudet

Kaksikerroksinen vikasietoisuus: FCI käsittelee instanssitason solmuvirheet; AG käsittelee sivustotason tai replikatason virheet;
Jokainen FCI lasketaan yhdeksi replikaksi saatavuusryhmässä riippumatta siitä, kuinka monta solmua FCI sisältää;
FCI:n isännöimät replikat vaativat edelleen jaettua tallennustilaa FCI:n vakiovaatimusten mukaisesti;
FCI-palvelimissa isännöidyt AG-replikat tukevat vain manuaalista vikasietoisuutta – automaattinen vikasietoisuus ei ole käytettävissä FCI-isännöidyissä replikoissa;
Erilliset instanssit voivat osallistua samaan saatavuusryhmään FCI:n isännöimien replikoiden rinnalla.

4.2 Käyttöönoton vaiheet

Ota käyttöön ja validoi jokainen FCI itsenäisesti noudattaen FCI:n vakioasennusmenettelyjä;
varmista, että kaikki FCI-solmut ja erilliset replikasolmut kuuluvat samaan Windows Serverin vikasietoklusteriin;
ota Always On Availability Groups -ominaisuus käyttöön jokaisessa FCI-instanssissa;
varmistaa, ettei mikään yksittäinen WSFC-solmu isännöi kahta saman saatavuusryhmän replikaa mahdollisen FCI-vikasietoisuuden jälkeen;
luo saatavuusryhmä, määritä FCI-instanssit replikoiksi ja määritä manuaalinen vikasietotila kaikille FCI:n isännöimille replikoille;
siemennä toissijaiset replikat ja määritä saatavuusryhmän kuuntelija.

Katso FCI-asetusten tiedot osoitteesta SQL Server Vikasietoklusterin täydellinen opas. Katso AG:n asennusohjeet Always On Availability Groups -oppaastamme.

4.3 Paras

Kriittiset ympäristöt, jotka vaativat suojausta sekä yksittäisten solmujen vikoja että toimipaikkatason katastrofeja vastaan;
organisaatiot, jotka jo käyttävät FCI:tä ja joiden on lisättävä toimipaikkojen välinen katastrofien palautus;
säännellyt toimialat, joilla maksimaalisen tietosuojan ja saatavuuden palvelutasosopimukset ovat pakollisia;
laajamittaiset käyttöönotot, joissa instanssitason ja tietokantatason vikasietokäytäntöjen on oltava voimassa rinnakkain.

4.4 Hyödyt

Maksimaalinen suojaus: FCI käsittelee solmujen viat, AG käsittelee sivustojen viat;
FCI-vikasietoisuus on läpinäkyvä saatavuusryhmälle – AG ei näe replikan muutosta FCI-vikasietoisuuden aikana;
joustava topologia: sekoita FCI:n isännöimiä ja erillisiä replikoita samaan saatavuusryhmään.

4.5 Miinukset

FCI-isännöidyt replikat tukevat vain manuaalista AG-vikasietoa – automaattinen AG-vikasieto ei ole käytettävissä näille replikoille;
vaatii huolellista WSFC-solmujen suunnittelua, jotta estetään yhden solmun isännöimästä kahta saman AG:n kopiota FCI-vikasietoisuuden jälkeen;
korkeammat infrastruktuurikustannukset ja operatiivinen monimutkaisuus kuin pelkästään AG:llä tai FCI:llä;
jaettua tallennustilaa tarvitaan edelleen jokaiselle FCI-komponentille.

4.6 Viitteet

Microsoftin virallinen dokumentti: Vikasietoklusterointi ja aina päällä olevat saatavuusryhmät (SQL Server)
Microsoftin virallinen dokumentti: Mikä on Always On -käytettävyysryhmä?
Microsoftin virallinen dokumentti: Always On -saavutettavuusryhmien käytön aloittaminen
Microsoftin virallinen dokumentti: Always On -viansietoklusterin instanssit (SQL Server)

5. Always On -ratkaisujen vertailu

5.1 Ominaisuuksien vertailutaulukko

Ominaisuus	Saatavuusryhmät	Vikasietoklusterin instanssit	AG + FCI -yhdistelmä
Vikasietoisuusalue	Tietokantataso	Instanssitason	molemmat
Jaettu tallennustila vaaditaan	Ei	Kyllä	Kyllä (FCI-komponentille)
Tietojen replikointi	Lokipohjainen kullekin replikalle	Ei mitään (jaettu tallennustila)	Lokipohjainen FCI:den välillä
Automaattinen vikasieto	Kyllä (synkroniset kopiot)	Kyllä	FCI: Kyllä; AG: Ei
Luettavat toissijaiset osat	Kyllä	Ei	Kyllä (AG-komponentti)
katastrofipalautuksen	Sisäänrakennettu	Ei sisäänrakennettu	Sisäänrakennettu
Maksimaalinen määrä kopioita	9 (yritys)	N / A	9 (yritys)
Infrastruktuurin monimutkaisuus	Keskikova	Keskikova	Korkea
Hinta	Alempi (ei SAN-verkkoa tarvita)	Korkeampi (SAN vaaditaan)	Korkein

5.2 Valitse aina käytettävissä oleva ratkaisu

Aloita tallennusinfrastruktuuristasi: jos sinulla ei ole olemassa jaettua tallennustilaa, saatavuusryhmät (Available Groups) ovat luonnollinen valinta ja kustannustehokkain tapa sekä HA- että DR-ominaisuuksiin. Jos käytät jo SAN-ympäristöä ja tarvitset instanssitason vikasietoisuutta, FCI on yksinkertaisempi vaihtoehto – mutta suunnittele AG:n lisäämistä myöhemmin, jos sivustojen välinen DR on tulevaisuudessa vaatimus.

Valitse AG + FCI -yhdistelmä vain, kun sinulla on aito tarve molemmille suojauskerroksille ja operatiivinen kypsyys lisääntyneen monimutkaisuuden hallitsemiseksi. Keskeinen muistettava rajoitus on, että FCI:n isännöimät AG-replikat eivät tue automaattista AG-vikasietoisuutta, joten tämä topologia vaatii manuaalisia toimia saatavuusryhmätason vikasietoisuuksien varalta.

Useimmille uusille käyttöönottoille nykyään suositeltu lähtökohta on Always On Availability Groups: se kattaa sekä HA:n että DR:n, ei vaadi jaettua tallennustilaa ja tukee luettavia toissijaisia osioita – ominaisuuksia, joihin FCI yksinään ei pysty.

6. Parhaat käytännöt SQL Server Aina saatavilla olevat ratkaisut

6.1 Suunnittelu ja suunnittelu

Määritä RTO- ja RPO-vaatimukset ennen Always On -ratkaisun valitsemista – nämä tavoitteet määrittävät suoraan, onko synkroninen vai asynkroninen vahvistustila sopiva ja onko automaattinen vikasietoisuus mahdollinen.
Mitoita toissijaisten replikoiden kokoa siten, että ne käsittelevät koko ensisijaisen työkuorman vikasietotilanteen aikana, mukaan lukien huippukuormitusskenaariot.
AG-käyttöönotoissa synkroniset replikat kannattaa sijoittaa samaan konesaliin tai matalan latenssin verkkoon kirjoitusviiveen vaikutuksen minimoimiseksi. Varaa asynkroninen tila maantieteellisesti kaukana sijaitseville DR-replikoille.
Suunnittele päätösvaltaisuus parittomalle määrälle ääniä. Lisää kahden solmun klustereihin tiedostonjako tai pilvitodistaja kolmantena äänenä aivojen jakamisen estämiseksi.
Suunnittele verkkotopologiasi huolellisesti usean aliverkon käyttöönottoja varten. Jokainen aliverkko vaatii oman kuuntelijan IP-osoitteen, ja asiakkaiden yhteysmerkkijonoissa on oltava MultiSubnetFailover=True.

6.2 Toteutusohjeet

Käytä johdonmukaisesti SQL Server versio-, painos- ja kumulatiiviset päivitystasot kaikissa replikoissa. Sekalaiset korjaustiedostotasot voivat aiheuttaa odottamatonta toimintaa vikasietoisuuden aikana.
Määritä klusterin syketietoliikenteelle erilliset verkkoliitännät sovellusliikenteestä erillään.
Ota automaattinen siementen määrä käyttöön tietokannan alkusynkronointia varten kohdassa SQL Server 2016 ja uudemmat versiot – se poistaa tarpeen kopioida varmuuskopioita manuaalisesti toissijaisiin replikoihin useimmissa tilanteissa.
AG + FCI -topologioissa varmista jokaisen FCI-solmun määritysmuutoksen jälkeen, ettei mikään yksittäinen WSFC-solmu voi isännöidä kahta saman saatavuusryhmän replikaa.
Käytä aina SQL Server Management Studio tai Transact-SQL saatavuusryhmien vikasietoisuuksien hallintaan – älä koskaan käytä vikasietoklusterin hallintaa suoraan, koska se ei ole tietoinen AG-synkronoinnin tilasta ja voi aiheuttaa pitkittyneitä käyttökatkoksia tai tietojen menetystä.

6.3 Valvonta ja ylläpito

Seuraa synkronoinnin kuntoa, lähetä jono ja tee jono uudelleen säännöllisesti saatavuusryhmän koontinäytön avulla. SQL Server Management Studio tai dynaamiset hallintanäkymät (DMV). Kasvava uudelleentoistojono toissijaisella palvelimella osoittaa I/O-pullonkaulaa, joka viivästyttää vikasietoisuuden palautumista.
Suorita DBCC CHECKDB toissijaisille replikoille siirtääksesi eheystarkistusten kuormituksen ensisijaisilta replikoilta. Katso lisätietoja. DBCC CHECKDB -opas lisätietoja.
käyttää SQL Server Päivitysten tekeminen rullaavilla päivityksillä: korjaa ensin toissijaiset replikat, suorita suunniteltu manuaalinen vikasietoisuus korjattuun toissijaiseen replikaan ja korjaa sitten entinen ensisijainen replika. Tämä rajoittaa seisokkiajan yhden vikasietoisuuden kestoon.
Testaa vikasietoisuutta säännöllisesti muissa kuin tuotantoympäristöissä. Automaattinen vikasietoisuus, jota ei ole koskaan testattu, ei ole luotettava palautusstrategia.
Määritä hälytykset saatavuusryhmän terveystilan muutoksille, replikaroolien siirtymille ja synkronointivirheille käyttämällä SQL Server Agentti tai erillinen valvontatyökalu, kuten SQL Server Performance Monitor.

7. Ohje

K: Mikä on SQL Server Aina päällä?

A: SQL Server Always On on Microsoftin korkean käytettävyyden ja katastrofien palautumisen alusta, joka esiteltiin vuonna SQL Server 2012. Se kattaa kaksi teknologiaa – Always On Availability Groupsin ja Always On Failover Cluster Instancesin – jotka tarjoavat automaattisen vikasietoisuuden, tietojen redundanssin ja jatkuvan pääsyn tietokantoihin laitteisto-, ohjelmisto- tai sivustovikojen sattuessa.

K: Mitä eroa on Always On -käyttöoikeusryhmillä ja vikasietoklusterin instanssilla?

A: Saatavuusryhmät toimivat tietokantatasolla, replikoivat tietoja itsenäisiin toissijaisiin replikoihin lokien toimituksen kautta eivätkä vaadi jaettua tallennustilaa. Vikasietoklusterin instanssit toimivat instanssitasolla, vaativat jaettua tallennustilaa, johon kaikilla solmuilla on pääsy, ja ne suorittavat vikasietoisuuden kaikissa tietokannoissa yhdessä yhtenäisenä yksikkönä. AG tukee luettavia toissijaisia replikoita ja sisäänrakennettua DR:ää; FCI ei.

K: Tarvitsenko jaettua tallennustilaa Always On -käyttöoikeusryhmiä varten?

A: Ei. Jokainen AG-replika ylläpitää omaa itsenäistä kopiotaan tietokannoista paikallisessa tallennustilassa. Jaettua tallennustilaa tarvitaan vain, jos käytät vikasietoklusterin instansseja AG-replikoiden isännöintiin.

K: Voinko käyttää Always On -toimintoa seuraavien kanssa: SQL Server Standard-versio?

A: SQL Server Standard Edition tukee peruskäytettävyysryhmiä, jotka alkavat SQL Server 2016, mutta merkittävin rajoituksin: yksi tietokanta AG:tä kohden, enintään kaksi replikaa eikä luettavaa toissijaista tukea. FCI on saatavilla Standard Editionissa ilman näitä rajoituksia. Täydellinen Always On -toiminto vaatii Enterprise Editionin.

K: Mikä on replikoiden enimmäismäärä saatavuusryhmässä?

A: SQL Server Enterprise Edition tukee jopa yhdeksää replikaa: yhtä ensisijaista ja kahdeksaa toissijaista replikaa. Hajautetut saatavuusryhmät voivat laajentaa tämän 18 replikaan kahdessa erillisessä saatavuusryhmässä.

K: Voivatko FCI:n isännöimät replikat käyttää automaattista AG-vikasietoisuutta?

A: Ei. Kun saatavuusreplika isännöidään vikasietoklusterin instanssissa, automaattista saatavuusryhmän vikasietoisuutta ei tueta kyseiselle replikalle. Kaikki FCI:n isännöimiä replikoita koskevat AG-vikasietoisuudet vaativat manuaalisia toimia.

K: Mitä eroa on synkronisilla ja asynkronisilla commit-tiloilla?

A: Synkroninen vahvistustila edellyttää, että ensisijainen palvelin odottaa toissijaisen palvelimen lokitietojen vahvistamista ennen vahvistamista. Tämä varmistaa, ettei tietoja mene häviä (RPO = 0) lisääntyneen kirjoitusviiveen kustannuksella. Asynkroninen vahvistustila sallii ensisijaisen palvelimen vahvistaa tiedot odottamatta, mikä vähentää viivettä, mutta lisää tietojen menetyksen riskiä, jos ensisijainen palvelin kaatuu ennen kuin toissijainen palvelin vastaanottaa kaikki lokitiedot. Käytä synkronista tilaa paikallisille HA-replikoille ja asynkronista tilaa etäisille DR-replikoille.

K: Kuinka kauan kestää SQL Server Aina vikasietotilassa?

A: Synkronisen AG-replikan automaattinen vikasietoisuus kestää yleensä alle 30 sekuntia normaaleissa olosuhteissa. FCI:n vikasietoisuus kestää yleensä 20–60 sekuntia tietokannan palautusajasta riippuen. Todellinen kesto riippuu työmäärästä, tietokannan koosta ja WSFC:ssä määritetyistä terveystarkistuksen aikakatkaisuasetuksista.

K: Mitä asiakasyhteyksille tapahtuu vikasietoisuuden aikana?

A: Olemassa olevat yhteydet katkeavat vikasietoisuuden yhteydessä. Sovellukset, jotka käyttävät saatavuusryhmän kuuntelijaa ja sisältävät yhteyden uudelleenyrityslogiikan, muodostavat automaattisesti yhteyden uuteen ensisijaiseen verkkoon vikasietoisuuden valmistuttua. MultiSubnetFailover=True-asetuksen lisääminen yhteysmerkkijonoihin parantaa uudelleenyhteyden muodostamisen nopeutta usean aliverkon käyttöönotoissa.

K: Miten teen hakemuksen SQL Server korjauspäivityksiä minimaalisella käyttökatkoksella Always On -ympäristössä?

A: Käytä jatkuvaa päivitystä: korjaa ensin toissijaiset replikat, suorita sitten suunniteltu manuaalinen vikasietoisuus korjattuun toissijaiseen replikaan ja lopuksi korjaa entinen ensisijainen replika. Tämä rajoittaa seisokkiajan yhden suunnitellun vikasietoisuuden kestoon – tyypillisesti alle minuuttiin.

K: Voinko yhdistää Always On -käyttöoikeusryhmät vikasietoklusterin instanssien kanssa?

V: Kyllä. Voit isännöidä AG-replikoita FCI-instansseissa sekä instanssi- että tietokantatason vikasietoisuuden saavuttamiseksi. Jokainen FCI lasketaan yhdeksi AG-replikaksi. Tämä topologia vaatii huolellista WSFC-solmujen suunnittelua sen varmistamiseksi, ettei yksikään solmu isännöi kahta saman AG:n kopiota mahdollisen FCI-vikasietoisuuden jälkeen.

K: Mitä minun pitäisi tehdä, jos tietokantani vioittuu Always On -ympäristössä?

A: Tarkista ensin, onko vioittunut kaikki replikat vai vain ensisijainen. Jos toimiva toissijainen varmuuskopio on olemassa, siirry siihen välittömästi. Jos kaikki replikat ovat vioittuneet, palauta tiedot puhtaasta varmuuskopiosta. Suorita DBCC CHECKDB säännöllisesti toissijaisille replikoille havaitaksesi vioittumisen varhaisessa vaiheessa. Jos myös varmuuskopiot ovat vioittuneet, erikoistunut... SQL Server tietojen palautustyökalu voi yrittää poimia tietoja vaurioituneista MDF-tiedostoista viimeisenä keinona.

K: Miten Always On Availability Groups vertautuu vanhempiin ryhmiin SQL Server HA-ratkaisut?

A: AG korvaa vanhemmat teknologiat, kuten tukkilähetys ja replikointiLokien lähetys vaatii manuaalisen vikasietoisuuden, eikä siinä ole automaattista roolinvaihtoa; replikointi on suunniteltu tiedon jakeluun eikä HA:han. AG tarjoaa automaattisen vikasietoisuuden, ei lainkaan tiedon menetystä synkronisella vahvistuksella ja luettavat toissijaiset lokit – ominaisuuksia, joita nämä teknologiat eivät pysty tarjoamaan.

8. Päätelmä

SQL Server Always On tarjoaa joustavan, yritystason alustan korkeaan käytettävyyteen ja katastrofien jälkeiseen palautukseen. Always On Availability Groups on oikea valinta useimpiin nykyaikaisiin käyttöönottoihin: se poistaa jaetun tallennustilan tarpeen, tukee luettavia toissijaisia tallennuksia ja käsittelee sekä paikallisen HA:n että sivustojen välisen DR:n yhdessä kokoonpanossa. Vikasietoklusterin instanssit ovat edelleen vakaa vaihtoehto, kun instanssitason vikasietoisuus ja olemassa oleva jaettu tallennusinfrastruktuuri ovat ensisijaisia vaatimuksia. Molempien teknologioiden yhdistäminen tarjoaa syvimmän saatavilla olevan suojauksen – suurempien infrastruktuuri-investointien ja toiminnan monimutkaisuuden hinnalla.

Valitsetpa minkä tahansa ratkaisun, perusasiat ovat samat: määritä ensin RTO- ja RPO-vaatimukset, suunnittele topologiasi näiden tavoitteiden ympärille ja testaa vikasietoisuutta säännöllisesti. Hyvin toteutettu ja perusteellisesti testattu Always On -ratkaisu palautuu ennustettavasti tuotantohäiriöiden sattuessa.

kirjailijasta

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

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

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

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