Veri taban\u0131 mimarinizi tasarlarken y\u00fcksek eri\u015filebilirlik, felaket kurtarma ve d\u00fc\u015f\u00fck gecikme s\u00fcresi kritik mi? \u0130\u015f s\u00fcreklili\u011finizi sa\u011flarken performans hedeflerine ula\u015fmak i\u00e7in do\u011fru AWS veri taban\u0131 \u00e7\u00f6z\u00fcm\u00fcn\u00fc se\u00e7mek, g\u00fcn\u00fcm\u00fcz\u00fcn rekabet\u00e7i dijital d\u00fcnyas\u0131nda hayati \u00f6neme sahiptir. Bu kapsaml\u0131 rehberde, AWS’in sundu\u011fu iki g\u00fc\u00e7l\u00fc se\u00e7enek olan RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database \u00e7\u00f6z\u00fcmlerini detayl\u0131 bir \u015fekilde kar\u015f\u0131la\u015ft\u0131racak, farklar\u0131n\u0131 inceleyecek ve i\u015f ihtiya\u00e7lar\u0131n\u0131za en uygun se\u00e7imi yapman\u0131za yard\u0131mc\u0131 olaca\u011f\u0131z.<\/p>\n
Modern uygulamalar i\u00e7in veri tabanlar\u0131, adeta bir i\u015fletmenin kalbi gibidir. M\u00fc\u015fteri verileri, finansal i\u015flemler, \u00fcr\u00fcn kataloglar\u0131 ve kritik i\u015f s\u00fcre\u00e7leri gibi t\u00fcm de\u011ferli bilgiler veri tabanlar\u0131nda saklan\u0131r. Bu nedenle, bir veri taban\u0131n\u0131n eri\u015filebilirli\u011fi, performans\u0131 ve dayan\u0131kl\u0131l\u0131\u011f\u0131, bir uygulaman\u0131n ve dolay\u0131s\u0131yla bir i\u015fletmenin ba\u015far\u0131s\u0131 i\u00e7in belirleyici fakt\u00f6rlerdir. Veri taban\u0131nda ya\u015fanacak k\u0131sa s\u00fcreli bir kesinti bile, gelir kayb\u0131na, m\u00fc\u015fteri memnuniyetsizli\u011fine ve marka itibar\u0131n\u0131n zedelenmesine yol a\u00e7abilir.<\/p>\n
Felaket senaryolar\u0131, donan\u0131m ar\u0131zalar\u0131, yaz\u0131l\u0131m hatalar\u0131 veya b\u00f6lgesel kesintiler gibi beklenmedik olaylar, veri taban\u0131 altyap\u0131n\u0131z\u0131 ciddi \u015fekilde tehdit edebilir. Bu t\u00fcr risklere kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olmak, yaln\u0131zca reaktif bir yakla\u015f\u0131m de\u011fil, ayn\u0131 zamanda proaktif bir strateji gerektirir. AWS, bulut tabanl\u0131 veri taban\u0131 hizmetleri ile bu zorluklar\u0131n \u00fcstesinden gelmek i\u00e7in \u00e7e\u015fitli ara\u00e7lar sunar. Amazon Relational Database Service (RDS), MySQL, PostgreSQL, Oracle, SQL Server gibi pop\u00fcler veri taban\u0131 motorlar\u0131n\u0131 kolayca kurman\u0131z\u0131, \u00e7al\u0131\u015ft\u0131rman\u0131z\u0131 ve \u00f6l\u00e7eklendirmenizi sa\u011flayan y\u00f6netilen bir hizmettir. Ancak RDS’in sundu\u011fu farkl\u0131 eri\u015filebilirlik ve felaket kurtarma se\u00e7enekleri aras\u0131nda se\u00e7im yapmak, teknik ekipler i\u00e7in kafa kar\u0131\u015ft\u0131r\u0131c\u0131 olabilir.<\/p>\n
Bu makalede \u00f6zellikle iki \u00f6nemli se\u00e7ene\u011fe odaklanaca\u011f\u0131z: RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database. Her iki \u00e7\u00f6z\u00fcm de y\u00fcksek eri\u015filebilirlik ve felaket kurtarma yetenekleri sunsa da, mimarileri, kullan\u0131m senaryolar\u0131 ve sunduklar\u0131 avantajlar a\u00e7\u0131s\u0131ndan \u00f6nemli farkl\u0131l\u0131klar g\u00f6sterir. Uygulaman\u0131z\u0131n b\u00f6lgesel mi yoksa k\u00fcresel bir kapsama m\u0131 sahip oldu\u011fu, hedefledi\u011finiz RPO (Kurtarma Noktas\u0131 Hedefi) ve RTO (Kurtarma S\u00fcresi Hedefi) de\u011ferleri, bu iki \u00e7\u00f6z\u00fcm aras\u0131nda do\u011fru karar\u0131 vermenizde belirleyici olacakt\u0131r. Bu nedenle, hangi \u00e7\u00f6z\u00fcm\u00fcn i\u015f y\u00fck\u00fcn\u00fcz i\u00e7in en uygun oldu\u011funu anlamak, hem maliyetleri optimize etmek hem de i\u015f s\u00fcreklili\u011fini garanti alt\u0131na almak i\u00e7in kritik bir ad\u0131md\u0131r. \u015eimdi, bu iki teknolojinin temelini olu\u015fturan kavramlar\u0131 daha yak\u0131ndan inceleyelim.<\/p>\n
Veri taban\u0131 d\u00fcnyas\u0131nda s\u0131k\u00e7a kar\u015f\u0131m\u0131za \u00e7\u0131kan y\u00fcksek eri\u015filebilirlik (High Availability – HA) ve felaket kurtarma (Disaster Recovery – DR) terimleri, bir sistemin beklenmedik kesintilere veya b\u00fcy\u00fck \u00f6l\u00e7ekli felaketlere kar\u015f\u0131 ne kadar dayan\u0131kl\u0131 oldu\u011funu ifade eder. Bu kavramlar\u0131 tam olarak anlamak, RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database gibi \u00e7\u00f6z\u00fcmlerin ard\u0131ndaki mant\u0131\u011f\u0131 kavramak i\u00e7in esast\u0131r.<\/p>\n
Y\u00fcksek eri\u015filebilirlik, bir sistemin veya uygulaman\u0131n kesintisiz bir \u015fekilde \u00e7al\u0131\u015fmaya devam etme yetene\u011fini ifade eder. Ba\u015fka bir deyi\u015fle, donan\u0131m ar\u0131zalar\u0131, yaz\u0131l\u0131m hatalar\u0131 veya a\u011f sorunlar\u0131 gibi yayg\u0131n kesinti nedenlerine ra\u011fmen hizmetin kullan\u0131c\u0131lara sunulmaya devam etmesidir. Veri tabanlar\u0131 i\u00e7in y\u00fcksek eri\u015filebilirlik, birincil veri taban\u0131 \u00f6rne\u011finde (primary instance) bir sorun ya\u015fand\u0131\u011f\u0131nda, h\u0131zl\u0131 bir \u015fekilde ba\u015fka bir yedek (standby) veri taban\u0131na ge\u00e7i\u015f yaparak kesinti s\u00fcresini minimuma indirmeyi ama\u00e7lar. Bu ge\u00e7i\u015f i\u015flemine “y\u00fck devretme” (failover) denir. Y\u00fcksek eri\u015filebilirlik genellikle tek bir AWS B\u00f6lgesi i\u00e7indeki farkl\u0131 Eri\u015filebilirlik Alanlar\u0131n\u0131 (Availability Zones – AZs) kullanarak sa\u011flan\u0131r. AWS Eri\u015filebilirlik Alanlar\u0131, birbirinden fiziksel olarak ayr\u0131, ba\u011f\u0131ms\u0131z g\u00fc\u00e7, a\u011f ve so\u011futmaya sahip veri merkezleridir. Bu mimari, bir AZ’de ya\u015fanacak bir kesintinin di\u011fer AZ’leri etkilememesini sa\u011flar ve b\u00f6ylece veri taban\u0131 altyap\u0131n\u0131z i\u00e7in \u00f6nemli bir dayan\u0131kl\u0131l\u0131k katman\u0131 olu\u015fturur.<\/p>\n
Felaket kurtarma ise, \u00e7ok daha geni\u015f \u00f6l\u00e7ekli ve genellikle daha y\u0131k\u0131c\u0131 olaylara kar\u015f\u0131 bir i\u015fletmenin operasyonlar\u0131n\u0131 s\u00fcrd\u00fcrme yetene\u011fiyle ilgilidir. Do\u011fal afetler (depremler, seller), b\u00fcy\u00fck \u00e7apl\u0131 siber sald\u0131r\u0131lar veya b\u00f6lgesel g\u00fc\u00e7 kesintileri gibi bir AWS B\u00f6lgesinin tamam\u0131n\u0131 veya b\u00fcy\u00fck bir k\u0131sm\u0131n\u0131 etkileyebilecek olaylar felaket olarak kabul edilir. Felaket kurtarma stratejileri, bu t\u00fcr durumlarda veri kayb\u0131n\u0131 en aza indirmeyi ve hizmetleri m\u00fcmk\u00fcn olan en k\u0131sa s\u00fcrede geri y\u00fcklemeyi hedefler. Y\u00fcksek eri\u015filebilirlik genellikle tek bir b\u00f6lge i\u00e7inde \u00e7al\u0131\u015f\u0131rken, felaket kurtarma genellikle verileri farkl\u0131 AWS B\u00f6lgeleri aras\u0131nda replike ederek sa\u011flan\u0131r. Bu, bir b\u00f6lgenin tamamen kullan\u0131lamaz hale gelmesi durumunda bile verilerinizin ba\u015fka bir b\u00f6lgede g\u00fcvende oldu\u011fu ve oradan hizmet vermeye devam edebilece\u011finiz anlam\u0131na gelir.<\/p>\n
Felaket kurtarma stratejilerini tasarlarken RPO ve RTO, belirlenmesi gereken en kritik iki metriktir:<\/p>\n
Bu kavramlar, veri taban\u0131 altyap\u0131n\u0131z\u0131 se\u00e7erken i\u015f gereksinimlerinizi netle\u015ftirmek ve do\u011fru AWS \u00e7\u00f6z\u00fcm\u00fcn\u00fc belirlemek i\u00e7in temel bir \u00e7er\u00e7eve sunar. \u015eimdi, bu kavramlar\u0131 kullanarak RDS Multi-AZ DB K\u00fcmelerinin nas\u0131l bir \u00e7\u00f6z\u00fcm sundu\u011funa bakal\u0131m.<\/p>\n
AWS RDS Multi-AZ (\u00c7oklu Eri\u015filebilirlik Alan\u0131) DB K\u00fcmeleri, veri tabanlar\u0131n\u0131z i\u00e7in y\u00fcksek eri\u015filebilirlik ve veri dayan\u0131kl\u0131l\u0131\u011f\u0131 sa\u011flamak \u00fczere tasarlanm\u0131\u015f, b\u00f6lgesel bir \u00e7\u00f6z\u00fcmd\u00fcr. Bu \u00f6zellik, \u00f6zellikle tek bir AWS B\u00f6lgesi i\u00e7inde operasyonlar\u0131n\u0131 y\u00fcr\u00fcten ancak yine de maksimum kesintisiz \u00e7al\u0131\u015fma s\u00fcresi ve h\u0131zl\u0131 felaket kurtarma yetenekleri arayan i\u015fletmeler i\u00e7in idealdir. Multi-AZ mimarisi, veri taban\u0131n\u0131z\u0131n birincil \u00f6rne\u011fi ile e\u015f zamanl\u0131, ba\u011f\u0131ms\u0131z bir ikincil \u00f6rne\u011fini farkl\u0131 bir Eri\u015filebilirlik Alan\u0131nda otomatik olarak olu\u015fturarak \u00e7al\u0131\u015f\u0131r.<\/p>\n
RDS Multi-AZ’nin kalbinde senkron replikasyon bulunur. Bu, birincil veri taban\u0131 \u00f6rne\u011fine yap\u0131lan her yazma i\u015fleminin, ikincil \u00f6rne\u011fe de e\u015f zamanl\u0131 olarak yaz\u0131ld\u0131\u011f\u0131 ve her iki \u00f6rnekte de ba\u015far\u0131yla tamamland\u0131\u011f\u0131 do\u011frulanana kadar i\u015flemin taahh\u00fct edilmedi\u011fi anlam\u0131na gelir. Bu yakla\u015f\u0131m, ola\u011fan\u00fcst\u00fc veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sa\u011flar ve s\u0131f\u0131ra yak\u0131n bir RPO de\u011feri sunar, yani veri kayb\u0131 riski ihmal edilebilir d\u00fczeydedir. Herhangi bir nedenden dolay\u0131 birincil \u00f6rne\u011fin kullan\u0131lamaz hale gelmesi durumunda (donan\u0131m ar\u0131zas\u0131, a\u011f kesintisi, g\u00fc\u00e7 kayb\u0131), RDS otomatik olarak ikincil \u00f6rne\u011fe y\u00fck devretme yapar.<\/p>\n
Geleneksel Multi-AZ mimarisinde, tek bir birincil DB \u00f6rne\u011fi ile bir adet ikincil DB \u00f6rne\u011fi bulunur. Y\u00fck devretme ger\u00e7ekle\u015fti\u011finde, DNS kayd\u0131 g\u00fcncellenerek uygulama trafi\u011fi yeni birincil olan ikincil \u00f6rne\u011fe y\u00f6nlendirilir. Bu s\u00fcre\u00e7 genellikle 60-120 saniye kadar s\u00fcrebilir. Ancak AWS, bu mimariyi daha da geli\u015ftirerek Multi-AZ DB K\u00fcmeleri<\/strong> ad\u0131n\u0131 verdi\u011fi yeni bir se\u00e7ene\u011fi de sunmu\u015ftur. Bu geli\u015fmi\u015f mimaride, bir birincil veri taban\u0131 \u00f6rne\u011fi ve iki adet okunabilir ikincil \u00f6rnek (standby) bulunur. Bu ikincil \u00f6rnekler, ayn\u0131 Eri\u015filebilirlik Alan\u0131’nda veya farkl\u0131 Eri\u015filebilirlik Alanlar\u0131nda konumlanabilir. Bu yap\u0131, hem daha h\u0131zl\u0131 y\u00fck devretme (genellikle 30 saniyenin alt\u0131nda) hem de ek okuma kapasitesi sunar, zira ikincil \u00f6rnekler pasif kalmak yerine okuma i\u015f y\u00fckleri i\u00e7in kullan\u0131labilir.<\/p>\n <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, RDS Multi-AZ DB K\u00fcmeleri, \u00f6zellikle tek bir AWS B\u00f6lgesi i\u00e7inde faaliyet g\u00f6steren ve y\u00fcksek eri\u015filebilirlik gerektiren uygulamalar i\u00e7in m\u00fckemmeldir. \u00d6rne\u011fin, bir \u00fclkeye veya belirli bir co\u011frafyaya hizmet veren e-ticaret siteleri, finansal uygulamalar, kurumsal ERP sistemleri veya i\u015f zekas\u0131 platformlar\u0131 bu mimariden b\u00fcy\u00fck fayda sa\u011flayabilir. B\u00f6lgesel bir felaket durumunda (\u00f6rne\u011fin, t\u00fcm bir AWS B\u00f6lgesini etkileyen bir durum) veri taban\u0131n\u0131z\u0131 kurtarmaz, \u00e7\u00fcnk\u00fc t\u00fcm bile\u015fenleri ayn\u0131 b\u00f6lge i\u00e7inde yer al\u0131r. Bu t\u00fcr senaryolar i\u00e7in Amazon Aurora Global Database gibi b\u00f6lgeler aras\u0131 \u00e7\u00f6z\u00fcmlere ihtiya\u00e7 duyulur. Ayr\u0131ca, okuma i\u015f y\u00fcklerini \u00f6l\u00e7eklendirmek i\u00e7in do\u011frudan ana \u00f6rne\u011fe ba\u011fl\u0131 okuma replikalar\u0131 sunmaz, ancak Multi-AZ DB K\u00fcmelerindeki ikincil \u00f6rnekler okuma trafi\u011fini kar\u015f\u0131layabilir.<\/p>\n \n Uzman \u0130pucu: RDS Multi-AZ DB K\u00fcmeleri'ni kullan\u0131rken, uygulaman\u0131z\u0131n veritaban\u0131 ba\u011flant\u0131 havuzlama (connection pooling) mekanizmalar\u0131n\u0131 do\u011fru yap\u0131land\u0131rd\u0131\u011f\u0131n\u0131zdan emin olun. Bu, otomatik y\u00fck devretme s\u0131ras\u0131nda ba\u011flant\u0131lar\u0131n h\u0131zl\u0131 bir \u015fekilde yeniden kurulmas\u0131na ve uygulaman\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131na yard\u0131mc\u0131 olur.\n <\/p><\/blockquote>\n K\u00fcresel \u00e7apta faaliyet g\u00f6steren i\u015fletmeler veya farkl\u0131 co\u011frafyalarda m\u00fc\u015fterileri olan uygulamalar i\u00e7in d\u00fc\u015f\u00fck gecikme s\u00fcresi ve b\u00f6lgeler aras\u0131 felaket kurtarma yetenekleri hayati \u00f6neme sahiptir. \u0130\u015fte tam da bu noktada Amazon Aurora Global Database devreye girer. Bu \u00e7\u00f6z\u00fcm, veri taban\u0131n\u0131z\u0131 birden fazla AWS B\u00f6lgesi aras\u0131nda sorunsuz bir \u015fekilde da\u011f\u0131tarak, uygulamalar\u0131n\u0131za k\u00fcresel \u00f6l\u00e7ekte eri\u015filebilirlik ve performans sunar. \u00d6zellikle 1 saniyenin alt\u0131nda RPO ve 1 dakikan\u0131n alt\u0131nda RTO hedefleri olan kritik i\u015f y\u00fckleri i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n Aurora Global Database, tek bir Aurora veri taban\u0131n\u0131, birden fazla AWS B\u00f6lgesine yay\u0131lan bir yap\u0131ya d\u00f6n\u00fc\u015ft\u00fcr\u00fcr. Bu mimaride, bir \"birincil b\u00f6lge\" (primary region) ve bir veya daha fazla \"ikincil b\u00f6lge\" (secondary regions) bulunur. Birincil b\u00f6lgedeki Aurora k\u00fcmesi, okuma ve yazma i\u015flemlerini ger\u00e7ekle\u015ftirirken, ikincil b\u00f6lgelerdeki Aurora k\u00fcmeleri, birincil b\u00f6lgeden gelen verileri \"asenkron\" olarak replike eder.<\/p>\n Ancak bu asenkron replikasyon, geleneksel veri tabanlar\u0131ndaki asenkron replikasyonlara k\u0131yasla \u00e7ok daha h\u0131zl\u0131 ve verimlidir. Aurora'n\u0131n depolama katman\u0131 seviyesindeki \u00f6zg\u00fcn mimarisi sayesinde, fiziksel blok tabanl\u0131 replikasyon kullan\u0131l\u0131r. Bu, replikasyon gecikmesini genellikle 1 saniyenin alt\u0131na d\u00fc\u015f\u00fcr\u00fcr, bu da onu \"yak\u0131n senkron\" replikasyon olarak adland\u0131rabilece\u011fimiz bir seviyeye getirir. Her ikincil b\u00f6lge, kendi ba\u015f\u0131na bir tam te\u015fekk\u00fcll\u00fc Aurora k\u00fcmesidir ve ba\u011f\u0131ms\u0131z okuma replikalar\u0131na sahip olabilir. Bu sayede, k\u00fcresel uygulamalar, kendi b\u00f6lgelerindeki ikincil Aurora k\u00fcmesinden okuma yaparak \u00e7ok d\u00fc\u015f\u00fck gecikme s\u00fcreleri elde edebilir.<\/p>\n <\/code><\/p>\n Bu \u00f6rnek, birincil bir Aurora k\u00fcmesi olu\u015fturup, ard\u0131ndan bu k\u00fcmeyi bir Global Database'e eklemeyi ve son olarak ikincil bir b\u00f6lgeyi bu Global Database'e ba\u011flamay\u0131 g\u00f6stermektedir. Bu sayede verileriniz us-east-1'den eu-west-1'e otomatik olarak replike edilmeye ba\u015flar.<\/p>\n Aurora Global Database, \u00f6zellikle uluslararas\u0131 \u00e7apta hizmet veren uygulamalar i\u00e7in tasarlanm\u0131\u015ft\u0131r. K\u00fcresel e-ticaret platformlar\u0131, \u00e7evrimi\u00e7i oyunlar, da\u011f\u0131t\u0131k SaaS uygulamalar\u0131 ve co\u011frafi olarak da\u011f\u0131n\u0131k kullan\u0131c\u0131 taban\u0131na sahip herhangi bir i\u015fletme bu \u00e7\u00f6z\u00fcmden b\u00fcy\u00fck fayda sa\u011flayabilir. M\u00fc\u015fterilerin d\u00fcnyan\u0131n d\u00f6rt bir yan\u0131ndan veri taban\u0131na eri\u015fmesi gerekti\u011finde, Global Database, en yak\u0131n b\u00f6lgeden okuma yaparak gecikmeyi \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n Ancak, Aurora Global Database'in maliyeti, tek bir b\u00f6lgede kalan Multi-AZ \u00e7\u00f6z\u00fcmlerine g\u00f6re daha y\u00fcksek olabilir. Birden fazla b\u00f6lgede kaynak bar\u0131nd\u0131rma ve b\u00f6lgeler aras\u0131 veri transfer maliyetleri g\u00f6z \u00f6n\u00fcnde bulundurulmal\u0131d\u0131r. Ayr\u0131ca, replikasyon asenkron oldu\u011fundan, teorik olarak \u00e7ok k\u00fc\u00e7\u00fck bir RPO (1 saniyeden az) olsa da, s\u0131f\u0131r veri kayb\u0131 garantisi vermez. \u0130\u015f y\u00fck\u00fcn\u00fcz\u00fcn ger\u00e7ekten k\u00fcresel mi yoksa b\u00f6lgesel mi oldu\u011fu, bu y\u00fcksek maliyetli ancak g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcme yat\u0131r\u0131m yapmadan \u00f6nce dikkatlice de\u011ferlendirilmelidir.<\/p>\n RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database, her ikisi de AWS \u00fczerinde y\u00fcksek eri\u015filebilirlik ve felaket kurtarma sunsa da, mimarileri ve optimize edildikleri senaryolar a\u00e7\u0131s\u0131ndan \u00f6nemli farkl\u0131l\u0131klara sahiptir. Do\u011fru se\u00e7imi yapmak, i\u015f hedeflerinize, b\u00fct\u00e7enize ve teknik gereksinimlerinize uygun bir denge kurmay\u0131 gerektirir. Bu b\u00f6l\u00fcmde, iki \u00e7\u00f6z\u00fcm\u00fc farkl\u0131 boyutlarda kar\u015f\u0131la\u015ft\u0131rarak, hangi senaryoda hangisinin daha uygun oldu\u011funu anlaman\u0131za yard\u0131mc\u0131 olaca\u011f\u0131z.<\/p>\n A\u015fa\u011f\u0131daki tablo, iki \u00e7\u00f6z\u00fcm aras\u0131ndaki temel farklar\u0131 \u00f6zetlemektedir:<\/p>\n Bu kar\u015f\u0131la\u015ft\u0131rma \u0131\u015f\u0131\u011f\u0131nda, karar\u0131n\u0131z\u0131 verirken a\u015fa\u011f\u0131daki sorular\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z:<\/p>\n Sonu\u00e7 olarak, her iki \u00e7\u00f6z\u00fcm de g\u00fc\u00e7l\u00fc ve g\u00fcvenilir se\u00e7enekler olmakla birlikte, farkl\u0131 i\u015f ihtiya\u00e7lar\u0131na hizmet ederler. Karar, uygulaman\u0131z\u0131n do\u011fas\u0131na, kullan\u0131c\u0131 taban\u0131n\u0131z\u0131n co\u011frafi da\u011f\u0131l\u0131m\u0131na ve i\u015finizin kritiklik derecesine g\u00f6re verilmelidir. Bir sonraki b\u00f6l\u00fcmde, bu \u00e7\u00f6z\u00fcmlerin ger\u00e7ek d\u00fcnyada nas\u0131l kullan\u0131ld\u0131\u011f\u0131na dair vaka analizlerini inceleyece\u011fiz.<\/p>\n Teorik bilgilerin \u00f6tesinde, bu veri taban\u0131 \u00e7\u00f6z\u00fcmlerinin ger\u00e7ek d\u00fcnyadaki i\u015fletmeler taraf\u0131ndan nas\u0131l kullan\u0131ld\u0131\u011f\u0131na bakmak, karar verme s\u00fcrecinize \u0131\u015f\u0131k tutacakt\u0131r. \u0130\u015fte RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database'in ba\u015far\u0131l\u0131 bir \u015fekilde uyguland\u0131\u011f\u0131 iki farkl\u0131 senaryo:<\/p>\n Bir finansal hizmetler \u015firketi olan \"SecureBank\", tek bir \u00fclkenin s\u0131n\u0131rlar\u0131 i\u00e7inde faaliyet g\u00f6steren, ancak binlerce m\u00fc\u015fterisine 7\/24 online bankac\u0131l\u0131k hizmetleri sunan bir kurulu\u015ftur. M\u00fc\u015fteri verilerinin b\u00fct\u00fcnl\u00fc\u011f\u00fc ve kesintisiz hizmet eri\u015fimi, SecureBank i\u00e7in en y\u00fcksek \u00f6nceliktir. \u015eirketin ana operasyonlar\u0131 ve m\u00fc\u015fteri taban\u0131 sadece tek bir AWS B\u00f6lgesi'nde (\u00f6rne\u011fin, AB-Frankfurt) bulunmaktad\u0131r. SecureBank, kritik i\u015f y\u00fckleri i\u00e7in geleneksel bir veri taban\u0131ndan (\u00f6rne\u011fin, PostgreSQL) AWS RDS'ye ge\u00e7meye karar verdi.<\/p>\n Neden RDS Multi-AZ DB K\u00fcmeleri Se\u00e7ildi?<\/strong><\/p>\n SecureBank'\u0131n temel gereksinimleri \u015funlard\u0131:<\/p>\n RDS Multi-AZ DB K\u00fcmeleri, bu gereksinimleri m\u00fckemmel bir \u015fekilde kar\u015f\u0131lad\u0131. Senkron replikasyon sayesinde, t\u00fcm finansal i\u015flemler an\u0131nda iki farkl\u0131 Eri\u015filebilirlik Alan\u0131ndaki veri taban\u0131 \u00f6rneklerine yaz\u0131l\u0131yordu. Birincil \u00f6rnekte ya\u015fanabilecek herhangi bir donan\u0131m veya yaz\u0131l\u0131m hatas\u0131 durumunda, RDS otomatik olarak di\u011fer Eri\u015filebilirlik Alan\u0131ndaki ikincil \u00f6rne\u011fe y\u00fck devretme yaparak, hizmet kesintisini minimuma indirdi. Multi-AZ DB K\u00fcmesinin sundu\u011fu h\u0131zl\u0131 y\u00fck devretme s\u00fcresi (30 saniyenin alt\u0131nda), SecureBank'\u0131n kritik SLA'lar\u0131n\u0131 (Hizmet Seviyesi Anla\u015fmalar\u0131) kar\u015f\u0131lamas\u0131na yard\u0131mc\u0131 oldu.<\/p>\n Faydalar\u0131 ve Mimari A\u00e7\u0131klama:<\/strong><\/p>\n SecureBank, birincil b\u00f6lgede (AB-Frankfurt) bir RDS PostgreSQL Multi-AZ DB K\u00fcmesi kurdu. Bu k\u00fcme, ana yazma ve okuma i\u015flemlerini y\u00fcr\u00fcten bir birincil \u00f6rnek ve ayn\u0131 b\u00f6lgedeki farkl\u0131 Eri\u015filebilirlik Alanlar\u0131nda bulunan iki adet okunabilir ikincil \u00f6rnekten olu\u015fuyordu. Uygulama sunucular\u0131, DNS ad\u0131 \u00fczerinden veri taban\u0131na ba\u011fland\u0131 ve y\u00fck devretme an\u0131nda otomatik olarak yeni birincil \u00f6rne\u011fe y\u00f6nlendirildi. Bu sayede:<\/p>\n Bu vaka, tek bir b\u00f6lge i\u00e7inde maksimum dayan\u0131kl\u0131l\u0131k ve veri kayb\u0131 riskini ortadan kald\u0131rma ihtiyac\u0131 olan i\u015fletmeler i\u00e7in RDS Multi-AZ DB K\u00fcmelerinin ne kadar etkili bir \u00e7\u00f6z\u00fcm oldu\u011funu g\u00f6steriyor.<\/p>\n \"GlobalShop\" adl\u0131 bir e-ticaret devi, d\u00fcnyan\u0131n d\u00f6rt bir yan\u0131ndaki m\u00fc\u015fterilerine hizmet veren, 7\/24 \u00e7al\u0131\u015fan bir platforma sahiptir. M\u00fc\u015fteriler G\u00fcney Amerika'dan Asya'ya kadar uzanan geni\u015f bir co\u011frafi alana yay\u0131lm\u0131\u015ft\u0131r. GlobalShop'un en b\u00fcy\u00fck zorluklar\u0131, k\u00fcresel kullan\u0131c\u0131lar i\u00e7in d\u00fc\u015f\u00fck gecikme s\u00fcresiyle al\u0131\u015fveri\u015f deneyimi sunmak ve herhangi bir AWS B\u00f6lgesi'ndeki b\u00fcy\u00fck bir felakete kar\u015f\u0131 i\u015f s\u00fcreklili\u011fini sa\u011flamakt\u0131.<\/p>\n Neden Amazon Aurora Global Database Se\u00e7ildi?<\/strong><\/p>\n GlobalShop'un gereksinimleri \u00e7ok daha karma\u015f\u0131kt\u0131:<\/p>\n Amazon Aurora Global Database, bu gereksinimleri kar\u015f\u0131lamak i\u00e7in ideal bir \u00e7\u00f6z\u00fcm olarak \u00f6ne \u00e7\u0131kt\u0131. Birincil operasyonlar\u0131n\u0131 Kuzey Virginia (us-east-1) b\u00f6lgesinde y\u00fcr\u00fcten GlobalShop, Avrupa (eu-west-1) ve Asya Pasifik (ap-southeast-2) b\u00f6lgelerinde de ikincil Aurora k\u00fcmeleri olu\u015fturdu.<\/p>\n Faydalar\u0131 ve Mimari A\u00e7\u0131klama:<\/strong><\/p>\n GlobalShop, Aurora PostgreSQL motorunu kullanarak birincil b\u00f6lgede bir Aurora k\u00fcmesi kurdu ve bunu bir Global Database'e ekledi. Ard\u0131ndan, Avrupa ve Asya'daki b\u00f6lgeleri ikincil olarak Global Database'e ba\u011flad\u0131. M\u00fc\u015fterilerin uygulamalar\u0131, en yak\u0131n AWS B\u00f6lgesi'ndeki Aurora k\u00fcmesinden okuma i\u015flemlerini ger\u00e7ekle\u015ftirdi. \u00d6rne\u011fin, bir Avrupal\u0131 m\u00fc\u015fteri, eu-west-1'deki ikincil k\u00fcmeden \u00fcr\u00fcn bilgilerini okurken, sat\u0131n alma i\u015flemi us-east-1'deki birincil k\u00fcmeye yaz\u0131ld\u0131. Bu mimari sayesinde:<\/p>\n Bu vaka, d\u00fcnya \u00e7ap\u0131nda geni\u015f bir kullan\u0131c\u0131 taban\u0131na sahip olan ve hem d\u00fc\u015f\u00fck gecikme s\u00fcresi hem de b\u00f6lgeler aras\u0131 felaket kurtarma arayan i\u015fletmeler i\u00e7in Amazon Aurora Global Database'in sundu\u011fu e\u015fsiz de\u011feri vurgulamaktad\u0131r. Her iki vaka analizi de, do\u011fru veri taban\u0131 mimarisinin i\u015f hedeflerinize ula\u015fmada ne kadar kritik oldu\u011funu net bir \u015fekilde g\u00f6stermektedir.<\/p>\n RDS Multi-AZ DB K\u00fcmeleri veya Aurora Global Database'i se\u00e7tikten sonra bile, en iyi performans\u0131 ve maliyet etkinli\u011fini sa\u011flamak i\u00e7in yapabilece\u011finiz bir\u00e7ok optimizasyon ve ileri d\u00fczey strateji bulunmaktad\u0131r. Bu b\u00f6l\u00fcmde, deneyimli kullan\u0131c\u0131lar i\u00e7in baz\u0131 ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131 sunaca\u011f\u0131z.<\/p>\n Veri taban\u0131 performans\u0131n\u0131 s\u00fcrekli izlemek, potansiyel darbo\u011fazlar\u0131 tespit etmek ve iyile\u015ftirmeler yapmak i\u00e7in hayati \u00f6neme sahiptir. AWS CloudWatch metriklerini, RDS Performance Insights'\u0131 ve Aurora i\u00e7in Enhanced Monitoring'i kullanarak veri taban\u0131 aktivitesini derinlemesine inceleyebilirsiniz. \u00d6zellikle CPU kullan\u0131m\u0131, ba\u011flant\u0131 say\u0131s\u0131, gecikme s\u00fcreleri (latency) ve i\u015flem hacmi (throughput) gibi metriklere dikkat edin.<\/p>\n Y\u00fcksek eri\u015filebilirlik ve k\u00fcresel da\u011f\u0131t\u0131m maliyetleri art\u0131rabilir, ancak baz\u0131 stratejilerle maliyetleri optimize edebilirsiniz:<\/p>\n Y\u00fck devretme mekanizmalar\u0131n\u0131z\u0131n ger\u00e7ekten \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in d\u00fczenli olarak testler yapmal\u0131s\u0131n\u0131z. AWS Management Console, CLI veya SDK'lar arac\u0131l\u0131\u011f\u0131yla birincil \u00f6rne\u011fi kas\u0131tl\u0131 olarak yeniden ba\u015flatarak veya bir Eri\u015filebilirlik Alan\u0131n\u0131 sim\u00fcle ederek y\u00fck devretme tetikleyebilirsiniz. Bu testler, RTO hedeflerinizi kar\u015f\u0131lad\u0131\u011f\u0131n\u0131zdan ve uygulaman\u0131z\u0131n kesintisiz bir \u015fekilde yeni birincil \u00f6rne\u011fe ge\u00e7i\u015f yapt\u0131\u011f\u0131ndan emin olman\u0131z\u0131 sa\u011flar.<\/p>\n <\/code><\/p>\n Yukar\u0131daki komut, belirtilen RDS \u00f6rne\u011fini yeniden ba\u015flatmaya zorlar ve bu esnada bir y\u00fck devretme (failover) tetikler. Bu, Multi-AZ ortam\u0131n\u0131z\u0131n bekledi\u011finiz gibi \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 kontrol etmek i\u00e7in harika bir yoldur.<\/p>\n Hem RDS Multi-AZ DB K\u00fcmeleri (okunabilir ikincil \u00f6rnekler arac\u0131l\u0131\u011f\u0131yla) hem de Aurora Global Database (ikincil b\u00f6lgelerdeki okuma replikalar\u0131 arac\u0131l\u0131\u011f\u0131yla) okuma \u00f6l\u00e7eklenebilirli\u011fi sunar. Okuma a\u011f\u0131rl\u0131kl\u0131 i\u015f y\u00fcklerinizi bu replikalara y\u00f6nlendirerek ana veri taban\u0131n\u0131z\u0131n y\u00fck\u00fcn\u00fc azalt\u0131n. Bu, yazma performans\u0131n\u0131 art\u0131r\u0131rken, okuma gecikmesini de d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n \n Uzman \u0130pucu: Uygulaman\u0131zdaki okuma\/yazma oran\u0131n\u0131 dikkatlice analiz edin. Okuma replikalar\u0131n\u0131 etkin bir \u015fekilde kullanmak i\u00e7in, uygulaman\u0131z\u0131n veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131 okuma ve yazma i\u015flemleri i\u00e7in ayr\u0131 ayr\u0131 y\u00f6nlendirebilen bir mimariye sahip olmas\u0131 \u00f6nemlidir. Bu teknikle performans\u0131 %40 art\u0131rabilirsiniz.\n <\/p><\/blockquote>\n Veri taban\u0131n\u0131z ne kadar eri\u015filebilir olursa olsun, g\u00fcvenli\u011fi her zaman \u00f6n planda tutmal\u0131s\u0131n\u0131z:<\/p>\n Bu ileri d\u00fczey ipu\u00e7lar\u0131 ve stratejiler, veri taban\u0131 altyap\u0131n\u0131z\u0131n sadece \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda en verimli, g\u00fcvenli ve maliyet etkin \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131za yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Bu makalede, AWS'in sundu\u011fu iki g\u00fc\u00e7l\u00fc veri taban\u0131 \u00e7\u00f6z\u00fcm\u00fc olan RDS Multi-AZ DB K\u00fcmeleri ve Amazon Aurora Global Database'i detayl\u0131 bir \u015fekilde inceledik. Her iki \u00e7\u00f6z\u00fcm de y\u00fcksek eri\u015filebilirlik ve felaket kurtarma hedeflerine ula\u015fmak i\u00e7in tasarlanm\u0131\u015ft\u0131r, ancak farkl\u0131 mimarileri ve optimize edildikleri senaryolar nedeniyle ayr\u0131\u015f\u0131rlar. RDS Multi-AZ DB K\u00fcmeleri, tek bir AWS B\u00f6lgesi i\u00e7inde maksimum dayan\u0131kl\u0131l\u0131k ve s\u0131f\u0131ra yak\u0131n veri kayb\u0131 arayan i\u015fletmeler i\u00e7in ideal bir b\u00f6lgesel \u00e7\u00f6z\u00fcm sunarken; Amazon Aurora Global Database, d\u00fc\u015f\u00fck gecikmeli k\u00fcresel eri\u015fim ve b\u00f6lgeler aras\u0131 felaket kurtarma yetenekleriyle k\u00fcresel uygulamalar i\u00e7in tasarlanm\u0131\u015f \u00fcst d\u00fczey bir \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n Do\u011fru se\u00e7imi yapmak, i\u015finizin gelece\u011fini do\u011frudan etkileyecek stratejik bir karard\u0131r. Uygulaman\u0131z\u0131n co\u011frafi kapsam\u0131, hedefledi\u011finiz RPO ve RTO de\u011ferleri, performans beklentileriniz ve b\u00fct\u00e7e k\u0131s\u0131tlamalar\u0131n\u0131z, bu karar s\u00fcrecinde temel belirleyiciler olmal\u0131d\u0131r. E\u011fer operasyonlar\u0131n\u0131z b\u00fcy\u00fck \u00f6l\u00e7\u00fcde tek bir co\u011frafi b\u00f6lgeye odaklanm\u0131\u015fsa ve b\u00f6lgesel bir felaket kurtarma plan\u0131 yeterliyse, RDS Multi-AZ DB K\u00fcmeleri maliyet etkin ve g\u00fcvenilir bir se\u00e7enektir. \u00d6te yandan, d\u00fcnya \u00e7ap\u0131nda da\u011f\u0131lm\u0131\u015f bir kullan\u0131c\u0131 taban\u0131na sahipseniz, b\u00f6lgeler aras\u0131 d\u00fc\u015f\u00fck gecikme s\u00fcresi ve s\u0131f\u0131ra yak\u0131n kesinti s\u00fcresi hayati \u00f6nem ta\u015f\u0131yorsa, Amazon Aurora Global Database'in sundu\u011fu g\u00fc\u00e7l\u00fc \u00f6zelliklere yat\u0131r\u0131m yapmak, i\u015finizin b\u00fcy\u00fcmesi ve m\u00fc\u015fteri memnuniyeti i\u00e7in vazge\u00e7ilmez olacakt\u0131r.<\/p>\n Unutmay\u0131n, veri taban\u0131 mimarisi sadece bug\u00fcn\u00fcn ihtiya\u00e7lar\u0131n\u0131 kar\u015f\u0131lamakla kalmamal\u0131, ayn\u0131 zamanda gelecekteki b\u00fcy\u00fcme ve de\u011fi\u015fen i\u015f gereksinimlerine de adapte olabilmelidir. AWS'in esnek ve \u00f6l\u00e7eklenebilir bulut altyap\u0131s\u0131 sayesinde, her iki \u00e7\u00f6z\u00fcm de ba\u015flang\u0131\u00e7ta daha k\u00fc\u00e7\u00fck \u00f6l\u00e7ekte ba\u015flay\u0131p, i\u015finiz b\u00fcy\u00fcd\u00fck\u00e7e sorunsuz bir \u015fekilde \u00f6l\u00e7eklenebilirlik sunar. Bu makaledeki bilgiler, do\u011fru karar\u0131 vermenizde ve AWS veri taban\u0131 stratejinizi ba\u015far\u0131yla uygulaman\u0131zda size yol g\u00f6stermeyi umuyoruz.<\/p>\n A\u015fa\u011f\u0131da, okuyucular\u0131m\u0131z\u0131n en \u00e7ok merak etti\u011fi sorular\u0131 ve yan\u0131tlar\u0131n\u0131 bulabilirsiniz:<\/p>\n C:<\/strong> Temel fark, kapsamd\u0131r. RDS Multi-AZ DB K\u00fcmeleri, tek bir AWS B\u00f6lgesi i\u00e7indeki farkl\u0131 Eri\u015filebilirlik Alanlar\u0131 aras\u0131nda y\u00fcksek eri\u015filebilirlik ve felaket kurtarma sa\u011flarken, Aurora Global Database, veri taban\u0131n\u0131 birden fazla AWS B\u00f6lgesine yayarak b\u00f6lgeler aras\u0131 felaket kurtarma ve k\u00fcresel d\u00fc\u015f\u00fck gecikmeli okumalar sunar.<\/p>\n<\/li>\n C:<\/strong> Genellikle RDS Multi-AZ DB K\u00fcmeleri, Aurora Global Database'e g\u00f6re daha uygun maliyetlidir, \u00e7\u00fcnk\u00fc yaln\u0131zca tek bir AWS B\u00f6lgesi i\u00e7inde kaynak bar\u0131nd\u0131r\u0131r ve b\u00f6lgeler aras\u0131 veri transfer maliyetleri olu\u015fmaz. Aurora Global Database'in birden fazla b\u00f6lgede kaynaklar\u0131 ve b\u00f6lgeler aras\u0131 veri transfer \u00fccretleri nedeniyle maliyeti daha y\u00fcksektir.<\/p>\n<\/li>\n C:<\/strong> Sadece tek bir b\u00f6lgedeki kullan\u0131c\u0131lar i\u00e7in d\u00fc\u015f\u00fck gecikme s\u00fcresi \u00f6nemliyse ve b\u00f6lgeler aras\u0131 bir felaketi g\u00f6ze alabiliyorsan\u0131z, yeterli olabilir. Ancak, d\u00fcnya \u00e7ap\u0131nda da\u011f\u0131lm\u0131\u015f kullan\u0131c\u0131lar i\u00e7in ultra d\u00fc\u015f\u00fck gecikme s\u00fcresi ve b\u00f6lgeler aras\u0131 felaket kurtarma kritikse, Aurora Global Database \u00e7ok daha uygun bir \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n<\/li>\n C:<\/strong> RDS Multi-AZ DB K\u00fcmeleri senkron replikasyon kulland\u0131\u011f\u0131 i\u00e7in veri kayb\u0131 riski s\u0131f\u0131ra yak\u0131nd\u0131r (RPO genellikle 0 saniyedir). Her yazma i\u015flemi, her iki kopyada da onaylanana kadar tamamlanmaz.<\/p>\n<\/li>\n C:<\/strong> Aurora Global Database, birincil b\u00f6lgenin tamamen kullan\u0131lamaz hale gelmesi durumunda ikincil bir b\u00f6lgeyi birincil olarak y\u00fckseltme s\u00fcresi (RTO) genellikle 1 dakikan\u0131n alt\u0131ndad\u0131r. Veri kayb\u0131 (RPO) ise 1 saniyenin alt\u0131ndad\u0131r.<\/p>\n<\/li>\n<\/ul>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Veri taban\u0131 mimarinizi tasarlarken y\u00fcksek eri\u015filebilirlik, felaket kurtarma ve d\u00fc\u015f\u00fck gecikme s\u00fcresi kritik mi? \u0130\u015f s\u00fcreklili\u011finizi sa\u011flarken performans…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[644],"tags":[],"class_list":{"0":"post-31179","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-postgresql","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nFaydalar\u0131: Y\u00fcksek Eri\u015filebilirlik ve Veri B\u00fct\u00fcnl\u00fc\u011f\u00fc<\/h3>\n
\n
\n \/\/ AWS CLI ile RDS Multi-AZ DB K\u00fcmesi olu\u015fturma \u00f6rne\u011fi (pseudo-code)\n aws rds create-db-cluster \\\n --db-cluster-identifier my-multi-az-cluster \\\n --engine aurora-postgresql \\\n --engine-version 13.7 \\\n --master-username admin \\\n --master-user-password myStrongPassword \\\n --db-cluster-option-group-name my-option-group \\\n --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx \\\n --db-subnet-group-name my-db-subnet-group \\\n --multi-az-cluster \\\n --tags Key=Environment,Value=Production\n <\/pre>\n--multi-az-cluster<\/code> parametresi, RDS Multi-AZ DB K\u00fcmesi olu\u015fturma komutunun anahtar\u0131n\u0131 temsil eder. Bu komut, belirtilen motor ve versiyonla, birincil ve iki ikincil (okunabilir) \u00f6rne\u011fe sahip bir Multi-AZ k\u00fcmesini otomatik olarak yap\u0131land\u0131r\u0131r.<\/p>\nKullan\u0131m Alanlar\u0131 ve S\u0131n\u0131rlamalar\u0131<\/h3>\n
Amazon Aurora Global Database: K\u00fcresel Uygulamalar \u0130\u00e7in Nas\u0131l Bir D\u00f6n\u00fc\u015f\u00fcm Sa\u011flar?<\/h2>\n
Aurora Global Database Mimarisi: H\u0131zl\u0131 Asenkron Replikasyon<\/h3>\n
Faydalar\u0131: K\u00fcresel Performans ve Felaket Kurtarma<\/h3>\n
\n
\n \/\/ AWS CLI ile Aurora Global Database olu\u015fturma \u00f6rne\u011fi (pseudo-code)\n\n \/\/ Ad\u0131m 1: Birincil b\u00f6lgede Aurora K\u00fcmesi olu\u015ftur (\u00f6rne\u011fin, us-east-1)\n aws rds create-db-cluster \\\n --db-cluster-identifier primary-aurora-cluster \\\n --engine aurora-postgresql \\\n --engine-version 13.7 \\\n --master-username admin \\\n --master-user-password myStrongPassword \\\n --region us-east-1\n \n \/\/ Ad\u0131m 2: Global Database olu\u015ftur\n aws rds create-global-cluster \\\n --global-cluster-identifier my-global-db \\\n --source-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:primary-aurora-cluster \\\n --region us-east-1\n\n \/\/ Ad\u0131m 3: \u0130kincil b\u00f6lgeyi Global Database'e ekle (\u00f6rne\u011fin, eu-west-1)\n aws rds create-db-cluster \\\n --db-cluster-identifier secondary-aurora-cluster \\\n --engine aurora-postgresql \\\n --global-cluster-identifier my-global-db \\\n --region eu-west-1\n <\/pre>\nKullan\u0131m Alanlar\u0131 ve S\u0131n\u0131rlamalar\u0131<\/h3>\n
RDS Multi-AZ vs. Aurora Global Database: Hangi Senaryoda Hangisi Tercih Edilmeli?<\/h2>\n
Kar\u015f\u0131la\u015ft\u0131rmal\u0131 Analiz: Temel Farklar ve Karar Fakt\u00f6rleri<\/h3>\n
\n\n
\n \n\u00d6zellik<\/th>\n RDS Multi-AZ DB K\u00fcmeleri<\/th>\n Amazon Aurora Global Database<\/th>\n<\/tr>\n<\/thead>\n \n Kapsam<\/strong><\/td>\n Tek bir AWS B\u00f6lgesi i\u00e7indeki AZ'ler aras\u0131<\/td>\n Birden fazla AWS B\u00f6lgesi aras\u0131<\/td>\n<\/tr>\n \n Replikasyon Tipi<\/strong><\/td>\n Senkron (Blok tabanl\u0131)<\/td>\n H\u0131zl\u0131 Asenkron (Depolama katman\u0131)<\/td>\n<\/tr>\n \n Temel Ama\u00e7<\/strong><\/td>\n B\u00f6lgesel Y\u00fcksek Eri\u015filebilirlik ve Felaket Kurtarma<\/td>\n K\u00fcresel Y\u00fcksek Eri\u015filebilirlik, D\u00fc\u015f\u00fck Gecikme ve B\u00f6lgeler Aras\u0131 Felaket Kurtarma<\/td>\n<\/tr>\n \n RPO (Kurtarma Noktas\u0131 Hedefi)<\/strong><\/td>\n S\u0131f\u0131ra yak\u0131n (genellikle 0 saniye)<\/td>\n 1 saniyenin alt\u0131nda (\u00e7ok d\u00fc\u015f\u00fck veri kayb\u0131)<\/td>\n<\/tr>\n \n RTO (Kurtarma S\u00fcresi Hedefi)<\/strong><\/td>\n 30-60 saniye aras\u0131 (y\u00fck devretme)<\/td>\n 1 dakikan\u0131n alt\u0131nda (b\u00f6lgeler aras\u0131 y\u00fck devretme)<\/td>\n<\/tr>\n \n Okuma \u00d6l\u00e7eklenebilirli\u011fi<\/strong><\/td>\n \u0130kincil \u00f6rnekler okuma trafi\u011fi i\u00e7in kullan\u0131labilir.<\/td>\n Her ikincil b\u00f6lge kendi okuma replikalar\u0131yla \u00f6l\u00e7eklenebilir.<\/td>\n<\/tr>\n \n Karma\u015f\u0131kl\u0131k<\/strong><\/td>\n Daha d\u00fc\u015f\u00fck (tek b\u00f6lge y\u00f6netimi)<\/td>\n Daha y\u00fcksek (b\u00f6lgeler aras\u0131 y\u00f6netim, ancak AWS taraf\u0131ndan y\u00f6netiliyor)<\/td>\n<\/tr>\n \n Maliyet<\/strong><\/td>\n Aurora Global Database'e g\u00f6re daha uygun<\/td>\n Daha y\u00fcksek (birden fazla b\u00f6lgede kaynak ve veri transferi)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
Ger\u00e7ek D\u00fcnya Uygulamalar\u0131: Ba\u015far\u0131l\u0131 Vaka Analizleri Nelerdir?<\/h2>\n
Vaka Analizi 1: Finansal Hizmetler ve RDS Multi-AZ DB K\u00fcmeleri<\/h3>\n
\n
\n
Vaka Analizi 2: K\u00fcresel E-Ticaret ve Amazon Aurora Global Database<\/h3>\n
\n
\n
\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve Optimizasyon Stratejileri<\/h2>\n
Performans \u0130zleme ve \u0130yile\u015ftirme<\/h3>\n
\n
Maliyet Optimizasyonu<\/h3>\n
\n
Otomatik Y\u00fck Devretme Testleri<\/h3>\n
\n \/\/ AWS CLI ile RDS DB K\u00fcmesinde y\u00fck devretme testi tetikleme \u00f6rne\u011fi (pseudo-code)\n aws rds reboot-db-instance \\\n --db-instance-identifier my-db-instance-primary \\\n --force-failover \\\n --region us-east-1\n <\/pre>\nOkuma Replikalar\u0131n\u0131n Ak\u0131ll\u0131ca Kullan\u0131m\u0131<\/h3>\n
G\u00fcvenlik Hususlar\u0131<\/h3>\n
\n
Sonu\u00e7: Do\u011fru Se\u00e7im \u0130\u015finizin Gelece\u011fini Nas\u0131l \u015eekillendirir?<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n