Gamybos darbo krūvių valdymas priglobtose duomenų bazėse

Pateikė „Amazon“ žiniatinklio paslaugos





AWS siūlo keletą galimybių priglobti jūsų duomenų bazes, aptarnaujančias OLTP darbo krūvius – priglobkite savo valdomą duomenų bazę Amazon EC2 atvejų ar naudojimo Amazon RDS valdo AWS. RDS valdo aukštą pasiekiamumą, automatines atsargines kopijas, duomenų bazių atnaujinimus, OS pataisas, saugumą ir skaitymo kopiją. RDS taip pat siūlo vietinę debesies parinktį Amazonė-Aurora duomenų bazės variklis, suderinamas su MySQL ir PostgreSQL. Aurora užtikrina didesnį pralaidumą, palyginti su standartinėmis MySQL ir PostgreSQL duomenų bazėmis.

Vykdydami gamybos darbo krūvius priglobtose duomenų bazėse su „Amazon RDS“ arba „Amazon EC2“, galėjote susidurti su šiais klausimais:



  • Kokios yra geriausios duomenų bazės saugyklos tipo parinktys?
  • Kaip išspręsti saugyklos našumo problemas?
  • Kokios yra RAID konfigūracijos parinktys EC2 egzempliorių priglobtoms duomenų bazėms?
  • Kokie yra taikomosios programos pakeitimai, siekiant optimalaus našumo?
  • Kaip pašalinti saugyklos našumo triktis naudojant „Amazon CloudWatch“. ?
  • „Amazon RDS“ ir „Aurora“ veiklos našumas?

Šiame įraše pateikiu geriausią saugojimo praktiką, kaip vykdyti gamybos darbo krūvius Amazon RDS arba EC2 egzempliorių priglobtose duomenų bazėse.

Palyginti su testavimo, kokybės užtikrinimo ar sustojimo aplinkomis, gamybos darbo krūviams reikia greito ir nuoseklaus I/O našumo. Nors reliacinės duomenų bazės gali būti naudojamos įvairiems tikslams, dažniausiai jos naudojamos internetinio transakcijų apdorojimo (OLTP) darbo krūviui priglobti. RDS, EC2 priglobtos duomenų bazės ir „Aurora“ naudoja skirtingus saugojimo metodus, kaip parodyta toliau:

  • Amazon RDS duomenų bazės egzempliorių naudojimas Amazon EBS saugojimui skirti tūriai.
  • „Aurora“ egzemplioriai naudoja AWS patentuotus saugyklos kiekius.
  • EC2 egzemplioriai įgalina įvairias saugojimo parinktis.

Geriausios duomenų bazės saugojimo tipo parinktys

„Amazon RDS“ teikia trys saugojimo tipai :



  • Bendrosios paskirties SSD (taip pat žinomas kaip gp2 tomai )
  • Suteiktas IOPS SSD (taip pat žinomas kaip io1 )
  • Magnetinis

Egzemplioriaus įvesties / išvesties talpa priklauso nuo egzemplioriaus saugyklos tipo ir dydžio. Jei DB egzempliorius sukonfigūruotas naudojant gp2 tomą, pagrindinė IOPS talpa yra 3 kartus didesnė už GiB saugyklą. Jei DB egzempliorius paskyrė 100 GiB gp2 tomą, pradinė IOPS talpa yra 300. Kuo daugiau saugyklos suteiksite, tuo didesnė IOPS talpa.

Be pradinio IOPS pajėgumo, gp2 apimtis taip pat užtikrina iki 3000 IOPS ilgesnį laiką. Serijos funkcija ribojama iki 1 TiB saugyklos ar mažesnio tūrio. DB egzemplioriai, skirti MySQL, MariaDB, Oracle ir PostgreSQL, gali būti sukonfigūruoti naudojant 20 GiB–32 TiB, tačiau didžiausia bazinė IOPS yra ribojama nuo 100 iki 16 000 IOPS. Taigi, gp2 tūris 5,34 TiB ar daugiau užtikrina tą pačią bazinę liniją: 16 000 IOPS.

Jei jūsų gamybos apkrovai reikalingas didelis OLTP ir greitas, nuolat didelis pralaidumas, turėtumėte sukonfigūruoti savo DB egzempliorių su io1 tomais. Palyginti su gp2 tomais, kurių didžiausia bazinė vertė yra 16 000 IOPS, io1 tomai gali pateikti iki 40 000 IOPS DB egzempliorių, skirtų MySQL, MariaDB, Oracle ir PostgreSQL, ir iki 32 000 SQL serverio egzempliorių.



Jei pastebite, kad IOPS naudojimo modelis nuolat viršija 16 000, turėtumėte pakeisti DB instance ir pakeiskite saugyklos tipą iš gp2 į io1. „Amazon RDS“ taip pat siūlo magnetinę saugyklą, tačiau ji netinka OLTP darbo krūviui, kuriam reikalingas pastovus I/O našumas ir mažas delsimas.

Magnetinės saugyklos tipas nerekomenduojamas daug įvesties / išvesties reikalaujantiems darbo krūviams, nes maksimali saugykla yra mažesnė nei gp2 arba io1. IOPS talpa taip pat ribojama iki 1000 IOPS.

Saugojimo našumo problemos

Gp2 saugyklos naudojimas idealiai tinka įvairiems DB darbo krūviams. Šiam saugyklos tipui, architekto duomenų bazės skaitymo ir rašymo darbo krūviai taip, kad suma Skaityti IOPS ir WriteIOPS vertės bet kuriuo metu neviršija pradinio IOPS pajėgumo.



Serija gali būti prieinama ilgą laiką. Tačiau panaudojus serijos talpą, nuolat didelė skaitymo ir rašymo IOPS reikšmė pablogina egzemplioriaus našumą. Šį degradaciją galima pastebėti padidėjus Rašymo delsa arba Skaitymo delsa vertybes. Idealiu atveju gp2 saugykla yra tinkama vieno skaitmens milisekundės delsai, tačiau per didelis IOPS naudojimas gali sukelti daugiau nei 10 ms delsą.

Toliau pateiktuose paveikslėliuose rodomas padidėjimas Rašymo delsa vertės, nes WriteIOPS nuolat sunaudoja 300 IOPS pradinės talpos Amazon RDS DB egzemplioriuje. Šiame pavyzdyje Amazon RDS PostgreSQL egzempliorius yra priglobtas t2.small egzemplioriuje su 100 GiB gp2 apimtimi.

Aukščiau pateiktame paveikslėlyje parodyta, kad Write IOPS nuolat sunaudoja 300 IOPS, o tai yra pradinis našumas.

Aukščiau pateiktame paveikslėlyje parodyta, kad rašymo delsa padidėjo iki 25 milisekundžių dėl per didelio IOPS naudojimo.

Kaip geriausia praktika, įsitikinkite, kad jūsų darbo krūvis neviršija egzemplioriaus IOPS pajėgumo. Kai kurie būdai sumažinti Skaityti IOPS vertės yra tokios:

  • Naudokite „Amazon“ RDS skaitymo kopiją.
  • Naudokite didesnę RAM.

Naudojant „Amazon RDS“ skaitymo kopiją

„Amazon RDS DB“ egzemplioriai, skirti „MySQL“, „MariaDB“, „Oracle“ ir „PostgreSQL“. RDS skaitymo kopijas . Šie egzemplioriai yra atskiri DB egzemplioriai, sinchronizuojami su šaltinio DB egzemplioriais pakartotinai leidžiant duomenų bazės operacijų žurnalus. Bet koks šaltinio DB egzemplioriaus duomenų modifikavimas taikomas skaitymo kopijai. Naudodami skaitymo kopiją, sumažinate šaltinio DB egzemplioriaus apkrovą nukreipdami skaitymo užklausas iš savo programų į skaitymo kopiją. Taip pat atlaisvinate IOPS pajėgumą papildomai rašymo veiklai šaltinio DB egzemplioriuje.

Naudojant skaitymo kopijas, svarbu stebėti replikacijos delsą. Paprastai didelę replikacijos delsą sukelia didelis šaltinio DB egzemplioriaus rašymo aktyvumas.

„Amazon RDS DB“ egzemplioriais galite stebėti replikos delsą naudodami „CloudWatch“ metriką ReplicaLag . Jei pastebite didelę replikos delsą, taip pat turėtumėte stebėti rašymo veiklą šaltinio DB egzemplioriuje. Tai galima padaryti stebint „CloudWatch“ metrikas WriteIOPS ir Rašymo pralaidumas . Jei šaltinio DB egzempliorius neturi IOPS (tai yra, visa IOPS talpa naudojama rašymo ir skaitymo darbo krūviui), kopija taip pat atsilieka.

Viena iš vėluojančių kopijų priežasčių yra ta, kad daugumoje DB variklių skaitytų kopijų atkūrimas apima vieno pakopų procesus. Tai reiškia, kad kuo didesnė pagrindinio egzemplioriaus apkrova, tuo eksponentiškai lėtesnis skaitymo kopijų atkūrimas. Bet koks papildomas didelis rašymo aktyvumas šaltinio DB egzemplioriuje eksponentiškai padidina skaitymo replikos delsą. Be „CloudWatch“ metrikos, su ReplicaLag taip pat galite stebėti atsilikimą naudodami SQL užklausas.

PostgreSQL skaitymo replikos delsą galima apskaičiuoti naudojant šią užklausą:

|_+_|

„MySQL“ galite patikrinti replikacijos būseną naudodami šią komandą:

|_+_|

Naudodami „Amazon RDS“ skaitymo repliką, sukonfigūruokite klientą taip, kad kopijoje rastas tam tikras delsos lygis arba replikacijos klaida suaktyvintų bandymą prisijungti prie kito kopijos galinio taško.

Geras būdas užtikrinti, kad jūsų programa galėtų rasti sveikiausią kopiją, yra iškviesti „CloudWatch“ metriką, kad surastumėte dabartines ReplicaLag ir skaitymo / rašymo delsą. Replikacijos delsą galima rasti naudojant SQL komandas, kaip parodyta ankstesniuose pavyzdžiuose. Taip pat dabartinę kopijos būseną galite sužinoti paskambinę AWS komandų eilutės sąsaja (AWS CLI) komanda aprašykite-db-pavyzdžius. Jei dabartinė replikos būsena yra kita, nei replikuojama, klientas turėtų pabandyti prisijungti prie kitos kopijos.

Be skaitymo operacijų platinimo pranašumų, skaitymo kopijos taip pat gali būti naudojamos jūsų duomenims suskaidyti. Vadovaudamiesi skeveldrų „nebendrinimo nieko“ architektūra, galite sukurti skaitymo kopijas, atitinkančias kiekvieną jūsų skeveldrą, ir jas reklamuoti, kai nuspręsite konvertuoti jas į atskiras skeveldras.

Didesnės RAM naudojimas

„Amazon RDS DB“ egzemplioriai turėtų turėti pakankamai RAM, kad visas jūsų darbo rinkinys būtų atmintyje. Kadangi skaitymo užklausos gali nuskaityti duomenis iš atminties, tai sumažina ryšį su saugojimo apimtimis. Taigi tai sumažina naudojimą Skaityti IOPS talpa, kurią galima panaudoti rašymo tikslais.

Nėra aiškaus būdo nustatyti veikiančio duomenų rinkinio dydį. Peržiūrėkite skaitytas užklausas ir sužinokite, kiek duomenų nukentėjo. Pavyzdžiui, jei duomenų bazės dydis yra 100 GiB, o darbo rinkinys yra 20 GiB, turėtumėte naudoti Amazon RDS DB egzempliorius su mažiausiai 20 GiB atminties. Tai leidžia atmintyje turėti visą darbo rinkinį.

EC2 egzempliorių prieglobos duomenų bazių RAID konfigūracijos parinktys

EBS tomai yra bloko lygio saugyklos, užtikrinančios nuolatinę blokų saugyklą. Šie tomai yra labai prieinami saugojimo tomai ir gali būti prijungti prie EC2 egzemplioriaus toje pačioje prieinamumo zonoje. EBS tomai idealiai tinka EC2 egzempliorių priglobtoms duomenų bazėms. Nerekomenduojama naudoti EC2 egzempliorių trumpalaikės duomenų bazės saugyklos.

Naudodami EBS saugyklos apimtis su EC2 egzemplioriais, galite konfigūruoti tomus su bet kuriais RAID lygiais. Pavyzdžiui, norėdami padidinti įvesties / išvesties našumą, galite pasirinkti RAID 0, kuris gali sujungti kelis tomus. RAID 1 gali būti naudojamas duomenų pertekliui, nes jis kartu atspindi du tomus.

Nepriklausomai nuo RAID konfigūracijos, EBS apimties duomenys yra dauginami antriniuose serveriuose, kad būtų išvengta duomenų praradimo. RAID 5 ir RAID 6 nerekomenduojami EC2 egzempliorių priglobtose duomenų bazėse, nes įvesties / išvesties našumas nėra toks geras kaip RAID 0 arba RAID 1.

Šioje lentelėje pateikiami šių dviejų skirtingų RAID konfigūracijų pranašumai ir trūkumai bei siūlomi galimi naudojimo atvejai.

Konfigūracija Privalumai Trūkumai Naudojimo atvejis
RAID 0 Įvesties / išvesties našumas yra geresnis, palyginti su atsparumu gedimams Vieno tomo praradimas sukelia visišką duomenų praradimą Jei duomenų bazei reikalingas didesnis pralaidumas, palyginti su duomenų prieinamumu, ir duomenys yra atkuriami
RAIDAS 1 Gedimų tolerancija yra geresnė, palyginti su įvesties / išvesties našumu Žemas rašymo našumas Jei duomenys yra svarbūs ir duomenų bazės gedimų tolerancija yra svarbesnė nei įvesties / išvesties našumas

Programos modifikacijos, užtikrinančios optimalų veikimą

Jei duomenų bazės egzempliorius susiduria su saugyklos problemomis ir susiduria su tokiomis problemomis, kaip ilgas vykdymo laikas ir didelė delsa, kartais programos pakeitimai gali sumažinti šį blogėjimą. Galite modifikuoti programas, kad įgalintumėte eksponentinį atsitraukimą arba klaidų kartojimus.

Eksponentinis atsitraukimas leidžia programoms vis ilgiau laukti tarp pakartojimų, kol bus gautas nuoseklus atsakymas į klaidas. Nors kai kurie algoritmai naudoja laipsnišką delsą, dauguma eksponentinių atsitraukimo algoritmų naudoja atsitiktinių imčių delsą. Čia pateikiami kito algoritmo pavyzdžiai:

Atsitiktinis delsimas:

  1. Paraiška inicijuoja užklausą.
  2. Jei užklausa nepavyksta, palaukite randų (1000,3000) milisekundžių ir inicijuokite užklausą dar kartą.
  3. Jei užklausa nepavyksta, palaukite randų (1000,3000) milisekundžių ir inicijuokite užklausą dar kartą.
  4. Jei užklausa nepavyksta, palaukite randų (1000,3000) milisekundžių ir inicijuokite užklausą dar kartą.

Laipsniškas vėlavimas:

  1. Paraiška inicijuoja užklausą.
  2. Jei užklausa nepavyksta, palaukite 1 = 1000 milisekundžių ir vėl inicijuokite užklausą.
  3. Jei užklausa nepavyksta, palaukite 2 = palaukite 1 + 1000 milisekundžių ir inicijuokite užklausą dar kartą.
  4. Jei užklausa nepavyksta, palaukite 3 = palaukite 2 + 1000 milisekundžių ir inicijuokite užklausą dar kartą.

Naudokite tam tikrą geriausią praktiką, kad pasiektumėte greitesnį „Amazon RDS Multi-AZ“ egzempliorių ir „Aurora“ grupių failų perkėlimą. Įgalinkite TCP išlaikymo parametrus ir nustatykite juos agresyviai, kad užtikrintumėte, jog jei jūsų klientas nebegali prisijungti prie DB egzemplioriaus, visi aktyvūs ryšiai būtų greitai uždaryti. Šis pakeitimas taip pat leidžia programoms greičiau reaguoti į pertrūkį ir greitai prisijungti prie naujojo galutinio taško.

Taip pat galite sumažinti kliento DNS talpyklos skirtąjį laiką. Greitai užmezgami skaitymo ir rašymo ryšiai su atitinkamais galiniais taškais. Taip pat galima keisti kai kuriuos serverio TCP parametrus. Šie pakeitimai padeda greičiau persitvarkyti. Pavyzdžiui, PostgreSQL tai galima valdyti naudojant tcp_keepalives_count, tcp_keepalives_idle ir tcp_keepalives_interval. parametrus .

Saugyklos našumo trikčių šalinimas naudojant „CloudWatch“.

Reguliariai stebint egzempliorių saugyklos būklę, anksti nustatoma našumo problema prieš tai, kai ji smarkiai paveikia duomenų bazės našumą. Kai kurios su saugykla „CloudWatch“ susijusios metrikos, kurias turėtumėte reguliariai stebėti, pateikiamos čia.

Rašyti operacijas

  • WriteIOPS: Matuojant skaičių per sekundę greičiu, ši „CloudWatch“ metrika nustato vidutinį disko įrašymo įvesties / išvesties operacijų skaičių per sekundę. Sutelkite dėmesį į šią metriką, jei jūsų duomenų bazės egzempliorius sukonfigūruotas su kelių AZ nustatymu.
    Naudojant „Multi-AZ“, antrinis egzempliorius sukuriamas kitoje prieinamumo zonoje su ta pačia egzemplioriaus konfigūracija kaip ir pagrindinis ir prijungtas EBS saugyklos tūris. Ši saugykla sinchroniškai sinchronizuojama su pagrindine egzemplioriaus saugykla. Duomenų pertekliaus atveju pagal numatytuosius nustatymus kiekvieno EBS tomo duomenys nukopijuojami į kitą, antrinį EBS tomą, esantį toje pačioje pasiekiamumo zonoje. Tai reiškia, kad rašymo operacija turi būti atlikta keturiose vietose prieš siunčiant patvirtinimą klientui. Didelė rašymo veikla virš egzempliorių IOPS ir pralaidumo pablogina bendrą našumą.
  • Rašymo pralaidumas: Ši „CloudWatch“ metrika rodo vidutinį baitų, įrašytų į diską per sekundę, skaičių. Viršijus egzemplioriaus pralaidumą arba saugyklos pralaidumo ribą, pablogėja egzemplioriaus našumas. Siūlau stebėti rašymo veiklą ir paskirstyti rašymo darbo krūvį su atitinkamu vėlavimu, kad būtų optimizuotas našumas.
  • Rašymo delsa: Tai yra vidutinis disko I/O operacijos laikas. Daugiausia laiko Rašymo delsa padidėjimas atsiranda dėl pernelyg didelio egzemplioriaus išteklių, pvz., CPU, IOPS ir pralaidumo, naudojimo.

Skaityti operacijas

  • Skaityti IOPS: Matuojant skaičių per sekundę greičiu, ši „CloudWatch“ metrika nustato vidutinį disko nuskaitymo įvesties / išvesties operacijų skaičių per sekundę. Padidėjusi vertė Skaityti IOPS rodo, kad skaitymo darbo krūvis yra didelis arba egzemplioriui reikia daugiau laisvos atminties.
  • Skaitymo pralaidumas: Ši metrika rodo vidutinį baitų, nuskaitomų iš disko per sekundę, skaičių. Viršijus egzempliorių ir EBS ribas, gali padidėti delsa.
  • Skaitymo delsa: Tai yra vidutinis disko I/O operacijos laikas. Jei turite didelę šios metrikos vertę, pažiūrėkite į skaitymo darbo krūvį ir įsitikinkite, kad per daug nenaudojami egzempliorių ištekliai.

Kiti rodikliai

Be anksčiau paminėtų metrikų, taip pat turėtumėte stebėti šias „CloudWatch“ metrikas:

  • DiskQueueDepth rodo nebaigtų įvesties / išvesties (skaitymo / rašymo užklausų), laukiančių, kad galėtų pasiekti diską, skaičių. Paprastai tai yra didelio darbo krūvio rezultatas.
  • FreeStorageSpace nustato laisvos saugyklos vietos kiekį. Kaip geriausia praktika, turėtumėte nustatyti „CloudWatch“ įspėjimai kad galėtumėte gauti SNS pranešimus, kai tik egzemplioriaus nemokama saugykla pasieks slenkstinę vertę, pvz., 15%.

„Amazon RDS“ ir „Aurora“ veikimo našumas

Kaip minėta anksčiau, Amazon RDS DB egzemplioriai ir EC2 egzemplioriai turi IOPS priklausomybę nuo saugyklos apimties. Gp2 ir io1 saugyklos tipai turi savo IOPS apribojimus.

Jei jūsų darbo krūviui reikalingas didesnis IOPS našumas ir didesnis pralaidumas, galite planuoti pereiti prie „Aurora“, kuri yra didelio našumo, labai prieinamas ir ekonomiškas sprendimas, tinkantis didelio našumo darbo krūviams. Šiuo metu, aušra siūlo su MySQL ir PostgreSQL suderinamus variklius.

Naudodami „Aurora“ įsitikinkite, kad IOPS techniškai nėra apribojimų, tačiau pralaidumas gali būti apribotas tik pagrindiniu Auroros pavyzdys riba. Norėdami gauti didesnį pralaidumą, pasirinkite aukštesnę „Aurora“ egzempliorių klasę.

„Aurora“ geriausiai tinka programoms, kurioms bet kuriai IOPS reikia mažai arba visai nereikia delsos. Jis skirtas apdoroti didelius duomenų greičius ir užtikrinti didesnį pralaidumą, palyginti su tradiciniais MySQL ir PostgreSQL varikliais. Kadangi duomenų bazė yra eilinė, ji idealiai tinka didelės apimties, didelio lygiagrečio OLTP darbo krūviams.

Kitas „Aurora“ naudojimo atvejis yra hibridinis sandorių analizės apdorojimas (HTAP). Aurora palaiko iki 15 kopijų. Kiekviena iš šių kopijų paleidžiama per 15–20 milisekundžių nuo rašymo egzemplioriaus. Su neseniai pridėtu „Amazon Aurora Parallel Query“ funkcija , užklausų apdorojimas vėliau perkeliamas į „Aurora“ saugyklą. Užklausa naudoja potencialiai tūkstančius saugyklos mazgų Aurora klasteryje, kad apdorotų, patikslintų ir kauptų duomenis prieš siunčiant juos į skaičiavimo mazgą.

Išvada

Šiame įraše sužinojote apie geriausią saugojimo praktiką, kaip vykdyti gamybos darbo krūvį Amazon RDS DB egzemplioriuje ir EC2 egzempliorių priglobtose duomenų bazėse. Ši praktika apėmė šiuos veiksmus:

  • Skaitymo darbo krūvių paskirstymas skaitymo kopijai.
  • IOPS talpos ir jos priklausomybės nuo saugyklos dydžio ir tipo supratimas.
  • Keičiama programos architektūra.
  • RAID parinkčių nagrinėjimas.
  • „CloudWatch“ metrikos stebėjimas.

Taip pat sužinojote apie „Aurora“ ir apie tai, kaip jos patentuota saugykla veikia kitaip nei EBS tomai. Visos šios žinios padeda sklandžiai ir be problemų AWS duomenų bazėse vykdyti gamybos darbo krūvį. Šiame duomenų bazės tinklaraščio įraše taip pat galite pažvelgti į tai, kaip „Aurora“ tvarko duomenų bazės greitį ir prieinamumą naudodama saugyklos sluoksnį: Pristatome „Aurora Storage Engine“.

paslėpti