Az AWS RDS szolgáltatását azok veszik igénybe, akiknek menedzselt adatbázisszerverre van szükségük. Nem a felhasználó dolga az operációs rendszer vagy az adatbázismotor frissítése, neki csak használnia kell a az adatbázist.

AWS RDS a következő adatbázis-motorokkal használható:

• MySQL,
• MariaDB,
• PostgreSQL,
• Microsoft SQL,
• Oracle,
• illetve az AWS saját rendszere, az Aurora, ami lehet MySQL- vagy PostgreSQL-kompatibilis.

Ha követjük a korszerű alkalmazás-tervezés irányelveit, akkor az adatainkat szinte bizonyosan valamilyen adatbázisban vagy magas rendelkezésre állású fájltároló-megoldásban tároljuk. Fájlok tárolására az AWS-ben lehetőség szerint S3-at használunk, és ilyenkor gyakorlatilag nem kell törődnünk a biztonsági mentésekkel - bár vannak rá megoldások, ha valamiért mégis szükségesnek érezzük ezt. Hasonló a helyzet az AWS NoSQL-megoldásában, a DynamoDB-ben tárolt adatokkal.

Az SQL-adatbázisban tárolt adatokkal azonban más a helyzet. Ennek oka nem más, mint az, hogy az RDS szolgáltatás menedzselt adatbázis-szerverei lényegében ugyanolyan virtuális gépek, mint az általunk telepített EC2-példányok, ennélfogva ugyanazok a veszélyek leselkednek rájuk:

• a hypervisor hibái,
• a virtuális gép hibái (van, amit az RDS mint szolgáltatás tud kezelni, és van, amit nem),
• a háttértár hibái (Az EBS-kötetek az AWS saját statisztikái szerint is a legmegbízhatatlanabb tárolási szolgáltatást jelentik, bár még mindig hússzor megbízhatóbbnak tekinthetők a hagyományos merevlemezeknél.),
• és hálózati hibák.

Az utolsóként említett típus kivételével a felsoroltak szinte bizonyosan "katasztrófa utáni hellyreállítást", magyarul Disaster Recoveryt tesznek szükségessé. És ne feledjük, nem az a kérdés, hogy lesz-e katasztrófa, hanem csak az, hogy mikor. Az alábbiakban áttekintünk pár lehetőséget, mégpedig úgy, hogy egyre szigorúbb RPO- és RTO-követelményeknek felelhessünk meg. (Az RPO és az RTO egyaránt időtartamot fejez ki. Az RPO megmutatja, hogy az utolsó mentéstől a katasztrófa bekövetkeztéig mennyi időn keresztül veszhetnek el az adataink. Az RTO pedig azt jelzi, hogy a hiba fellépése és az üzemszintű működés helyreállása között mennyi idő telik el.)

Egyetlen AZ-ben futó adatbázisszerver

Az egyetlen Availability Zone-ban futó RDS-szerver a legolcsóbb, ugyanakkor a meghibásodásnak leginkább kitett megoldás. A szerverről automatikusan készül inkrementális napi mentés, ami már nem EBS-en tárolódik, hanem S3-ba kerül, és így bátran tekinthetjük úgy, hogy ez a mentés biztonságban van. Készül róla ugyanakkor tranzakciónapló is, nagyjából ötpercenkénti mentéssel. A mentés ismét S3-ba kerül, azaz biztonságosnak tekintjük, és point-in-time helyreállítást tesz lehetővé, azaz ha nekünk a hét perccel ezelőtti állapotra van szükségünk, akkor majdnem biztosan meglesz, a tizenegy perccel ezelőtti pedig meglesz (amennyire ezt biztonságosan ki lehet jelenteni - jelen sorok írója elég régen dolgozik az informatikában ahhoz, hogy tudja, hogy csak az biztos, ami megtörtént). Mit is jelent ez számunkra?

RDS-által kezelt virtuálisgép-hibák esetén az RDS Event Notification jóvoltából értesülünk a hibáról, de a szerver továbbra is elérhető státuszú marad. Az RDS szolgáltatás ilyenkor új gépet indít, és csatolja hozzá az adatokat tároló EBS-kötetet. A gép ugyanabban az AZ-ben indul, ahol az az előző is volt (hiszen az EBS-kötet léte AZ-hez kapcsolódik), a végpont neve nem változik, azaz az alkalmazásnak nem kell szólnunk a dologról. Ilyenkor

• az RPO nulla, lévén adat nem veszett el (legfeljebb az épp leírásra várók),
• az RTO pedig rendszerint fél óra alatti.

Vannak olyan hibák, amiket az RDS-szolgáltatás képtelen kezelni, ide tartoznak például az EBS-kötet meghibásodásával járó helyzetek. A szerverünk állapota ezekben az esetben elérhetetlenre módosul. Ilyen esetekben be kell kalkulálnunk

• nagyjából öt perces RPO-t (a pontos érték lekérdezhető a LatestRestorableTime kiolvasásával) és
• pár perc - pár óra RTO-t.

Miért ilyen nagy az utóbbi érték? Mert a helyreállítást kézzel vagy szkripttel kell elindítanunk, és új RDS-példány létrehozásával jár. Maga a helyreállítás is lehet igen hosszú egy méretesebb adatbázisnál, de még azzal is kell törődnünk, hogy az alkalmazás tudomására hozzuk a mostantól használandó adatbázis-végpont nevét. Jól tervezett alkalmazásnál ez nem idő, de nem mindig vagyunk szerencsések. Alternatívaként lehetőség van az új példány átnevezésére is.

Hálózati hibák esetén is lehet teendőnk, mert ha egy egész Availability Zone válik elérhetetlenné, akkor még mindig tudunk az előző esetben tárgyalt point-in-time helyreállítást kezdeményezni, ezúttal egy másik AZ-be kérve a helyreállított (új) RDS-szervert. Az RPO ilyenkor nyilván nem nő meg, de az RTO attól függően, hogy az AZ mennyire volt bedrótozva az alkalmazásunkba, mennyire volt dokumentálva, volt-e hozzá például frissen tartott CloudFormation leírófájlunk, igen fájdalmasan megnőhet. Ugyanakkor AZ-kiesések nem történnek minden nap, érdemes átgondolni, hogy megéri-e ekkora kiesésre is tervezni. Ha igen, ha elég fontos a szolgáltatás, akkor esetleg jobb ötlet már eleve több AZ-ben futtatni az adatbázis-szerverünket.

Multi-AZ, azaz több zónában futó adatbázisszerver

A Multi-AZ adatbázisszerver lényegében azt jelenti, hogy a régióban fut még egy adatbázis-szerver virtuális gépünk. Ez a második gép szigorúan nem abba az AZ-be kerül, ahova az elsődleges szerver, és nem is látjuk, hogy pontosan merre van, csak akkor, ha kifejezetten kutatunk utána. Végső soron annyira nem is érdekes, hogy merre van, hiszen csak akkor válik fontossá a jelenléte, ha az elsődleges szerver elérhetetlenné vált. Ha ez bekövetkezik, akkor a végpont (a szerver DNS-neve) automatikusan a másodlagos szerver IP-címére oldódik fel, tehát az eseményt az alkalmazásunk jó eséllyel észre sem veszi. Hogyan alakul a két mutatónk ezúttal?

• Lévén a másodlagos példány egy-két másodperces késéssel replikálta az elsődlegesnek minden adatát, az RPO lényegében nulla,
• az RTO pedig egy-két perc: ennyi kell, amíg a monitorozó rendszer észreveszi az elsődleges szerver hibáját és frissíti a DNS-szerver bejegyzését.

Ha nem valamelyik "hagyományos" adatbázis-megoldást használjuk, hanem Aurora mellett döntünk, a mutatóink esetleg nem változnak, de a valóságban mégis jobb lesz a helyzet, lévén az Aurora a régió három AZ-jében tart fenn két-két másolatot, a fájlrendszeren tárolt adatok pedig tíz gigabájtos darabokba tagolódnak, azaz egy diszk-alrendszerbeli hiba esetén ennyi adat visszamásolásával kell számolni, és mindez beavatkozás nélkül történik.

Egész régió kiesése esetén

Ebben az esetben két megoldásunk lehet. Ha mi magunk akarunk hegeszteni - akár, mert szeretjük az ívfényt, akár, mert az Oracle vagy MS-SQL licencelésünk olyan -, akkor például tehetjük azt is, hogy

• Periodikusan másolatot készíttetünk az RDS-példányunról:
  1. A CloudWatch Events használatával n óránként elindítunk egy olyan Lambda-függvényt, amelyik snapshotot készít az RDS-példányunkról,
  2. bekapcsoljuk az RDS-események szolgáltatást, és a backup eseményekre figyelünk,
  3. az eseményeket SNS-topicba vezetjük,
  4. és a topic célpontjául megadott Lambda átmásolja a snapshotot egy másik régióba.
• Észrevesszük a karasztrófát, és elindítjuk az RDS-példányunkat:
  1. Az RDS-események közül ezúttal azokat figyeljük, amik az elérhetetlenné válást jelzik,
  2. az eseményeket most is SNS-topicba vezetjük,
  3. a topic célpontjául megadott Lambda dolga, hogy elindítsa az RDS-példányt,
  4. és az alkalmazás tudomására hozza az RDS-végpont nevét.

Mint látható, ezzel a megoldással meglehetős RPO-val kell számolnunk. Ha ez nem elfogadható, akkor természetesen van gyorsabb (és drágább) megoldás: Cross-Region Read Replicat üzemeltetünk egy másik régióban (akár MySQL, akár PostgreSQL, akár Oracle esetében), vagy bevetjük az igazi nagyágyút, az Aurora Global Databases-t. Ez utóbbiban PostgreSQL-kompatibilitás esetén pár napja lehetőségünk van a menedzselt RPO-k használatára is, ami röviden összefoglalva a következőt jelenti:

• Megadjuk a maximálisan elfogadható késleltetést, ennél nagyobb nem lehet a lag az elsődleges (írható) adatbázis-szerver és a másodlagos (olvasható) szerverek között (20 másodperc - 68 év intervallumban).
• Ha a lag legalább az egyik másodlagos szerveren ez alatt az érték alatt marad, akkor mehetnek a tranzakciók az elsődleges szerveren.
• Ha mindenhol (akár öt másodlagos régió is definiálható) rosszabb a helyzet, akkor az Aurora PostgreSQL blokkolja a tranzakció-kommitokat. Ilyenkor esemény kerül a PostgreSQL-naplófájlba, és olyan wait esemény is létrejön, ami a blokkolt munkameneteket jeleníti meg.
• Amikor valamelyik másodlagos régió ismét elég gyorsan fogadja az adatokat, megszűnik a blokkolás.

És bár említettük, hogy a katasztrófával kapcsolatban nem az a kérdés, hogy lesz-e, hanem az, hogy mikor, most mégis azzal a jókívásággal búcsúzunk, hogy készíts jó disaster recovery tervet, amit aztán soha nem kell használnod.