MySQLYedekleme ve kurtarma 14 dk 14.06.2026

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.

Bu yazı sana şu durumda yardımcı olur

yanlış DELETE veya UPDATE çalıştı
son tam yedekten sonra çok veri değişti
binlog açık ama ne kadar saklandığı bilinmiyor
binlog dosyası var fakat geri dönüş hiç test edilmedi
replika gecikmesi ve binlog büyümesi aynı anda görülüyor

Yazıyı bitirince

MySQL binlog’un hangi senaryoda işe yarayacağını, ne zaman yetersiz kalacağını ve geri dönüş öncesi hangi kanıtları toplamanız gerektiğini anlayacaksınız.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB MySQL tarafında yedek, PITR ve replika durumunu aynı operasyon bağlamında görünür kılmayı hedefler. Binlog ile geri dönüş yine iş kararına bağlıdır; platformun değeri, doğru dosya, doğru zaman ve doğrulama adımlarını daha izlenebilir hale getirmektir.

Binlog neyi geri getirebilir?

MySQL binary log, veritabanında yapılan değişiklikleri kaydeder. Replikasyonun temel parçalarından biridir; aynı zamanda tam yedekten sonra yapılan işlemleri tekrar oynatmak için de kullanılabilir.

Yanlış işlemden önceki tam yedeğe dönüp, binlog’u olaydan hemen önceki ana kadar çalıştırırsanız belirli bir noktaya yaklaşabilirsiniz. Bu yaklaşım özellikle yanlış DELETE, yanlış UPDATE veya hatalı uygulama sürümü sonrası değerlidir.

Binlog, tam yedeğin yerine geçmez; tam yedeği tamamlar.
Hedef zaman veya pozisyon doğru seçilmezse hatalı işlem yeniden oynatılabilir.
Saklama süresi kısa ise ihtiyacınız olan binlog dosyası çoktan silinmiş olabilir.
Row tabanlı log çoğu geri dönüş senaryosunda daha güvenli iz bırakır.

Geri dönüş planı önce kopya ortamda denenir

Üretim veritabanına doğrudan binlog uygulamak tehlikelidir. Sağlıklı yaklaşım, ayrı bir hedef ortam açmak, son güvenilir yedeği buraya dönmek ve binlog’u hedef zamana kadar uygulamaktır. Sonra veri doğrulanır ve uygulama veya iş tarafıyla karar verilir.

Bu süreçte amaç “komut çalıştı” demek değildir. Asıl amaç, hatalı işlemin dışarıda kaldığını ve geçerli işlemlerin korunduğunu kanıtlamaktır.

mysqlbinlog ile hedef zamana kadar oynatma fikri

mysql-binlog-restore.sh

mysqlbinlog \
  --start-datetime="2026-06-14 10:00:00" \
  --stop-datetime="2026-06-14 10:42:10" \
  mysql-bin.000123 mysql-bin.000124 \
  | mysql --host=restore-target --user=restore_user --password appdb

Bu örnek üretime doğrudan uygulanmamalıdır. Önce ayrı bir geri yükleme hedefinde denenmelidir.

Binlog ne zaman yetmez?

Binlog bazı durumlarda tek başına yeterli değildir. Hatalı işlem çok geç fark edildiyse, binlog saklama süresi dolduysa, tam yedek bozuksa veya olay zamanında yoğun geçerli trafik varsa karar zorlaşır.

Ayrıca bazı DDL işlemleri, dış sistemlerle etkileşim ve uygulama tarafındaki yan etkiler yalnızca binlog’dan okunarak tamamen geri alınamaz. Örneğin ödeme sağlayıcısına gönderilen istek, e-posta veya dosya silme gibi etkiler ayrı ele alınmalıdır.

Geri dönüş kararını yazıya dökün

MySQL geri dönüşlerinde sözlü kararlar risklidir. Hangi yedeğin döndüğü, hangi binlog aralığının uygulandığı, hangi kayıtların kontrol edildiği ve hangi verinin kaybedilebileceği yazılmalıdır.

Bu not, olaydan sonra suçlu aramak için değil, bir sonraki olayda daha hızlı ve daha doğru karar almak için kullanılır.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler