MySQL Master-Slave Replication Kurulumu: Adım Adım Rehber

MySQL master-slave replication, okuma yükünü ölçeklemek ve yedekleme yaklaşımını güçlendirmek için kullanılan bir çoğaltma (replication) modelidir. Kurulumda tek bir yanlış ayar, replikanın senkron dışında kalmasına ya da yazmaların beklenmedik şekilde durmasına yol açar. Bu rehberde master ve slave taraflarını somut komutlarla ve kontrol adımlarıyla birlikte kuracaksınız: replication kullanıcı yetkileri, binlog (binary log) ayarları, doğru veri aktarımı (dump/GTID dışı akış) ve replikasyon durumunun doğrulanması.

Not: Bu yazı “master-slave” terminolojisiyle anlatılsa da güncel pratikte çoğu kurulum “primary-replica” kavramına uyarlanır. Yine de mantık aynıdır: master değişiklikleri binary log’a yazar, slave bu log’ları okur ve uygular.

Mimari ve Kurulum Ön Koşulları

Master-slave replication’da rol dağılımı nettir:

• Master (Primary): Yazmaları alır, her değişikliği binary log’a yazar.
• Slave (Replica): Master’ın binary log’larını takip eder, sıralı biçimde uygular.
• Ağ bağlantısı: Slave, master’a belirli port üzerinden erişir (genellikle 3306).

Hangi senaryoda doğru seçim?

Aşağıdaki amaçlarda master-slave replikasyon mantıklıdır:

• Trafiğin büyük kısmı okumaysa (read-heavy) ve uygulama katmanı slave’i okuyacak şekilde yönlendirilebiliyorsa.
• Bakım pencerelerinde master’ı planlı kapatıp slave’i yeni master yapmak (failover) hedefleniyorsa.
• Veri kaybını azaltmak için ayrı bir sunucuda tutarlı kopya isteniyorsa.

Kurulumda kaçınılmaz net kararlar

• Hangi replikasyon tabanı? (GTID var/yok) Bu rehber, GTID zorunluluğu olmadan “klasik” akışa odaklanır.
• Slave hangi anı temel alacak? Veri tutarlılığı için slave’e veri kopyalarken master’ın log konumunu kesin sabitlemek gerekir.
• Server-id zorunluluğu: Master ve slave’de server-id farklı olmalıdır. Aynı değer replikasyon çakışmasına neden olur.

Master (Primary) Sunucusunda Yapılandırma

Master tarafında yapılacaklar, binary log üretimini açmak ve replikasyon kullanıcı yetkisini vermektir.

1) my.cnf/my.ini parametreleri

Master’da genellikle şu ayarlar hedeflenir. Konfigürasyon dosyanızın yolunu dağıtıma göre kontrol edin:

• Ubuntu/Debian: /etc/mysql/mysql.conf.d/mysqld.cnf
• CentOS/Alma/Rocky: /etc/my.cnf veya /etc/mysql/my.cnf

Örnek ayarlar:

• server-id = 1
• log_bin = mysql-bin
• binlog_format = ROW
• binlog_row_image = FULL
• sync_binlog = 1
• expire_logs_days = 7

Ek notlar:

• binlog_format = ROW, replikasyon tutarlılığı açısından sık tercih edilir. Karma formatlar (MIXED) bazı uygulamalarda beklenmeyen sonuçlar doğurabilir.
• sync_binlog = 1, her binlog flush’ında diske senkron yazım yapar; performans etkisi olabilir ama veri tutarlılığını artırır.

2) Replikasyon kullanıcı oluşturma

Master’da slave’in bağlanabilmesi için özel bir kullanıcı tanımlayın.

Örnek SQL:

CREATE USER 'repl'@'SLAVE_IP' IDENTIFIED BY 'güclü_parola';

Ardından yetki verin:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'SLAVE_IP';

Son olarak:

FLUSH PRIVILEGES;

Burada SLAVE_IP yerine çoğu kurulumda gerçek slave IP’si yazılır. Subnet kullanacaksanız 192.168.10.% gibi kapsamlı değerler yerine mümkün olan en dar aralığı tercih edin.

3) Master log konumunu yakalama (başlangıç için şart)

Slave’e veri aktarımı öncesi master’ın binary log konumunu bilmek gerekir. Master’da şu komutu çalıştırın:

SHOW MASTER STATUS;

Çıktıda önemli alanlar:

• File (ör. mysql-bin.000123)
• Position (ör. 4567890)

Bu değerler, slave’e aktarım bittikten sonra MASTER_LOG_FILE ve MASTER_LOG_POS olarak verilir.

Slave (Replica) Sunucusunda Yapılandırma

Slave tarafında replikasyon thread’leri için gerekli ayarlar yapılır. Ardından master’dan veri senkronu (snapshot) sağlanır.

1) Slave my.cnf ayarları

Slave’da şu mantıkla ayarlayın:

• server-id = 2 (master’dan farklı)
• relay_log = mysql-relay-bin
• read_only = 1
• super_read_only = 1 (destekliyorsa)

relay_log ayarı, slave’in master’dan aldığı event’leri geçici olarak kaydetmesini sağlar.

2) Slave okuma konumunu kilitleme (önlemek istediğiniz hatalar)

Replikasyon çalışırken uygulamanız yanlışlıkla slave’e yazarsa veri tutarlılığı bozulur. Bu yüzden read_only ve varsa super_read_only ayarları pratikte güvenli olur.

Sıfırdan Senkron: Veri Taşıma ve İlk Replikasyon Başlatma

Replication’ın en kritik adımı veri tabanını aynı noktaya getirmektir. En yaygın yöntem “master’tan dump alıp slave’e import” etmektir.

1) Master’tan dump alma

Master’da replikasyon kullanıcısı yerine genelde root/yeterli yetkili kullanıcı ile dump alınır. Uygulamanız canlıysa lock etkisini azaltmak için tutarlı dump almanız gerekir.

Örnek (tablo kilitleme yaklaşımı için seçenekler değişebilir):

mysqldump --single-transaction --quick --routines --triggers --events \
  --master-data=2 -u root -p --all-databases > full.sql

• --single-transaction InnoDB için consistent snapshot sağlar.
• --master-data=2, dump içine master log konum bilgisi ekler (bazı sistemlerde kullanım kolaylığı sağlar).

Eğer çok büyük veriniz varsa tüm DB yerine sadece replike edilecek şemaları dump almak daha doğrudur.

2) Slave’e import

Slave’da dump’ı içeri aktarın:

mysql -u root -p < full.sql

Import tamamlandıktan sonra slave tarafında replikasyon konfigurasyonuna geçilebilir.

3) “Change Master” ayarları

Slave üzerinde şu komutu çalıştırın. Değerleri master’da aldığınız File ve Position ile değiştirin:

STOP SLAVE;

CHANGE MASTER TO
  MASTER_HOST='MASTER_IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='güclü_parola',
  MASTER_LOG_FILE='mysql-bin.000123',
  MASTER_LOG_POS=4567890,
  MASTER_PORT=3306,
  MASTER_CONNECT_RETRY=10;

START SLAVE;

Bazı sürümlerde isimlendirmeler farklı olabilir; örneğin “START REPLICA”/“SHOW REPLICA STATUS” gibi. Mantık aynıdır.

Replikasyonun Doğrulanması ve Hata Ayıklama

Replikasyon başladıktan sonra “çalışıyor mu?” sorusunu sadece “başladı” deyip geçmeyin. Somut metrikleri kontrol edin.

1) Replikasyon durumunu kontrol edin

Slave’de şu komutu kullanın:

• Klasik sürümler: SHOW SLAVE STATUS\G

Çıktıda kritik alanlar:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: gecikme (0’a yakın idealdir)
• Last_Errno, Last_Error: varsa hata

2) Yaygın arızalar ve net çözüm adımları

Hata A: Access denied (IO thread bağlantısı)

Belirti: - Slave_IO_Running = No - Last_Error içinde kimlik doğrulama hatası

Çözüm: - Master tarafında repl kullanıcısının @'SLAVE_IP' ile tanımlı olup olmadığını kontrol edin. - Parolanın doğru olduğunu doğrulayın. - Firewall/security group üzerinden master 3306 portunun slave’den erişime açık olduğundan emin olun.

Hata B: Replikasyon duruyor / SQL thread No

Belirti: - Slave_SQL_Running = No - Last_Error veri uygulama hatası (ör. constraint/trigger farkı)

Çözüm: - Master ve slave şemalarında tetikleyici (trigger), event ve fonksiyonların aynı olduğundan emin olun. - binlog_format ve tablo motorlarının (InnoDB) uyumlu olduğuna bakın. - Gerekirse hata üreten event’ten sonra SQL_THREAD üzerinde düzeltme yapın (hata türüne göre). Bu adım için event’i tespit etmek gerekir.

Hata C: Seconds_Behind_Master artıyor

Belirti: - Slave_IO_Running = Yes, Slave_SQL_Running = Yes ama gecikme büyüyor.

Çözüm: - Master tarafında yazma yükünü azaltın veya daha hızlı disk/CPU sağlayın. - Uygulamanın replikaya yönlendirmesinde gecikmeyi dikkate alın. - Büyük transaction’lar varsa daha sık ama daha küçük transaction tasarımına yönelin.

Performans ve Güvenlik Parametrelerini Doğru Seçme

Replication yalnızca “açmak” değil, sürdürülebilir şekilde çalıştırmaktır.

Parametre seçimleri: trade-off tablosu

Aşağıdaki tablo, sık kullanılan ayarların etkisini özetler:

Backup planı: replication tek başına yedek değildir

Replication, replica’da tutarlılık sağlar; ancak yine de backup planınız olmalıdır:

• Replica’dan periyodik snapshot/backuplar alın.
• Binlog retention süresi (expire_logs_days) planınıza göre ayarlansın.
• Uygulama katmanında “replica gecikmesi” (read-your-writes ihtiyacı) göz önünde bulundurulsun.

Master-Slave Kurulumunda Uygulama Tarafı: Okuma-Yazma Yönlendirme

Replication kurduğunuzda uygulamanız otomatik olarak slave’e okumaları dağıtmaz. Bu nedenle net kural koyun:

• Yazmalar her zaman master/primary’ye gitsin.
• Okumalar belirli endpoint’ler için replica’ya gitsin.
• “Şu anda replica kaç saniye geride?” bilgisi uygulama mantığına entegre edilebiliyorsa tercih edin.

Pratik kural seti:

• Admin paneli / ödeme gibi “kesin güncel veri” gerektiren işlemler: master
• Genel katalog/arama gibi “birkaç saniyelik gecikme tolere edilebilir” işlemler: replica

Son Kontrol Listesi (Kurulumdan Önce ve Sonra)

Aşağıdaki listeyi adım adım uygulayın.

Kurulumdan önce

• [ ] Master’da server-id ve log_bin açık
• [ ] Slave’de server-id farklı
• [ ] Replikasyon kullanıcısı yalnızca gerekli host/IP’den izinli
• [ ] Master ve slave arasında 3306 bağlantısı erişilebilir

Kurulumdan sonra

• [ ] SHOW MASTER STATUS alındı ve File/Position doğru kullanıldı
• [ ] Slave_IO_Running=Yes
• [ ] Slave_SQL_Running=Yes
• [ ] Last_Error boş (veya hata yok)
• [ ] Gecikme makul seviyede

Sonuç: En Hızlı Sağlam Kurulum Yolunuzu Seçin

Bu rehberi uyguladığınızda replikasyonun çalışıp çalışmadığını sadece “başladı” ekranıyla değil; SHOW SLAVE STATUS\G çıktısındaki thread durumları ve gecikme metriğiyle doğrulayabilirsiniz. Eğer hedefiniz ölçeklemekse okuma-yazma yönlendirme kuralınızı netleştirin; hedefiniz veri dayanıklılığıysa replica yedek planını ayrıca kurun.

En pratik aksiyon: Master’da SHOW MASTER STATUS ile log konumunu çıkarın, slave’e dump import ettikten sonra CHANGE MASTER TO komutunda MASTER_LOG_FILE ve MASTER_LOG_POS değerlerini birebir kullanın. Ardından Slave_IO_Running ve Slave_SQL_Running değerlerini “Yes” görmeden üretime geçmeyin.