MySQL Replikasyon Nasıl Kurulur? Kapsamlı Rehber

Veritabanı sistemleri, modern uygulamaların ve işletmelerin kalbidir. Ancak bu kritik verilerin tek bir noktada tutulması, performans darboğazlarına, veri kaybı riskine ve hizmet kesintilerine yol açabilir. İşte tam bu noktada MySQL replikasyonu devreye girerek, veritabanınızın güvenliğini, erişilebilirliğini ve performansını önemli ölçüde artırır. Bu kapsamlı rehberde, MySQL replikasyonunun ne olduğunu, neden gerekli olduğunu ve adım adım nasıl kurulacağını öğrenecek, ayrıca ileri düzey ipuçları ve sıkça sorulan sorularla bilginizi pekiştireceksiniz.

MySQL Replikasyon Neden Önemlidir ve Ne İşe Yarar?

Günümüzün sürekli açık ve yüksek performans beklentisi olan dijital dünyasında, tek bir veritabanı sunucusuna bağımlı kalmak büyük riskler taşır. Donanım arızaları, ağ kesintileri veya yazılım hataları gibi öngörülemeyen olaylar, veri kaybına ve uzun süreli hizmet kesintilerine neden olabilir. Bir e-ticaret sitesinin yoğun bir kampanya döneminde veritabanının çökmesi veya bir finans uygulamasının kritik anlarda erişilemez hale gelmesi, ciddi maliyetlere ve müşteri memnuniyetsizliğine yol açabilir. MySQL replikasyonu, bu tür felaket senaryolarına karşı güçlü bir koruma kalkanı sunar. Temel olarak, bir MySQL sunucusundaki veri değişikliklerini (master sunucu) bir veya daha fazla başka MySQL sunucusuna (slave sunucular) otomatik olarak kopyalama işlemidir. Bu sayede, verilerinizin birden fazla kopyasını farklı sunucularda tutarak birçok önemli fayda sağlarsınız.

Öncelikle, Yüksek Erişilebilirlik (High Availability), replikasyonun en temel faydalarından biridir. Master sunucu herhangi bir nedenle çevrimdışı kalırsa, slave sunuculardan biri hızlıca yeni master olarak atanabilir ve hizmet kesintisi minimuma indirilir. Bu, özellikle 7/24 hizmet vermesi gereken uygulamalar için hayati öneme sahiptir. İkinci olarak, Yük Dengeleme (Load Balancing), replikasyon ile kolayca başarılabilir. Okuma ağırlıklı sorgular (SELECT) slave sunuculara yönlendirilerek master üzerindeki yük azaltılır ve genel sistem performansı artırılır. Bu, özellikle yoğun okuma trafiği olan web siteleri ve uygulamalar için büyük bir avantajdır. Örneğin, bir haber sitesi, makalelerin okunması için birden fazla slave sunucu kullanabilirken, yeni makale ekleme veya yorum yapma gibi yazma işlemleri master sunucuya yönlendirilebilir.

Üçüncü olarak, Veri Yedekleme ve Felaket Kurtarma (Backup and Disaster Recovery) açısından replikasyon vazgeçilmezdir. Slave sunucular, master sunucunun canlı bir yedeği olarak işlev görür. Herhangi bir veri bozulması veya kaybı durumunda, slave sunuculardaki veriler hızlıca kurtarma için kullanılabilir. Geleneksel yedekleme yöntemleri belirli zaman aralıklarında veri yakalarken, replikasyon neredeyse gerçek zamanlı bir veri kopyası sunar. Dördüncü olarak, Raporlama ve Analiz (Reporting and Analytics) işlemleri için ayrı bir ortam sağlar. Yoğun ve karmaşık raporlama sorguları, canlı master sunucu yerine slave sunucularda çalıştırılarak master’ın performansının etkilenmesi önlenir. Bu, iş zekası (BI) araçları ve analitik platformları için ideal bir senaryodur. Son olarak, Sıfır Kesinti ile Bakım (Zero Downtime Maintenance) imkanı sunar. Master sunucuda planlı bir bakım yapılması gerektiğinde, trafik önce slave’e yönlendirilebilir, bakım tamamlandıktan sonra master tekrar devreye alınabilir. Bu işlemler sırasında kullanıcılar herhangi bir kesinti yaşamazlar.

Master-Slave mimarisi, bu faydaların temelini oluşturur. Bu modelde, bir sunucu (master) tüm yazma işlemlerini (INSERT, UPDATE, DELETE) kabul ederken, bu değişiklikler otomatik olarak bir veya daha fazla başka sunucuya (slave) kopyalanır. Slave’ler genellikle okuma işlemleri için kullanılır. Bu basit ama güçlü mimari, veritabanı altyapınızın dayanıklılığını ve ölçeklenebilirliğini artırmak için kritik bir araçtır.

Temel Replikasyon Kavramları Nelerdir?

MySQL replikasyonunu kurmadan önce, altında yatan temel kavramları anlamak hayati öneme sahiptir. Bu kavramlar, replikasyonun nasıl çalıştığını, olası sorunları nasıl gidereceğinizi ve sisteminizi nasıl optimize edeceğinizi anlamanıza yardımcı olacaktır. Bu temel taşları bilmek, sadece kurulumu yapmakla kalmayıp, aynı zamanda replikasyon ortamınızı etkili bir şekilde yönetmenizi de sağlar.

Binary Log (Binlog), MySQL replikasyonunun kalbidir. Master sunucu üzerinde gerçekleşen tüm veri değiştirme işlemlerinin (INSERT, UPDATE, DELETE, CREATE TABLE vb.) kaydedildiği ikili bir dosyadır. MySQL, bu log dosyalarını, veritabanında yapılan değişikliklerin kronolojik bir kaydı olarak tutar. Binlog’un temel amacı, master sunucudaki tüm değişiklikleri slave sunuculara iletmektir. Slave sunucular, bu binlog dosyalarını okuyarak kendi verilerini master ile senkronize ederler. Binlog’un farklı formatları vardır:
* STATEMENT tabanlı replikasyon: Her bir SQL ifadesini kaydeder. Avantajı daha küçük log dosyaları olmasıdır. Dezavantajı ise bazı deterministik olmayan fonksiyonlar (örneğin UUID(), NOW()) veya karmaşık sorgular nedeniyle master ve slave arasında veri tutarsızlıklarına yol açabilmesidir.
* ROW tabanlı replikasyon: Değişen her satırın tam olarak neye dönüştüğünü kaydeder. Daha güvenli ve tutarlıdır, çünkü hangi satırların nasıl değiştiğini açıkça belirtir. Dezavantajı ise daha büyük log dosyaları oluşturabilmesidir.
* MIXED tabanlı replikasyon: Varsayılan olarak STATEMENT tabanlı çalışır, ancak deterministik olmayan veya ROW tabanlı replikasyon gerektiren durumları algıladığında otomatik olarak ROW tabanlıya geçer. Bu, hem performans hem de tutarlılık arasında iyi bir denge sunar.

Relay Log, slave sunucu üzerinde bulunan ve master’dan kopyalanan binlog olaylarını geçici olarak depolayan bir dizi dosyadır. Slave’in I/O Thread’i master’dan binlog olaylarını çeker ve bunları kendi relay log’una yazar. Daha sonra, slave’in SQL Thread’i bu relay log’u okur ve içindeki SQL olaylarını slave veritabanına uygular. Bu iki aşamalı süreç, slave’in olayları almasını ve uygulamasını birbirinden ayırarak daha esnek bir yapı sağlar.

Replikasyon Threadleri, slave sunucudaki replikasyon sürecini yöneten iki ana işlemci birimidir:
* I/O Thread (Slave I/O Thread): Master sunucuya bağlanır ve master’ın binlog’undaki olayları talep eder. Master, bu olayları I/O Thread’e gönderir ve I/O Thread de bunları slave sunucusundaki relay log’a yazar. Bu süreç, master’daki değişikliklerin slave’e aktarılmasından sorumludur.
* SQL Thread (Slave SQL Thread): Relay log’u okur ve içindeki SQL olaylarını slave veritabanına uygular. Yani, master’da yapılan değişiklikleri slave üzerinde tekrarlar. Bu thread, relay log’daki olayları sırayla işler ve veritabanı tutarlılığını sağlamaya çalışır.

GTID (Global Transaction Identifiers – Küresel İşlem Tanımlayıcıları), MySQL 5.6 sürümüyle birlikte gelen ve replikasyonu önemli ölçüde basitleştiren ve güvenliğini artıran bir özelliktir. Her bir işlem (transaction) için global olarak benzersiz bir kimlik sağlar. Geleneksel replikasyonda, slave’in master’ın binlog dosyasındaki konumunu (dosya adı ve pozisyon) takip etmesi gerekirken, GTID ile slave sadece hangi işlemleri uyguladığını bilir ve master’dan henüz uygulamadığı işlemleri talep eder. Bu, replikasyon topolojilerini yönetmeyi çok daha kolay hale getirir:
* Otomatik Failover: Bir master çöktüğünde, GTID sayesinde bir slave’i yeni master olarak atamak çok daha basittir, çünkü slave’in hangi işlemleri tamamladığını ve hangi işlemleri kaçırdığını kolayca belirleyebiliriz.
* Slave Ekleme/Değiştirme: Yeni bir slave sunucusu eklemek veya mevcut bir slave’i değiştirmek, GTID ile daha az manuel müdahale gerektirir. Yeni slave, master’dan eksik GTID’lere sahip işlemleri otomatik olarak talep edebilir.
* Tutarlılık: GTID, veri tutarlılığını sağlamada daha güçlü bir mekanizma sunar, çünkü her işlem benzersiz bir şekilde tanımlanır ve tekrarlanan veya atlanan işlemlerin önüne geçilir. GTID, karmaşık replikasyon topolojileri (örneğin master-master, zincirleme replikasyon) için vazgeçilmez bir araçtır.

Bu temel kavramları anlamak, replikasyon kurulumu, izlenmesi ve sorun giderme süreçlerinde size sağlam bir temel sağlayacaktır.

Adım Adım MySQL Master-Slave Replikasyon Kurulumu

MySQL Master-Slave replikasyonu kurmak, dikkatli bir planlama ve adım adım uygulama gerektiren bir süreçtir. Bu bölümde, iki sunucu (bir master, bir slave) arasında temel bir replikasyonun nasıl kurulacağını ayrıntılı olarak inceleyeceğiz. Hedefimiz, master sunucudaki tüm veri değişikliklerinin slave sunucuya sorunsuz bir şekilde kopyalanmasını sağlamaktır. Bu adımları takip ederek, kendi replikasyon ortamınızı başarıyla oluşturabilirsiniz.

Gereksinimler ve Ön Hazırlıklar Nelerdir?

Replikasyon kurulumuna başlamadan önce bazı temel gereksinimleri karşılamanız ve ön hazırlıkları yapmanız önemlidir. Bu adımlar, kurulum sürecinin sorunsuz ilerlemesini sağlayacak ve olası hataları minimize edecektir.

1. İki MySQL Sunucusu: En az iki ayrı sunucuya ihtiyacınız olacak: biri master (ana) sunucu, diğeri slave (kopya) sunucu. Bu sunucular fiziksel makineler, sanal makineler veya bulut tabanlı örnekler (örneğin AWS EC2, Google Cloud VM) olabilir. Önemli olan, birbirleriyle ağ üzerinden iletişim kurabilmeleridir.
2. MySQL Versiyon Uyumluluğu: Master ve slave sunucularında aynı MySQL sürümünü (veya çok yakın sürümleri) kullanmanız şiddetle tavsiye edilir. Genellikle, slave sunucu master’dan daha yeni bir sürüm olabilir, ancak master’ın slave’den daha yeni olması önerilmez. Örneğin, master MySQL 5.7 ise, slave MySQL 5.7 veya 8.0 olabilir. Ancak master MySQL 8.0 iken slave MySQL 5.7 olmamalıdır.
3. Ağ Bağlantısı ve Güvenlik Duvarı: Master ve slave sunucuları arasında ağ bağlantısı olduğundan emin olun. MySQL’in varsayılan portu olan 3306’nın her iki yönde de açık olması gerekir. Güvenlik duvarı (firewall) kurallarınızı buna göre yapılandırın. Örneğin, ufw kullanan bir Linux sunucuda:

sudo ufw allow from [SLAVE_IP_ADRESI] to any port 3306
    sudo ufw allow from [MASTER_IP_ADRESI] to any port 3306

Bu komutlar, slave sunucunun IP adresinden master’a ve master sunucunun IP adresinden slave’e 3306 portundan erişime izin verir.
4. Benzersiz Sunucu Kimlikleri (Server IDs): Her MySQL sunucusunun server_id parametresi aracılığıyla benzersiz bir kimliğe sahip olması gerekir. Bu, replikasyon için kritik bir ayardır ve çakışan kimlikler ciddi sorunlara yol açabilir.
5. Yeterli Disk Alanı: Hem master hem de slave sunucularda binary log’lar ve relay log’lar için yeterli disk alanı olduğundan emin olun. Özellikle yoğun yazma işlemi olan sistemlerde log dosyaları hızla büyüyebilir.
6. Kök (Root) Erişim veya Sudo Yetkisi: my.cnf dosyasını düzenlemek ve MySQL hizmetini yeniden başlatmak için gerekli yetkilere sahip olmanız gerekecektir.

Master Sunucu Yapılandırması Nasıl Yapılır?

Master sunucuyu replikasyon için hazırlamak, my.cnf yapılandırma dosyasında birkaç önemli değişiklik yapmayı ve bir replikasyon kullanıcısı oluşturmayı içerir.

1. my.cnf Dosyasını Düzenleyin: MySQL yapılandırma dosyası genellikle /etc/mysql/mysql.conf.d/mysqld.cnf veya /etc/my.cnf konumunda bulunur. Bu dosyayı bir metin düzenleyiciyle açın (örneğin sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf). [mysqld] bölümünün altına aşağıdaki satırları ekleyin veya mevcutlarını düzenleyin:

# Her sunucu için benzersiz bir kimlik. Master için 1 kullanabiliriz.
    server_id = 1 
    
    # Binary log'u etkinleştirir. Bu olmadan replikasyon mümkün değildir.
    log_bin = /var/log/mysql/mysql-bin.log 
    
    # Binary log formatını belirler. ROW, MIXED veya STATEMENT olabilir.
    # Genellikle MIXED veya ROW daha güvenlidir.
    binlog_format = ROW 
    
    # Slave'lerin bağlanacağı IP adresini belirler.
    # 0.0.0.0 tüm arayüzlerden bağlantıya izin verir. Güvenlik için belirli bir IP'ye bağlayabilirsiniz.
    bind-address = 0.0.0.0 
    
    # GTID kullanmak isterseniz bu satırları ekleyin (MySQL 5.6+ için)
    # gtid_mode = ON
    # enforce_gtid_consistency = ON

log_bin için belirtilen dizinin (örneğin /var/log/mysql/) var olduğundan ve MySQL kullanıcısının bu dizine yazma iznine sahip olduğundan emin olun. Gerekirse sudo mkdir -p /var/log/mysql ve sudo chown -R mysql:mysql /var/log/mysql komutlarını çalıştırın.

2. MySQL Servisini Yeniden Başlatın: Yapılandırma değişikliklerinin etkili olması için MySQL servisini yeniden başlatmanız gerekir:

sudo systemctl restart mysql

3. Replikasyon Kullanıcısı Oluşturun ve Yetkilendirin: Slave sunucunun master’a bağlanabilmesi ve binary log’ları okuyabilmesi için özel bir kullanıcıya ihtiyacı vardır. MySQL komut istemcisine bağlanın:

mysql -u root -p

Aşağıdaki komutları çalıştırın (kullanıcı adı, şifre ve slave IP adresini kendi değerlerinizle değiştirin):

CREATE USER 'repluser'@'SLAVE_IP_ADRESI' IDENTIFIED BY 'gucl_sifre';
    GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'SLAVE_IP_ADRESI';
    FLUSH PRIVILEGES;

Eğer birden fazla slave sunucunuz olacaksa veya slave’in IP adresi dinamikse, '%' kullanarak herhangi bir IP’den bağlantıya izin verebilirsiniz: CREATE USER 'repluser'@'%' IDENTIFIED BY 'gucl_sifre';. Ancak güvenlik nedeniyle belirli IP adreslerini belirtmek daha iyidir.

4. Mevcut Veritabanının Yedeğini Alın (Önemli Adım): Eğer master sunucunuzda zaten veriler varsa, bu verileri slave’e aktarmanız gerekir. Bunun en güvenli yolu, master’ın binary log’unu durdurmadan bir anlık görüntü (snapshot) almaktır.

FLUSH TABLES WITH READ LOCK; -- Master'daki tüm yazma işlemlerini durdurur
    SHOW MASTER STATUS;         -- Bu komutun çıktısını not alın (File ve Position değerleri)
    -- Şimdi ayrı bir terminalde veri yedeğini alın
    -- Örneğin: mysqldump -u root -p --all-databases --single-transaction --master-data > full_backup.sql
    -- VEYA LVM snapshot/bulut anlık görüntüsü kullanın
    -- Yedekleme tamamlandıktan sonra:
    UNLOCK TABLES;              -- Yazma kilitlerini serbest bırakın

SHOW MASTER STATUS; çıktısındaki File (örneğin mysql-bin.000001) ve Position (örneğin 1234) değerleri, slave’in replikasyona nereden başlayacağını belirlemek için kritik öneme sahiptir. Bu değerleri mutlaka bir yere not edin. Eğer LVM veya bulut snapshot kullanıyorsanız, FLUSH TABLES WITH READ LOCK komutunu çalıştırdıktan hemen sonra snapshot almalısınız. mysqldump kullanıyorsanız, master-data seçeneği otomatik olarak bu bilgileri yedek dosyasına ekler ve FLUSH TABLES WITH READ LOCK komutuna gerek kalmaz.

Slave Sunucu Yapılandırması Nasıl Yapılır?

Slave sunucuyu yapılandırmak, master’daki gibi my.cnf dosyasında server_id ayarını yapmayı ve ardından master’dan alınan verileri yükleyip replikasyonu başlatmayı içerir.

1. my.cnf Dosyasını Düzenleyin: Slave sunucuda /etc/mysql/mysql.conf.d/mysqld.cnf veya /etc/my.cnf dosyasını açın. [mysqld] bölümünün altına aşağıdaki satırları ekleyin veya düzenleyin:

# Her sunucu için benzersiz bir kimlik. Slave için 2 kullanabiliriz.
    server_id = 2 
    
    # Slave'in bağlanacağı IP adresini belirler.
    bind-address = 0.0.0.0 
    
    # GTID kullanmak isterseniz bu satırları ekleyin (MySQL 5.6+ için)
    # gtid_mode = ON
    # enforce_gtid_consistency = ON

Slave sunucuda log_bin etkinleştirmek zorunlu değildir, ancak slave’in de master olabilme potansiyeli varsa (örneğin zincirleme replikasyon veya master-master kurulumlarında) etkinleştirmek iyi bir uygulamadır.

2. MySQL Servisini Yeniden Başlatın: Yapılandırma değişikliklerinin etkili olması için MySQL servisini yeniden başlatın:

sudo systemctl restart mysql

3. Yedekten Geri Yükleme (Eğer Master’dan Yedek Alındıysa): Master’dan aldığınız full_backup.sql dosyasını slave sunucusuna aktarın (örneğin scp kullanarak). Ardından, bu yedeği slave veritabanına yükleyin:

mysql -u root -p < full_backup.sql

Bu adım, slave’in master ile aynı başlangıç verilerine sahip olmasını sağlar. Eğer master sunucunuzda henüz veri yoksa veya yeni bir veritabanı kuruyorsanız bu adımı atlayabilirsiniz.

4. Replikasyonu Başlatma Komutları: MySQL komut istemcisine bağlanın:

mysql -u root -p

Aşağıdaki komutu kullanarak replikasyonu yapılandırın. MASTER_IP_ADRESI, MASTER_PORT, repluser, gucl_sifre, mysql-bin.000001 ve 1234 değerlerini kendi ortamınızdaki değerlerle değiştirin (özellikle MASTER_LOG_FILE ve MASTER_LOG_POS değerleri, SHOW MASTER STATUS; çıktısından aldığınız değerler olmalıdır):

CHANGE MASTER TO
      MASTER_HOST='MASTER_IP_ADRESI',
      MASTER_USER='repluser',
      MASTER_PASSWORD='gucl_sifre',
      MASTER_PORT=3306,
      MASTER_LOG_FILE='mysql-bin.000001', 
      MASTER_LOG_POS=1234, 
      GET_MASTER_PUBLIC_KEY=1; -- SSL/TLS kullanıyorsanız veya yeni MySQL sürümlerinde önerilir
    
    START SLAVE;

GET_MASTER_PUBLIC_KEY=1 parametresi, MySQL 8.0 ve üzeri sürümlerde güvenli bağlantılar için önerilir. Eğer MySQL 5.7 kullanıyorsanız veya SSL/TLS kullanmıyorsanız bu parametreyi atlayabilirsiniz.

Replikasyon Durumu Nasıl Kontrol Edilir?

Replikasyonun doğru çalıştığını doğrulamak için hem master hem de slave sunucularda düzenli olarak durumu kontrol etmeniz gerekir.

1. Master Sunucuda Kontrol: Master’da SHOW MASTER STATUS; komutunu çalıştırın:

SHOW MASTER STATUS;

Çıktı aşağıdaki gibi olacaktır:

+------------------+----------+--------------+------------------+-------------------+
    | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
    +------------------+----------+--------------+------------------+-------------------+
    | mysql-bin.000001 | 1547     |              |                  |                   |
    +------------------+----------+--------------+------------------+-------------------+

File ve Position değerleri, master’ın şu anki binary log dosyasını ve içindeki pozisyonunu gösterir. Bu değerler, slave’in takip etmesi gereken son noktadır.

2. Slave Sunucuda Kontrol: Slave’de SHOW SLAVE STATUS\G; komutunu çalıştırın. \G ifadesi çıktıyı daha okunabilir bir formatta gösterir:

SHOW SLAVE STATUS\G;

Bu çıktıda dikkat etmeniz gereken en önemli alanlar şunlardır:
* Slave_IO_Running: Yes: Slave’in master’dan binary log olaylarını başarıyla çektiğini gösterir.
* Slave_SQL_Running: Yes: Slave’in relay log’daki olayları başarıyla uyguladığını gösterir.
* Last_IO_Error: : Boş olmalı. Bir hata varsa burada görünür.
* Last_SQL_Error: : Boş olmalı. Bir hata varsa burada görünür.
* Seconds_Behind_Master: 0: Slave’in master’a ne kadar geciktiğini saniye cinsinden gösterir. İdeal olarak bu değer 0 olmalıdır. Eğer 0’dan büyükse, replikasyon gecikmesi (lag) yaşanıyor demektir.
* Master_Log_File, Read_Master_Log_Pos: Slave’in master’dan en son okuduğu binary log dosyasını ve pozisyonunu gösterir.
* Relay_Log_File, Relay_Log_Pos: Slave’in kendi relay log dosyasını ve pozisyonunu gösterir.
* Exec_Master_Log_Pos: Slave’in master’dan aldığı ve uyguladığı son binary log pozisyonunu gösterir.

Her iki Slave_IO_Running ve Slave_SQL_Running değerlerinin Yes olması ve Seconds_Behind_Master değerinin 0 veya çok düşük olması, replikasyonun sağlıklı çalıştığını gösterir. Şimdi master’da bir veri değişikliği yapın (örneğin CREATE DATABASE testdb;) ve slave’de bu değişikliğin yansıyıp yansımadığını kontrol edin (SHOW DATABASES;). Eğer her şey yolundaysa, replikasyonunuz başarıyla kurulmuş demektir.

GTID Tabanlı Replikasyon Kurulumu: Daha Güvenli ve Esnek Bir Yaklaşım

GTID (Global Transaction Identifiers) tabanlı replikasyon, MySQL 5.6 ile tanıtılan ve replikasyon yönetimini önemli ölçüde basitleştiren ve güçlendiren bir özelliktir. Geleneksel dosya ve pozisyon tabanlı replikasyona göre daha sağlam ve esnektir.

GTID Nedir ve Neden Kullanmalıyız?

GTID, her bir işleme (transaction) evrensel olarak benzersiz bir kimlik atar. Bu kimlik, sunucu UUID’si ve bir işlem dizin numarasının birleşimidir (örneğin 3E11FA47-71CA-11E1-9E33-C80AA9429562:23). Bu benzersiz kimlik sayesinde:
* Basitleştirilmiş Failover: Master sunucu çöktüğünde, slave’lerden herhangi birini yeni master olarak atamak çok daha kolaydır. Slave, hangi GTID’lere sahip işlemleri uyguladığını bilir ve yeni master’dan eksik olanları talep eder. Manuel olarak binlog dosya adı ve pozisyonu belirlemeye gerek kalmaz.
* Otomatik Senkronizasyon: Yeni bir slave sunucusunu mevcut bir replikasyon topolojisine eklemek veya mevcut bir slave’i değiştirmek basitleşir. Slave, master’dan hangi GTID’lere sahip işlemleri alması gerektiğini otomatik olarak belirleyebilir.
* Daha Güvenli Replikasyon: GTID, aynı işlemin birden fazla kez uygulanmasını veya bir işlemin atlanmasını önleyerek veri tutarlılığını artırır. Bu, özellikle karmaşık replikasyon topolojilerinde (örneğin master-master, zincirleme replikasyon) kritik öneme sahiptir.
* Topoloji Değişikliklerinde Esneklik: Replikasyon topolojisini yeniden yapılandırmak (örneğin bir slave’i başka bir master’a bağlamak), GTID sayesinde çok daha az karmaşıktır.

GTID Aktif Etme: my.cnf Ayarları

GTID’yi etkinleştirmek için hem master hem de slave sunucularda my.cnf dosyasında (genellikle /etc/mysql/mysql.conf.d/mysqld.cnf) aşağıdaki ayarları yapmanız gerekir:

[mysqld]
server_id = 1 # Her sunucu için benzersiz bir ID
log_bin = /var/log/mysql/mysql-bin.log # Binary log etkin olmalı
binlog_format = ROW # GTID ile ROW formatı önerilir
gtid_mode = ON # GTID modunu açar
enforce_gtid_consistency = ON # GTID tutarlılığını zorlar
log_slave_updates = ON # Slave'in kendi binlog'una olayları yazmasını sağlar (zincirleme replikasyon için gerekli)
bind-address = 0.0.0.0

Önemli Notlar:
* gtid_mode ve enforce_gtid_consistency parametrelerini ON olarak ayarlamadan önce, mevcut tüm işlemlerin tamamlandığından ve sunucuda bekleyen replikasyon olayları olmadığından emin olun.
* Mevcut bir sistemde GTID’yi etkinleştirmek, dikkatli bir planlama gerektirir. Önce gtid_mode = OFF_PERMISSIVE ve gtid_mode = ON_PERMISSIVE aşamalarından geçmek daha güvenli bir yaklaşımdır. Ancak yeni bir kurulum yapıyorsanız doğrudan ON olarak ayarlayabilirsiniz.
* log_slave_updates = ON ayarı, slave sunucunun kendi binlog’una master’dan aldığı ve uyguladığı olayları yazmasını sağlar. Bu, slave’in kendisinin başka bir slave’e master olacağı (zincirleme replikasyon) veya master-master replikasyon gibi topolojilerde gereklidir.

Bu ayarları yaptıktan sonra, her iki sunucudaki MySQL servisini yeniden başlatın:

sudo systemctl restart mysql

GTID ile Replikasyon Başlatma: CHANGE MASTER TO Komutunda GTID Kullanımı

Slave sunucuda replikasyonu başlatırken, artık MASTER_LOG_FILE ve MASTER_LOG_POS yerine MASTER_AUTO_POSITION=1 kullanırız. Bu, slave’in master’dan eksik GTID’lere sahip tüm işlemleri otomatik olarak talep etmesini sağlar.

1. Master’da Replikasyon Kullanıcısı Oluşturma: Bu adım önceki ile aynıdır. Master sunucuda replikasyon kullanıcısını oluşturun ve yetkilendirin:

CREATE USER 'repluser'@'SLAVE_IP_ADRESI' IDENTIFIED BY 'gucl_sifre';
    GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'SLAVE_IP_ADRESI';
    FLUSH PRIVILEGES;

2. Mevcut Veritabanının Yedeğini Alma (GTID için): Eğer master’da mevcut veriler varsa, slave’e aktarmak için bir yedek almanız gerekir. mysqldump kullanıyorsanız, master-data seçeneği GTID bilgisini de dahil eder.

mysqldump -u root -p --all-databases --single-transaction --master-data --set-gtid-purged=ON > full_backup_gtid.sql

--set-gtid-purged=ON parametresi, yedek dosyasına master’da zaten uygulanmış GTID setini ekler. Bu, slave’in replikasyona doğru noktadan başlaması için kritik öneme sahiptir.

3. Slave’de Yedekten Geri Yükleme ve Replikasyonu Başlatma: Slave sunucuda, master’dan aldığınız yedeği yükleyin:

mysql -u root -p < full_backup_gtid.sql

Ardından, MySQL komut istemcisine bağlanın ve replikasyonu başlatın:

CHANGE MASTER TO
      MASTER_HOST='MASTER_IP_ADRESI',
      MASTER_USER='repluser',
      MASTER_PASSWORD='gucl_sifre',
      MASTER_PORT=3306,
      MASTER_AUTO_POSITION=1, -- GTID replikasyonu için anahtar
      GET_MASTER_PUBLIC_KEY=1;
    
    START SLAVE;

MASTER_AUTO_POSITION=1 ayarı, slave’in master’dan eksik GTID’lere sahip tüm işlemleri otomatik olarak istemesini sağlar. Bu, replikasyonun başlangıç noktasını manuel olarak belirleme ihtiyacını ortadan kaldırır.

4. Replikasyon Durumunu Kontrol Etme: Slave sunucuda SHOW SLAVE STATUS\G; komutunu çalıştırarak replikasyonun sağlıklı çalışıp çalışmadığını kontrol edin. Slave_IO_Running: Yes, Slave_SQL_Running: Yes ve Seconds_Behind_Master: 0 değerlerini gördüğünüzden emin olun. Ayrıca Executed_Gtid_Set alanının master’daki Executed_Gtid_Set ile eşleştiğini de kontrol edebilirsiniz (SHOW MASTER STATUS; çıktısında).

GTID tabanlı replikasyon, özellikle dinamik ve karmaşık veritabanı ortamlarında yönetim kolaylığı ve güvenilirlik açısından önemli avantajlar sunar. Bu nedenle, mümkünse GTID kullanmayı tercih etmelisiniz.

Replikasyon Yönetimi ve İleri Düzey İpuçları

Replikasyon kurulumu, sürecin sadece ilk adımıdır. Kurulumdan sonra, replikasyon ortamınızın sağlıklı ve verimli bir şekilde çalıştığından emin olmak için düzenli izleme, bakım ve sorun giderme işlemleri yapmanız gerekir. Bu bölümde, replikasyon yönetimi için önemli ipuçlarına ve ileri düzey stratejilere değineceğiz.

Replikasyon Gecikmesi (Lag) Nasıl İzlenir ve Çözülür?

Replikasyon gecikmesi (replication lag), slave sunucunun master’dan ne kadar geride olduğunu ifade eder. Bu, SHOW SLAVE STATUS\G; çıktısındaki Seconds_Behind_Master alanında görülebilir. İdeal olarak bu değer 0 veya çok düşük olmalıdır. Yüksek bir gecikme, slave’in güncel olmayan verilere sahip olduğu anlamına gelir ve bu durum, raporlama, yük dengeleme veya felaket kurtarma senaryolarında ciddi sorunlara yol açabilir.

Replikasyon Gecikmesinin Nedenleri:

* Ağ Gecikmesi: Master ve slave arasındaki ağ bağlantısının yavaş olması veya yüksek gecikme süresine sahip olması.
* Slave’in Yetersiz Performansı: Slave sunucusunun donanım kaynaklarının (CPU, RAM, Disk I/O) master’dan gelen yoğun yazma yükünü kaldıramaması. Slave’in disk I/O performansı, relay log’a yazma ve oradan okuma işlemlerinde kritik öneme sahiptir.
* Uzun Süren Master İşlemleri: Master’da çok büyük veya uzun süren işlemler (örneğin büyük bir ALTER TABLE işlemi, toplu veri yüklemeleri) slave’in bu işlemleri uygulaması için daha fazla zaman harcamasına neden olabilir.
* Tek Çekirdekli SQL Thread: MySQL’in geleneksel replikasyonunda, SQL Thread tek çekirdek üzerinde çalışır. Bu, master’da paralel olarak gerçekleşen birçok işlemi slave’in tek tek ve sırayla uygulamak zorunda kalması nedeniyle bir darboğaz oluşturabilir. MySQL 5.6 ve üzeri sürümlerde slave_parallel_workers ayarı ile bu durum kısmen iyileştirilebilir.
* Yoğun Okuma Yükü (Slave Üzerinde): Slave sunucusu aynı zamanda yoğun okuma sorguları için kullanılıyorsa, bu durum SQL Thread’in performansını etkileyebilir.

Replikasyon Gecikmesini Çözme Yöntemleri:

* Donanım Yükseltme: Slave sunucusunun CPU, RAM veya SSD gibi disk I/O kaynaklarını artırmak, replikasyon performansını önemli ölçüde iyileştirebilir. Özellikle hızlı depolama birimleri (NVMe SSD’ler), relay log’a yazma ve okuma hızını artırarak gecikmeyi azaltır.
* Sorgu Optimizasyonu: Master’daki uzun süren veya optimize edilmemiş sorguları tespit edip iyileştirmek, replikasyon yükünü azaltabilir.
* slave_parallel_workers Kullanımı: MySQL 5.6’dan itibaren kullanılabilen bu parametre, slave SQL Thread’inin birden fazla işçi (worker) kullanarak işlemleri paralel olarak uygulamasını sağlar. Bu, özellikle GTID tabanlı replikasyon ile birlikte kullanıldığında çok etkilidir. my.cnf dosyasına slave_parallel_workers = N (N, CPU çekirdek sayısı kadar veya biraz daha az olabilir) ekleyerek etkinleştirebilirsiniz.
* Percona Toolkit (pt-heartbeat): pt-heartbeat gibi araçlar, replikasyon gecikmesini gerçek zamanlı ve daha hassas bir şekilde izlemek için kullanılabilir. Bu araç, master’da küçük bir tabloya düzenli olarak veri yazarak ve slave’in bu veriyi ne kadar sürede yakaladığını ölçerek gecikmeyi belirler.
* Trafik Yönetimi: Eğer slave üzerindeki okuma yükü replikasyonu etkiliyorsa, bazı okuma sorgularını başka slave’lere yönlendirmek veya daha az kritik raporlama sorgularını mesai saatleri dışında çalıştırmak gibi stratejiler uygulanabilir.
* Yarı Senkron Replikasyon: Tamamen asenkron replikasyonda veri kaybı riski varken, yarı senkron replikasyon (semisynchronous replication) master’ın bir işlemi onaylamadan önce en az bir slave’in bu işlemi aldığını doğrulamasını sağlar. Bu, veri kaybı riskini azaltır ancak master’ın yazma performansını bir miktar etkileyebilir.

Replikasyon Hataları ve Giderilmesi

Replikasyon ortamında hatalar meydana gelebilir ve bu hataları hızlı bir şekilde tespit edip gidermek, veri tutarlılığını sağlamak için kritiktir. SHOW SLAVE STATUS\G; çıktısındaki Last_IO_Error ve Last_SQL_Error alanları, hataları belirlemek için anahtar noktalardır.

Yaygın Hata Türleri ve Giderilmesi:

* Last_IO_Error: Genellikle ağ bağlantısı sorunları, master’ın çevrimdışı olması, replikasyon kullanıcısının yetkisiz olması veya master’ın binary log’unun silinmesi gibi nedenlerden kaynaklanır.
* Çözüm: Ağ bağlantısını kontrol edin, master sunucunun çalıştığından emin olun, repluser kullanıcısının şifresini ve yetkilerini doğrulayın. Master’da binlog’ların silinmediğinden emin olun veya slave’i yeni bir binlog pozisyonundan başlatın.
* Last_SQL_Error: Çoğunlukla slave’de master’da olmayan birincil anahtar çakışmaları (duplicate key errors), eksik tablolar veya veri tutarsızlıkları gibi veri uygulama hatalarından kaynaklanır. Örneğin, master’da bir kayıt silinmişken slave’de bu kayıt zaten yoksa, slave DELETE işlemini uygularken hata verebilir.
* Çözüm: Hata mesajını dikkatlice okuyun. Eğer hata önemsizse ve atlanabilecek bir durumsa (örneğin bir DELETE işleminin zaten olmayan bir kaydı silmeye çalışması), hatayı atlayabilirsiniz:

STOP SLAVE;
        SET GLOBAL sql_slave_skip_counter = 1; -- Bir sonraki hatayı atlar
        START SLAVE;

UYARI: sql_slave_skip_counter dikkatli kullanılmalıdır. Sadece hatanın nedenini anladığınızda ve veri tutarlılığını bozmayacağından emin olduğunuzda kullanın. Aksi takdirde, master ve slave arasında veri uyuşmazlıkları oluşabilir. Daha ciddi hatalar için slave’i yeniden oluşturmak (master’dan yeni bir yedekle) daha güvenli bir yöntem olabilir.
* Veri Uyuşmazlıkları (Data Drift): Master ve slave arasındaki verilerin farklılaşması durumudur. Bu, genellikle slave üzerinde doğrudan yazma işlemleri yapılması, hatalı sql_slave_skip_counter kullanımı veya binlog formatının yanlış ayarlanması gibi nedenlerle oluşur.
* Önlemler: Slave sunucularında yazma işlemlerini engelleyin (uygulama seviyesinde veya MySQL kullanıcı yetkilerini kısıtlayarak). binlog_format=ROW kullanmak, STATEMENT tabanlı replikasyonda ortaya çıkabilecek deterministik olmayan fonksiyon sorunlarını ortadan kaldırır. Düzenli olarak master ve slave verilerini karşılaştıran araçlar kullanın (örneğin Percona Toolkit’ten pt-table-checksum).

Failover ve Yüksek Erişilebilirlik Stratejileri

Replikasyonun temel amaçlarından biri yüksek erişilebilirlik sağlamaktır. Master sunucu arızalandığında, slave sunuculardan birinin hızla yeni master olarak atanması (failover) kritik öneme sahiptir.

* Manuel Failover: Master çöktüğünde, bir slave’i manuel olarak yeni master olarak atayabilirsiniz.
1. Tüm slave’lerde replikasyonu durdurun: STOP SLAVE;
2. En güncel slave’i (en düşük Seconds_Behind_Master değerine sahip olanı) belirleyin.
3. Seçilen slave’i yeni master olarak tanıtın: RESET MASTER; (GTID kullanılıyorsa RESET MASTER gerekmeyebilir).
4. Uygulamalarınızı yeni master’ın IP adresine yönlendirin.
5. Diğer slave’leri yeni master’a bağlayın.
Bu süreç karmaşık ve hata yapmaya açıktır.

* Otomatik Failover Araçları: Daha güvenilir ve hızlı bir failover için otomatik araçlar kullanmak önerilir:
* ProxySQL: Gelişmiş bir MySQL proxy’sidir. Hem yük dengeleme hem de otomatik failover yeteneklerine sahiptir. Sunucuların durumunu izler ve bir master çöktüğünde trafiği otomatik olarak sağlıklı bir slave’e yönlendirir, onu yeni master olarak atayabilir.
* Orchestrator (GitHub): MySQL topolojilerini keşfetmek, görselleştirmek ve otomatik failover yapmak için tasarlanmış güçlü bir araçtır. Bir master’ın arızalandığını algıladığında, en uygun slave’i yeni master olarak yükseltir ve diğer slave’leri otomatik olarak yeni master’a bağlar.
* MHA (Master High Availability Manager): MySQL master’ın arızasını tespit eden ve otomatik failover gerçekleştiren bir başka popüler araçtır.

* Read Replicas ile Yük Dengeleme: Okuma ağırlıklı uygulamalar için birden fazla slave sunucusu (read replicas) kurarak yükü dağıtabilirsiniz. Uygulamanız, okuma sorgularını bu read replica’lara yönlendirmelidir. Bu, master üzerindeki yükü azaltır ve sorgu performansını artırır. ProxySQL gibi araçlar, bu yük dengeleme işlemini otomatik olarak yapabilir.

Bu ileri düzey yönetim ve sorun giderme ipuçları, replikasyon ortamınızın istikrarlı, performanslı ve güvenilir kalmasını sağlamak için kritik öneme sahiptir. Düzenli izleme ve proaktif yaklaşımlar, olası sorunları büyümeden önce tespit etmenize ve çözmenize yardımcı olacaktır.

Vaka Analizi: E-ticaret Sitesi İçin MySQL Replikasyonu

Bir e-ticaret sitesi, modern iş dünyasının en dinamik ve veri yoğun platformlarından biridir. Müşteri bilgileri, ürün katalogları, sipariş geçmişleri, ödeme kayıtları gibi kritik verileri barındırır ve sürekli olarak yüksek erişilebilirlik, hızlı yanıt süreleri ve veri güvenliği beklentisiyle karşı karşıyadır. Tek bir MySQL sunucusuna bağımlı kalmak, bu beklentileri karşılamakta yetersiz kalabilir ve site için felaket anlamına gelebilir. İşte böyle bir senaryoda MySQL replikasyonunun nasıl bir çözüm sunduğuna dair bir vaka analizi.

Senaryo:

Orta ölçekli bir e-ticaret sitesi, hızla büyüyen müşteri tabanı ve artan ürün çeşitliliği ile birlikte ciddi performans sorunları yaşamaya başlıyor. Özellikle şikayetler şu noktalarda yoğunlaşıyor:

1. Performans Darboğazları: Yoğun kampanya dönemlerinde veya günün belirli saatlerinde (örneğin öğle araları, akşam saatleri), site yavaşlıyor. Ürün sayfaları geç yükleniyor, sepete ekleme işlemleri yavaş kalıyor ve ödeme süreçleri takılıyor. Bu durum, aynı anda hem ürün listeleme/arama gibi okuma ağırlıklı işlemlerin hem de sipariş verme/stok güncelleme gibi yazma ağırlıklı işlemlerin tek bir veritabanı sunucusunda yapılmasıyla tetikleniyor.
2. Raporlama İhtiyaçları: Pazarlama ve finans departmanları, günlük satış raporları, en çok satan ürün analizleri, müşteri davranış analizleri gibi karmaşık ve uzun süren sorgular çalıştırmak istiyor. Bu sorgular, canlı site performansını olumsuz etkiliyor ve operasyonel ekiplerin işini aksatıyor.
3. Veri Güvenliği ve Felaket Kurtarma: Mevcut tek sunucu, donanım arızası veya yazılım hatası gibi durumlarda tüm verilerin kaybolma riskini taşıyor. Bir sunucu çökmesi durumunda, sitenin saatlerce, hatta günlerce kapalı kalması, gelir kaybı ve marka itibarı açısından büyük bir tehdit oluşturuyor.
4. Kesintisiz Bakım: Veritabanı sunucusunda planlı bakım (örneğin işletim sistemi yamaları, MySQL yükseltmeleri) yapılması gerektiğinde, sitenin tamamen kapatılması gerekiyor. Bu da müşteri deneyimini olumsuz etkiliyor ve satış kayıplarına neden oluyor.

Çözüm: Master-Slave Replikasyon ve Read Replica Kullanımı

E-ticaret sitesinin teknik ekibi, bu sorunları çözmek ve platformun ölçeklenebilirliğini, dayanıklılığını artırmak için MySQL Master-Slave replikasyon mimarisini benimsemeye karar verir. Kurulum adımları şu şekilde planlanır ve uygulanır:

1. Master Sunucu (Yazma İşlemleri): Mevcut yüksek performanslı MySQL sunucusu master olarak belirlenir. Tüm INSERT, UPDATE, DELETE işlemleri (sipariş oluşturma, stok güncelleme, kullanıcı kaydı gibi) bu sunucuya yönlendirilir. my.cnf dosyası server_id, log_bin, binlog_format=ROW ve gtid_mode=ON ayarlarıyla yapılandırılır. Bir replikasyon kullanıcısı oluşturulur ve yetkilendirilir.
2. Slave Sunucu 1 (Read Replica – Yük Dengeleme): Yeni bir sunucu temin edilir ve master’dan ilk yedek alınarak bu sunucuya yüklenir. Bu slave, sitenin ana okuma trafiğini (ürün listeleme, arama, ürün detay sayfaları) karşılamak üzere yapılandırılır. Uygulama katmanında, okuma sorguları bu slave’e yönlendirilir. Böylece master üzerindeki yük önemli ölçüde azalır.
3. Slave Sunucu 2 (Read Replica – Raporlama ve Yedekleme): Bir başka sunucu daha temin edilir ve aynı şekilde master’dan yedek alınarak replikasyon zincirine dahil edilir. Bu slave, özellikle pazarlama ve finans ekiplerinin çalıştırdığı yoğun raporlama ve analiz sorguları için ayrılır. Canlı site performansını etkilemeden, bu sunucu üzerinde karmaşık raporlar oluşturulabilir. Ayrıca, bu slave, master’ın bir sıcak yedeği olarak da işlev görür.
4. Otomatik Failover ve Yük Dengeleme Aracı: Replikasyon topolojisini yönetmek ve otomatik failover sağlamak için ProxySQL gibi bir araç devreye alınır. ProxySQL, tüm veritabanı bağlantılarını kendi üzerinden geçirir. Okuma sorgularını otomatik olarak Slave 1 ve Slave 2 arasında dengelerken, yazma sorgularını master sunucuya yönlendirir. Master sunucu çevrimdışı kalırsa, ProxySQL bunu algılar ve otomatik olarak Slave 1 veya Slave 2’yi yeni master olarak yükseltir ve tüm trafiği ona yönlendirir.

Faydaları:

Bu replikasyon mimarisi sayesinde e-ticaret sitesi aşağıdaki önemli faydaları elde eder:

* Daha Yüksek Performans: Okuma ve yazma işlemlerinin farklı sunuculara dağıtılmasıyla master üzerindeki yük azalır. Ürün sayfaları daha hızlı yüklenir, arama sonuçları anında gelir ve genel site performansı belirgin şekilde artar. Kampanya dönemlerinde dahi site performansı istikrarlı kalır.
* Yüksek Erişilebilirlik ve Kesintisiz Hizmet: Master sunucu arızalandığında, otomatik failover mekanizması sayesinde sistem saniyeler içinde yeni master’a geçiş yapar. Kullanıcılar neredeyse hiç kesinti yaşamaz. Bu, sürekli açık kalması gereken bir e-ticaret sitesi için hayati önem taşır.
* Gelişmiş Veri Güvenliği ve Felaket Kurtarma: İki ayrı slave sunucusu, master’daki verilerin canlı kopyalarını tutar. Herhangi bir veri kaybı veya bozulması durumunda, slave’lerden biri hızlıca kurtarma için kullanılabilir. Bu, geleneksel yedekleme yöntemlerine ek olarak güçlü bir koruma katmanı sağlar.
* Etkili Raporlama ve Analiz: Raporlama işlemleri için ayrılmış slave sunucu, canlı site performansını etkilemeden karmaşık analizlerin yapılmasını sağlar. İş zekası ekipleri, ihtiyaç duydukları verilere daha hızlı ve güvenilir bir şekilde erişebilirler.
* Sıfır Kesinti ile Bakım: Master sunucuda planlı bakım yapılması gerektiğinde, ProxySQL trafiği geçici olarak slave’lere yönlendirir. Bakım tamamlandıktan sonra master tekrar devreye alınır. Bu süreçte site kesintisiz olarak hizmet vermeye devam eder.

Bu vaka analizi, MySQL replikasyonunun sadece teknik bir gereklilik olmaktan öte, bir işletmenin operasyonel verimliliğini, müşteri memnuniyetini ve gelirini doğrudan etkileyen stratejik bir yatırım olduğunu açıkça göstermektedir.

Sonuç ve Sıkça Sorulan Sorular

MySQL replikasyonu, modern veritabanı altyapılarının vazgeçilmez bir bileşenidir. Bu kapsamlı rehber boyunca, replikasyonun temel kavramlarından başlayarak, adım adım kurulumuna, GTID gibi ileri düzey özelliklerine ve yönetim ipuçlarına kadar birçok konuyu ele aldık. Replikasyonun yüksek erişilebilirlik, yük dengeleme, veri yedekleme ve felaket kurtarma gibi kritik faydaları, herhangi bir ölçekteki uygulama için vazgeçilmezdir. Özellikle yoğun trafikli web siteleri, e-ticaret platformları ve kritik iş uygulamaları için replikasyon, kesintisiz hizmet ve veri bütünlüğünü sağlamanın anahtarıdır.

Unutulmamalıdır ki, replikasyon kurulumu kadar, replikasyon ortamının düzenli olarak izlenmesi, olası gecikmelerin ve hataların giderilmesi de büyük önem taşır. GTID tabanlı replikasyon, bu yönetim süreçlerini basitleştirirken, otomatik failover araçları ve yük dengeleme çözümleri, sistemin dayanıklılığını ve performansını daha da artırır. MySQL 8.0 ve sonraki sürümler, replikasyon konusunda daha da fazla iyileştirme ve yeni özellikler sunmaya devam etmektedir, bu da MySQL’in gelecekteki veritabanı ihtiyaçları için güçlü bir seçenek olmaya devam edeceğini göstermektedir.

Sıkça Sorulan Sorular (SSS):

Replikasyon türleri nelerdir?

MySQL’de temel olarak asenkron replikasyon kullanılır; master bir işlemi kaydettikten hemen sonra slave’in onayını beklemeden devam eder. Bu, yüksek performans sağlar ancak küçük bir veri kaybı riski taşır. Yarı-senkron (semisynchronous) replikasyon ise master’ın bir işlemi onaylamadan önce en az bir slave’in bu işlemi aldığını doğrulamasını bekler, bu da veri kaybı riskini azaltır ancak yazma performansını bir miktar etkileyebilir. Tam senkron replikasyon ise MySQL’in yerleşik bir özelliği değildir, genellikle harici araçlar veya üçüncü taraf çözümlerle sağlanır.

Replikasyon performansı nasıl etkiler?

Replikasyon, master sunucunun performansını genellikle çok az etkiler, çünkü sadece binary log’a yazma işlemi eklenir. Asıl performans artışı, okuma sorgularının slave sunuculara dağıtılmasıyla elde edilir. Ancak, slave sunucuların donanım kaynakları yetersizse veya ağ gecikmesi yüksekse, replikasyon gecikmesi (lag) yaşanabilir ve bu durum slave’lerin güncel olmayan veriler sunmasına neden olabilir.

Replikasyon ne zaman kullanılmamalıdır?

Replikasyon, her zaman en iyi çözüm olmayabilir. Eğer uygulamanız çok az veri değiştiriyor ve yüksek erişilebilirlik veya yük dengeleme gibi ihtiyaçlarınız yoksa, tek bir sunucu yeterli olabilir. Ayrıca, replikasyon karmaşıklığı artırır ve yönetim yükü getirir. Eğer veri tutarlılığı kritik derecede önemli ve herhangi bir gecikme kabul edilemezse (örneğin finansal işlemler gibi), daha çok senkron replikasyon veya dağıtılmış veritabanı çözümleri düşünülmelidir.

GTID kullanmak zorunlu mu?

Hayır, GTID kullanmak zorunlu değildir. Geleneksel dosya ve pozisyon tabanlı replikasyon hala kullanılabilir. Ancak, GTID replikasyon yönetimini, failover süreçlerini ve topoloji değişikliklerini önemli ölçüde basitleştirir ve daha güvenilir hale getirir. Özellikle MySQL 5.6 ve üzeri sürümlerde yeni kurulumlar için GTID kullanılması şiddetle tavsiye edilir.

Replikasyon güvenli midir?

Evet, doğru yapılandırıldığında replikasyon güvenlidir. Master ve slave sunucular arasındaki bağlantıyı şifrelemek için SSL/TLS kullanmak, replikasyon kullanıcısına en az yetkiyi vermek (REPLICATION SLAVE yetkisi yeterlidir) ve güvenlik duvarı kurallarını sıkılaştırmak önemlidir. Ayrıca, replikasyonun kendisi veri bütünlüğü sorunlarına yol açmaz; ancak yanlış yapılandırma veya manuel müdahaleler veri tutarsızlıklarına neden olabilir.