Veritabanı sorunlarına uygulanabilir çözümler.
PostgreSQL, MySQL, MongoDB, Redis ve ClickHouse tarafında işler bazen tek bir hata mesajına sıkışır: bağlantı kopar, sorgu yavaşlar, yedek güven vermez. Buradaki yazılar o anlarda “nereden başlayayım?” sorusuna sakin ve uygulanabilir cevap vermek için hazırlandı.
Nasıl yazıyoruz?
Önce derdi anlıyor, sonra ölçüp çözmeye çalışıyoruz.
- 1Önce sakinleşHata mesajını tek başına değil, kullanıcı etkisi ve zaman çizgisiyle birlikte oku.
- 2Kanıtla ilerleTahmin yürütmek yerine motorun kendi metrikleri, explain çıktıları ve olay kayıtlarıyla nedeni daralt.
- 3Düzelt, sonra tekrar bakKomutu çalıştırmak işin yarısıdır; gerçekten iyileşti mi diye aynı metriklere yeniden dön.
En sık görülen üretim sorunları
Her yazı tek bir gerçek derde odaklanır. Okuyan kişi sayfayı kapattığında en azından neye bakacağını, neyi değiştireceğini ve neyi değiştirmemesi gerektiğini bilsin istiyoruz.
Veritabanına bağlanılamıyor: bağlantı hatalarını 10 dakikada ayırma rehberi
Veritabanına bağlanamamak panik yaratır; çünkü hata çoğu zaman tek satırdır ama arkasında DNS, ağ, TLS, parola, IP izin listesi ya da bağlantı havuzu olabilir. Bu yazı, önce panik düğmesini kapatıp hatayı sakin sakin hangi sepete koyacağınızı anlatır.
- connection refused veya connection timed out
- no pg_hba.conf entry, access denied, authentication failed
- TLS handshake failed veya certificate verify failed
PostgreSQL too many clients ve yavaş sorgu: PgBouncer, indeks ve EXPLAIN planı
PostgreSQL “too many clients” dediğinde sorun sadece bağlantı sayısı değildir; çoğu zaman uygulama fazla bağlantı açıyor, bazı sorgular da o bağlantıları gereğinden uzun süre meşgul ediyordur. Bu yazı bağlantı havuzu ile yavaş sorguyu aynı hikâyenin iki parçası olarak ele alır.
- FATAL: sorry, too many clients already
- API isteklerinde kuyruklanma ve yüksek gecikme
- pg_stat_activity içinde idle in transaction oturumları
MySQL Too many connections ve InnoDB yavaşlığı: bağlantı, indeks ve PITR kontrolü
MySQL tarafında kullanıcı yalnızca “site yavaş” der; içeride ise fazla bağlantı, uzun transaction, kilit bekleme veya kötü indeks olabilir. Bu yazı, aynı görünen bu sorunları birbirinden ayırıp önce hangisine dokunmanız gerektiğini anlatır.
- ERROR 1040 Too many connections
- Lock wait timeout exceeded
- API tarafında ara ara 5xx veya zaman aşımı
MongoDB yavaş sorgu ve indeks büyümesi: explain, compound index ve replica set sağlığı
MongoDB ilk günlerde çok rahat hissettirir: şema esnektir, veri hızlı akar. Ama veri büyüdüğünde kötü indeks ya da belirsiz sorgu deseni, kullanıcıya yavaş listeleme olarak döner. Bu yazı, “COLLSCAN gördüm, şimdi ne yapacağım?” sorusuna odaklanır.
- COLLSCAN görünen explain çıktısı
- nReturned düşükken totalDocsExamined çok yüksek
- ikincil replika gecikmesi
Redis bellek doldu, eviction başladı: TTL, SLOWLOG ve gecikme spike çözümü
Redis çoğu ekip için “hızlı olsun” diye konur; sonra bir gün bellek dolar, eviction başlar ya da p99 gecikme zıplar. Bu yazı Redis’i kara kutu gibi görmek yerine TTL, key boyutu ve riskli komutlar üzerinden okunabilir hale getirir.
- OOM command not allowed
- evicted_keys artışı
- SLOWLOG içinde KEYS veya büyük LRANGE komutları
ClickHouse SELECT sorguları neden yavaşlar ve nasıl hızlandırılır?
ClickHouse yavaşladığında ilk tepki genellikle “bu motor hızlı değil miydi?” olur. Aslında ClickHouse hâlâ hızlıdır; ama yanlış sorgu, yanlış ORDER BY veya fazla veri okuma onu gereksiz yere koşturur. Bu yazı SELECT tarafında önce ne kadar veri okuduğunuzu buldurur, sonra okunan veriyi azaltmanın yollarını anlatır.
- Pano sorguları saniyeler yerine onlarca saniye sürüyor
- CPU yükseliyor ama sonuç seti küçük dönüyor
- Aynı tablo bazı filtrelerle hızlı, bazı filtrelerle yavaş çalışıyor
ClickHouse INSERT yavaşlıyor: küçük batch ve too many parts sorunu nasıl çözülür?
ClickHouse INSERT tarafında sorun çoğu zaman “az veri yazıyorum, niye yavaşlıyor?” diye başlar. Cevap genellikle verinin miktarında değil, yazılma biçimindedir: çok sık, çok küçük batchler ClickHouse’un part/merge düzenini yorar.
- INSERT gecikme zamanla artıyor
- Too many parts veya parts are forming too quickly uyarısı görülüyor
- system.parts içinde aynı partition için yüzlerce aktif part var
Yedek, PITR ve geri yükleme stratejisi: hangi veritabanında hangi kurtarma modeli gerekir?
Yedek almak insana iyi hissettirir; ama asıl soru şudur: “Bugün yanlışlıkla veri silsek, gerçekten geri dönebiliyor muyuz?” Bu yazı yedek, PITR ve geri yükleme konusunu bir güven hissi değil, kanıtlanması gereken bir çalışma düzeni olarak ele alır.
- yedek var ama geri yükleme hiç test edilmemiş
- hangi zamana geri dönülebileceği bilinmiyor
- analitik veride snapshot yeterliyken OLTP sistemde PITR ihtiyacı var
Veritabanı göçü nasıl planlanır: snapshot, CDC, cutover ve geri dönüş
Veritabanı göçü çoğu zaman teknik bir kopyalama işi gibi başlar, ama gerçek risk son dakikadadır: uygulamayı ne zaman durduracağız, ne kadar veri farkı kalacak, geri dönmek zorunda kalırsak ne yapacağız? Bu yazı göçü bir komut değil, küçük ve kontrollü kararlar dizisi olarak ele alır.
- mevcut veritabanını yönetilen bir platforma taşımak istiyorsunuz
- kesinti süresini ne kadar azaltabileceğinizi bilmiyorsunuz
- hangi motor için CDC, hangisi için one-shot kopya gerektiği karışık
PostgreSQL CDC cutover: logical replication ile kesintiyi nasıl azaltırsınız?
PostgreSQL CDC göçü, “bir gece kapatalım, dump alalım” seçeneğinden daha zarif olabilir; ama sadece doğru hazırlandıysa. Logical replication ilk kopyayı alır, değişiklikleri akıtır ve cutover anındaki farkı küçültür. Bu yazı o farkı güvenle sıfıra yaklaştırmanın pratiğini anlatır.
- PostgreSQL veritabanını taşımak istiyorsunuz ama uzun kesinti istemiyorsunuz
- kaynak veritabanında yazma trafiği devam ediyor
- wal_level, publication veya replication yetkileri kafanızı karıştırıyor
TLS ve IP izin listesi: veritabanı erişimini güvenli ama yaşanabilir tasarlamak
Güvenli veritabanı erişimi bazen iki uç arasında sıkışır: ya her şeyi açıp işleri kolaylaştırırız ya da erişimi o kadar kilitleriz ki ekip çalışamaz. Bu yazı TLS ve IP izin listesi tasarımını, günlük hayatı zorlaştırmadan güvenliği artıracak şekilde düşünür.
- geliştiriciler farklı ağlardan bağlanmak zorunda kalıyor
- CI/CD runner veritabanına bazen bağlanıyor bazen bağlanmıyor
- 0.0.0.0/0 açmak kısa yol gibi görünüyor
Veritabanı kullanıcıları ve rol ayrımı: herkes admin olmasın
Bir ekibin büyüdüğünü anlamanın yollarından biri şudur: aynı veritabanı kullanıcısı hem uygulamada, hem raporda, hem migrationda, hem de geliştiricinin laptopında kullanılıyordur. Bu yazı herkesi admin yapmadan yaşanabilir bir rol ayrımı kurmayı anlatır.
- uygulama admin yetkisiyle bağlanıyor
- BI aracı canlı ortam tablolarına yazabilecek yetkide
- migration kullanıcısı günlük uygulama trafiğinde de kullanılıyor
PostgreSQL vacuum ve bloat: tablo neden şişer, nasıl toparlanır?
PostgreSQL bazen disk dolduğu için değil, geçmişi taşıdığı için ağırlaşır. UPDATE ve DELETE işlemleri eski satır izlerini hemen yok etmez; autovacuum onları arkadan toplar. Bu yazı “tablo neden büyüyor, vacuum neyi yetiştiremiyor?” sorusunu sakin sakin açar.
- tablo boyutu veri hacmine göre anlamsız büyüyor
- UPDATE/DELETE yoğun tablolar zamanla yavaşlıyor
- autovacuum çalışıyor ama yetmiyor gibi görünüyor
MySQL buffer pool ve indeks performansı: RAM gerçekten yetiyor mu?
MySQL’de “RAM yetmiyor” demek kolaydır; bazen doğrudur da. Ama buffer pool baskısı, kötü indeks, fazla bağlantı ve disk okuması birbirine karışır. Bu yazı MySQL’in belleği nasıl kullandığını ve indeks kararının neden RAM kadar önemli olduğunu anlatır.
- aynı sorgular veri büyüdükçe yavaşlıyor
- disk I/O artıyor ve önbellek etkisi düşüyor
- EXPLAIN çıktısında type=ALL veya yüksek rows görülüyor
MongoDB indeks yaşam döngüsü: her yavaş sorguya indeks eklemeyin
MongoDB’de indeks eklemek kolaydır; bu yüzden fazla indeks biriktirmek de kolaydır. Her indeks okumayı hızlandırabilir ama yazmayı, belleği ve disk kullanımını ağırlaştırır. Bu yazı “hangi indeks gerçekten işe yarıyor?” sorusunu sorar.
- koleksiyonda çok sayıda indeks var ama sorgular hâlâ yavaş
- write gecikme indeks eklendikçe artıyor
- düşük seçicilikte alanlar indekslenmiş
Redis bellek profili: hot key, TTL ve önbellek stratejisini birlikte düşünmek
Redis’i sadece “önbellek” diye görmek bazen tehlikelidir; çünkü önbellek de zamanla ürün davranışının bir parçası olur. Hangi key sıcak, hangisi gereğinden büyük, hangisinin TTL’i yok bilmiyorsanız kapasite kararınız tahmine dönüşür.
- önbellek hit oranı düşüyor
- bazı keyler aşırı büyük veya aşırı sık okunuyor
- TTL olmayan önbellek keyleri birikiyor
ClickHouse projection ve materialized view: ne zaman hangisini kullanmalı?
ClickHouse’ta her yavaş pano sorgusunu ham tablo üzerinde hızlandırmaya çalışmak bazen gereksiz inat olur. Bazı sorular tekrar tekrar soruluyorsa, cevabı önceden hazırlamak daha doğrudur. Bu yazı projection, materialized view ve özet tablo kararını sadeleştirir.
- pano aynı agregasyonu sürekli çalıştırıyor
- ham event tablosu büyüdükçe raporlar yavaşlıyor
- ORDER BY tek başına tüm sorgu desenlerini karşılamıyor
Veritabanı olayında ilk 15 dakika: panik yerine kanıt toplayan müdahale rehberi
Olay anında en pahalı şey çoğu zaman sorun değil, herkesin aynı anda farklı yöne koşmasıdır. Bu yazı ilk 15 dakikayı “kim neyi kanıtlıyor?” sorusuyla düzenler: etkiyi ölç, kapsamı daralt, değişiklikleri dondur, doğru sinyali topla.
- uygulama bir anda 500 hatası vermeye başladı
- veritabanı bağlantıları zaman aşımı oluyor
- gecikme yükseldi ama CPU düşük görünüyor
Failover sonrası kontroller: veritabanı ayakta mı, uygulama gerçekten toparlandı mı?
Failover tamamlandı mesajı güzel bir başlangıçtır, bitiş çizgisi değildir. Asıl soru şudur: uygulama yeni yazma noktasına bağlandı mı, kullanıcı işlemleri dönüyor mu, replikalar sağlıklı mı, yedekleme akışı kaldığı yerden devam ediyor mu?
- failover sonrası uygulama hâlâ eski primaryye bağlanmaya çalışıyor
- okuma var ama yazma hataları sürüyor
- bazı workerlar toparlandı, bazıları eski bağlantıyı tutuyor
RPO/RTO tatbikatı: yedek geri yükleme gerçekten çalışıyor mu nasıl kanıtlanır?
Yedek listesinde yeşil görünen satır, felaket anında uygulamanın geri geleceğini tek başına kanıtlamaz. RPO/RTO tatbikatı, “yedek var” cümlesini “şu kadar sürede, şu noktaya, şu kontrollerle döndük” cümlesine çevirir.
- yedekler alınıyor ama geri yükleme hiç denenmedi
- RPO/RTO hedefleri belgede var ama ölçülmedi
- PITR penceresi biliniyor fakat uygulama geri yükleme hedefine bağlanmadı
Bakım penceresi: veritabanı upgrade ve parametre değişikliği nasıl güvenli yapılır?
Bakım penceresi “gece kimse yokken yaparız” diye geçiştirilecek bir iş değildir. İyi bakım, neyin değişeceğini, neyin değişmeyeceğini, hangi sinyalde durulacağını ve geri dönüş kararının kimde olduğunu önceden yazar.
- minor upgrade veya parametre değişikliği planlanıyor
- bakımdan önce yedekleme/PITR kontrolü yapılmadı
- rollback eşiği net değil
Veritabanı maliyet anomalisi: fatura mı arttı, kullanım mı değişti?
Fatura bir anda yükseldiğinde ilk tepki genellikle “platform pahalılaştı mı?” olur. Bazen öyledir; ama çoğu zaman kullanım deseni sessizce değişmiştir: tablo büyümüştür, yedek saklama süresi uzamıştır, yavaş sorgu daha çok kaynak yakmıştır veya gereksiz büyük tier seçilmiştir.
- aylık veritabanı maliyeti beklenenden hızlı arttı
- disk büyüyor ama veri hacmi aynı sanılıyor
- yedek saklama maliyeti görünmez kalıyor
Kimlik bilgisi rotasyonu: veritabanı şifresi ve API key nasıl kesinti yaratmadan değiştirilir?
Şifre değiştirmek kolay gibi görünür; zor olan, hangi uygulamanın hangi kimlik bilgisini kullandığını bilerek kesinti yaratmadan değiştirmektir. İyi rotasyon eski anahtarı aniden kesmek değil, yeni anahtarı devreye alıp eskiyi kanıtla kapatmaktır.
- eski çalışan veya eski entegrasyon kimlik bilgisi hâlâ duruyor
- tek veritabanı kullanıcısı birçok serviste kullanılıyor
- şifre değişince hangi servislerin etkileneceği bilinmiyor
Denetim kaydı okumak: veritabanında kim, neyi, ne zaman değiştirdi?
Denetim kaydı, olay bittikten sonra bakılan sıkıcı bir tablo olmamalı. Doğru tutulduğunda ekip için hafıza görevi görür: kim erişti, hangi ayar değişti, hangi kullanıcı oluşturuldu, hangi yedek geri yükleme edildi?
- hangi kullanıcının değişiklik yaptığı bilinmiyor
- admin aksiyonları Slack mesajlarında kalıyor
- yedek geri yükleme veya kullanıcı silme olaylarının kanıtı yok
Tenant izolasyonu: çok kiracılı veritabanı mimarisinde risk nasıl küçültülür?
Çok kiracılı sistemlerde asıl soru sadece “veri ayrı mı?” değildir. Ağ yolu, kullanıcı yetkisi, yedek, metrik, destek erişimi ve kaynak tüketimi de tenant sınırını doğru okumalıdır.
- tenant_id filtresi uygulama kodunda unutulabilir diye endişe ediliyor
- bir müşterinin yoğunluğu diğerini etkiliyor
- destek ekibi müşteri verisine nasıl güvenli bakacağını bilmiyor
Destek erişimi ve acil erişim: canlı ortam veritabanına ne zaman, nasıl bakılır?
Canlı ortam verisine bakmak bazen gerçekten gerekir; ama “bir bakıp çıkacağım” cümlesi güvenlik modeli olamaz. Destek erişimi süreli, gerekçeli, mümkünse salt okunur ve denetimli olmalıdır.
- destek ekibi müşteri sorununu incelemek için canlı ortam verisine bakmak istiyor
- kimin ne zaman eriştiği sonradan kanıtlanamıyor
- admin kullanıcı günlük destek işleri için kullanılıyor
Veri yaşam döngüsü: TTL, retention ve arşivleme kararını nasıl verirsiniz?
Veri büyümesi çoğu zaman ürün başarısı gibi görünür; ama her veri sonsuza kadar sıcak kalmak zorunda değildir. TTL, retention ve arşivleme kararı hem performansı hem faturayı hem de uyum yükünü etkiler.
- eski event ve log verisi ana tabloda büyümeye devam ediyor
- soft delete kayıtları hiç temizlenmiyor
- yedek maliyeti canlı veriden hızlı artıyor
PostgreSQL partitioning: büyüyen tabloda ne zaman parçalama gerekir?
PostgreSQL’de tablo büyüdüğünde ilk soru “partition açalım mı?” olur. Bazen doğru cevaptır; bazen de yanlış indeks, eski veri yaşam döngüsü veya yavaş sorguyu saklayan pahalı bir mimari değişikliktir.
- tek tablo yüz milyonlarca satıra ulaştı
- tarih aralığıyla çalışan sorgular yavaşlıyor
- eski veriyi silmek veya arşivlemek zorlaşıyor
MySQL online schema change: ALTER TABLE neden gece kabusu olabilir?
MySQL’de bir kolon eklemek küçük bir iş gibi görünür; ama büyük tabloda yanlış ALTER TABLE, metadata lock ve uzun kopyalama yüzünden uygulamayı bekletebilir. Şema değişikliği kod değişikliği kadar plan ister.
- ALTER TABLE canlı ortamda bekliyor ve sorgular kilitleniyor
- metadata lock yüzünden uygulama zaman aşımı alıyor
- büyük tabloya kolon veya indeks eklenecek
MongoDB schema drift: doküman esnekliği ne zaman borca dönüşür?
MongoDB’nin şema esnekliği ilk günlerde hız kazandırır. Ama aynı alan bazen string, bazen number, bazen object oluyorsa sorgu, indeks ve uygulama kodu yavaş yavaş belirsizleşir.
- aynı koleksiyonda alan tipleri karıştı
- eski uygulama sürümleri farklı doküman şekli yazıyor
- indeks var ama sorgu hâlâ verimsiz
Redis önbellek stampede: aynı anda expire olan keyler veritabanını nasıl yorar?
Önbellek keyleri aynı anda expire olduğunda, Redis boşluğu ana veritabanına yük olarak geri döner. Sorun Redis’in yavaş olması değil, önbellek’in aynı anda herkesi kapıya göndermesidir.
- belirli dakikalarda veritabanı trafiği aniden artıyor
- önbellek hit oranı dalgalanıyor
- popüler uç noktalarde p95 gecikme sıçrıyor
ClickHouse dictionary ve JOIN tasarımı: boyut tablolarını nasıl hızlı okursunuz?
ClickHouse ham eventleri çok hızlı tarar; ama her pano sorgusunda büyük dimension tablolarla JOIN yapmak hız vaadini zayıflatabilir. Dictionary, denormalizasyon ve özet tablo kararını doğru yerde kullanmak gerekir.
- pano sorguları JOIN yüzünden yavaşlıyor
- küçük lookup tabloları her sorguda tekrar okunuyor
- event tablosu hızlı ama kullanıcı/ürün bilgisiyle birleşince ağırlaşıyor
Ajans ve yazılım ekipleri için çok müşteri veritabanı yönetimi: izolasyon, erişim ve fatura karmaşası
Bir ajans veya yazılım evi için veritabanı sorunu çoğu zaman tek bir müşterinin problemi değildir. Müşteri sayısı arttıkça erişim, yedek, fatura, yetki ve “bu veritabanına kim dokundu?” sorusu büyür.
- her müşteri için farklı bağlantı bilgisi ve farklı not dosyası tutuluyor
- müşteri verileri aynı yerde karışmasın diye manuel kurallar yazılıyor
- destek ekibi geçici erişim aldıktan sonra ne yaptığı izlenemiyor
SaaS tenant açılış süreci: yeni müşteri için veritabanını güvenli ve tekrarlanabilir açmak
SaaS ürünlerde yeni müşteri açmak sadece kayıt formu oluşturmak değildir. Tenant’ın veritabanı, kullanıcıları, bağlantı yolu, migration durumu, yedekleri ve ilk gün destek izleri aynı anda hazır olmalıdır.
- yeni müşteri açılışı manuel adımlarla ilerliyor
- tenant oluşturuldu ama migration eksik kaldığı için ilk giriş hata veriyor
- bağlantı dizesi ve gizli değer dağıtımı gelişi güzel yapılıyor
Analitik event pipeline: PostgreSQL uygulama verisini ClickHouse raporlamasına nasıl ayırırsınız?
Uygulama veritabanı her şeyi taşımaya başladığında raporlama sorguları ürünün kalbini yorar. Analitik eventleri ClickHouse’a ayırmak doğru olabilir; ama event modeli, idempotency ve batch yazma tasarlanmadan yapılan taşıma sadece sorunu başka yere götürür.
- pano sorguları PostgreSQL üzerinde uygulama trafiğini yavaşlatıyor
- raporlama için ağır GROUP BY ve tarih aralığı sorguları çalışıyor
- event tablosu büyüdükçe indeks ve vacuum maliyeti artıyor
E-ticaret ödeme akışı dayanıklılığı: PostgreSQL, Redis ve yedek planı birlikte nasıl düşünülür?
Ödeme akışı akışı, veritabanı mimarisinin en dürüst sınavlarından biridir. Sepet, stok, ödeme ve sipariş aynı anda doğru, hızlı ve tekrar denenebilir olmalıdır; sadece “veritabanı ayakta” olması yetmez.
- ödeme tekrar denenince çift sipariş riski oluşuyor
- Redis sepet verisi kaybolunca kullanıcı deneyimi bozuluyor
- stok rezervasyonu ile ödeme durumu tutarsızlaşıyor
Test ortamı ve canlı ortam veri ayrımı: test ortamı gerçek veriye nasıl zarar vermez?
Test ortamı canlı ortama benzesin isteriz; ama canlı ortam verisinin aynısını kontrolsüz şekilde test ortamına taşımak güvenlik, KVKK ve müşteri güveni açısından ciddi risktir.
- test ortamında gerçek müşteri e-postaları ve telefonları var
- test scripti yanlışlıkla canlı ortam bağlantı dizesiyle çalıştı
- geliştirici erişimleri canlı ortam verisine fazla geniş
Bölgesel bulut veya hosting sağlayıcısı yönetilen veritabanı hizmetini nasıl paketler?
Yönetilen veritabanı satmak, Kubernetes üzerinde birkaç operatör çalıştırmaktan daha fazlasıdır. Müşteri bir cluster değil; paket, bağlantı, yedek, destek, fatura ve güven hissi satın alır.
- hosting müşterileri veritabanı yönetimini de sizden bekliyor
- motorları kurabiliyorsunuz ama paket ve faturalama modeli net değil
- müşteri başına izolasyon ve destek sınırı karışıyor
KVKK veri silme talebi geldiğinde veritabanı tarafında neyi kanıtlamalısınız?
Veri silme talebi sadece bir DELETE komutu değildir. Canlı veritabanı, yedekler, denetim kayıtları, fatura kayıtları ve destek exportları aynı veri yaşam döngüsünün parçasıdır.
- müşteri veya kullanıcı veri silme talebi iletiyor
- hangi tabloda hangi kişisel veri duruyor net değil
- canlı veriden silinen verinin yedeklerde ne olacağı belirsiz
Müşteri platformdan ayrılırken veritabanı export, silme ve fatura kapanışı nasıl yönetilir?
Müşteri ayrılırken süreç “clusterı sil” diye kapanmaz. Veri exportu, abonelik, kimlik bilgisi, webhook, silme kuyruğu, final fatura ve denetim paketi birlikte kapanmalıdır.
- müşteri ayrılmak istiyor ama verisini nasıl alacağı belirsiz
- cluster silindi fakat API key veya webhook açık kaldı
- final fatura ile ölçümleme kayıtları uyuşmuyor
SLA ve hizmet kredisi: veritabanı kesintisinde müşteriye karşı sorumluluk nasıl izlenir?
SLA ihlali yalnızca status page notu değildir. Müşteriye görünür claim, admin onayı, denetim kaydı, meter credit ve faturada kredi satırıyla kapanmalıdır.
- kesinti yaşandı ama hangi müşterinin nasıl etkilendiği belirsiz
- hizmet kredisi manuel notla uygulanıyor
- faturada kredi var ama hangi olaya bağlı olduğu görünmüyor
Kapasite paketleme: makine paketi, depolama, yedekleme ve geri yükleme maliyeti nasıl okunur?
Veritabanı maliyeti sadece CPU/RAM paketinden ibaret değildir. Canlı depolama, yedek, PITR arşivi, geri yükleme hedefi ve ağ kullanımı doğru okunmazsa hem müşteri hem sağlayıcı fatura sürprizi yaşar.
- müşteri paketi küçük seçiyor ama depolama hızla büyüyor
- yedek maliyeti canlı veriden daha hızlı artıyor
- geri yükleme hedefi test için açıldıktan sonra unutuluyor
Kendi yönettiğiniz veritabanı operatörü mü, managed TürkDB mi: hangi durumda hangisi mantıklı?
Kendi yönettiğiniz operatör kurmak ilk bakışta özgürlük ve maliyet avantajı gibi görünür. Ama asıl karar “kurabilir miyiz?” değil; yedek, geri yükleme, upgrade, failover, güvenlik ve nöbet yükünü yıllarca taşıyabilir miyiz sorusudur.
- Kubernetes üzerinde operatör kurmayı düşünüyorsunuz
- yönetilen veritabanı maliyeti yüksek görünüyor ama ekip zamanı hesaba katılmıyor
- yedekleme ve geri yükleme sorumluluğunun kimde olduğu belirsiz
Genel bulut DBaaS mı, bölgesel TürkDB mi: gecikme, veri yerleşimi ve destek kararını nasıl verirsiniz?
Genel bulut DBaaS güçlü bir seçenektir; ama her şirketin problemi aynı değildir. Bazıları için global servis zenginliği önemlidir, bazıları için veri yerleşimi, düşük gecikme, yerel destek ve sade fatura daha belirleyicidir.
- uygulama Türkiye veya yakın bölge kullanıcılarına hizmet veriyor
- genel bulut DBaaS güçlü ama maliyet ve destek dili ağır geliyor
- veri yerleşimi ve müşteri sözleşmeleri karar sürecini etkiliyor
Hangi veritabanı motorunu seçmeliyim: PostgreSQL, MySQL, MongoDB, Redis ve ClickHouse karar ağacı
Veritabanı seçimi çoğu zaman teknoloji sevgisiyle başlar, ama üretimde ürün sorusuna döner: veri nasıl değişiyor, nasıl okunuyor, ne kadar tutarlı olmalı, hangi sorgu gerçekten kritik?
- yeni ürün için hangi veritabanını seçeceğiniz belirsiz
- her ekip bildiği motoru önermek istiyor
- analitik yükü OLTP veritabanını yavaşlatıyor
Veritabanı migration maliyeti nasıl hesaplanır: downtime, doğrulama, rollback ve ekip zamanı
Migration maliyeti sadece hedef cluster fiyatı değildir. Asıl maliyet çoğu zaman hazırlık, doğrulama, çift çalışma, downtime riski, rollback planı ve ekip dikkatinde gizlidir.
- migration projesi ucuz görünüyor ama takvim uzuyor
- hedef cluster fiyatı hesaplandı fakat ekip zamanı yok
- downtime penceresi iş tarafıyla konuşulmadı
Canlı ortam veritabanı canlıya çıkış kontrol listesi: canlıya çıkmadan önce neyi kanıtlamalısınız?
Canlı ortam veritabanı canlıya çıkışı “uygulama bağlandı mı?” kontrolünden ibaret değildir. Yedek, geri yükleme, güvenlik, alarm, kapasite, bakım ve geri dönüş kanıtlanmadan canlıya çıkış eksik kalır.
- canlıya çıkış yaklaşıyor ama veritabanı kontrol listesi yok
- yedekleme açık fakat geri yükleme hiç denenmedi
- uygulama bağlanıyor ama alarm ve müdahale rehberi hazır değil
Yönetilen veritabanı pilotunda hangi kanıtları istemelisiniz?
Yönetilen veritabanı kararını özellik listesiyle değil, pilotta görülen kanıtla vermek daha sağlıklıdır. Bir servis “yedek var” diyebilir; asıl soru o yedek’ın geri dönüp dönmediği, kimin eriştiği, maliyetin nasıl oluştuğu ve olay anında hangi kanıtın kaldığıdır.
- yönetilen veritabanı sağlayıcısı değerlendiriyorsunuz
- satış sunumu iyi ama hangi kanıtı istemeniz gerektiği belirsiz
- yedek, failover ve güvenlik başlıkları özellik listesi gibi anlatılıyor
PostgreSQL kilit beklemeleri: idle in transaction, deadlock ve uzun transaction nasıl çözülür?
PostgreSQL’de kilit sorunu çoğu zaman “veritabanı yavaşladı” diye görünür. Oysa bazen tek bir açık transaction, bütün sipariş akışını bekletebilir. Bu yazı, kilidi kimin tuttuğunu ve kimi beklettiğini sakin şekilde bulmayı anlatır.
- UPDATE veya DELETE sorguları bekliyor
- deadlock detected hatası görülüyor
- idle in transaction oturumları uzun süre açık kalıyor
MySQL replication lag ve binlog büyümesi: okuma gecikmesi neden olur, nasıl toparlanır?
MySQL replikasında gecikme başladığında sorun sadece “replika geride kaldı” değildir. Kullanıcı eski veri görebilir, raporlar şaşabilir, failover kararı riskli hale gelebilir. Bu yazı gecikmenin nedenini ve güvenli toparlama sırasını anlatır.
- okuma replikasında eski veri görülüyor
- Seconds_Behind_Source artıyor
- binlog dosyaları hızla büyüyor
MongoDB bağlantı havuzu ve server selection timeout: uygulama neden bağlanamıyor?
MongoDB bağlantı hataları bazen veritabanı kapalıymış gibi görünür; ama gerçek neden yanlış replica set adı, DNS, TLS, aşırı küçük bağlantı havuzu veya uygulamanın gereksiz yeni client açması olabilir.
- MongoServerSelectionError görülüyor
- server selection timed out after 30000 ms
- uygulama yoğun saatte MongoDB’ye bağlanamıyor
Redis veri kaybı riski: AOF, RDB ve önbellek ile kalıcı veri ayrımı nasıl yapılır?
Redis çoğu ekip için “önbellek” diye başlar, sonra oturum, sayaç, kuyruk ve kritik durum bilgisi de içine girer. Bu sınır bulanıklaştığında restart sonrası veri kaybı sürpriz değil, tasarım borcu olur.
- Redis restart sonrası bazı veriler kayboldu
- AOF kapalı mı açık mı bilinmiyor
- oturum verisi ile önbellek aynı clusterda duruyor
ClickHouse disk doluyor: TTL, retention ve partition temizliği nasıl planlanır?
ClickHouse çok hızlı veri yutar; sorun da bazen tam buradan doğar. Event, log ve metrik verisi aylarca temizlenmeden büyürse disk dolar, sorgular ağırlaşır ve maliyet sessizce yükselir.
- ClickHouse disk kullanımı hızla artıyor
- eski event veya log verisi silinmiyor
- TTL tanımlı ama disk hemen boşalmıyor
Veritabanı normalizasyonu nedir: ne zaman normalleştirmeli, ne zaman denormalize etmeli?
Normalizasyon çoğu kişiye okul konusu gibi gelir; ama asıl soru hâlâ çok canlıdır: veriyi tek yerde mi tutacağız, yoksa okuma hızlansın diye tekrar mı edeceğiz? Bu yazı normalizasyonu ezber tanım olarak değil, günlük veritabanı kararı olarak anlatır.
- aynı müşteri bilgisi birçok tabloda veya dokümanda tekrar ediyor
- bir alan güncellenince başka yerde eski değer kalıyor
- çok fazla join yüzünden sorgular karmaşıklaşıyor
PostgreSQL ve MySQL’de normalizasyon: foreign key, join ve indeks dengesini nasıl kurarsınız?
İlişkisel veritabanlarında normalizasyon güçlü bir başlangıçtır; ama “her şeyi en küçük tabloya bölelim” demek de çözüm değildir. Bu yazı foreign key, join ve indeks dengesini gerçek uygulama akışları üzerinden anlatır.
- aynı müşteri veya ürün bilgisi birçok tabloda tekrar ediyor
- foreign key yok diye silinen kayıtlar yetim satır bırakıyor
- join sayısı artınca sorgular yavaşlıyor
MongoDB’de normalizasyon var mı: embed mi reference mı kararını nasıl verirsiniz?
MongoDB kullanınca normalizasyon ortadan kalkmaz; sadece soru değişir. Tablo ve foreign key yerine doküman, gömülü alan ve referans arasında karar verirsiniz.
- aynı kullanıcı bilgisi birçok dokümanda tekrar ediyor
- dokümanlar büyüdükçe güncelleme zorlaşıyor
- lookup sorguları yavaşlıyor
ClickHouse’ta normalizasyon: analitik tabloda neden çoğu zaman denormalizasyon seçilir?
ClickHouse tarafında normalizasyon sorusu OLTP’den farklıdır. Analitik sorgu milyonlarca satır tararken her seferinde birçok tabloyu join etmek yerine, bazı boyutları tabloya kopyalamak doğru tercih olabilir.
- ClickHouse sorguları çok fazla JOIN yapıyor
- boyut tabloları küçük ama sorgular karmaşık
- wide table mı star schema mı karar verilemiyor
Redis’te normalizasyon olur mu: cache key tasarımı ve veri tekrarı nasıl yönetilir?
Redis ilişkisel veritabanı değildir; ama “aynı veriyi kaç yerde tutuyorum?” sorusu burada da vardır. Kötü key tasarımı ve kontrolsüz cache kopyaları, normalizasyon borcunun Redis versiyonudur.
- ürün bilgisi farklı cache keylerinde farklı görünüyor
- TTL var ama eski veri kullanıcıya dönüyor
- cache silinince uygulama aşırı yavaşlıyor
PostgreSQL PITR adım adım: WAL arşivi, restore target time ve doğrulama
PITR kulağa sihirli bir geri alma düğmesi gibi gelir; ama aslında disiplinli bir kayıt düzenidir. Base backup, WAL arşivi ve doğru hedef zaman birleşirse veritabanını belirli bir ana yaklaştırabilirsiniz. Bu yazı, PITR’ı ezber komut değil karar ve doğrulama süreci olarak anlatır.
- yanlışlıkla tablo silindi ve hangi zamana dönüleceği bilinmiyor
- WAL arşivi açık ama hiç restore tatbikatı yapılmadı
- base backup var fakat WAL dosyalarının tamam olup olmadığı belirsiz
MySQL binlog ile veri geri alma: ne zaman işe yarar, ne zaman yetmez?
MySQL binlog, doğru kurulduysa yanlış bir işlemden sonra hayat kurtarabilir. Ama binlog tek başına zaman makinesi değildir; temel yedek, saklama süresi, format ve hedef zaman kararı olmadan güvenli geri dönüş planı sayılmaz.
- yanlış DELETE veya UPDATE çalıştı
- son tam yedekten sonra çok veri değişti
- binlog açık ama ne kadar saklandığı bilinmiyor
MongoDB yedekleme ve geri yükleme: snapshot, oplog ve tutarlılık riski
MongoDB’de yedekleme, sadece dosya kopyalamak değildir. Replica set, oplog, snapshot zamanı ve uygulamanın veri modeli birlikte düşünülmezse geri yüklenen veri açılır ama doğru çalışmayabilir.
- mongodump var ama geri yükleme hiç denenmedi
- snapshot hangi saniyeyi temsil ediyor bilinmiyor
- oplog penceresi kısa olduğu için hedef zamana dönülemiyor
ClickHouse backup/restore: büyük tabloda geri dönüşü nasıl test edersiniz?
ClickHouse’ta yedekleme sorusu çoğu zaman veri boyutuyla büyür. Terabaytlarca tabloyu geri döndürmek sadece dosyayı bulmak değildir; partition, object storage, süre, maliyet ve rapor doğruluğu birlikte düşünülmelidir.
- ClickHouse tabloları hızla büyüyor ama restore süresi bilinmiyor
- backup var fakat büyük partition geri dönüşü denenmedi
- raporlar eski veriye ne kadar toleranslı bilinmiyor
Redis Cluster mı Sentinel mi: yüksek erişilebilirlik beklentisi nasıl kurulmalı?
Redis tarafında Sentinel ve Cluster çoğu zaman aynı şeymiş gibi konuşulur. Oysa Sentinel esas olarak failover düzenidir; Cluster ise veriyi parçalara dağıtan farklı bir mimaridir. Doğru seçim, “kaç GB veri var?” kadar “uygulama istemcisi neyi destekliyor?” sorusuna da bağlıdır.
- Redis tek node çalışıyor ve kesinti riski var
- Sentinel mi Cluster mı seçileceği karışık
- uygulama istemcisinin Cluster destekleyip desteklemediği bilinmiyor
MySQL lock wait timeout: hangi sorgu kimi bekletiyor?
MySQL’de lock wait timeout çoğu zaman yavaş sorgu gibi görünür ama kökte bekleyen bir transaction vardır. Doğru soru “hangi sorgu yavaş?” değil, “kim kimi bekletiyor?” olmalıdır.
- Lock wait timeout exceeded hatası alınıyor
- bazı UPDATE veya DELETE sorguları takılıyor
- uygulamada sipariş veya ödeme adımı ara ara donuyor
PostgreSQL query planner neden yanlış plan seçer?
PostgreSQL bazen “indeks varken neden kullanmadı?” sorusunu sordurur. Çoğu zaman cevap planner’ın kötü olması değil, elindeki istatistiklerin, veri dağılımının veya sorgu biçiminin gerçeği eksik anlatmasıdır.
- indeks var ama sequential scan yapılıyor
- bazı tenantlarda sorgu hızlı bazılarında çok yavaş
- EXPLAIN tahmini satır ile gerçek satır çok farklı
MongoDB replica set election: primary değişince uygulama neden etkilenir?
MongoDB replica set primary değiştirirken kısa bir kararsızlık penceresi oluşabilir. Veritabanı tasarımı doğru olsa bile uygulama driver ayarları, timeout ve retry davranışı uygun değilse kullanıcı bunu hata olarak görür.
- primary değişimi sırasında server selection timeout görülüyor
- uygulama birkaç saniye yazma yapamıyor
- driver eski primary’ye bağlanmaya çalışıyor
Uygulama bağlantı havuzu rehberi: Node.js, Go ve Java için pratik ayarlar
Bağlantı havuzu küçük bir ayar gibi görünür ama üretimde veritabanını en hızlı yoran konulardan biridir. Her pod, her worker ve her servis kendi havuzunu açtığında “max 20 bağlantı” bir anda yüzlerce bağlantıya dönüşebilir.
- too many connections hatası alınıyor
- uygulama ölçeklenince veritabanı bağlantı limiti doluyor
- idle bağlantılar birikiyor
ORM kaynaklı veritabanı sorunları: N+1 sorgu, gereksiz transaction ve eksik indeks
ORM kötü değildir; ama veritabanını görünmez yaparsa sorun çıkarır. N+1 sorgu, gereksiz transaction, eksik indeks ve kontrolsüz eager loading üretimde “veritabanı yavaş” diye görünür.
- liste sayfası kayıt sayısı arttıkça yavaşlıyor
- loglarda aynı sorgu yüzlerce kez tekrar ediyor
- transaction içinde dış API çağrısı yapılıyor
Multi-tenant veri modelleme: ayrı database, ayrı schema, tenant_id kolonu
Multi-tenant mimaride tek doğru yoktur. Ayrı database güçlü izolasyon verir ama operasyon yükü artar. Tenant_id kolonu ekonomiktir ama disiplin ister. Ayrı schema ortada durur; ama o da bedelsiz değildir.
- SaaS ürününde tenant verisi nasıl ayrılacak bilinmiyor
- bazı müşteriler özel izolasyon istiyor
- tek tabloda tenant_id unutma riski var
KVKK için veri maskeleme: test ortamına canlı veri taşımadan nasıl çalışılır?
Test ortamında canlı veri kullanmak pratik görünür; ama çoğu veri sızıntısı böyle sıradan kopyalarla başlar. Sağlıklı yaklaşım, test ihtiyacını karşılayacak kadar gerçekçi ama kişisel veri riskini azaltacak kadar maskelenmiş veri üretmektir.
- canlı veritabanı yedeği test ortamına doğrudan dönülüyor
- geliştiriciler gerçek müşteri e-postası ve telefonlarını görüyor
- test ortamında erişim kontrolleri canlı kadar sıkı değil
Motor bazlı ölçeklenebilirlik rehberi: PostgreSQL, MySQL, MongoDB, Redis ve ClickHouse ne zaman nasıl ölçeklenir?
Ölçeklenebilirlik çoğu zaman “daha büyük makine alalım” diye başlar; ama her motor aynı şekilde büyümez. PostgreSQL ve MySQL’de bağlantı, indeks ve okuma/yazma ayrımı öne çıkar. MongoDB’de shard key, Redis’te hot key, ClickHouse’ta shard/replica ve veri modeli belirleyicidir.
- trafik artınca hangi motorun nasıl büyütüleceği bilinmiyor
- CPU yükselince hemen daha büyük makine seçiliyor
- okuma yükü ile yazma yükü ayrılmadan replica ekleniyor
PostgreSQL ölçeklenebilirlik: connection pool, read replica, partitioning ve ne zaman yetmez?
PostgreSQL çoğu ürün için uzun süre çok iyi ölçeklenir; ama doğru sırayla. Önce sorgu ve bağlantı düzeni, sonra dikey kaynak, sonra read replica ve partitioning düşünülmelidir. Sharding en başta değil, gerçekten gerektiğinde konuşulmalıdır.
- PostgreSQL CPU sürekli yüksek
- too many clients hatası sıklaşıyor
- okuma sorguları yazma trafiğini yavaşlatıyor
MySQL ölçeklenebilirlik: read replica, InnoDB, proxy ve partition kararları
MySQL ölçekleme çoğu zaman üç soruyla başlar: InnoDB gerçekten bellekte çalışıyor mu, okuma trafiği primaryden ayrılabilir mi, uygulama bağlantıları kontrol altında mı? Bunlar çözülmeden replica veya partition kararı eksik kalır.
- MySQL CPU ve disk I/O artıyor
- buffer pool yetmiyor gibi görünüyor
- okuma raporları yazma işlemlerini etkiliyor
MongoDB ölçeklenebilirlik: replica set, sharding ve shard key nasıl seçilir?
MongoDB yatay ölçeklenebilirlik denince sharding akla gelir; ama sharding yanlış shard key ile yapılırsa yükü dağıtmak yerine tek shardı yakar. Replica set erişilebilirlik sağlar, sharding kapasite dağıtır; ikisi aynı karar değildir.
- tek koleksiyon hızla büyüyor
- bazı tenantlar tüm yükü taşıyor
- sharding düşünülüyor ama shard key belirsiz
Redis ölçeklenebilirlik: Cluster, hot key, bellek ve ne zaman cache yetmez?
Redis hızlıdır; ama sonsuz değildir. Bellek dolduğunda, tek hot key tüm trafiği çektiğinde veya cache verisi kaynak gerçeklik gibi kullanılmaya başladığında ölçek sorunu başlar. Cluster çözüm olabilir; ama her Redis problemine otomatik cevap değildir.
- Redis bellek kullanımı sürekli artıyor
- tek key çok yoğun okunuyor
- Cluster kuruldu ama bazı nodelar daha sıcak
ClickHouse ölçeklenebilirlik: shard, replica, Distributed table ve veri modeli
ClickHouse büyük okuma için güçlüdür; ama iyi ölçeklenmesi shard sayısından önce veri modeline bağlıdır. Yanlış partition, küçük insertler, zayıf ORDER BY ve gereksiz JOIN yükü varsa cluster büyür ama sorgular beklenen kadar rahatlamaz.
- ClickHouse sorguları veri büyüdükçe yavaşlıyor
- tek node sınırına yaklaşılıyor
- shard ve replica farkı karışıyor
76 makalenin tamamı bir konu başlığına bağlı
Genel görünen yazılar da artık sahipsiz değil: erişim, performans, yedekleme, göç, güvenlik, olay, bakım ve maliyet başlıkları altında net şekilde ayrılıyor.
Her motorun kritik konuları farklı
Aynı makaleler ayrıca motorlara göre de ayrılır; böylece PostgreSQL, MySQL, MongoDB, Redis ve ClickHouse tarafındaki derinlik korunur.
Sorunun kaynağını birlikte netleştirelim
Bazen doğru cevap yeni bir ayar değil, doğru soruyu sormaktır. Bağlantı, performans, yedekleme veya kapasite tarafında nerede takıldığınızı birlikte açalım.