Amazon Aurora HA at DR Design Pattern para sa Global Resilience (DAT442)

Mga Tala ng Sesyon

Ang Diskarte ni Aurora sa Pagganap

Pagdaragdag ng mga replika para sa mga layunin ng pagganap

• Ang mga offload ay nagbabasa ng trapiko sa mga replika, na nagpapababa ng epekto sa pangunahing manunulat.
• Nagbibigay-daan sa paghihiwalay ng maingay na kapitbahay sa pamamagitan ng paglalaan ng mga replika sa mga partikular na workload (hal., analytics).
• Hanggang 15 replika ang maaaring maidagdag para sa pinong pamamahala ng pagganap.
• Pag-scale ng Storage:
• Awtomatikong nasa Aurora ang kapasidad ng storage at sukat ng performance, na hindi nangangailangan ng manual na provisioning.
• Pag-scale ng Instance:
• Maaaring magdagdag ng mga instance sa iba't ibang laki (hal., 16XL, 8XL, 4XL) para sa failover at pamamahala ng performance.
• DB instance ay elastic, scaling mula 0 hanggang 256 Aurora capacity units.
• Ang mga failover tier ay tinukoy upang pamahalaan ang instance failover order batay sa laki at kapasidad.
• Nakakatulong ang mga elastic na instance na pamahalaan ang mga spike sa workload nang walang pangmatagalang implikasyon sa gastos.

Hamon: Pamamahala ng Koneksyon sa Aurora

• Pamamahala ng mga koneksyon sa maraming pagkakataon, lalo na ang pagkilala sa manunulat para sa mga transaksyon.
• Mga diskarte:
• Pagsasama-sama at paglilimita sa mga koneksyon sa bawat DB instance, pag-iwas sa muling pagkonekta.
• Mga Framework ng Driver:
• Maaaring hindi epektibong pangasiwaan ng mga karaniwang kasanayan tulad ng Spring at JDBC ang mga clustered database.

Mga Endpoint ng Aurora

Endpoint ng Manunulat

• Palaging tumuturo sa kasalukuyang node ng manunulat, na pinapadali ang pare-parehong pagruruta ng transaksyon.
• Endpoint ng Reader:
• Tumuturo sa isang pool ng mga instance para sa mga read operation gamit ang DNS round robin para sa coarse load balancing.
• Mga Custom na Endpoint:
• Pagpipilian upang lumikha ng mga custom na endpoint para sa mga partikular na kaso ng paggamit (hal., analytics).

AWS Mga Advanced na Wrapper Driver

Mga Mabilis na Driver

• Pinahusay na mga driver na may malalim na kaalaman sa estado ng cluster, na nagpapadali sa mas mabilis na failover.
• RDS Proxy:
• Karagdagang tool para sa pamamahala ng mga koneksyon at pagbabawas ng oras ng failover.
• Mga Plugin:
• Pinahusay na failover, rewrite splitting, mga blue-green na deployment.

Multi-Region Resilience

• Hamon: Tinitiyak ang pagpapatuloy ng negosyo kung ang isang rehiyon ay nabigo o naputol sa network.
• Solusyon: Pagpapanatili ng isang kopya sa ibang rehiyon, pinapanatili itong napapanahon sa kaunting gastos, at paggamit nito para sa iba't ibang layunin.
• Multi-Region Resilience sa Aurora Global Database:
• Pinapayagan ng Aurora Global Database ang hanggang 10 pangalawang rehiyon para sa AMS at APG.
• Pinangangasiwaan ng internal replication server ang asynchronous na pisikal na pagtitiklop sa pagitan ng mga rehiyon.
• Ang mga node ng ulo ay hindi kasama, na iniiwasan ang pagganap na nauugnay sa lohikal na pagtitiklop.
• Configuration at Mga Benepisyo:
• Rehiyon A: Pangunahing rehiyon na may mga replika at imbakan.
• Rehiyon B: Ang pangalawang rehiyon na may imbakan sa simula, ay maaaring magdagdag ng mga read-only na pagkakataon para sa mga lokal na pagbabasa.
• Posible ang mga pagsasaayos ng walang simetriko; ang mga pagkakataon sa mga pangalawang rehiyon ay hindi kailangang tumugma sa pangunahin.
• Ang RPO lag ay karaniwang humigit-kumulang 1 segundo, depende sa distansya ng pares ng rehiyon.
• Pandaigdigang Endpoint at Failover:
• Pinamamahalaan ng pandaigdigang endpoint ang pangunahing pagkakakilanlan ng rehiyon.
• Sa kaso ng pagkabigo sa Rehiyon A, ang failover sa Rehiyon B ay pinamamahalaan, na may potensyal na pagkawala ng data dahil sa asynchronous na pagtitiklop.
• Ang pandaigdigang endpoint ay nire-repoint gamit ang Route 53 data planes para sa mabilis na pag-redirect.
• Paglipat:
• Ang paglipat ay isinasagawa kapag ang parehong mga rehiyon ay malusog.
• Ang Rehiyon A ay sinabihan na huminto sa pagiging pangunahin, at ang Rehiyon B ay magiging pangunahin.
• Payagan ang mabilis na paglipat sa pagitan ng mga rehiyon nang walang pagkaantala.
• Proseso ng Paglipat:
• Naglalagay ng espesyal na tala ng log (marker log record) sa stream ng log record.
• Kinikilala ng kabilang panig ang marker at nagiging pangunahin sa tinukoy na oras ng pag-log.
• Ang Rehiyon A ay humihinto sa pagiging pangunahin sa parehong oras, na tinitiyak ang isang malinis na handoff.
• Mga resulta sa zero RPO at napakababang RTO (mga 30 segundo).

Pagpapanatili at Pag-upgrade

• Ang mga upgrade ng bersyon (hal., PostgreSQL 16 sa PostgreSQL 17) at OS patch ay kinakailangan.
• Ang mga self-managed system ay nangangailangan ng downtime, mga snapshot para sa rollback, compatibility testing, at performance testing.
• Nagbibigay ang Aurora ng ganap na pinamamahalaan at automated na menor de edad na bersyon at karanasan sa pag-upgrade ng patch.
• Available na ngayon ang mga rolling operating system upgrade, na nagpapataas ng availability.
• Maaaring tukuyin ang mga pagkilos sa pagpapanatili sa loob ng isang tinukoy na window o awtomatikong pinamamahalaan ng Aurora.
• AWS Health Dashboard ay nagbibigay ng mga abiso sa pagpapanatili.
• Mahigpit na inirerekomenda ang pag-opt-in automation para sa pagpapanatili.
• AWS Patakaran sa Paglunsad ng Pag-upgrade ng Organisasyon:
• Bagong feature para pamahalaan ang mga upgrade sa maraming DB cluster sa development, QA, at production environment.
• Pinapasimple ang automation ng pamamahala ng lifecycle para sa mga fleet ng DB cluster.
• Nagbibigay-daan sa pagtatakda ng mga patakaran sa pag-upgrade batay sa mga tag sa maraming mapagkukunan sa isang organisasyong AWS.
• Halimbawa:
• Ang mga mapagkukunang na-tag na Prod ay huling na-upgrade; Ang mga mapagkukunan ng dev ay na-upgrade muna.
• Default na gawi: Ang mga mapagkukunang walang kinikilalang mga tag ay ina-upgrade sa pangalawa.
• Ang paglulunsad ng pag-upgrade ay nagsasangkot ng pagtatalaga ng patakaran sa mga mapagkukunan, pagtukoy sa order ng pag-upgrade, at pagpapatuloy sa mga wave sa loob ng mga window ng pagpapanatili.
• Nagbibigay ng kakayahang umangkop upang ihinto ang mga pag-upgrade kung may nakitang mga isyu sa panahon ng maintenance window.
• Mga In-Place na Upgrade:
• Para sa mga pangunahing pag-upgrade na hindi tugma sa open source, isinasagawa ang mga in-place na pag-upgrade.
• Kasama ang paggawa ng clone ng database cluster, pag-upgrade ng clone, at pagsubok sa application.
• Kapag napatunayan na, itatapon ang clone, at ilalapat ang pag-upgrade sa cluster ng produksyon.
• Blue-Green Deployment:
• Mas nababaluktot na diskarte para sa mga pangunahing pag-upgrade, pagbabago ng schema, o pagbabago ng static na parameter.
• Kinasasangkutan ng paglikha ng bagong kapaligiran ( Berde ) habang pinapanatili ang lumang kapaligiran ( Asul ) na naka-sync gamit ang lohikal na pagtitiklop.
• Nagbibigay-daan sa pagsubok sa pag-upgrade sa berdeng kapaligiran bago ito i-promote sa produksyon.
• Pinapalitan ng switchover ang pangalan ng mga mapagkukunan upang mapanatili ang pagkakapare-pareho, na nakumpleto sa kasing liit ng isang minuto.
• Available na ngayon ang mga blue-green na deployment para sa mga global database sa maraming rehiyon.
• Buod ng Aurora APG at AMS Features:
• Pagdaragdag ng mga replika upang madagdagan ang kakayahang magamit at paganahin ang failover.
• Paggamit ng AWS Advanced Rapid Drivers para sa mas maayos na proseso ng failover.
• Global Database para sa tibay at kakayahang magamit sa hanggang 10 pangalawang rehiyon.
• Mababang latency na lokal na pagbabasa ng rehiyon at pinasimple ang pamamahala ng endpoint gamit ang mga pandaigdigang endpoint.
• Pinamamahalaan at automated ang cluster-wide upgrade, mabilis na clone, at asul-berde deployment para sa pagpapanatili.

Panimula kay Aurora DSQL

• Ang Amazon Aurora DSQL ay ang pinakamabilis na serverless distributed SQL database para sa palaging available na mga application. Nag-aalok ang Aurora DSQL ng pinakamabilis na multi-Region reads and writes. Ginagawa nitong madali para sa mga customer na sukatin upang matugunan ang anumang pangangailangan sa workload na may zero na pamamahala sa imprastraktura at zero downtime maintenance.
• Pinagsasama ang pinakamahusay sa mga relational na database, distributed database architecture, at serverless na serbisyo.
• Idinisenyo upang magpatakbo ng mga kumplikadong query, sukatin, at mag-alok ng pay-per-use na pagpepresyo.
• DSQL Pangkalahatang-ideya ng Arkitektura:
• Paghahambing sa self-managed PostgreSQL na tumatakbo sa EC2.
• Gumagamit ang DSQL ng query processor sa bawat koneksyon, katulad ng mga proseso ng backend ng PostgreSQL.
• Ang mga read query ay direktang ipinapadala sa DSQL storage engine.
• Ang mga pagsusulat ay naka-buffer sa memorya sa processor ng query hanggang sa mag-commit.
• Sa pag-commit, ipinapadala ang mga transaksyon sa Adjudicator para sa concurrency control at pagkatapos ay sa Journal para sa tibay, na kinokopya sa hindi bababa sa 2 AZs.
• Ginagamit ang Journal para i-update ang storage, katulad ng tradisyonal na PostgreSQL.
• Ang DSQL ay isang aktibong-aktibong serbisyo, na nagpapahintulot sa anumang koneksyon na magbasa o magsulat ng data anumang oras.
• Maaaring tumakbo ang mga query processor (QP) sa iba't ibang host o availability zone.
• Availability sa DSQL:
• Kung nabigo ang isang database node, makikita ng mga Query processor (QP) ang pagkabigo at inilipat ang trapiko sa isang malusog na replika.
• Ang mga replika ay maaaring nasa pareho o magkaibang mga availability zone.
• Ang mga operasyon sa paglipad ay maaaring makaranas ng maliit na pagtaas sa latency dahil sa mga muling pagsubok.
• DSQL patuloy na nagba-back up ng data at awtomatikong pinapalitan ang mga nabigong node.
• Kumokonekta ang mga kapalit na node sa Journal upang makahabol sa pinakabagong data.
• Ang trapiko ay inilipat pabalik sa lokal na replika para sa pinakamainam na pagganap.
• Concurrency Control at Durability:
• Ang Adjudicator ang humahawak ng concurrency control at conflict resolution.
• Ang nag-iisang Adjudicator ay nagbibigay-daan para sa mabilis na paglutas ng salungatan nang walang koordinasyon ng network.
• Ang mga standby adjudicators ay pinananatili sa ibang mga availability zone para sa failover.
• Kung sakaling mabigo, ang mga standby na tagahatol ay nagpapatakbo ng isang protocol ng pamumuno upang pumili ng bagong pinuno.
• Sinusubukang muli ng mga processor ng query ang mga in-flight commit laban sa bagong pinunong tagahatol.
• Ang proseso ay walang putol at hindi nangangailangan ng aksyon mula sa aplikasyon.

Mataas na Availability sa DSQL

• Ang DSQL ay dinisenyo na walang iisang punto ng pagkabigo.
• Ang aktibong-aktibong arkitektura ay nagbibigay ng mataas na kakayahang magamit sa labas ng kahon.
• Ang DSQL ay idinisenyo upang awtomatikong mag-scale upang mahawakan ang pagtaas ng pagkarga.
• Concurrency Control Protocol:
• Gumagamit ang DSQL ng optimistic concurrency control, sa pag-aakalang bihirang magkasalungat ang mga transaksyon.
• Ang mga salungatan ay nagreresulta sa isang error sa serialization failure at nangangailangan ng kliyente na muling subukan ang transaksyon.
• Dapat pangasiwaan ng mga application ang mga muling pagsubok at mga isyu sa pagkontrol ng concurrency na optimistic.
• Inirerekomenda na bumuo ng mga function ng helper o isama ang paghawak sa pinakamababang layer ng application.
• Pag-iwas sa Mga Hindi Kailangang Salungatan:
• Magdisenyo ng mga application upang mabawasan ang mga hindi kinakailangang salungatan upang mabawasan ang mga muling pagsubok.
• Ang mga transaksyong nag-a-update ng iba't ibang row ay maaaring gawin nang sabay-sabay nang walang salungatan.
• Panloob na Sharding at Pagsusukat:
• Awtomatikong ibinabagsak ni DSQL ang sarili nito sa loob para mahawakan ang tumaas na load sa adjudicator at journal.
• Ang mga processor ng query ay direktang nagko-commit sa naaangkop na shard.
• Tinitiyak ng na-optimize na two-phase commit ang mga atomic na transaksyon sa maraming shards.
• Awtomatikong lumalawak ang DSQL sa pamamagitan ng pagdadala ng mga bagong node online at pag-load ng pagbabalanse sa mga replika.
• Ang mga replika sa DSQL ay palaging malakas na pare-pareho, na nagbibigay-daan sa tuluy-tuloy na pag-scale.
• Consistency sa DSQL:
• Tinitiyak ng DSQL ang malakas na pagkakapare-pareho sa pamamagitan ng isang time-based na synchronization protocol.
• Gumagamit ng EC2 Time Sync Service para sa microsecond-tumpak na timestamp at Clockbound na library upang itama ang mga error sa pagsukat.
• Ginagarantiyahan ang isang linearizable na timestamp na palaging pagkatapos ng anumang dating ginawang timestamp.
• Ang storage ay naghihintay ng mga update mula sa journal bago ibalik ang mga row para matiyak ang pare-pareho.

Pangkalahatang-ideya ng Protocol ng Two-Phase Commit (2PC).

• Ang 2PC ay isang distributed system protocol na nagtitiyak na ang lahat ng kalahok sa isang transaksyon ay magkakasama o mag-abort.
• Binubuo ito ng dalawang yugto: Maghanda at Mag-commit/Abort.
• Phase 1: Prepare Phase:
• Nagpapadala ang isang coordinator ng kahilingang "maghanda" sa lahat ng kalahok na node.
• Ginagawa ng bawat kalahok ang gawain ng transaksyon, nakakakuha ng mga kinakailangang kandado, at nagsusulat ng isang "handa" na tala sa log ng transaksyon nito.
• Ang mga kalahok ay nagpapadala ng "oo" o "hindi" na boto pabalik sa coordinator.

Phase 2: Commit/Abort Phase

Kung ang lahat ng kalahok ay bumoto ng "oo"

• Ang coordinator ay nagsusulat ng isang "commit" na tala sa log nito at nagpapadala ng isang "commit" na mensahe sa lahat ng mga kalahok.
• Ang mga kalahok ay nagsagawa ng transaksyon, naglalabas ng mga kandado, at nagpapadala ng isang pagkilala sa coordinator.
• Kung ang sinumang kalahok ay bumoto ng "hindi":
• Ang coordinator ay nagsusulat ng "abort" na tala sa log nito at nagpapadala ng "abort" na mensahe sa lahat ng kalahok.
• Ibabalik ng mga kalahok ang transaksyon at ilalabas ang anumang mga kandado.
• Mga Pangunahing Pagsasaalang-alang: Atomicity: Ginagarantiyahan ng
• 2PC na atomic ang isang transaksyon, kumpleto man sa lahat ng node o isang kumpletong pagkabigo sa lahat ng node.
• Consistency:
• Tinitiyak ang pagkakapare-pareho ng data sa maraming node, ngunit maaaring makaapekto sa availability dahil sa pagharang at paghihintay ng desisyon.
• Paghawak ng Kabiguan:
• Kasama ang mga mekanismo para makabawi mula sa mga pagkabigo; ang pagkabigo ng coordinator ay maaaring humantong sa isang "in-doubt" na estado na nangangailangan ng manu-manong interbensyon.

Pamamahala ng Koneksyon sa DSQL

• Ang mga koneksyon sa DSQL ay pinamamahalaan ng layer ng pagruruta ng session.
• Tinitiyak ang mabilis na pagkakaroon ng mga koneksyon, kahit na sa panahon ng mga kaganapan sa network na nagdudulot ng mga pagbabago.
• Nagpapanatili ng mainit na pool ng mga query processor (QP) na handa para sa agarang paggamit.
• Kapag humiling ng koneksyon, magtatalaga ang DSQL ng available na QP mula sa pool.
• Paghawak sa mga Pagkabigo sa Koneksyon:
• Sa kaganapan ng pagkabigo ng koneksyon, dapat makita ng application ang pagkabigo at subukang muli.
• Ang retry handler mula sa optimistic concurrency control section ay kapaki-pakinabang para sa layuning ito.
• Dapat ipatupad ng mga application ang retry logic para sa mga error sa koneksyon upang mapanatili ang availability.
• Hindi tulad ng mga pagkabigo sa storage at adjudicator, ang mga application ay dapat na manu-manong muling ikonekta ang mga nabigong koneksyon. Ang
• DSQL ay nagpapatupad ng 1-hour na maximum na buhay para sa mga koneksyon upang mahikayat ang wastong pamamahala ng koneksyon.
• Pinakamahuhusay na Kasanayan para sa Pamamahala ng Koneksyon:
• Gumamit ng client-side connection pooling library (hal., Java C3PO) na may mga pagsusuri sa kalusugan at maximum na edad ng koneksyon.
• DSQL likas na kasama ang pagsasama-sama ng koneksyon, ginagawang hindi kailangan ang pag-pool sa gilid ng server (hal., PG Bouncer, RDS Proxy).
• Inirerekomenda na kumonekta sa mga QP sa parehong availability zone para sa mas mababang latency. Awtomatikong nabigo ang
• DSQL sa isang malusog na sona kung hindi available ang kasalukuyang sona.

Multi-Region Clusters sa DSQL

• Sinusuportahan ng DSQL ang mga cluster ng maraming rehiyon sa pamamagitan ng paglikha ng mga cluster sa dalawang rehiyon at pagtatalaga ng ikatlong rehiyon bilang rehiyon ng saksi.
• Ang rehiyon ng saksi ay may hawak na kopya ng journal upang mapadali ang protocol na nakabatay sa korum para sa mga pagkabigo sa rehiyon.
• Maaaring manatiling aktibo ang mga application sa mga rehiyon, na may parehong mga rehiyon na may kakayahang pangasiwaan ang mga pagbabasa at pagsusulat.
• Isang protocol na nakabatay sa korum
• ay isang paraan na ginagamit sa mga distributed system upang matiyak ang pagkakapare-pareho ng data, fault tolerance, at pagiging maaasahan sa pamamagitan ng pag-aatas ng pinakamababang bilang ng mga kalahok na node (isang quorum) upang sumang-ayon sa isang operasyon bago ito ituring na wasto.
• S3 Protocol na nakabatay sa korum:
• Sa mga distributed system, ang ibig sabihin ng "Quorum" ay "isang minimum na bilang ng mga miyembro na kinakailangan upang bumuo ng isang pulong."
• Ang mekanismo ng Quorum ay isang algorithm sa pagboto para sa pagtiyak ng redundancy ng data at pagkakapare-pareho sa mga distributed storage system tulad ng Amazon S3.
• Mga Pangunahing Konsepto at Terminolohiya:
• Read Quorum (Vr): Pinakamababang bilang ng mga nabasang boto
• Sumulat ng Korum (Vw): Pinakamababang bilang ng mga boto sa pagsulat
• Kabuuang Mga Boto (V)
• Prinsipyo ng Paggawa:
• Ipagpalagay na mayroong V data replicas sa isang distributed system.
• Upang matiyak ang pagkakapare-pareho ng data, ang mga operasyon sa pagbasa at pagsulat ay dapat makakuha ng isang "quorum" ng mga pagkumpirma ng node.
• Mga pangunahing panuntunan:
• Vr + Vw > V: Tinitiyak na ang parehong data ay hindi binabasa at isinusulat nang sabay-sabay, iniiwasan ang mga salungatan sa read-write.
• Vw > V / 2: Tinitiyak ang mga serialized na pagbabago sa data, na pumipigil sa dalawang pagpapatakbo ng pagsulat mula sa pagbabago ng data nang sabay-sabay.
• Ang pagsasaayos ng Vr at Vw ay nagbibigay-daan sa system na balansehin ang pagganap sa pagbasa at pagsulat.
• Tungkol sa Amazon S3:
• Inanunsyo ng Amazon 2020 sa 2020 na ang lahat ng operasyon ng GET, PUT, at LIST ay may malakas na pagkakapare-pareho.
• Mababasa kaagad ang data na nakasulat bilang pinakabagong bersyon, na nagpapasimple sa mga workload ng malalaking data.
• Ginagarantiyahan ng S3 ang mataas na tibay at kakayahang magamit sa pamamagitan ng arkitektura nito, na nag-iimbak ng mga replika ng data sa hindi bababa sa tatlong mga availability zone.

Pangangasiwa sa mga Panrehiyong Pagkabigo

• Kung sakaling magkaroon ng kabiguan sa rehiyon (hal., nabigo ang rehiyon B), tinutulungan ng saksing rehiyon na i-disambiguate ang kabiguan at mga boto upang ibukod ang nabigong rehiyon mula sa korum.
• Awtomatikong nire-reconfigure ng DSQL ang journal upang ibukod ang nabigong rehiyon, na tinitiyak na mananatiling available ang cluster sa malusog na rehiyon (rehiyon A).
• Walang pagkawala ng data, at ang mga transaksyon ay patuloy na ginagaya sa kahit isa pang AWS rehiyon.
• Kapag ang nabigong rehiyon (rehiyon B) ay bumalik online, DSQL nakita ito, ina-update ito sa pinakabagong estado, at nire-restore ang multi-region na configuration.
• Inirerekomendang pattern: I-deploy ang mga application sa tabi ng mga cluster sa parehong rehiyon para sa aktibong redundancy.
• Mga Benepisyo ng Active Redundancy:
• Ang pag-deploy ng mga application sa tabi ng mga cluster sa maraming rehiyon ay nagbibigay ng mababang latency at patuloy na pagpapatunay ng functionality ng application.
• Gumamit ng pandaigdigang endpoint (hal., Ruta 53 DNS record) upang idirekta ang trapiko sa pinakamalapit na available na malusog na rehiyon.
• Pangangasiwa sa mga Panrehiyong Pagkabigo gamit ang Global Endpoint:
• Kung sakaling magkaroon ng kabiguan sa rehiyon, hindi mawawala ang data, at awtomatikong ididirekta ng DNS ang trapiko sa malusog na rehiyon.
• Tinitiyak ng patuloy na pagpapatunay na gumagana ang malusog na rehiyon.
• Pagpapanatili sa DSQL:
• Ang DSQL ay isang ganap na pinamamahalaang serbisyo na walang kinakailangang maintenance mula sa mga customer.
• Pana-panahong pinapalitan ang mga proseso ng query ng mga na-update na bersyon, na tinitiyak ang pinakabagong OS, mga patch ng seguridad, mga pagpapahusay sa performance, at mga feature.
• Ang mga customer ay hindi kailangang magsagawa ng anumang mga gawain sa pagpapanatili.
• Takeaways:
• Nag-aalok ang Aurora ng tatlong makina: PostgreSQL, MySQL, at DSQL.
• Lahat ng makina ay nagbibigay ng 3 AZ na tibay sa labas ng kahon.
• Iba-iba ang mga opsyon sa pag-scale: APG at AMS scale up para sa writes at out para sa reads; Nag-aalok ang DSQL ng hands-free, awtomatikong pag-scale.
• Mga pagsasaalang-alang sa maraming rehiyon: APG at AMS ay nagbibigay-daan sa pagsubok ng failover nang walang pagkawala ng data; Sinusuportahan ng DSQL ang active-active sa mga rehiyon.
• Nag-aalok ang lahat ng engine ng madaling pagpapanatili na may mga awtomatikong pag-update sa seguridad at pag-upgrade ng menor de edad na bersyon.