DevOps-inseneride, andmebaasiadministraatorite (DBA) ja IT-süsteemiarhitektide jaoks on taasteaja eesmärk (RTO) ja taastepunkti eesmärk (RPO) enamat kui lihtsalt äritegevuse järjepidevuse moesõnad – need on ranged insenertehnilised piirangud. Kriitilise tähtsusega andmebaaside haldamisel võib nende mõõdikute ebatäpne arvutamine, planeerimine ja valideerimine põhjustada katastroofilist andmekadu ja pikaajalist seisakut.
Kaasaegsetes ettevõttekeskkondades nõuab RTO ja RPO arvutamine sügavaid teadmisi andmebaaside sisemusest, salvestusruumi I/O-st, võrgu läbilaskevõimest ja tehingulogide mehaanikast. See juhend uurib tehnilisi metoodikaid RTO ja RPO arvutamiseks, testimiseks ja optimeerimiseks tootmisandmebaaside süsteemides.
RPO (taastepunkti eesmärk) lahtivõtmine andmebaasisüsteemides
RPO määratleb maksimaalse vastuvõetava andmekao suuruse ajas mõõdetuna. Kui teie RPO on 15 minutit, tähendab kell 12:00 toimunud katastroof, et peate suutma taastada kõik kinnitatud tehingud vähemalt kella 11:45-ni.
Andmebaaside puhul dikteerib RPO teie tehingulogide haldamise strateegia (WAL PostgreSQL-is, Redo Logs Oracle’is, Transaction Logs SQL Serveris).
Andmekao ja logide genereerimise mehaanika
Saavutatava RPO arvutamiseks peate esmalt mõistma oma andmebaasi tehingulogide genereerimise kiirust. Kui saadate logisid varukoopiate hoidlasse iga 15 minuti järel, kuid teie võrk ei suuda selle aja jooksul 15 minuti jagu logisid edastada, halveneb teie tegelik RPO pidevalt.
Saate oma logide genereerimise kiiruse baastaseme määrata SQL-i põhikäskude abil. Näiteks PostgreSQL-is (versioon 10+) saate mõõta Write-Ahead Log (WAL) genereerimise kiirust kindla ajavahemiku jooksul:
-- Käivitage see ajal T=0
SELECT pg_current_wal_lsn() AS start_lsn;
-- Oodake täpselt 5 minutit (300 sekundit), seejärel käivitage:
SELECT pg_current_wal_lsn() AS end_lsn,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;
Kui see päring näitab, et genereerite tippkoormuse ajal 50 MB/s WAL-andmeid, nõuab 15-minutiline RPO 45 GB logiandmete edastamist teie varukoopiate salvestusruumi. Teie võrk ja salvestusruumi sihtkohad peavad selle RPO säilitamiseks toetama püsivat kirjutamiskiirust üle 50 MB/s.
Sünkroonse ja asünkroonse replikatsiooni mõju
Paljud DBA-d toetuvad RPO täitmiseks kõrge kättesaadavuse (HA) replikatsioonile. Kuid replikatsioon ei ole varukoopia. Kustutatud tabel (DROP TABLE users;) replikeeritakse silmapilkselt.
Kui kasutate replikatsiooni katastroofi taastamiseks (DR), mõjutab replikatsioonirežiim otseselt RPO-d:
* Sünkroonne replikatsioon: Tagab nullilähedase RPO (RPO=0). Primaarne andmebaas ei kinnita tehingut enne, kui ooterežiimis olev andmebaas on selle kättesaamist kinnitanud. Kompromissiks on suurenenud latentsus primaarsetel kirjutamistoimingutel.
* Asünkroonne replikatsioon: Toob kaasa replikatsiooni viivituse. Teie RPO on tegelikult võrdne teie praeguse replikatsiooni viivitusega.
Asünkroonse replikatsiooni viivituse jälgimiseks PostgreSQL-is kasutage:
SELECT application_name,
client_addr,
state,
sync_state,
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;
RTO (taasteaja eesmärk) lahtivõtmine suuremahuliste andmebaaside jaoks
RTO on maksimaalne talutav seisakuaeg. Andmebaasi RTO arvutamine on kurikuulsalt keeruline, sest see ei ole lihtsalt failide serverisse tagasi kopeerimiseks kuluv aeg.
RTO arvutamise matemaatiline mudel
Realistlik andmebaasi RTO arvutus peab arvestama nelja erineva etapiga:
RTO = T(infra) + T(transfer) + T(restore) + T(recovery)
- T(infra) – Infrastruktuuri ettevalmistamine: Aeg asendusarvutusvõimsuse ja salvestusruumi käivitamiseks. (Võib olla peaaegu null, kui on olemas eelnevalt ettevalmistatud DR-saidid või Infrastructure-as-Code torujuhtmed).
- T(transfer) – Andmeedastus: Aeg varukoopia andmete liigutamiseks hoidlast andmebaasiserverisse.
- T(restore) – Füüsiline taastamine: Aeg andmefailide kirjutamiseks sihtkettale.
- T(recovery) – Andmebaasi avariitaaste: Aeg, mis kulub andmebaasimootoril tehingulogide uuesti esitamiseks, kinnitatud tehingute edasiviimiseks ja kinnitamata tehingute tagasipööramiseks.
Edastus- ja taastamisaegade arvutamine
T(transfer) ja T(restore) arvutamiseks peate määrama oma võrgu ribalaiuse ja ketta IOPS/läbilaskevõime baastaseme. Ärge lootke teoreetilistele maksimumidele; testige oma tegelikku infrastruktuuri.
Kasutage iperf3-e võrgu läbilaskevõime testimiseks varukoopiate hoidla ja andmebaasiserveri vahel:
# Varukoopiate hoidlas (server)
iperf3 -s
# Andmebaasiserveris (klient)
iperf3 -c <backup_repo_ip> -t 60 -P 4
Kasutage fio-d oma andmebaasi salvestusmahtude järjestikuse kirjutamise jõudluse testimiseks, simuleerides andmebaasi taastamise toimingut:
fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile
Kui teie andmebaas on 5 TB ja teie fio testid näitavad maksimaalset püsivat kirjutamiskiirust 500 MB/s, on teie absoluutne minimaalne T(restore) ligikaudu 2,8 tundi. Kui teie äri-SLA nõuab 1-tunnist RTO-d, siis traditsioonilised voogedastusel põhinevad taastamised ebaõnnestuvad. Peate oma arhitektuuri muutma salvestustaseme hetktõmmiste (snapshots) või plokktaseme replikatsiooni suunas.
Varjatud lõks: T(recovery)
Kõige sagedamini alahinnatud muutuja on T(recovery). Kui taastate iganädalase täieliku varukoopia ja peate oma RPO saavutamiseks rakendama 6 päeva tehinguloge, peab andmebaasimootor iga tehingu järjestikku uuesti esitama.
500 GB tehingulogide uuesti esitamine võib võtta tunde, olles tugevalt piiratud ühekeermelise protsessori jõudluse ja ketta IOPS-i poolt. T(recovery) minimeerimiseks suurendage oma täielike või diferentsiaalsete varukoopiate sagedust.
Lõhe ületamine: praktilised sammud RTO ja RPO valideerimiseks
Teoreetilise RTO ja RPO arvutamine on alles esimene samm. Kriitilise tähtsusega keskkonnad nõuavad pidevat valideerimist.
1. samm: Rakendage pidev arhiveerimine
Alla minutiliste RPO-de saavutamiseks ilma sünkroonse replikatsiooni jõudluse vähenemiseta rakendage pidev logide arhiveerimine. Selle asemel, et oodata logifaili täitumist (mis võib madala liiklusega perioodidel võtta tunde), sundige logide vahetamist regulaarsete ajavahemike järel.
SQL Serveris saate sagedasi tehingulogide varukoopiaid automatiseerida:
BACKUP LOG [MissionCriticalDB]
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'MissionCriticalDB-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
Parim tava: Planeerige see töö käivituma iga 1–5 minuti järel, sõltuvalt teie RPO nõuetest.
2. samm: Automatiseerige taastamise testimine
Testimata varukoopia on vaid teoreetiline kontseptsioon. Oma arvutatud RTO tagamiseks peate läbi viima automatiseeritud taastamise testimise.
Ettevõtte varundusplatvormid nagu CloudSave lihtsustavad seda, pakkudes automatiseeritud ja isoleeritud taastamise testimist. CloudSave saab automaatselt käivitada liivakastikeskkonna, ühendada uusima varukoopia, teostada täieliku andmebaasi taastamise ja käivitada kohandatud valideerimisskripte (nt DBCC CHECKDB SQL Serveri jaoks), et mõõta täpset RTO-d ja tagada andmete terviklikkus. See muudab RTO arvutatud oletusest tõestatud ja raporteeritavaks mõõdikuks.
3. samm: Jälgige ja teavitage SLA rikkumistest
Teie seirepinu (Prometheus, Datadog, Zabbix) peaks aktiivselt jälgima mõõdikuid, mis ohustavad teie RTO/RPO SLA-sid. Teavitamisreeglid tuleks konfigureerida järgmisteks juhtudeks:
* Varundustööde ebaõnnestumised: Otsene oht RPO-le.
* Logide edastamise latentsus: Kui logide edastamine võtab kauem aega kui genereerimise intervall.
* Salvestusruumi IOPS-i piiramine: Pilveteenuse pakkujad (nagu AWS EBS) piiravad IOPS-i, kui “burst”-krediidid on ammendatud, mis hävitab tegeliku hädaolukorra ajal vaikselt teie RTO.
Andmebaasi varundusarhitektuuri optimeerimine rangete SLA-de täitmiseks
Kui matemaatilised arvutused näitavad, et teie praegune arhitektuur ei suuda äri-SLA-sid täita, peate oma varundusstrateegiat optimeerima.
1. Kasutage plokktaseme inkrementaalseid varukoopiaid
Traditsioonilised andmebaasi tõmmised (loogilised varukoopiad nagu pg_dump või mysqldump) on kriitilise tähtsusega RTO-de jaoks liiga aeglased. Kasutage füüsilisi plokktaseme varukoopiaid. Plokktaseme inkrementaalsed varukoopiad kopeerivad ainult neid kettaplokke, mis on pärast viimast varukoopiat muutunud, vähendades drastiliselt T(transfer)-i ja võrgu koormust.
2. Kasutage salvestusruumi hetktõmmiseid (snapshots)
Mitme terabaidiste andmebaaside puhul, mis nõuavad alla 15-minutilist RTO-d, on traditsiooniline failide kopeerimine standardvõrkude kaudu füüsiliselt võimatu. Integreerimine SAN-i või pilvepõhiste salvestusruumi hetktõmmistega (nt AWS EBS Snapshots, Pure Storage) võimaldab peaaegu hetkelist T(restore)-i. Andmebaasimootor peab seejärel teostama avariitaaste ainult hetktõmmisel.
3. Rakendage paralleelsust
Veenduge, et teie varundus- ja taastamistööriistad kasutaksid mitmelõimelisust. PostgreSQL-i andmebaasi taastamisel pgbackrest-i abil või SQL Serveri andmebaasi puhul määrake selgesõnaliselt paralleelsed töökeermed, et kasutada ära kogu saadaolev võrgu- ja kettaribalaius.
# Näide paralleelsest taastamisest pgBackRest-is
pgbackrest --stanza=prod_db --process-max=8 restore
Kokkuvõte
Kriitilise tähtsusega andmebaaside RTO ja RPO arvutamine on range süsteemitehniline harjutus. See nõuab DBA-delt vaikimisi varunduskonfiguratsioonidest kaugemale liikumist ning oma salvestusruumi I/O, võrgu läbilaskevõime ja andmebaasi taastamise mehaanika matemaatilist modelleerimist.
Logide genereerimise kiiruste baastaseme määramise, andmebaasi taastamise erinevate etappide mõistmise ja automatiseeritud testimise rakendamise kaudu tugevate platvormide (nagu CloudSave) abil saavad IT-meeskonnad enesekindlalt tagada oma katastroofi taastamise SLA-d. Pidage meeles: andmebaasi haldamise vallas ei ole lootus strateegia ja testimata varukoopiad on kohustus.
Õppige, kuidas DevOps-insenerid ja DBA-d saavad täpselt arvutada, testida ja optimeerida RTO-d ja RPO-d kriitilise tähtsusega andmebaaside jaoks, kasutades täiustatud taastamismehaanikat, CLI-tööriistu ja automatiseeritud testimist.
