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

MySQL master-slave replication (çoğaltma), tek bir yazma (master) akışından birden fazla okuma sunucusu (slave) üretmenin en pratik yoludur. Doğru kurulum; gecikmeyi (replication lag), veri tutarsızlığını ve kesinti riskini doğrudan etkiler. Bu rehberde, canlıya taşımadan önce kuracağınız mimariyi netleştirecek; kurulum adımlarını, doğrulama komutlarını ve sık yapılan hataları somut şekilde aktaracağım.

Not: Aşağıdaki anlatım klasik master-slave mantığını baz alır. MySQL sürümünüze göre GTID (Global Transaction Identifiers) kullanımı veya bazı ifadeler değişebilir.

1) Ön koşullar: Mimarinin doğru kurulması

Kurulumun en kritik kısmı, replike edilecek veriyi ve senkronizasyon mantığını baştan doğru seçmektir.

Rol tanımı (örnek)

master (primary): Yazma işlemleri ve binlog üretir.
slave (replica): Master’dan binlog’ları okur, kendi relay log’una yazar ve uygular.

Ağ ve saat senkronu

Master ve slave arasında erişim için genelde TCP 3306 kullanılır.
Saat farkı küçük olmalıdır. NTP (Network Time Protocol) ile sistem saatlerini eşleyin.

Sürüm uyumu

En sağlıklısı: master ve slave aynı MySQL major/minor sürüm bandında olsun.
Farklı sürümlerde replike edilen bazı ifadeler beklenmedik şekilde davranabilir (özellikle DDL tarafı).

Değişiklik kuralı (veri tutarlılığı)

Canlı veritabanında çoğaltma yapılan tablolar için slave tarafında doğrudan DDL/DML yapmak veri uyumsuzluğu yaratır.
DDL gerekiyorsa master’dan çalıştırın; replikasyonla slave’e gelsin.

2) Master hazırlığı: Replication için binlog ve kullanıcı

Slave’in bağlanabilmesi için master tarafında hem log üretimi hem de replikasyon yetkisi gerekir.

Binlog ayarlarını kontrol et

Master üzerinde aşağıdaki komutla binlog’un aktif olup olmadığını doğrulayın:

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';

Genelde uygun değer: ROW format (satır bazlı). Örneğin: - binlog_format=ROW

Binlog ile ilgili temel ayarlar: - server_id: Her sunucu için benzersiz olmalı. - log_bin: Aktif olmalı. - binlog_format: Uygun format seçilmeli.

Master için örnek doğrulama: - SHOW VARIABLES LIKE 'server_id'; - SELECT @@server_id;

Replication kullanıcısı oluştur

Master üzerinde slave’in bağlanacağı bir kullanıcı açın. Örnek (yetkileri olabildiğince sınırlayın):

Kullanıcı adı: repl_user
Şifre: güçlü bir parola
IP kısıtlaması: mümkünse slave’in IP’si

Örnek akış: - CREATE USER 'repl_user'@'SLAVE_IP' IDENTIFIED BY 'GUÇLU_SIFRE'; - GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'SLAVE_IP'; - FLUSH PRIVILEGES;

Master tarafında doğru binlog konumunu yakalama

Kurulum için slave’i aynı noktadan başlatmanız gerekir.

Kullanıcıyı ve konumu doğruladıktan sonra aşağıdakilerden birini kullanın: - GTID kullanmıyorsanız: SHOW MASTER STATUS; - GTID kullanıyorsanız: SELECT @@gtid_executed; ve GTID tabanlı konum.

Klasik yaklaşım için SHOW MASTER STATUS; sonucu içinden özellikle şunları not edin: - File (binlog dosyası) - Position (okuma konumu)

3) Slave hazırlığı: Data snapshot al ve temiz kurulum

Slave’in master ile aynı veri tablosuna başlaması gerekir. Bu genellikle master’dan konsistent snapshot alarak yapılır.

Konsistent yedekleme yaklaşımı

Amaç: Slave’e gelecek yedekte hem tablo içerikleri hem de binlog koordinatı tutarlı olsun.

Uygulama mantığı: 1. Master üzerinde snapshot alın. 2. Slave’de veri tabanı restore edilir. 3. Slave replike etmeye başlar (master konumu ile).

Tutarlı yedekleme için pratik yol

Master’da FLUSH TABLES WITH READ LOCK; komutu bazı senaryolarda kullanılır.
Büyük sistemlerde daha riskli olabilir (kilit etkisi). Bu yüzden üretimde genelde xtrabackup gibi yöntemler tercih edilir.

Bu rehberde en kritik noktayı vurguluyorum: yedek alırken konum bilgisi (File/Position veya GTID aralığı) mutlaka alınmalıdır.

Restore sonrası kontrol

Slave üzerinde MySQL kuruluysa, restore sonrası şu kontrolleri yapın: - Aynı veritabanı şeması yüklendi mi? - En azından replike edilecek tablolar mevcut mu?

4) Replication bağlantısını kur: CHANGE MASTER TO ve start

Şimdi slave tarafında replike ayarlarını tanımlayacağız.

Slave üzerinde replication ayarlarını sıfırlama

Önceden bir replika tanımı varsa karışmaması için temizleyin:

STOP SLAVE;
RESET SLAVE ALL;

MySQL sürümünüze göre komut isimleri RESET REPLICA ALL; gibi değişebilir. Sizdeki sürüme göre karşılığını kullanın.

CHANGE MASTER TO (klasik File/Position)

Aşağıdaki örnek mantığı uygulayın:

CHANGE MASTER TO ile master IP/port, kullanıcı adı, şifre ve konum tanımlanır.

Örnek mantık (yer tutucuları kendi değerlerinizle değiştirin): - MASTER_HOST='MASTER_IP', - MASTER_USER='repl_user', - MASTER_PASSWORD='GUÇLU_SIFRE', - MASTER_PORT=3306, - MASTER_LOG_FILE='binlog.0000xx', - MASTER_LOG_POS=123456;

Sonra: - START SLAVE;

Replikasyon durumunu izleme

Slave üzerinde temel kontrol komutları:

SHOW SLAVE STATUS\G; (klasik gösterim)

Kontrol edilecek alanlar: - Slave_IO_Running: Yes - Slave_SQL_Running: Yes - Last_Errno (hata kodu) - Last_Error (hata mesajı) - Seconds_Behind_Master (gecikme)

Eğer SHOW SLAVE STATUS\G yerine SHOW REPLICA STATUS\G görüyorsanız, MySQL sürümünüz “replica” terminolojisini kullanıyordur.

Gecikme (lag) normal mi?

İlk çalıştırmada gecikme beklenebilir. Ancak: - Dakikalar süren ve azalmayan lag, - Last_Error veya SQL thread durması, - sürekli yeniden denemeler

gibi durumlar bir problemin işaretidir.

5) Doğrulama: Verinin kopyalandığını kanıtlayın

Kurulum “çalışıyor” görünse bile veri doğru mu sorusu ayrıca test edilmelidir.

Test senaryosu (minimum set)

Master’da yeni bir kayıt ekleyin.
Slave’de aynı kaydın gelip gelmediğini kontrol edin.
Güncelleme ve silme (DML) test edin.
Basit bir DDL değişikliği test edin (ör. index ekleme), ancak DDL testini üretimde acele etmeden yapın.

Kanıt için pratik sorgular

Master’da: INSERT INTO ...
Slave’de: SELECT ...

Ayrıca gecikme için durum: - Seconds_Behind_Master düşüyor mu?

Replikasyon kipleri ve farklar

ROW format: Satır değişimlerini replike eder; tutarlılık için çoğu senaryoda daha uygundur.
STATEMENT format: Aynı SQL ifadesi aynı sonuç üretmek zorundadır; bazı fonksiyonlarda farklılıklar olabilir.

Bu nedenle performans odaklı kurulumlarda bile, veri tutarlılığı hedefi varsa ROW format tercih edilmesi daha güvenlidir.

6) Performans ve operasyon: Lag’i düşürme, izleme ve sorun giderme

Replicaton kurulduktan sonra iş bitmez. Gözlemlenmezse lag birikir, slave düşer veya hatalı replikasyon bir noktada kalır.

Izleme için temel metrikler

Slave_IO_Running / Slave_SQL_Running
Seconds_Behind_Master
SHOW PROCESSLIST; ile yoğunluk
relay_log büyümesi (özellikle sorun varsa)

Sık sorunlar ve net çözümler

Aşağıdaki tablo, en yaygın durumlarda ne yapmanız gerektiğini hızlıca özetler.

Belirti	Muhtemel neden	Net kontrol	Net aksiyon
SQL thread durdu	DDL/DML uyumsuzluğu veya veri çakışması	`Last_Error`	Hata satırını tespit et, master’dan gelen işlemin slave’de nasıl çakıştığını incele; gerekiyorsa re-restore
IO thread durdu	Yetki/IP/bağlantı sorunu	`Last_IO_Error`	Replication kullanıcı yetkilerini ve `MASTER_HOST` erişimini doğrula
Sürekli lag artıyor	Slave CPU/IO yetersizliği	Yük, disk/IO wait	Slave kaynaklarını artır, yavaş query’leri master’dan başlayıp optimize et
Kesintisiz ama büyüyen relay log	Uygulama thread’i geride	Relay log boyutu	İyileştirme: performans + gerekirse büyük transaction’ları böl

DDL (schema değişikliği) stratejisi

Schema değişiklikleri replikasyon üzerinde en riskli kısımdır. - Büyük tablolar üzerinde lock üreten DDL’leri planlayın. - Gerekirse “percona toolkit” gibi araçlarla planlama yapın. - Değişikliği önce master’da uygulayıp replikasyonun oturmasını izleyin.

Geri dönüş planı (rollback) fikri

Canlıya taşıma sürecinde rollback her zaman kolay olmayabilir. - Replikasyon başlamadan önce restore testini yapın. - Binlog konumu ve yedek koordinatını kaydedin. - Hata durumunda slave’i “temiz restore + tekrar start” ile yeniden kurma planınız olsun.

7) GTID mi, File/Position mı? Hangi kurulum daha net yönetilir

Dosya/konum yöntemi basit görünür; fakat operasyon karmaşıklığı büyüdükçe GTID yönetimi daha kontrollü olabilir.

Karar özeti

File/Position: Kurulum basit, kontrol doğrudan. Ancak çok sayıda re-build ihtiyacında iz sürmek zorlaşabilir.
GTID: İşlemleri kimlikli izler; yeniden başlatma ve failover senaryolarında yönetim daha temiz olur.

GTID kullanıyorsanız ek olarak: - binlog_gtid_simple_recovery gibi ayarlar sürüme bağlı değişir. - gtid_mode aktif olmalıdır.

Hangi yöntemin sizin sisteminizde daha iyi olacağını belirlemek için master ve slave MySQL sürümlerini ve operasyon senaryonuzu (planlı bakım, failover, sık restore) değerlendirin.

Sonuç: Kurulumu “çalışıyor”dan “doğru çalışıyor”a taşıyın

Master-slave replication kurulumunda asıl değer; binlog üretimi, master konum koordinatı ve slave restore tutarlılığının birlikte sağlanmasıdır. Bu rehberdeki adımları uyguladıktan sonra mutlaka şu iki şeyi kanıtlayın: (1) hem IO hem SQL thread’leri running, (2) master’da yaptığınız test DML/DDL slave’e aynı sırayla ulaşıyor ve lag kontrol altında.

Aksiyon önerisi: Kurulumu hemen üretime bağlamadan önce aynı mimariyi test ortamında kurun; SHOW SLAVE STATUS\G / SHOW REPLICA STATUS\G çıktısında kritik alanları (thread durumları, hata mesajı, gecikme) kayıt altına alın. Ardından canlıya geçişi planlayın ve rollback için “temiz restore + start” senaryosunu baştan hazır edin.