MySQL Master-Slave Replication Kurulumu: Net Adımlar

MySQL master-slave replication, uygulama yükünü okuma tarafında dağıtmak ve yedeklilik (failover hazırlığı) oluşturmak için kullanılan temel yöntemlerden biridir. Ancak yanlış kurulursa gecikme (replication lag), veri tutarsızlığı ve beklenmeyen kesintiler ortaya çıkar. Bu rehberde, master’dan slave’e replikasyon kurulumunu GTID’siz ve GTID’li senaryolarla, ayrıca güvenli ve ölçülebilir doğrulama adımlarıyla anlatıyorum. En sonunda ise kontrol listesiyle “kuruldu mu, değil mi” sorusunu net cevaplayacağız.

Replication mimarisi: master, slave, gecikme ve tutarlılık

MySQL replication’de mantık şudur:

Master: Yazma işlemlerini alır; değişiklikleri binlog (binary log) olarak kaydeder.
Slave: Master’daki binlog olaylarını (events) okur ve kendi veri setine uygular.
Gecikme (replication lag): Slave’in olayı alıp uygulaması arasında geçen süredir.

Bu mimaride kritik iki risk şunlardır:

Binlog konfigürasyonu yanlışsa (ör. yanlış log formatı): Slave hiçbir şey alamaz veya hatalı olay uygular.
Veri başlangıç senkronizasyonu yanlışsa: Slave’in tablosu master ile farklı başlar; bu durumda replikasyon “çalışıyor gibi” görünse bile veri sapması oluşur.

Bu yüzden kuruluma başlamadan önce hedefi netleştirmek gerekir:

Okumaları slave’e dağıtacak mısınız?
Gecikmeyi kabul edilebilir aralıkta mı tutacaksınız? (ör. saniyeler düzeyi)
Failover (yönlendirme değişimi) planlıyor musunuz?

Hazırlık: sürüm, ağ, erişim ve veri başlangıcı

Kurulumun sorunsuz ilerlemesi için 4 hazırlık adımı vardır.

1) MySQL sürümü ve setting uyumu

Master ve slave’de en azından şu ayarlar uyumlu olmalıdır:

server-id (slave ve master benzersiz olmalı)
binlog_format
log_bin
(GTID kullanacaksanız) gtid_mode, enforce_gtid_consistency

En kritik pratik: Master ve slave sürümleri birbirine çok uzak olmamalıdır. Uzak sürümlerde replication davranışları farklılaşabilir.

2) Ağ planı: sadece replication trafiği

Slave, master ile bağlantı kuracak. Bu nedenle:

Slave’in master’a TCP erişimi sadece MySQL portuyla açılmalı (genelde 3306)
Güvenlik duvarı kuralında slave IP’si baz alınmalı
Mümkünse hem master hem slave üzerinde bağlantıları sınırlayın

Net hedef: İnternete açık “her yerden MySQL” yerine yalnızca slave IP’sinden replication erişimi.

3) Replikasyon kullanıcısı ve yetkiler

Master’da slave’in bağlanacağı ayrı bir kullanıcı açın. Örnek (sadece mantık için):

Kullanıcı: repl_user
Yetki: replikasyon için gerekli yetkiler (ör. MySQL sürümüne göre REPLICATION SLAVE/REPLICATION CLIENT)

4) Master ile slave verisini başlangıçta eşitle

Replication kurulumu, slave’de veri seti master ile aynı olacak şekilde başlatılmalıdır. En doğru yöntem:

Master’dan nokta atışı anlık yedek (snapshot) almak
Bu yedeği slave’e yüklemek
Yedek sonrası master binlog pozisyonunu veya GTID setini slave’e bildirmek

Bunun garantisi yoksa (ör. canlı veritabanını gelişi güzel kopyalıyorsanız) replication çok kez “çalışıyor ama yanlış” sonuç üretebilir.

Kurulum adımları (GTID’siz): binlog pozisyonu ile senkron

GTID’siz kurulum, klasik yöntemdir. Mantık şu:

Master, binlog yazar.
Slave bu binloglardan belirli bir dosya/pos noktası ile başlar.

1) Master ayarları

Master üzerinde my.cnf (veya mysqld ayarları) içine şu tarz parametreler girilir:

server-id (ör. 1)
log_bin (aktif)
binlog_do_db kullanılacaksa net filtre
Gerekirse binlog_format=ROW önerilir (özellikle tutarlılık için)

Ardından MySQL’i yeniden başlatın.

Master’da doğrulama için şu sorgular kullanılır:

SHOW MASTER STATUS;

Çıktıda aradığınız alanlar:

File (binlog dosyası)
Position (dosya içi başlangıç konumu)

2) Slave tarafı: ilk veriyi yükleyin

Slave’e master’dan alınan anlık yedeği geri yükleyin. Aynı veri seti olmadan replication açmayın.

3) Slave ayarları: master host ve binlog pos

Slave üzerinde şu genel adımlar uygulanır:

CHANGE MASTER TO ile master bilgisi ve başlangıç pozisyonu tanımlanır.
Ardından replikasyon başlatılır.

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

CHANGE MASTER TO MASTER_HOST="master_ip", MASTER_USER="repl_user", MASTER_PASSWORD="sifre", MASTER_LOG_FILE="binlog_file", MASTER_LOG_POS=12345;

Ardından:

START SLAVE;

4) Replikasyon durumunu anlık kontrol et

Slave’de şu durum sorguları kritik:

SHOW SLAVE STATUS\G;

Burada doğrulamanız gereken alanlar:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master (isterseniz gecikmeyi izleyin)
Hata varsa Last_SQL_Error / Last_IO_Error

Not: Seconds_Behind_Master bazı durumlarda güvenilir olmayabilir. Yine de “0’a yakın ve hatasız” hedefi pratikte iyi bir sinyaldir.

Kurulum adımları (GTID): “binlog dosya/pos” yerine GTID seti

GTID’li kurulumda amaç, binlog dosya/pozisyon takibini yerine daha deterministik bir mekanizma kullanmaktır.

Ne zaman GTID tercih edilmeli?

Aşağıdaki durumlarda GTID kurulum daha yönetilebilir olur:

Çok sayıda geçiş/yeniden kurulum yapacaksanız
Failover senaryosu planlıyorsanız
Operasyonel süreçte hata ayıklama süresi azaltmak istiyorsanız

GTID temel adımlar

Master ve slave’de gtid_mode aktif edilir
enforce_gtid_consistency gerektiğinde açılır
Başlangıç eşitleme sonrası slave tarafında MASTER_AUTO_POSITION=1 mantığı kullanılır

GTID ile kurulum, dosya/pos hatalarını azaltır; fakat yanlış GTID ayarı “hemen çalışmayan” bir replikasyon durumuna sebep olabilir. Bu yüzden master ve slave settinglerini birebir kontrol edin.

Doğrulama: kuruldu mu, veri aynı mı?

Replication sadece “SQL thread çalışıyor” demek değildir; asıl soru veri aynı mı ve gecikme kabul edilebilir mi?

1) Hata var mı kontrol edin

Slave tarafında SHOW SLAVE STATUS\G; çıktısında şu mantıkla bakın:

Slave_IO_Running ve Slave_SQL_Running ikisi de Yes olmalı
Last_SQL_Error boş olmalı

2) Uygulama doğrulaması: master ve slave tutarlılık testi

En azından şu iki kontrol önerilir:

Aynı tablolarda satır sayısı karşılaştırması
Ana sorgu (ör. son 100 kayıt) için veri kontrolü

Pratik örnek test yaklaşımı:

Master’da SELECT COUNT(*) ile tablo sayısını alın
Slave’de aynı sorguyla doğrulayın

Gecikme varsa test sonuçlarında sapma normaldir; bu durumda test sırasında replication gecikmesini düşürüp tekrar bakın.

3) Gecikmeyi ölçün ve sınır koyun

Kurulumdan hemen sonra, replikasyon gecikmesi düşmezse şu kaynaklar araştırılmalıdır:

Slave donanım kaynakları yetersiz (CPU/IO)
Ağ gecikmesi veya paket kaybı
Büyük transaction’lar (özellikle uzun süreli write işlemleri)
İndeks/şema farkları

Sık yapılan hatalar: net teşhis senaryoları

Aşağıdaki hatalar sahada en sık görülür. Her birinin kısa teşhis/çözüm mantığı vardır.

1) Yanlış başlangıç verisi

Belirti: Slave_SQL_Running çalışsa bile veri uyumsuzluğu görülür.

Teşhis: Slave verisi master ile aynı noktadan başlamamıştır.

Çözüm: Yeniden anlık yedek alıp aynı süreçle kurulum yapın. Canlı kopyalama yaklaşımından kaçının.

2) Eksik izinler veya yanlış şifre

Belirti: Last_IO_Error içinde kullanıcı/erişim hatası.

Çözüm: Master’da repl kullanıcı yetkilerini kontrol edin; parolayı doğru tanımladığınızdan emin olun.

3) binlog ayarı uyumsuzluğu

Belirti: Replikasyon thread’leri hata ile düşer veya sürekli yeniden denemeye girer.

Çözüm: Master ve slave binlog_format ve ilgili log ayarlarını uyumlu hale getirin.

4) server-id çakışması

Belirti: Replikasyon davranışı garipleşir, loglardan doğru olaylar alınmaz.

Çözüm: Master ve slave server-id değerleri kesinlikle benzersiz olmalı.

Performans ve işletim: replication’i sürdürülebilir yapın

Master-slave replication, “kuruldu bitti” değil; izleme ve operasyon şarttır.

İzleme için minimum metrik seti

Aşağıdaki metrikleri düzenli kontrol edin:

Seconds_Behind_Master (mümkünse ek izleme ile birlikte)
Slave_IO_Running / Slave_SQL_Running
Hata logları ve thread yeniden denemeleri
Slave üzerinde disk kullanım ve IOPS (özellikle veri dosyaları büyürken)

Donanım ölçekleme kuralı

Genel pratik yaklaşım:

Okuma trafiğini slave’e alıyorsanız CPU yine de önemlidir, çünkü slave SQL thread’leri değişiklikleri uygularken CPU kullanır.
Depolama performansı (SSD/NVMe) doğrudan gecikme üzerinde etkilidir.

Yedekleme ile replication’i birlikte düşünün

Replication çalışıyor olsa bile düzenli yedek şarttır. En sağlıklı model:

Master yedek (tam + binlog/GTID tabanlı saklama)
Slave yedek (kısa aralıkla) veya master yedeklerine dayalı geri dönüş planı

Failover hazırlığı yapıyorsanız yedekleri “geri dönüş testinden” geçirin. Test yapılmayan yedek, pratikte güvence değildir.

Hızlı karar tablosu: GTID’siz mi GTID’li mi?

Aşağıdaki tablo, hangi yöntemi seçeceğinizi hızlı belirlemeniz için hazırlanmıştır.

Kriter	GTID’siz (binlog dosya/pos)	GTID’li (auto-position)
İlk kurulum karmaşıklığı	Orta	Düşük/orta
Yeniden kurulumda hata riski	Dosya/pos kaynaklı risk artabilir	Daha deterministik
Operasyonel değişiklikler	Daha fazla koordinasyon gerekir	Geçişler daha yönetilebilir
Uyum şartları	Binlog ayarları ve pos doğru olmalı	GTID ayarları birebir doğru olmalı
Tercih ne zaman?	Basit senaryolar ve kontrollü değişiklikler	Failover/operasyonel süreç planlanan ortamlar

Sonuç: Doğru başlangıç + net doğrulama ile kurulumu tamamlayın

MySQL master-slave replication’ta asıl başarı, kurulumdan önce doğru hazırlık (binlog/GTID ayarı, anlık yedek, veri eşitleme) ve kurulumdan sonra net doğrulama (thread durumları, gecikme, tutarlılık testleri) ile gelir. Aksiyon planı olarak şu sırayı uygulayın:

1) Master ve slave server-id ile log/GTID ayarlarını uyumlu hale getirin. 2) Veri setini master ile aynı başlangıç noktasından başlatın (anlık yedek/snapshot). 3) Slave’de CHANGE MASTER TO (veya GTID ile auto-position) sonrası Slave_IO_Running ve Slave_SQL_Running durumlarını kontrol edin. 4) Gecikmeyi izleyin ve en az bir tablo üzerinden tutarlılık testi çalıştırın.

Bu 4 adım tamamlandığında, replication “çalışıyor” değil “doğru çalışıyor” hale gelir. İsterseniz bir sonraki adım olarak okuma-yazma yönlendirmesini (application tarafında slave okuma politikası) ve failover için prosedürü de planlayabilirsiniz.