Klinik biyokimya ve fizyolojide hekimlerin asla taviz vermediği bir kural vardır: Teşhis koymak için hastanın yaşamını durduramazsınız. Şimdi gözünüzün önüne akıl almaz bir kardiyolog getirin: Hastanın dinlenme halindeki bazal kalp ritmini ve kan gazı değerlerini en ufak bir hareket paraziti olmadan, "kusursuz bir netlikle" ölçmek istiyor.

Ve bu ölçümü yapabilmek için hastanın kalbine kardiyopleji sıvısı enjekte ederek kalbi 15 dakika boyunca tamamen durduruyor! EKG monitöründe düz bir çizgi çekiliyor, kan örnekleri alınıyor. Ölçüm gerçekten de sıfır titreşimle, "mükemmel" bir netlikte tamamlanmıştır.

Fakat bu 15 dakika boyunca beyne kan gitmediği için hasta masada hipoksik beyin ölümü yaşar! Cerrah gururla "Tahlil sonuçlarını harika bir şekilde kaydettim" der; ama hasta çoktan mezarlığı boylamıştır. Teşhis hastayı yaşatmak içindir; tahlil yaparken hastayı öldüren hekime hekim denilemez.

Veritabanı mimarisinde ve sistem yönetiminde de gece yarısı sistem mühendislerinin iyi niyetle kurduğu ve e-ticaret sitelerine kendi elleriyle DoS (Denial of Service - Hizmeti Dışı Bırakma) saldırısı yaşatan o ölümcül tahlil tam olarak budur: mysqldump komutunu --single-transaction parametresi olmadan çalıştırıp veritabanını canlı canlı dondurmak.

Gece 02:00: Nöbetçi Script Devrede

Bir e-ticaret platformunun veya 7/24 hizmet veren küresel bir rezervasyon sitesinin sunucusu... Şirketin sistem yöneticisi çok sorumlu bir mühendistir; "Her gece mutlaka veritabanının yedeğini almalıyım" diyerek sunucunun crontab dosyasına şu görevi yazmıştır:

# Her gece 02:00'de tam veritabanı yedeği al:
0 2 * * * /usr/bin/mysqldump -u root -p'parola' eticaret_db > /backup/gece_yedegi.sql

Zamanlama kulağa çok mantıklı gelir: Saat gece 02:00'dir, yerel trafik azalmıştır.

Fakat unutulan devasa bir gerçek vardır: İnternet asla uyumaz! Gece vardiyasında çalışanlar, uykusu kaçanlar, yurt dışından alışveriş yapan gurbetçiler tam o saatte sepetteki ürünlerini onaylamaktadır.

Saat tam 02:00:01'de cron tetiklenir.

Çıplak mysqldump ve Kutsal "LOCK TABLES" Felaketi

mysqldump komutunu hiçbir ek parametre vermeden çıplak bir şekilde çalıştırdığınızda, MySQL motoru şu kararı verir:
"Ben bu veritabanının yedeğini alırken verilerin tutarlı (consistent) olması gerekir. Yani ben ürünler tablosunu kopyalarken kimse stoğu değiştirmesin, siparişler tablosunu alırken kimse yeni sipariş yazmasın!"

Ve mysqldump, veritabanındaki tüm tablolara acımasızca o emri fırlatır:

FLUSH TABLES WITH READ LOCK;

Bu komutun Türkçe meali şudur: "Tüm dünyayı durdurun! İkinci bir emre kadar bu veritabanına TEK BİR HARF BİLE YAZILAMAZ!"

Veritabanı 40 GB büyüklüğündedir. Diskin okuma hızı ve sıkıştırma süresiyle birlikte bu döküm alma ameliyatı tam 18 dakika sürer!

18 Dakikalık Felç: Kilitlenen Sepetler

O 18 dakika boyunca web sitesinde tam bir can pazarı yaşanır:

  1. Bir müşteri kredi kartı bilgilerini girer ve "Siparişi Tamamla" butonuna tıklar. Kod INSERT INTO orders sorgusu atar.
  2. MySQL kapıda bekletir: "Tablo kilitli (State: Locked), bekle!"
  3. İkinci müşteri üye olmak ister: INSERT INTO users -> "Tablo kilitli, bekle!"
  4. Üçüncü müşteri yorum yazar: INSERT INTO comments -> "Tablo kilitli, bekle!"

Sitedeki tüm yazma (write) işlemleri kuyruğa girer. PHP-FPM havuzundaki worker'lar veritabanından yanıt beklemekten kilitlenir. Apache'nin tüm yuvaları (slots) dolar.

Sonuç ne olur? Sitenin ana sayfası bile açılmaz hale gelir!

Ziyaretçilerin ekranında o meşhur hatalar patlar:

"504 Gateway Timeout"
"MySQL Server Has Gone Away"

Kredi kartından para çekilmiş ancak sipariş tablosuna yazılamadığı için siparişler havada kalır. Bankalar hata döner, müşteriler sitenin çöktüğünü sanıp sepeti terk eder.

Saat 02:18 olduğunda mysqldump işlemi biter, kilitler açılır (UNLOCK TABLES). Fakat arkada yüzlerce yarım kalmış sipariş, kilitlenmiş bağlantı ve kaybedilmiş binlerce liralık ciro kalmıştır!

Sistem yöneticisi sabah geldiğinde /backup klasöründeki dosyayı görür ve sevinir: "Harika, 40 GB yedeğimiz pırıl pırıl alınmış!" Oysa o yedeği alırken canlı hastaya 18 dakika boyunca kalp masajı yapmayı unuttuğundan zerre kadar haberi yoktur.

Cerrahi Güvence: --single-transaction Mucizesi

InnoDB gibi modern, ACID uyumlu ve MVCC (Çoklu Sürüm Eşzamanlılık Denetimi) destekleyen bir veritabanı motoru kullanıyorsanız; veritabanını bir saniye bile kilitlemeden, canlı trafiği sıfır kesintiyle akıtarak yedek almanın yolu tek bir parametredir:

# Kesintisiz ve kilitsiz cerrahi yedekleme:
/usr/bin/mysqldump -u root -p'parola' \
  --single-transaction \
  --quick \
  --skip-lock-tables \
  eticaret_db | gzip > /backup/gece_yedegi.sql.gz

Bu sihirli parametrelerin yaptığı cerrahi mucizeler şunlardır:

  1. --single-transaction: Veritabanına LOCK TABLES koymaz! Bunun yerine bir transaction başlatır ve InnoDB'nin MVCC yeteneğini kullanarak veritabanının o anki "anlık görüntüsünü" (snapshot) okur. Siz arka planda 40 GB veriyi çekerken; müşteriler siteden sipariş vermeye, ürün güncellemeye ve ödeme yapmaya kesintisiz devam eder! Canlı trafik ile yedek alma süreci iki paralel evrende akar; kimse kimseyi engellemez.
  2. --quick: Veritabanı tablolarını satır satır doğrudan diskten akıtır (stream). Sunucunun RAM'ini şişirmez, bellek tükenmesi (OOM) yaşatmaz.
  3. gzip ile Borulama (Pipelining): Ham SQL dosyasını diske yazıp sonra sıkıştırmak yerine, çıktıyı doğrudan gzip borusuna vererek disk I/O yükünü %80 azaltır.

Yedekleme Bir Sabotaj Değil, Bir Sanattır

Sisteminizi korumak için aldığınız bir tedbir, sisteminizin çöküş sebebi olamaz. Yedekleme operasyonlarını kurarken şu kuralları asla aklınızdan çıkarmayın:

  • Canlı veritabanında çıplak mysqldump çalıştırmak, ameliyat masasındaki hastanın boğazını sıkmaktır.
  • Eğer veritabanınızda hâlâ eski MyISAM tabloları varsa --single-transaction işe yaramaz (çünkü MyISAM transaction desteklemez). Bu yüzden tüm tablolarınızı vakit kaybetmeden InnoDB'ye dönüştürün.
  • Devasa (100 GB+) veritabanlarında mysqldump yerine Percona XtraBackup gibi fiziksel, kilitlenmesiz sıcak yedekleme (Hot Backup) araçlarını tercih edin.

Ölçüm yaparken hastanın kalbini durduran hekime nasıl katil gözüyle bakılırsa; yedek alırken e-ticaret sitesini kilitleyen yöneticiye de mühendis denilemez. Profesyonel altyapı yönetimi, en ağır bakım ve yedekleme operasyonlarını bile canlı sistemin nabzını bir milisaniye dahi aksatmadan arka planda sessizce yürütme sanatıdır.