Konuyu Açan #1
SQL Binlog Nedir? MySQL Binary Log Rehberi

Not: Bu yazı, SQL binlog kavramını, nasıl çalıştığını ve günlük yönetimini adım adım açıklamayı amaçlar; teknik bağlamı sade ve anlaşılır örneklerle sunar.


İlk bakışta nedir?
[ul]
  • MySQL’de Binary Log (binlog), veritabanı üzerinde yapılan tüm değişikliklerin kaydedildiği bir günlük dosyasıdır. Genelde veri değiştiren operasyonlar: INSERT, UPDATE, DELETE ve DDL ifadelerini kapsar. Binlog olmadan bu değişiklikler uzaktan replikasyon veya geri alma (point-in-time) gibi işlemleri gerçekleştirmek zorlaşır.
  • Binlog’un amacı iki ana senaryoda karşımıza çıkar: felaket kurtarma (recovery) ve replikasyon. Felaket halinde, yedeğin ardından binlog sayesinde o zamana kadar yapılan değişiklikler uygulanabilir. Replikasyonda ise bir ana (master) sunucudaki değişiklikler, bir veya daha fazla ikincil (slave) sunuculara aktarılır.
  • Çalışma prensibi genel olarak şu şekildedir: sunucu, veri değiştiren her işlem için log satırları üretir ve bu satırlar uygulanabilir (row-based) veya olay tabanlı (statement-based) ya da her ikisinin karışımı olan karışık formatta (mixed) tutulabilir.
    [/ul]

    Kullanım alanları ve yönetim ipuçları
    [ul]
  • Replikasyon kurulumu: Master’da binlog etkin olarak ayarlanır (binlog formatı, dosya adı/konumu gibi parametreler belirlenir). Slave tarafında bu binloglardan gelen değişiklikler yeniden uygulanır.
  • PITR (Point-In-Time Recovery): Yedek alınan zamandan itibaren binloglar okunarak belirli bir zamana geri dönülebilir. Bu, özellikle büyük güncellemelerin veya yanlış silinen kayıtların kurtarılmasında kullanışlıdır.
  • Log güvenliği ve döndürme (rotation): binlog dosyaları belirli boyuta ulaştığında yeni dosya oluşturulur. Bu süreç, depolama yönetimi ve geriye dönük inceleme için önemlidir.
  • Performans etkisi: binlog yazımı I/O üzerinde ek yük yaratır; bu nedenle tamponlama ve senkronizasyon ayarları dikkatle belirlenmelidir. Karşılaştırmada, row-based formatler genelde daha ayrıntılı olabilirken hata ayıklama açısından daha yoğun olabilir.
  • Güvenlik: binlog’lar önemli veri değişikliklerini içerir; bu nedenle yetkilendirme ve saklama politikaları uygulanmalıdır. Özellikle üretim ortamında binlog erişimini sınırlandırmak gerekir.
    [/ul]

    Kısa bir örnek akış
    KOD
    12345-- Master yapılandırması (örnek): 
    [mysqld]
    log_bin = /var/log/mysql/mysql-bin.log
    binlog_format = mixed
    server_id = 1
    

    KOD
    123456-- Slave yapılandırması (örnek):
    [mysqld]
    server_id = 2
    read_only = 1
    relay_log = /var/log/mysql/mysql-relay-bin
    log_bin = /var/log/mysql/mysql-bin.log
    

    Bu ayarlar ile master üzerinde yapılan değişiklikler, slave’a aktarılabilir ve gerektiğinde PITR için binloglar üzerinden zamana göre geri alınabilir.

    Bu konudaki deneyimleriniz veya karşılaştığınız zorluklar nelerdi? Özellikle hangi binlog formatını tercih ettiniz ve neden?
  • Yanıt vermek için giriş yapmış olmalısınız.

    Bu konuyu görüntüleyen kullanıcılar (Toplam: 4, Üyeler: 4, Misafirler: 0)
    Toplam: 4 (üyeler: 4, misafirler: 0)
    0 alıntı seçildi