MySQL Master-Slave Replication Kurulumu (2026 Rehberi)

MySQL master-slave replication, uygulama yükünü dağıtmak ve yedeklilik katmanı eklemek için kullanılan temel replikasyon yöntemlerinden biridir. Doğru kurulmadığında ise veri tutarsızlığı, beklenmeyen gecikme (replication lag) ve “neden senkron değil?” sorunları kaçınılmaz hale gelir. Bu rehberde, master (primary) ve slave (replica) sunucular arasında replikasyonu net adımlarla kuracak; kullanıcı yetkileri, binlog/GTID, anlık durum kontrolü ve hata ayıklama akışını öğreneceksiniz.

Not: “slave” ve “replica” terimleri MySQL’de kavramsal olarak aynı rolü ifade eder. Yazıda teknik komutlarda “slave” terimi geçebilir; ancak hedef replica mantığıdır.

Hedef mimari: Master-Slave ne zaman doğru seçim?

Master-slave replication kurulumunu planlarken ilk karar, yönlendirme (routing) stratejisidir. En yaygın senaryolar:

• Okuma ölçekleme: Uygulama okuma isteklerini slave’e, yazmaları master’a yönlendirir.
• Yüksek erişilebilirlik hazırlığı: Slave’teki veri güncel tutulur; failover senaryosu planlanır.
• Raporlama ayırımı: Analitik sorgular slave üzerinde çalıştırılır.

Aşağıdaki tabloda “ne beklemeli?” sorusuna net bir cevap var:

Ön koşullar: Sunucu, MySQL sürümü ve replikasyon modları

Kurulumun en sık patladığı yer, sürüm/ayar uyumsuzluğudur. Aşağıdaki kontrol listesini kurulumdan önce uygulayın.

Gerekenler (checklist)

• Master ve slave’de aynı MySQL ailesi (MySQL -> MySQL veya MariaDB -> MariaDB) ve mümkünse benzer sürüm.
• İletişim için network erişimi: 3306 (ve varsa özel port) açık olmalı.
• Time sync: Her iki sunucuda NTP/chrony aktif olmalı. (Replication loglarında zaman karşılaştırması yapacaksınız.)
• Yeterli disk: Slave’e taşınacak veri + relay log alanı.

Replication modu seçimi: binlog File/Position vs GTID

MySQL’de iki yaygın yaklaşım var:

1. File/Position tabanlı (eski kurulum): MASTER_LOG_FILE ve MASTER_LOG_POS ile ilerler.
2. GTID tabanlı (daha operasyonel): MASTER_AUTO_POSITION=1 ve GTID seti üzerinden senkron gider.

Bu rehber GTID yaklaşımını ana akış olarak verir. Eğer sürümleriniz GTID desteklemiyorsa File/Position kısmına geçebilirsiniz.

Master tarafı kurulumu: binlog, replika kullanıcı, snapshot hazırlığı

Master üzerinde yapılacak adımlar replikasyonun omurgasıdır.

1) MySQL konfigürasyonunda binlog ve server-id

Master’da MySQL konfigürasyon dosyanızı güncelleyin (genelde /etc/my.cnf veya /etc/mysql/my.cnf). Örnek ayarlar:

• server-id her iki sunucuda benzersiz olmalı.
• log_bin aktif olmalı.
• GTID kullanacaksanız gtid_mode ve enforce_gtid_consistency ayarlanmalı.

Örnek (değerleri kendi ortamınıza göre değiştirin):

[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW
binlog_row_image=FULL
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON

binlog_format=ROW, uygulamada veri türlerine göre farklı etkiler yaratabilir ama replikasyon doğruluğu açısından yaygın tercih edilir.

2) Replikasyon kullanıcı yetkisini oluşturma

Master’da slave’in bağlanacağı bir kullanıcı oluşturun. Bu kullanıcı sadece replikasyon yetkilerine sahip olmalı:

CREATE USER 'replica_user'@'SLAVE_IP' IDENTIFIED BY 'GUVENLI_SIFRE';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'SLAVE_IP';
FLUSH PRIVILEGES;

• SLAVE_IP yerine aynı ağda statik IP/host kullanın.
• İmkan varsa slave IP’si statik olsun; dinamik IP replikasyonu daha sık koparır.

3) Master durumunu kaydetme (snapshot için)

GTID ile çalışırken otomatik konumlama kolaydır ama yine de doğru anı yakalamak gerekir.

Önce master’da şunları kontrol edin:

SHOW MASTER STATUS;

Çıktıdaki GTID/pozisyon bilgileri replikasyon testinde referans olur.

4) Tutarlı bir snapshot alma (taşıma için)

Veriyi kopyalarken en kritik nokta tutarlılıktır. En sağlıklı yöntem:

• Master üzerinde kısa süreli kilitlemeden tutarlı bir dump alın.

Örnek mantık:

mysqldump --single-transaction --quick --set-gtid-purged=ON \
  --all-databases \
  --routines --events --triggers \
  -u root -p > master_snapshot.sql

• --single-transaction InnoDB için tutarlıdır.
• Replikasyon için --set-gtid-purged=ON GTID kullanıyorsanız faydalıdır.

Snapshot alırken yoğun yazma varsa master yüklenebilir; dump süresini planlayın.

Slave tarafı kurulumu: aynı veriyi yükle, replikasyonu başlat

Slave’de iki aşama vardır: başlangıç verisi ve replikasyon ayarlarının yapılması.

1) Slave’e snapshot yükleme

Slave’e snapshot dosyanızı aktarın ve içe aktarın:

mysql -u root -p < master_snapshot.sql

2) Slave konfigürasyonunda server-id ve relay log

Slave my.cnf ayarlarında server-id değerini benzersiz yapın.

Örnek:

• server-id=2
• relay log aktif olmalı
• GTID kullanıyorsanız gtid_mode ayarlarıyla tutarlı olun

Örnek:

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
log_bin=OFF
relay_log=relay-bin

Master’dan farklı rol için log_bin=OFF tercih edilebilir; ancak environment policy’nize göre revize edin.

3) Replikasyon kaynağını tanımlama (GTID otomatik konum)

Slave üzerinde replikasyon ayarlarını verin.

MySQL 8 / modern sürümlerde genelde CHANGE REPLICATION SOURCE TO kullanılır. Örnek:

STOP REPLICA;
RESET REPLICA;

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='MASTER_IP',
  SOURCE_USER='replica_user',
  SOURCE_PASSWORD='GUVENLI_SIFRE',
  SOURCE_AUTO_POSITION=1;

START REPLICA;

Sürümünüz START SLAVE tarafını kullanıyorsa şu eşleştirmeyi düşünün: - REPLICA yerine SLAVE - CHANGE REPLICATION SOURCE yerine CHANGE MASTER

4) İlk sağlık kontrolü: STOP/START sonrası durum

Slave’de replikasyon durumunu sorgulayın:

SHOW REPLICA STATUS\G

Kontrol etmeniz gereken ana alanlar: - Replica_IO_Running: Yes - Replica_SQL_Running: Yes - Seconds_Behind_Source: 0 veya düşük (ilk kurulumda değişebilir) - Last_Errno ve Last_Error: hata varsa burada net mesaj olur

Beklenen hedef: IO ve SQL ikisi de “Running: Yes”.

İleri doğrulama: Tutarlılık testi ve replikasyon gecikmesi (lag) yönetimi

Kurulum “çalışıyor” demek değildir. Asıl hedef, veri tutarlılığını ve gecikmeyi yönetmektir.

1) Tutarlılık testi (pratik kontrol)

Uygulama trafiğiniz üzerinden basit bir doğrulama yapın.

Örnek kontroller: - Bazı kritik tablolar için satır sayısı karşılaştırması - Anahtar sorgularda aynı sonuç

Örnek:

-- Master
SELECT COUNT(*) FROM orders;

-- Slave
SELECT COUNT(*) FROM orders;

Satır sayısı uyuşmuyorsa replikasyon gecikmesi veya hata var demektir.

2) Replikasyon gecikmesi için metrik

Replica status’te Seconds_Behind_Source değerini izleyin. Ancak bunu tek metrik gibi kullanmayın; bazı durumlarda gecikme “yanıltıcı” olabilir.

Daha sağlıklı bir yaklaşım: - Periyodik olarak SHOW REPLICA STATUS\G sonuçlarını loglamak - Hata yoksa gecikmenin trendini izlemek

3) Slave üzerinde okuma politikası

Uygulamanız slave’i sadece okuma için kullanacaksa iki güvenlik katmanı ekleyin: - Slave’e uygulama üzerinden yazma engelleyin. - Gerekirse super_read_only veya benzeri ayarlarla SQL thread koruma yaklaşımı uygulayın.

Örnek mantık: - Uygulama kullanıcıları read-only yetkide olsun.

4) Kullanıcı/şema değişikliği süreci

Replikasyonda en büyük operasyon riski şema değişiklikleridir.

Net kural: - Şema değişikliklerini master’da yapın. - “Manual slave güncellemesi” yerine replikasyonun kendi yoluyla yayılmasını tercih edin.

Hata ayıklama: En sık sorunlar ve net çözümler

Aşağıdaki senaryolar master-slave kurulumlarında en sık görülür.

1) IO thread Running=No

En yaygın sebep: ağ/kimlik bilgisi hatası. - SOURCE_HOST yanlış mı? - SOURCE_USER yetkisi doğru mu? - Port erişimi var mı? - Parola uyuşuyor mu?

Çözüm akışı: - SHOW REPLICA STATUS\G içinde hata mesajını kontrol edin (Last_Error). - Master’da GRANT REPLICATION SLAVE yetkisini doğrulayın.

2) SQL thread Running=No (uygulama veri çakışması)

Slave tarafında başlangıç verisi master ile aynı değilse veya GTID geçmişi uyuşmuyorsa SQL thread stop olur.

Çözüm: - Snapshot sürecinin doğru alındığından emin olun. - GTID kullanıyorsanız dump sırasında --set-gtid-purged=ON ve konfigürasyon uyumu kontrol edin. - Gerekiyorsa slave verisini sıfırlayıp yeniden snapshot ile başlatın.

3) Seconds_Behind_Source artıyor

Bu durumda replikasyon “takılma” yaşıyor demektir.

Nedenler: - Master aşırı yazma yükü (binlog üretimi pahalı) - Slave disk I/O yavaş - Uzun transaction’lar - Büyük batch işlemlerinin yanlış zamanda yapılması

Hızlı müdahale planı: - Master tarafında yoğun yazan sorguları gözleyin. - Slave’de CPU/disk kullanımına bakın. - Uygulama sorgularını optimize edin (özellikle indeksler).

Failover hazırlığı: Slave’i canlı yedek gibi düşünün

Master-Slave kurulumunda çoğu ekip “failover” planını en sona bırakır; bu hata maliyeti yükseltir. Net bir hazırlık:

• Rutin olarak replika gecikmesini ölçün.
• Slave sunucusunda Prometheus/MySQL exporter gibi izleme yoksa en azından SHOW REPLICA STATUS\G çıktısını periyodik toplayın.
• Failover prosedürünüzü test edin: replication kesme, new master seçimi, yeniden yönlendirme.

Gerçek otomatik failover için ek araçlar gerekir; bu rehber kurulum adımlarına odaklanır.

Doğru ayarları seçmek için hızlı karşılaştırma

Aşağıdaki karar tablosu, kurulum sırasında sık yapılan yanlışları azaltır.

Sonuç: Kurulumu bitirdikten sonra yapılacak 5 aksiyon

Master-slave replication kurulumu “START REPLICA” ile bitmez; doğru işletim için doğrulama ve izleme şarttır. Şu 5 aksiyonu uygulayın:

1. Slave’de Replica_IO_Running ve Replica_SQL_Running durumlarını “Yes” olarak doğrulayın.
2. Seconds_Behind_Source değerini ilk saat boyunca ve yoğun yükte izleyin.
3. Kritik tablolar için master/slave satır sayısı veya örnek sorgu tutarlılığını kontrol edin.
4. Uygulama yönlendirmesini netleştirin: yazma master’a, okuma slave’e.
5. Failover senaryosunu bir test planına bağlayın (kısa bir provası bile arıza anında zaman kazandırır).

Bu adımları izlediğinizde replikasyon, yalnızca çalışan bir servis değil; raporlama ve yedeklilik süreçlerinin güvenilir bir parçası haline gelir.