Bir g\u00fcn, her \u015feyin yolunda gitti\u011fini d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fcz bir anda, kritik sistemlerinizden biri aniden sessizli\u011fe b\u00fcr\u00fcnse ne yapard\u0131n\u0131z? Bizim i\u00e7in bu senaryo, Redis 8.0 Cluster ve Sentinel kurulumumuzun merkezinde ya\u015fand\u0131. Bu makale, sizi 2 saatlik bir kesintinin e\u015fi\u011fine getiren, ard\u0131ndan sistemlerimizi nas\u0131l ayakta tuttu\u011fumuzu ve bu s\u00fcre\u00e7ten hangi dersleri \u00e7\u0131kard\u0131\u011f\u0131m\u0131z\u0131 ad\u0131m ad\u0131m anlatacak.<\/p>\n
Dijital d\u00fcnyada her saniye \u00f6nemlidir. Bir e-ticaret sitesi i\u00e7in birka\u00e7 dakikal\u0131k kesinti, milyonlarca liral\u0131k sat\u0131\u015f kayb\u0131na yol a\u00e7abilirken, bir finans uygulamas\u0131 i\u00e7in veri eri\u015fimindeki aksakl\u0131klar telafisi g\u00fc\u00e7 zararlar do\u011furabilir. Kullan\u0131c\u0131lar, g\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zl\u0131 tempolu dijital ortam\u0131nda kesintisiz hizmet beklerler ve en ufak bir aksakl\u0131k bile marka itibar\u0131n\u0131 ciddi \u015fekilde zedeleyebilir. \u0130\u015fte bu y\u00fczden y\u00fcksek eri\u015filebilirlik (high availability) kavram\u0131, modern altyap\u0131lar\u0131n vazge\u00e7ilmez bir par\u00e7as\u0131 haline gelmi\u015ftir. Y\u00fcksek eri\u015filebilirlik, sistemlerin beklenmedik ar\u0131zalara ra\u011fmen \u00e7al\u0131\u015fmaya devam etmesini sa\u011flayarak, hizmet kesintilerini minimuma indirmeyi hedefler. Bu, sadece donan\u0131m ar\u0131zalar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda yaz\u0131l\u0131m hatalar\u0131n\u0131, a\u011f sorunlar\u0131n\u0131 ve hatta insan kaynakl\u0131 hatalar\u0131 da kapsar.<\/p>\n
Bizim hikayemiz de tam olarak bu noktada ba\u015fl\u0131yor. Uygulamalar\u0131m\u0131z\u0131n kritik veri katman\u0131n\u0131 olu\u015fturan Redis, anl\u0131k veri depolama, \u00f6nbellekleme ve oturum y\u00f6netimi gibi hayati i\u015flevleri yerine getiriyor. Redis’in sundu\u011fu y\u00fcksek performans, \u00f6zellikle yo\u011fun trafikli anlarda bile uygulamalar\u0131m\u0131z\u0131n h\u0131zl\u0131 ve sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011fl\u0131yor. Ancak bu kadar merkezi bir bile\u015fenin kesintiye u\u011framas\u0131, domino etkisi yaratarak t\u00fcm hizmetlerimizi fel\u00e7 edebilir. Bu bilin\u00e7le, Redis altyap\u0131m\u0131z\u0131 tasarlarken y\u00fcksek eri\u015filebilirlik ve hata tolerans\u0131 (fault tolerance) ilkelerini merkeze ald\u0131k. Redis Cluster ve Redis Sentinel’in birle\u015fimini kullanarak, tek bir hata noktas\u0131n\u0131n (single point of failure) \u00f6n\u00fcne ge\u00e7meyi ve otomatik y\u00fck devretme (automatic failover) yetene\u011fi kazanmay\u0131 hedefledik. Ancak teori ile pratik aras\u0131ndaki fark\u0131, ancak ger\u00e7ek bir kriz an\u0131nda anlayabiliyorsunuz. O g\u00fcn, sistemlerimizin ne kadar sa\u011flam oldu\u011funu ya da zay\u0131f noktalar\u0131n\u0131n nerede oldu\u011funu ac\u0131 bir tecr\u00fcbeyle \u00f6\u011frenme f\u0131rsat\u0131m\u0131z oldu. Bu deneyim, sadece teknik bir sorun giderme hikayesi de\u011fil, ayn\u0131 zamanda bir ekibin kriz y\u00f6netimi, h\u0131zl\u0131 karar alma ve i\u015fbirli\u011fi yeteneklerinin de bir testiydi. Y\u00fcksek eri\u015filebilirlik, sadece sistemlerin ayakta kalmas\u0131n\u0131 sa\u011flamakla kalmaz, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi ve m\u00fc\u015fteri memnuniyeti a\u00e7\u0131s\u0131ndan da kritik bir role sahiptir.<\/p>\n
Redis, a\u00e7\u0131k kaynakl\u0131, bellek i\u00e7i bir veri yap\u0131s\u0131 sunucusu olarak bilinir ve genellikle veritaban\u0131, \u00f6nbellek ve mesaj arac\u0131s\u0131 olarak kullan\u0131l\u0131r. Anahtar-de\u011fer (key-value) format\u0131nda veri depolama yetene\u011fi sayesinde ola\u011fan\u00fcst\u00fc h\u0131z ve performans sunar. Stringler, hashler, listeler, setler, s\u0131ral\u0131 setler gibi \u00e7e\u015fitli veri yap\u0131lar\u0131n\u0131 desteklemesi, onu geli\u015ftiriciler i\u00e7in son derece esnek bir ara\u00e7 haline getirir. Ancak tek bir Redis \u00f6rne\u011fi, do\u011fal olarak tek bir hata noktas\u0131d\u0131r. Bu durum, kritik i\u015f y\u00fckleri i\u00e7in kabul edilemez riskler ta\u015f\u0131r. \u0130\u015fte bu noktada, Redis’in y\u00fcksek eri\u015filebilirlik ve \u00f6l\u00e7eklenebilirlik (scalability) \u00e7\u00f6z\u00fcmleri devreye girer: Redis Cluster ve Redis Sentinel.<\/p>\n
Redis Cluster (Redis K\u00fcmesi)<\/strong>, verilerinizi birden fazla Redis d\u00fc\u011f\u00fcm\u00fcne (node) da\u011f\u0131tarak yatay \u00f6l\u00e7eklenebilirlik sa\u011flar. Bu, tek bir d\u00fc\u011f\u00fcm\u00fcn kald\u0131rabilece\u011finden daha fazla veri depolaman\u0131za ve daha fazla i\u015flem yapman\u0131za olanak tan\u0131r. Cluster mimarisi, verileri “hash slot” ad\u0131 verilen 16384 farkl\u0131 par\u00e7aya b\u00f6ler ve bu slotlar\u0131 k\u00fcmedeki d\u00fc\u011f\u00fcmler aras\u0131nda da\u011f\u0131t\u0131r. Her anahtar, bir hash algoritmas\u0131 kullan\u0131larak belirli bir slota atan\u0131r ve b\u00f6ylece ilgili veri o slotun sahibi olan d\u00fc\u011f\u00fcmde depolan\u0131r. Redis Cluster, ayn\u0131 zamanda birincil (master) ve ikincil (replica) d\u00fc\u011f\u00fcm \u00e7iftleri olu\u015fturarak veri yedeklili\u011fi ve hata tolerans\u0131 sa\u011flar. Bir birincil d\u00fc\u011f\u00fcm \u00e7\u00f6kt\u00fc\u011f\u00fcnde, k\u00fcme otomatik olarak o birincil d\u00fc\u011f\u00fcm\u00fcn ikincil d\u00fc\u011f\u00fcmlerinden birini yeni birincil olarak se\u00e7er. Bu s\u00fcre\u00e7, uygulaman\u0131n veri eri\u015fimini kesintiye u\u011fratmadan devam etmesini sa\u011flar. Redis 8.0 ile birlikte gelen yenilikler, \u00f6zellikle performans optimizasyonlar\u0131 ve baz\u0131 y\u00f6netim kolayl\u0131klar\u0131, cluster y\u00f6netimini daha da verimli hale getiriyor. \u00d6rne\u011fin, yeni veri yap\u0131lar\u0131 veya komut setindeki iyile\u015ftirmeler, belirli senaryolarda daha iyi performans ve esneklik sunabilir.<\/p>\n Redis Sentinel (Redis G\u00f6zc\u00fc)<\/strong> ise, Redis Cluster’dan farkl\u0131 bir y\u00fcksek eri\u015filebilirlik \u00e7\u00f6z\u00fcm\u00fcd\u00fcr ve \u00f6zellikle tekil Redis \u00f6rnekleri veya birincil-ikincil (master-replica) mimarileri i\u00e7in tasarlanm\u0131\u015ft\u0131r. Sentinel, bir veya daha fazla Redis birincil d\u00fc\u011f\u00fcm\u00fcn\u00fc ve onlar\u0131n ikincil d\u00fc\u011f\u00fcmlerini s\u00fcrekli olarak izleyen bir dizi Sentinel s\u00fcrecinden olu\u015fur. Bir birincil d\u00fc\u011f\u00fcm\u00fcn eri\u015filemez hale geldi\u011fini tespit etti\u011finde (\u00f6rne\u011fin, belirli bir s\u00fcre yan\u0131t vermedi\u011finde), Sentinel’ler kendi aralar\u0131nda bir oybirli\u011fi (quorum) olu\u015fturarak yeni bir birincil d\u00fc\u011f\u00fcm se\u00e7imi s\u00fcrecini ba\u015flat\u0131r. Bu s\u00fcrece “y\u00fck devretme” (failover) denir. Se\u00e7ilen yeni birincil d\u00fc\u011f\u00fcm, eski birincil d\u00fc\u011f\u00fcm\u00fcn yerini al\u0131r ve t\u00fcm ikincil d\u00fc\u011f\u00fcmler bu yeni birincil d\u00fc\u011f\u00fcm\u00fc takip etmeye ba\u015flar. Uygulamalar, Sentinel’lere ba\u011flanarak g\u00fcncel birincil d\u00fc\u011f\u00fcm\u00fcn adresini \u00f6\u011frenebilir ve ba\u011flant\u0131lar\u0131n\u0131 otomatik olarak y\u00f6nlendirebilirler. Sentinel, otomatik y\u00fck devretmenin yan\u0131 s\u0131ra, birincil d\u00fc\u011f\u00fcm\u00fcn durumunu izleme, bildirim g\u00f6nderme ve yap\u0131land\u0131rma sa\u011flama gibi g\u00f6revleri de \u00fcstlenir. Bu sayede, manuel m\u00fcdahaleye gerek kalmadan sistemin kesintisiz \u00e7al\u0131\u015fmas\u0131 sa\u011flan\u0131r.<\/p>\n Bizim senaryomuzda, Redis Cluster’\u0131n yatay \u00f6l\u00e7eklenebilirlik avantajlar\u0131n\u0131 ve Sentinel’in otomatik y\u00fck devretme kabiliyetini birle\u015ftirerek, hem veri da\u011f\u0131t\u0131m\u0131n\u0131 hem de hata tolerans\u0131n\u0131 en \u00fcst d\u00fczeye \u00e7\u0131karmay\u0131 hedefledik. Redis 8.0’\u0131n getirdi\u011fi performans art\u0131\u015flar\u0131 ve kararl\u0131l\u0131k iyile\u015ftirmeleri de bu mimarinin sa\u011flaml\u0131\u011f\u0131n\u0131 peki\u015ftiren \u00f6nemli fakt\u00f6rlerdi. Bu kavramlar\u0131 anlamak, kesinti an\u0131nda al\u0131nan kararlar\u0131 ve sistemin nas\u0131l tepki verdi\u011fini kavramak a\u00e7\u0131s\u0131ndan hayati \u00f6neme sahiptir.<\/p>\n Her b\u00fcy\u00fck krizden \u00f6nce, genellikle kapsaml\u0131 bir haz\u0131rl\u0131k s\u00fcreci bulunur. Bizim durumumuzda bu haz\u0131rl\u0131k, Redis 8.0 Cluster ve Sentinel mimarisini titizlikle kurmak ve yap\u0131land\u0131rmaktan ibaretti. Amac\u0131m\u0131z, en k\u00f6t\u00fc senaryolara bile dayanabilecek, otomatik olarak kendini iyile\u015ftirebilen bir altyap\u0131 olu\u015fturmakt\u0131. Bu b\u00f6l\u00fcmde, kurulum ve yap\u0131land\u0131rma ad\u0131mlar\u0131n\u0131, kullan\u0131lan komutlar\u0131 ve dikkat edilmesi gereken \u00f6nemli noktalar\u0131 detayland\u0131raca\u011f\u0131z.<\/p>\n 1. Temel Redis Kurulumu:<\/strong> <\/code>\n<\/div>\n 2. Redis Cluster D\u00fc\u011f\u00fcmlerinin Yap\u0131land\u0131r\u0131lmas\u0131:<\/strong> \u00d6rnek <\/code>\n<\/div>\n Bu yap\u0131land\u0131rma, Redis'i k\u00fcme modunda \u00e7al\u0131\u015ft\u0131r\u0131r, k\u00fcme yap\u0131land\u0131rma dosyas\u0131n\u0131n ad\u0131n\u0131 belirtir ve d\u00fc\u011f\u00fcmler aras\u0131 ileti\u015fim zaman a\u015f\u0131m\u0131n\u0131 ayarlar. Her d\u00fc\u011f\u00fcm i\u00e7in farkl\u0131 bir port ve dizin kullanmak \u00f6nemlidir.<\/p>\n 3. Redis Cluster'\u0131n Olu\u015fturulmas\u0131:<\/strong> <\/code>\n<\/div>\n Bu komut, 3 birincil ve 3 ikincil d\u00fc\u011f\u00fcmden olu\u015fan bir k\u00fcme olu\u015fturur. 4. Redis Sentinel Kurulumu ve Yap\u0131land\u0131rmas\u0131:<\/strong> \u00d6rnek <\/code>\n<\/div>\n Bu yap\u0131land\u0131rma, Sentinel'in 5. Uygulama Ba\u011flant\u0131lar\u0131n\u0131n Yap\u0131land\u0131r\u0131lmas\u0131:<\/strong> Bu detayl\u0131 kurulum ve yap\u0131land\u0131rma s\u00fcreci, sistemimizin omurgas\u0131n\u0131 olu\u015fturdu. Her bir bile\u015fenin do\u011fru ayarland\u0131\u011f\u0131ndan emin olmak i\u00e7in kapsaml\u0131 testler yapt\u0131k. \u00d6zellikle, birincil d\u00fc\u011f\u00fcmlerin manuel olarak kapat\u0131lmas\u0131 ve Sentinel'in otomatik y\u00fck devretme yetene\u011fini g\u00f6zlemlemek, sistemin beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 do\u011frulamam\u0131z\u0131 sa\u011flad\u0131. Bu \"sava\u015f \u00f6ncesi\" haz\u0131rl\u0131k, ger\u00e7ek kriz an\u0131nda bize b\u00fcy\u00fck bir avantaj sa\u011flad\u0131 ve panik yerine kontroll\u00fc bir yan\u0131t vermemize yard\u0131mc\u0131 oldu. Unutulmamal\u0131d\u0131r ki, iyi bir haz\u0131rl\u0131k, kriz an\u0131nda en b\u00fcy\u00fck m\u00fcttefikinizdir.<\/p>\n O g\u00fcn, her zamanki gibi ba\u015flayan s\u0131radan bir i\u015f g\u00fcn\u00fcyd\u00fc. Sabah saatlerinde, sistem izleme (monitoring) panelimizden gelen bir dizi alarm, rutin ak\u0131\u015f\u0131m\u0131z\u0131 aniden kesti. \u0130lk ba\u015fta, \"ge\u00e7ici bir a\u011f sorunu\" diye d\u00fc\u015f\u00fcnd\u00fck, ancak dakikalar ge\u00e7tik\u00e7e durumun ciddiyeti ortaya \u00e7\u0131kt\u0131. Redis Cluster'\u0131m\u0131zdaki birincil d\u00fc\u011f\u00fcmlerden baz\u0131lar\u0131 eri\u015filemez hale gelmi\u015fti ve bu durum, uygulamalar\u0131m\u0131z\u0131n kritik veri eri\u015fimini do\u011frudan etkiliyordu. Kullan\u0131c\u0131lar, web sitemizde ve mobil uygulamam\u0131zda yava\u015flamalar, hata mesajlar\u0131 ve hatta oturum kay\u0131plar\u0131 ya\u015famaya ba\u015flam\u0131\u015ft\u0131. Bu, tam anlam\u0131yla bir \"kriz an\u0131\"yd\u0131.<\/p>\n Kesintinin Tetikleyicisi:<\/strong> Alarm ve \u0130lk Tepkiler:<\/strong> * Durum Tespiti:<\/strong> Hangi Redis d\u00fc\u011f\u00fcmlerinin etkiledi\u011fi, hangi uygulamalar\u0131n bu durumdan etkilendi\u011fi ve etki alan\u0131n\u0131n geni\u015fli\u011fi h\u0131zla belirlendi. Bu 2 saatlik kesinti, sadece teknik bir ar\u0131za de\u011fil, ayn\u0131 zamanda bir stres testiydi. Uygulamalar\u0131m\u0131z\u0131n kritik bile\u015fenlerinin nas\u0131l tepki verdi\u011fini, izleme sistemimizin ne kadar etkili oldu\u011funu ve ekibimizin kriz an\u0131nda ne kadar koordineli \u00e7al\u0131\u015fabildi\u011fini g\u00f6sterdi. En \u00f6nemlisi, bu olay, Sentinel'in ve Cluster'\u0131n tasar\u0131m felsefesinin ne kadar hayati oldu\u011funu bize bir kez daha hat\u0131rlatt\u0131. \u0130\u015fte bu y\u00fczden, bir sonraki b\u00f6l\u00fcmde Sentinel'in bu kriz an\u0131nda nas\u0131l bir \"kahraman\" rol\u00fc oynad\u0131\u011f\u0131n\u0131 detayland\u0131raca\u011f\u0131z.<\/p>\n Kesinti an\u0131nda ya\u015fanan ilk panik dalgas\u0131 ge\u00e7tikten sonra, Redis Sentinel kurulumumuzun devreye girdi\u011fini ve beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6rmek, bize derin bir nefes ald\u0131rd\u0131. A\u011fdaki ar\u0131za nedeniyle baz\u0131 birincil Redis d\u00fc\u011f\u00fcmlerimiz eri\u015filemez hale geldi\u011finde, Sentinel'ler, kendi aralar\u0131nda ileti\u015fim kurarak bu durumu h\u0131zla tespit etti. \u0130\u015fte o an, otomatik y\u00fck devretme (automatic failover) s\u00fcreci ba\u015flad\u0131 ve sistemimizin kesintisizli\u011finin en kritik a\u015famas\u0131 ya\u015fand\u0131.<\/p>\n 1. Birincil D\u00fc\u011f\u00fcm\u00fcn Eri\u015filemez Oldu\u011funun Tespiti (Subjective Down):<\/strong> 2. Oybirli\u011fi ile Onay (Objective Down):<\/strong> 3. Lider Sentinel Se\u00e7imi (Leader Election):<\/strong> 4. Yeni Birincil D\u00fc\u011f\u00fcm\u00fcn Se\u00e7imi ve Y\u00fck Devretme (Failover):<\/strong> 5. Uygulama Ba\u011flant\u0131lar\u0131n\u0131n Yeniden Y\u00f6nlendirilmesi:<\/strong> Bu s\u00fcre\u00e7, yakla\u015f\u0131k 30 saniye i\u00e7inde tamamland\u0131. Bu, kullan\u0131c\u0131lar\u0131m\u0131z i\u00e7in k\u0131sa bir kesinti veya yava\u015flama anlam\u0131na geliyordu, ancak tam bir hizmet duru\u015fundan \u00e7ok daha iyiydi. Sentinel'in otomatik y\u00fck devretme yetene\u011fi, kriz an\u0131nda manuel m\u00fcdahaleye gerek kalmadan sistemin kendini toparlamas\u0131n\u0131 sa\u011flad\u0131. Bu, sadece operasyonel y\u00fck\u00fc azaltmakla kalmad\u0131, ayn\u0131 zamanda insan hatas\u0131 riskini de ortadan kald\u0131rd\u0131. Sentinel, o g\u00fcn bizim i\u00e7in ger\u00e7ek bir kurtar\u0131c\u0131 oldu ve y\u00fcksek eri\u015filebilirlik mimarimizin ne kadar kritik oldu\u011funu bir kez daha kan\u0131tlad\u0131.<\/p>\n Sentinel'in otomatik y\u00fck devretme yetene\u011fi sayesinde kritik sistemlerimiz kesintinin ilk \u015fokunu atlatm\u0131\u015f olsa da, as\u0131l i\u015fimiz, a\u011f ar\u0131zas\u0131n\u0131n k\u00f6k nedenini \u00e7\u00f6zmek ve etkilenen d\u00fc\u011f\u00fcmleri tekrar k\u00fcmeye dahil etmekti. Bu, bir kurtarma operasyonundan \u00e7ok daha fazlas\u0131yd\u0131; ayn\u0131 zamanda gelecekteki olas\u0131 kesintilere kar\u015f\u0131 sistemimizi daha da g\u00fc\u00e7lendirmek i\u00e7in \u00f6nemli dersler \u00e7\u0131kard\u0131\u011f\u0131m\u0131z bir s\u00fcre\u00e7ti.<\/p>\n 1. K\u00f6k Neden Analizi ve A\u011f Sorununun Giderilmesi:<\/strong> 2. Etkilenen Redis D\u00fc\u011f\u00fcmlerinin Durumunu Kontrol Etme:<\/strong> 3. Eski Birincil D\u00fc\u011f\u00fcmlerin K\u00fcmeye Yeniden Kat\u0131lmas\u0131:<\/strong> <\/code>\n<\/div>\n 4. Post-Mortem Analizi ve \u00d6\u011frenilen Dersler:<\/strong> * A\u011f Altyap\u0131s\u0131 \u0130yile\u015ftirmeleri:<\/strong> En b\u00fcy\u00fck ders, a\u011f altyap\u0131m\u0131z\u0131n tek bir hata noktas\u0131na sahip oldu\u011fuydu. Gelecekte benzer sorunlar\u0131n ya\u015fanmamas\u0131 i\u00e7in, a\u011f anahtarlar\u0131m\u0131z\u0131n yedeklili\u011fini art\u0131rma ve farkl\u0131 raflara da\u011f\u0131tma karar\u0131 ald\u0131k. Bu 2 saatlik kesinti, pahal\u0131 bir tecr\u00fcbe olsa da, sistemlerimizi ve s\u00fcre\u00e7lerimizi daha dayan\u0131kl\u0131 hale getirmek i\u00e7in paha bi\u00e7ilmez dersler sundu. Art\u0131k sadece Redis'in y\u00fcksek eri\u015filebilirlik \u00f6zelliklerine g\u00fcvenmekle kalm\u0131yor, ayn\u0131 zamanda bu \u00f6zelliklerin alt\u0131nda yatan altyap\u0131n\u0131n da ayn\u0131 derecede sa\u011flam oldu\u011fundan emin olmak i\u00e7in daha proaktif ad\u0131mlar at\u0131yoruz.<\/p>\n Ya\u015fad\u0131\u011f\u0131m\u0131z 2 saatlik kesinti, Redis 8.0 Cluster ve Sentinel mimarimizin temel sa\u011flaml\u0131\u011f\u0131n\u0131 kan\u0131tlasa da, her kriz gibi bu da bize daha g\u00fc\u00e7l\u00fc ve dayan\u0131kl\u0131 bir gelecek in\u015fa etmek i\u00e7in de\u011ferli ipu\u00e7lar\u0131 ve en iyi uygulamalar \u00f6\u011fretti. \u0130\u015fte bu tecr\u00fcbelerden yola \u00e7\u0131karak geli\u015ftirdi\u011fimiz ve her Redis kullan\u0131c\u0131s\u0131n\u0131n dikkate almas\u0131 gereken stratejiler:<\/p>\n 1. Kapsaml\u0131 \u0130zleme (Monitoring) ve Alarm Sistemleri:<\/strong>Sava\u015f \u00d6ncesi Haz\u0131rl\u0131k: Redis 8.0 Cluster ve Sentinel Kurulumu ve Yap\u0131land\u0131rmas\u0131<\/h3>\n
\n\u0130lk ad\u0131m, her bir sunucuya Redis 8.0’\u0131 kurmakt\u0131. Genellikle bu, i\u015fletim sistemi paket y\u00f6neticisi (APT, YUM) veya Redis’in kaynak kodundan derlenerek yap\u0131l\u0131r. Biz, kararl\u0131l\u0131k ve g\u00fcncel \u00f6zellikler i\u00e7in genellikle kaynak koddan derlemeyi tercih ettik.<\/p>\n\nsudo apt update\nsudo apt install build-essential tcl\nwget http:\/\/download.redis.io\/releases\/redis-8.0.0.tar.gz\ntar xzf redis-8.0.0.tar.gz\ncd redis-8.0.0\nmake\nsudo make install\n <\/pre>\n
\nRedis Cluster, en az 3 birincil d\u00fc\u011f\u00fcm gerektirir, ancak y\u00fcksek eri\u015filebilirlik i\u00e7in her bir birincil d\u00fc\u011f\u00fcm\u00fcn en az bir ikincil d\u00fc\u011f\u00fcmle e\u015fle\u015ftirilmesi \u00f6nerilir (toplamda 6 d\u00fc\u011f\u00fcm: 3 birincil, 3 ikincil). Her bir Redis \u00f6rne\u011fi i\u00e7in ayr\u0131 bir yap\u0131land\u0131rma dosyas\u0131 olu\u015fturduk. \u00d6rne\u011fin, redis-cluster-6379.conf<\/code>, redis-cluster-6380.conf<\/code> vb.<\/p>\nredis-cluster-6379.conf<\/code> i\u00e7eri\u011fi:<\/p>\n\nport 6379\ncluster-enabled yes\ncluster-config-file nodes-6379.conf\ncluster-node-timeout 5000\nappendonly yes\ndaemonize yes\npidfile \/var\/run\/redis-6379.pid\nlogfile \/var\/log\/redis-6379.log\ndir \/var\/lib\/redis\/6379\nbind 0.0.0.0 # Veya belirli IP adresleri\n <\/pre>\n
\nT\u00fcm d\u00fc\u011f\u00fcmler yap\u0131land\u0131r\u0131l\u0131p ba\u015flat\u0131ld\u0131ktan sonra, redis-cli --cluster create<\/code> komutu ile k\u00fcme olu\u015fturulur.<\/p>\n\nredis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 \\\n192.168.1.101:6380 192.168.1.102:6380 192.168.1.103:6380 \\\n--cluster-replicas 1\n <\/pre>\n--cluster-replicas 1<\/code> parametresi, her bir birincil d\u00fc\u011f\u00fcm i\u00e7in bir ikincil d\u00fc\u011f\u00fcm atanaca\u011f\u0131n\u0131 belirtir.<\/p>\n
\nRedis Sentinel, ayr\u0131 sunucularda veya Redis Cluster d\u00fc\u011f\u00fcmlerinden farkl\u0131 sunucularda \u00e7al\u0131\u015ft\u0131r\u0131lmal\u0131d\u0131r. Genellikle, en az 3 Sentinel \u00f6rne\u011fi \u00e7al\u0131\u015ft\u0131rmak, kendi i\u00e7inde hata tolerans\u0131 sa\u011flamak i\u00e7in \u00f6nerilir.<\/p>\nsentinel.conf<\/code> i\u00e7eri\u011fi:<\/p>\n\nport 26379\ndaemonize yes\npidfile \/var\/run\/redis-sentinel-26379.pid\nlogfile \/var\/log\/redis-sentinel-26379.log\ndir \/var\/lib\/redis\/sentinel\/26379\n\nsentinel monitor mycluster 192.168.1.101 6379 2\nsentinel down-after-milliseconds mycluster 5000\nsentinel failover-timeout mycluster 10000\nsentinel parallel-syncs mycluster 1\n <\/pre>\nmycluster<\/code> ad\u0131ndaki birincil d\u00fc\u011f\u00fcm\u00fc (192.168.1.101:6379<\/code>) izlemesini sa\u011flar. 2<\/code> say\u0131s\u0131, birincil d\u00fc\u011f\u00fcm\u00fcn eri\u015filemez oldu\u011funu onaylamak i\u00e7in gereken Sentinel oybirli\u011fi (quorum) say\u0131s\u0131n\u0131 belirtir. Yani, en az 2 Sentinel'in birincil d\u00fc\u011f\u00fcm\u00fcn eri\u015filemez oldu\u011funu onaylamas\u0131 gerekir ki y\u00fck devretme s\u00fcreci ba\u015flas\u0131n.<\/p>\n
\nUygulamalar\u0131m\u0131z\u0131n Redis Cluster'a ba\u011flan\u0131rken, k\u00fcmenin t\u00fcm d\u00fc\u011f\u00fcmlerinin adreslerini bilmesi gerekir. \u00c7o\u011fu Redis istemci k\u00fct\u00fcphanesi (\u00f6rne\u011fin, Jedis, go-redis), k\u00fcme modunu destekler ve ilk ba\u011flant\u0131dan sonra k\u00fcme topolojisini otomatik olarak ke\u015ffedebilir. Sentinel i\u00e7in ise, uygulamalar Sentinel adreslerine ba\u011flan\u0131r ve g\u00fcncel birincil d\u00fc\u011f\u00fcm\u00fcn adresini Sentinel'lerden sorgular.<\/p>\nKriz An\u0131: 2 Saatlik Kesintinin Anatomisi ve \u0130lk Tepkilerimiz<\/h3>\n
\nDetayl\u0131 incelemelerimiz sonucunda, sorunun temelinde veri merkezimizdeki bir a\u011f altyap\u0131 ar\u0131zas\u0131 yatt\u0131\u011f\u0131n\u0131 tespit ettik. Birka\u00e7 sunucunun bulundu\u011fu raf\u0131n (rack) ana a\u011f anahtar\u0131 (network switch) beklenmedik bir \u015fekilde ar\u0131zalanm\u0131\u015ft\u0131. Bu durum, o anahtara ba\u011fl\u0131 olan Redis birincil d\u00fc\u011f\u00fcmlerimizden ikisini ve baz\u0131 Sentinel \u00f6rneklerimizi a\u011fdan izole etmi\u015fti. Redis Cluster'\u0131n hash slot da\u011f\u0131l\u0131m\u0131 sayesinde, verilerin tamam\u0131 kaybolmam\u0131\u015ft\u0131, ancak belirli hash slotlar\u0131na ait veriler ve dolay\u0131s\u0131yla bu verilere ba\u011f\u0131ml\u0131 uygulama fonksiyonlar\u0131 eri\u015filemez hale gelmi\u015fti. \u00d6rne\u011fin, kullan\u0131c\u0131 oturum bilgileri veya belirli \u00fcr\u00fcn kategorileri ile ilgili \u00f6nbellekler aniden kaybolmu\u015ftu.<\/p>\n
\nAlarm sistemimiz (Prometheus ve Grafana ile entegre edilmi\u015f) an\u0131nda devreye girmi\u015fti. CPU kullan\u0131m\u0131, bellek t\u00fcketimi gibi klasik metriklerin yan\u0131 s\u0131ra, Redis'e \u00f6zel metrikler olan connected_clients<\/code>, keyspace_hits<\/code> ve keyspace_misses<\/code> gibi de\u011ferlerdeki ani d\u00fc\u015f\u00fc\u015fler ve art\u0131\u015flar, bize sorunun Redis katman\u0131nda oldu\u011funu g\u00f6sterdi. \u0130lk tepkimiz, h\u0131zla bir kriz toplant\u0131s\u0131 d\u00fczenlemek oldu. Geli\u015ftirme, operasyon ve a\u011f ekiplerinden temsilciler bir araya geldi. Durumu de\u011ferlendirmek ve h\u0131zl\u0131ca bir eylem plan\u0131 olu\u015fturmak i\u00e7in zamanla yar\u0131\u015f\u0131yorduk.<\/p>\nredis-cli --cluster check<\/code> komutu, k\u00fcmenin sa\u011fl\u0131k durumunu anlamak i\u00e7in ilk ba\u015fvurdu\u011fumuz ara\u00e7lardan biriydi.
\n* \u0130leti\u015fim:<\/strong> \u0130\u00e7 ve d\u0131\u015f payda\u015flara durum hakk\u0131nda bilgi vermek, panik havas\u0131n\u0131 yat\u0131\u015ft\u0131rmak ve \u015feffafl\u0131\u011f\u0131 sa\u011flamak i\u00e7in kritikti. M\u00fc\u015fterilerimize y\u00f6nelik bir \"durum sayfas\u0131\" (status page) g\u00fcncellendi.
\n* H\u0131zl\u0131 M\u00fcdahale:<\/strong> A\u011f ekibi, ar\u0131zal\u0131 anahtar\u0131 tespit edip de\u011fi\u015ftirmek i\u00e7in harekete ge\u00e7erken, biz de Redis taraf\u0131nda olas\u0131 manuel m\u00fcdahaleleri de\u011ferlendirmeye ba\u015flad\u0131k. Ancak burada Sentinel'in otomatik y\u00fck devretme yetene\u011fine g\u00fcvenmek, en do\u011fru strateji gibi g\u00f6r\u00fcn\u00fcyordu.<\/p>\nSentinel Devrede: Otomatik Y\u00fck Devretme S\u00fcreci Nas\u0131l \u0130\u015fledi?<\/h3>\n
\nHer bir Sentinel \u00f6rne\u011fi, yap\u0131land\u0131r\u0131lm\u0131\u015f birincil d\u00fc\u011f\u00fcmleri ve ikincil d\u00fc\u011f\u00fcmleri belirli aral\u0131klarla (sentinel down-after-milliseconds<\/code> parametresiyle belirlenen s\u00fcre i\u00e7inde) ping g\u00f6ndererek izler. A\u011f anahtar\u0131n\u0131n ar\u0131zalanmas\u0131yla birlikte, a\u011fdan izole olan birincil d\u00fc\u011f\u00fcmlerimizden baz\u0131lar\u0131, bu ping'lere yan\u0131t verememeye ba\u015flad\u0131. Her bir Sentinel, kendi perspektifinden bu birincil d\u00fc\u011f\u00fcmlerin \"\u00f6znel olarak eri\u015filemez\" (subjectively down) oldu\u011funu kaydetti.<\/p>\n
\nBir Sentinel, bir birincil d\u00fc\u011f\u00fcm\u00fcn \u00f6znel olarak eri\u015filemez oldu\u011funu tespit etti\u011finde, di\u011fer Sentinel'lere bu durumu bildirmek i\u00e7in bir mesaj g\u00f6nderir. E\u011fer yeterli say\u0131da Sentinel (yap\u0131land\u0131rmadaki quorum<\/code> de\u011feri kadar), ayn\u0131 birincil d\u00fc\u011f\u00fcm\u00fcn eri\u015filemez oldu\u011funu onaylarsa, bu birincil d\u00fc\u011f\u00fcm \"nesnel olarak eri\u015filemez\" (objectively down) olarak i\u015faretlenir. Bizim yap\u0131land\u0131rmam\u0131zda, quorum<\/code> de\u011feri 2 olarak ayarlanm\u0131\u015ft\u0131. Bu, en az iki Sentinel'in birincil d\u00fc\u011f\u00fcm\u00fcn \u00e7\u00f6kt\u00fc\u011f\u00fcn\u00fc onaylamas\u0131 gerekti\u011fi anlam\u0131na geliyordu. A\u011f ar\u0131zas\u0131, baz\u0131 Sentinel'leri de etkilemi\u015f olsa da, yeterli say\u0131da Sentinel \u00f6rne\u011fi sa\u011flam kalmay\u0131 ba\u015fard\u0131 ve bu onay s\u00fcrecini ba\u015far\u0131yla tamamlad\u0131.<\/p>\n
\nBir birincil d\u00fc\u011f\u00fcm nesnel olarak eri\u015filemez hale geldi\u011finde, Sentinel'ler kendi aralar\u0131nda bir \"lider Sentinel\" se\u00e7imi ba\u015flat\u0131r. Bu lider, y\u00fck devretme s\u00fcrecini y\u00f6netecek olan Sentinel'dir. Bu s\u00fcre\u00e7, Raft benzeri bir algoritma kullanarak ger\u00e7ekle\u015fir ve en az\u0131ndan \u00e7o\u011funlu\u011fun oyunu alan Sentinel, lider olarak se\u00e7ilir. Lider Sentinel, y\u00fck devretme s\u00fcrecinin tek ve yetkili orkestrat\u00f6r\u00fc olur.<\/p>\n
\nLider Sentinel, eri\u015filemez olan birincil d\u00fc\u011f\u00fcm\u00fcn ikincil d\u00fc\u011f\u00fcmleri aras\u0131ndan, en g\u00fcncel verilere sahip ve en uygun olan\u0131n\u0131 yeni birincil d\u00fc\u011f\u00fcm olarak se\u00e7er. Bu se\u00e7im genellikle ikincil d\u00fc\u011f\u00fcmlerin replikasyon ofsetlerine (replication offset) ve Sentinel'in alg\u0131lad\u0131\u011f\u0131 di\u011fer sa\u011fl\u0131k metriklerine g\u00f6re yap\u0131l\u0131r. Se\u00e7ilen ikincil d\u00fc\u011f\u00fcm, SLAVEOF NO ONE<\/code> komutuyla birincil d\u00fc\u011f\u00fcme d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Ard\u0131ndan, di\u011fer t\u00fcm ikincil d\u00fc\u011f\u00fcmler, yeni birincil d\u00fc\u011f\u00fcm\u00fc takip etmeleri i\u00e7in yap\u0131land\u0131r\u0131l\u0131r (SLAVEOF
\nUygulamalar\u0131m\u0131z, Redis'e do\u011frudan ba\u011flanmak yerine, Sentinel'lere ba\u011flanarak g\u00fcncel birincil d\u00fc\u011f\u00fcm\u00fcn adresini sorgulayacak \u015fekilde tasarlanm\u0131\u015ft\u0131. Y\u00fck devretme s\u00fcreci tamamland\u0131\u011f\u0131nda, Sentinel'ler yeni birincil d\u00fc\u011f\u00fcm\u00fcn adresini istemci uygulamalar\u0131na bildirdi. Bu sayede, uygulamalar\u0131m\u0131z k\u0131sa bir s\u00fcre i\u00e7inde yeni birincil d\u00fc\u011f\u00fcme otomatik olarak yeniden ba\u011fland\u0131 ve veri eri\u015fimine devam etti. Bu yeniden ba\u011flant\u0131 s\u00fcreci, istemci k\u00fct\u00fcphanelerimizin (\u00f6rne\u011fin, Java i\u00e7in Jedis, Python i\u00e7in redis-py) Sentinel entegrasyonu sayesinde b\u00fcy\u00fck \u00f6l\u00e7\u00fcde sorunsuz ger\u00e7ekle\u015fti.<\/p>\nKurtarma Operasyonu ve \u00d6\u011frenilen Dersler: Sistemi Yeniden Aya\u011fa Kald\u0131rmak<\/h3>\n
\nA\u011f ekibimiz, ar\u0131zal\u0131 anahtar\u0131 tespit ettikten sonra h\u0131zla de\u011fi\u015fim ve yap\u0131land\u0131rma s\u00fcrecini ba\u015flatt\u0131. Bu s\u00fcre\u00e7 yakla\u015f\u0131k 1.5 saat s\u00fcrd\u00fc. Bu s\u00fcre zarf\u0131nda, Sentinel'in y\u00f6netti\u011fi yeni birincil d\u00fc\u011f\u00fcmlerimiz hizmet vermeye devam etti. A\u011f ba\u011flant\u0131s\u0131 geri geldi\u011finde, izole olan Redis d\u00fc\u011f\u00fcmleri ve Sentinel'ler tekrar a\u011fa dahil oldu.<\/p>\n
\nA\u011f ba\u011flant\u0131s\u0131 kurulduktan sonra, etkilenen Redis d\u00fc\u011f\u00fcmlerinin durumunu kontrol ettik. redis-cli -p 6379 cluster nodes<\/code> komutunu kullanarak k\u00fcmenin genel sa\u011fl\u0131\u011f\u0131n\u0131 ve her bir d\u00fc\u011f\u00fcm\u00fcn durumunu inceledik. A\u011fdan izole olan birincil d\u00fc\u011f\u00fcmlerimiz, art\u0131k k\u00fcme taraf\u0131ndan \"fail\" (ar\u0131zal\u0131) olarak i\u015faretlenmi\u015fti. Sentinel'ler ise, eski birincil d\u00fc\u011f\u00fcmleri otomatik olarak ikincil d\u00fc\u011f\u00fcm olarak yap\u0131land\u0131rmaya ba\u015flam\u0131\u015ft\u0131, ancak baz\u0131 durumlarda manuel m\u00fcdahale gerekebiliyordu.<\/p>\n
\nA\u011f ar\u0131zas\u0131 nedeniyle birincil d\u00fc\u011f\u00fcm olarak g\u00f6rev yapamayan ve daha sonra ikincil d\u00fc\u011f\u00fcme d\u00f6n\u00fc\u015fen Redis \u00f6rneklerini tekrar k\u00fcmeye dahil etme s\u00fcreci karma\u015f\u0131k olabilirdi. Eski birincil d\u00fc\u011f\u00fcmlerin veri senkronizasyonu (data synchronization) yapmas\u0131 ve k\u00fcme topolojisine uygun \u015fekilde entegre olmas\u0131 gerekiyordu.
\n* Senaryo 1: Sentinel Otomatik Olarak D\u00fczeltti:<\/strong> \u00c7o\u011fu durumda, Sentinel'ler, eski birincil d\u00fc\u011f\u00fcmler tekrar eri\u015filebilir hale geldi\u011finde, onlar\u0131 otomatik olarak yeni birincil d\u00fc\u011f\u00fcm\u00fcn ikincil d\u00fc\u011f\u00fcm\u00fc olarak yap\u0131land\u0131rd\u0131. Bu, veri senkronizasyonunun otomatik olarak ba\u015flamas\u0131n\u0131 sa\u011flad\u0131.
\n* Senaryo 2: Manuel M\u00fcdahale Gerekti:<\/strong> Nadiren de olsa, baz\u0131 d\u00fc\u011f\u00fcmlerin k\u00fcme topolojisine manuel olarak kat\u0131lmas\u0131 gerekti. Bu durumda, redis-cli --cluster meet<\/code> komutunu kullanarak d\u00fc\u011f\u00fcm\u00fc k\u00fcmeye tekrar ekledik ve ard\u0131ndan cluster replicate<\/code> komutuyla birincil d\u00fc\u011f\u00fcm\u00fcn\u00fc belirledik.<\/p>\n\n# D\u00fc\u011f\u00fcm\u00fcn k\u00fcme modundan \u00e7\u0131k\u0131p tekrar girmesi gerekebilir (nadiren)\n# redis-cli -p 6379 shutdown\n# rm \/var\/lib\/redis\/6379\/nodes-6379.conf\n# redis-server \/etc\/redis\/redis-cluster-6379.conf\n\n# E\u011fer d\u00fc\u011f\u00fcm otomatik olarak replicaya d\u00f6n\u00fc\u015fmediyse, manuel olarak birincil d\u00fc\u011f\u00fcme ekleme:\n# redis-cli -p 6380 cluster replicate
\nKesinti tamamen giderildikten sonra, kapsaml\u0131 bir post-mortem (kriz sonras\u0131 de\u011ferlendirme) toplant\u0131s\u0131 yapt\u0131k. Bu toplant\u0131, sadece teknik sorunlar\u0131 de\u011fil, ayn\u0131 zamanda operasyonel s\u00fcre\u00e7leri ve ileti\u015fim ak\u0131\u015f\u0131n\u0131 da de\u011ferlendirmemizi sa\u011flad\u0131.<\/p>\n
\n* \u0130zleme ve Alarm \u0130yile\u015ftirmeleri:<\/strong> Sentinel'in otomatik y\u00fck devretmesi harika olsa da, a\u011f sorununu daha erken tespit edebilecek veya Redis d\u00fc\u011f\u00fcmlerinin neden eri\u015filemez oldu\u011funu daha net belirtebilecek yeni izleme metrikleri ve alarm e\u015fikleri ekledik. \u00d6zellikle, a\u011f gecikmesi (network latency) ve paket kayb\u0131 (packet loss) gibi metriklerin daha yak\u0131ndan izlenmesi gerekti\u011fini fark ettik.
\n* Kurtarma Prosed\u00fcrlerinin G\u00f6zden Ge\u00e7irilmesi:<\/strong> Kurtarma operasyonumuz ba\u015far\u0131l\u0131 olsa da, bu s\u00fcreci daha da optimize etmek i\u00e7in prosed\u00fcrlerimizi g\u00fcncelledik. \u00d6zellikle, Redis Cluster ve Sentinel'in bir arada \u00e7al\u0131\u015ft\u0131\u011f\u0131 senaryolarda manuel m\u00fcdahale ad\u0131mlar\u0131n\u0131 daha net belgeledik.
\n* Ekip \u0130leti\u015fimi ve \u0130\u015fbirli\u011fi:<\/strong> Kriz an\u0131nda h\u0131zl\u0131 ve etkili ileti\u015fimin ne kadar \u00f6nemli oldu\u011funu bir kez daha g\u00f6rd\u00fck. Ekipler aras\u0131 i\u015fbirli\u011fini g\u00fc\u00e7lendirmek i\u00e7in d\u00fczenli tatbikatlar yapma karar\u0131 ald\u0131k.<\/p>\nDaha G\u00fc\u00e7l\u00fc Bir Gelecek \u0130\u00e7in: Redis Y\u00fcksek Eri\u015filebilirlik \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h3>\n
\nSistemlerinizin sa\u011fl\u0131\u011f\u0131n\u0131 s\u00fcrekli olarak izlemek, olas\u0131 sorunlar\u0131 erken a\u015famada tespit etmenin anahtar\u0131d\u0131r.
\n* Redis'e \u00d6zel Metrikler:<\/strong> Sadece CPU, bellek gibi genel metrikleri de\u011fil, ayn\u0131 zamanda connected_clients<\/code>, keyspace_hits\/misses<\/code>, replication_offset<\/code>, used_memory<\/code>, latency<\/code> gibi Redis'e \u00f6zg\u00fc metrikleri de yak\u0131ndan takip edin.
\n* Sentinel Durumu:<\/strong> Sentinel \u00f6rneklerinin kendi sa\u011fl\u0131k durumlar\u0131n\u0131, birincil d\u00fc\u011f\u00fcm se\u00e7imlerini ve y\u00fck devretme olaylar\u0131n\u0131 izleyin.
\n* A\u011f Metrikleri:<\/strong> Redis d\u00fc\u011f\u00fcmleri aras\u0131ndaki a\u011f gecikmesi, paket kayb\u0131 ve bant geni\u015fli\u011fi gibi met<\/p>\n","protected":false},"excerpt":{"rendered":"Redis 8.","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":[1404],"tags":[],"class_list":{"0":"post-41555","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-redis","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n