Veritabanı Replikasyonu: MySQL/MariaDB Master-Slave Kurulumu ve GTID

Veritabanı Replikasyonu: MySQL/MariaDB Master-Slave Kurulumu ve GTID

MySQL replikasyonu verinin bir source sunucudan (MySQL 8.0.26+ terminolojisinde "source", eski adıyla "master") bir veya birden çok replica'ya ("slave") otomatik olarak kopyalanmasını sağlar. Okuma yükü dağıtımı, yüksek erişilebilirlik, yedek alma ve coğrafi dağıtım için kullanılır. Bu rehberde binary log temelleri, position-based ve GTID-based replikasyon, multi-source kurulum, monitoring, hata yönetimi ve ProxySQL ile read/write split konularını ele alıyoruz.

Replikasyon Neden Gerekli?

Tek bir veritabanı sunucusu belirli bir noktada darboğaz olur. Replikasyon bu sorunu birkaç farklı boyutta çözer:

Okuma ölçekleme: Web uygulamalarının yükünün %70-90'ı okuma sorgusudur. SELECT sorgularını replica'lara dağıtarak master üzerindeki yükü ciddi ölçüde azaltabilirsiniz. Tek master, birden çok replica mimarisi bunu doğrudan karşılar.

Yüksek erişilebilirlik (HA): Master çöktüğünde bir replica yeni master olarak promote edilir. Bu işlem saniyeler içinde tamamlanır; veri kaybı riski asenkron replikasyonda küçük bir "lag penceresi" kadar olmakla birlikte, semi-senkron modda bu pencere neredeyse sıfıra indirilir.

Yedekleme ayrı node üzerinden: Master üzerinde FLUSH TABLES WITH READ LOCK yapmak üretimi etkiler. Replica üzerinde mysqldump veya mariabackup çalıştırmak master'a dokunmaz. Büyük veritabanları için en pratik yedekleme stratejisidir.

Coğrafi dağıtım: Uzak lokasyondaki bir replica, yerel kullanıcıların okuma gecikmesini düşürür. Yazma işlemleri hâlâ merkezi master'a gider; ama okuma trafiği lokal replica üzerinden karşılanır.

Buyukweb notu: cPanel paylaşımlı hosting paketlerinde MySQL/MariaDB paylaşımlı bir sunucudadır; root yetkisi yoktur ve replikasyon kurulmaz. Replikasyon Buyukweb VDS (KVM + NVMe, ₺250/ay başlangıç) üzerinde iki veya daha fazla VDS arasında özel ağ ya da VPN üzerinden kurulabilir.

Replikasyon Türleri: Async, Semi-Sync, Sync

Üç temel replikasyon modeli vardır; seçim gecikme toleransınıza ve veri kaybı riskine göre yapılır.

Asenkron replikasyon (varsayılan): Master işlemi commit eder ve replica'nın onayını beklemeden devam eder. Replica biraz geride kalabilir — bu "replication lag" olarak ölçülür. Performans en yüksek bu modda alınır ama master çöktüğünde replica'ya ulaşmamış birkaç transaction kaybolabilir. MySQL/MariaDB'nin varsayılan modudur.

Semi-senkron replikasyon: Master, commit'i en az bir replica'nın binary log'u aldığını onayladıktan sonra tamamlar. Veri kaybı riski neredeyse sıfırdır; ancak her commit için replica'dan ACK beklenmesi latency'yi artırır. Plugin ile etkinleştirilir:

-- Master'da
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 1000; -- ms, bu sürede ACK gelmezse async'e düşer

-- Replica'da
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

Senkron replikasyon (Galera Cluster / Group Replication): Commit tüm node'lara yazılmadan tamamlanmaz. Paxos tabanlı protokol kullanır; tam ACID garantisi vardır. Multi-master yazma desteklenir. Gecikme daha yüksektir; WAN üzerinde kullanımı dikkat gerektirir. Galera (MariaDB Galera Cluster / Percona XtraDB Cluster) ve MySQL Group Replication bu kategoridedir.

Binary Log Temeli: SBR, RBR, MBR

Replikasyon binary log üzerinden çalışır. Binary log, master'da gerçekleşen tüm değişiklikleri kaydeder. Üç format vardır:

Format	Adı	Nasıl Kaydeder	Avantaj	Dezavantaj
SBR	Statement-Based	SQL ifadesinin kendisi	Küçük log boyutu	Non-deterministic fonksiyonlar (NOW(), UUID()) sorun çıkarır
RBR	Row-Based	Değişen satırların kendisi	Deterministik, güvenilir	Büyük log boyutu (bulk operasyonlarda)
MBR	Mixed	İki modu otomatik seçer	Orta yol	Bazı edge case'ler hâlâ riskli

2026 önerisi: binlog_format=ROW. Statement-based replikasyon RAND(), UUID(), SYSDATE() gibi non-deterministic fonksiyonları kullanan sorgularda replica'da farklı sonuç üretir. Row-based bu riski tamamen ortadan kaldırır; log boyutu artsa da modern NVMe disklerde bu fark ihmal edilebilir düzeydedir.

[mysqld]
binlog_format = ROW
binlog_row_image = MINIMAL  ; sadece değişen kolonları yaz, log boyutunu küçültür

Position-Based Replikasyon (Klasik Yöntem)

MySQL 5.6 öncesinin tek seçeneğidir; hâlâ yaygın şekilde kullanılmaktadır.

Master her binary log event'ini bir dosya adı ve position ile tanımlar:

mysql-bin.000003  |  Position: 4  →  157  →  513  →  ...

Replica bu koordinatları takip eder: "mysql-bin.000003 dosyasının 157. byte'ından sonrasını oku." Sorun: master çöktüğünde ve yeni bir master belirlenmek istendiğinde, her replica farklı bir position'da olabilir. Doğru position'ı bulmak ve CHANGE MASTER TO ile yeniden bağlamak operatöre düşer; hatalı position failover'ı bozar.

-- Klasik CHANGE MASTER TO (position-based)
CHANGE MASTER TO
  MASTER_HOST = '192.168.1.10',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'güçlü_şifre',
  MASTER_LOG_FILE = 'mysql-bin.000003',
  MASTER_LOG_POS  = 157;

START SLAVE;   -- MySQL 8.0.22+: START REPLICA;

GTID Tabanlı Replikasyon (Modern Yaklaşım)

GTID (Global Transaction Identifier), MySQL 5.6 ve MariaDB 10.0'da tanıtıldı. Her transaction küresel olarak benzersiz bir kimlik alır:

GTID format: source_uuid:transaction_id
Örnek:       3E11FA47-71CA-11E1-9E33-C80AA9429562:23

Replica hangi transaction'ların uygulandığını bilir; failover sırasında "nerede kaldım?" sorusu otomatik yanıtlanır. Yeni master'a bağlanmak için position hesaplamaya gerek yoktur — GTID seti karşılaştırılır ve eksik transaction'lar otomatik tamamlanır.

GTID etkinleştirme (her iki sunucuda):

[mysqld]
gtid_mode              = ON
enforce_gtid_consistency = ON
log_slave_updates      = ON   ; MariaDB'de log_slave_updates varsayılan ON; MySQL'de açıkça belirtilmeli

-- GTID ile replica bağlama
CHANGE MASTER TO
  MASTER_HOST     = '192.168.1.10',
  MASTER_USER     = 'repl',
  MASTER_PASSWORD = 'güçlü_şifre',
  MASTER_AUTO_POSITION = 1;   -- position/file yazmaya gerek yok

START SLAVE;

MariaDB notu: MariaDB'de GTID implementasyonu MySQL'den farklıdır — domain_id:server_id:sequence_no formatı kullanılır. MariaDB 10.0+ varsayılan olarak GTID desteğiyle gelir; gtid_mode=ON yerine gtid_strict_mode=1 tercih edilir.

Master (Source) Sunucu Kurulumu

/etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu/Debian) veya /etc/my.cnf.d/server.cnf (RHEL/AlmaLinux):

[mysqld]
server_id              = 1          ; Benzersiz, küme içinde tekrar etmemeli
log_bin                = /var/log/mysql/mysql-bin.log
binlog_format          = ROW
binlog_row_image       = MINIMAL
binlog_expire_logs_seconds = 604800  ; 7 gün; eski: expire_logs_days = 7
max_binlog_size        = 100M

; İsteğe bağlı: sadece belirli DB'yi replicate et
; binlog_do_db     = uygulama_db
; Ya da hariç tut:
; binlog_ignore_db = test
; binlog_ignore_db = information_schema

; GTID kullanıyorsanız:
gtid_mode              = ON
enforce_gtid_consistency = ON
log_slave_updates      = ON

sudo systemctl restart mysql

Replikasyon kullanıcısı oluştur:

-- MySQL 8.0+
CREATE USER 'repl'@'%' IDENTIFIED WITH caching_sha2_password BY 'güçlü_şifre_buraya';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

-- MySQL 5.7 / MariaDB (eski authentication plugin)
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'güçlü_şifre_buraya';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

Güvenlik notu: '%' yerine replica IP bloğunu veya IP adresini belirtin. VDS özel ağında bu 192.168.x.x veya kullandığınız VPN subnet'i olur.

Replica (Slave) Sunucu Kurulumu

[mysqld]
server_id          = 2          ; Master'dan FARKLI bir değer
relay_log          = /var/log/mysql/relay-bin
read_only          = ON         ; Uygulamaların yanlışlıkla yazmasını engeller
super_read_only    = ON         ; SUPER yetkili kullanıcılar da yazamaz (MySQL 5.7.8+)
log_slave_updates  = ON         ; Bu replica'nın da binlog yazması (cascade için)

; GTID kullanıyorsanız (master ile aynı):
gtid_mode              = ON
enforce_gtid_consistency = ON

İlk veri kopyalama:

# Seçenek 1: mysqldump (küçük-orta DB'ler için)
# Master'da:
mysqldump -u root -p   --all-databases   --master-data=2        # GTID ile: --set-gtid-purged=ON ekle
  --single-transaction   # InnoDB için lock kullanmadan tutarlı dump
  --routines --events   > master_dump.sql

# Replica'ya kopyala ve yükle:
scp master_dump.sql replica_ip:/tmp/
mysql -u root -p < /tmp/master_dump.sql

# Seçenek 2: mariabackup (MariaDB, büyük DB'ler için — lock almaz)
mariabackup --backup --slave-info --user=root --password=SİFRE   --target-dir=/var/backup/mariabackup
mariabackup --prepare --target-dir=/var/backup/mariabackup

CHANGE MASTER TO / CHANGE REPLICATION SOURCE TO

MySQL 8.0.23+ yeni syntax kullanır ama eski syntax hâlâ çalışır:

-- MySQL 8.0.23+ (yeni syntax)
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST     = '192.168.1.10',
  SOURCE_USER     = 'repl',
  SOURCE_PASSWORD = 'güçlü_şifre_buraya',
  SOURCE_AUTO_POSITION = 1;   -- GTID kullanıyorsanız

START REPLICA;    -- Eski: START SLAVE;

-- Durum kontrolü
SHOW REPLICA STATUSG  -- Eski: SHOW SLAVE STATUSG

Kritik alanlar:

Replica_IO_Running:  Yes    ← Master'dan binlog çekiliyor mu?
Replica_SQL_Running: Yes    ← Events uygulanıyor mu?
Seconds_Behind_Source: 0   ← Kaç saniye geride (0 = güncel)
Last_Error:                ← Hata mesajı (boş olmalı)

Multi-Source Replikasyon

Bir replica'nın birden çok source'tan binlog tüketmesi: MariaDB 10.0+ ve MySQL 5.7+ destekler. Her kaynak bir "channel" (kanal) ile ayrılır.

-- İki farklı source'tan replikasyon (MySQL 8.0)
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST     = '192.168.1.10',
  SOURCE_USER     = 'repl',
  SOURCE_PASSWORD = 'şifre1',
  SOURCE_AUTO_POSITION = 1
  FOR CHANNEL 'shard-1';

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST     = '192.168.1.20',
  SOURCE_USER     = 'repl',
  SOURCE_PASSWORD = 'şifre2',
  SOURCE_AUTO_POSITION = 1
  FOR CHANNEL 'shard-2';

START REPLICA FOR CHANNEL 'shard-1';
START REPLICA FOR CHANNEL 'shard-2';

-- Durum kontrolü kanal bazlı
SHOW REPLICA STATUS FOR CHANNEL 'shard-1'G

Kullanım senaryosu: birden çok shard'ı tek bir analytics replica'sında birleştirmek. Yazma çakışması yoktur çünkü her shard farklı tablolara yazar.

Multi-Master Replikasyon ve Riskleri

Çift yönlü replikasyon (iki sunucunun birbirini source olarak kullandığı yapı) teorik olarak kurulabilir ama pratikte ciddi riskler taşır:

• auto_increment çakışması: İki master aynı ID'yi üretebilir. auto_increment_increment = 2 ve auto_increment_offset = 1/2 ile kısmen çözülür ama zarif değildir.
• Çakışan yazma döngüsü: A → B → A → B... yazan binlog loop'u oluşabilir; log_slave_updates ile tetiklenir.

Önerilen alternatif: Galera Cluster (MariaDB) veya MySQL Group Replication. Paxos protokolüyle tutarlı multi-master sağlar; çakışmayı otomatik yakalar. Buyukweb VDS üzerinde Galera 3-node kurulumu mümkündür; ek karmaşıklık ve en az 3 VDS gerektirir.

Replikasyon İzleme

Temel SQL izleme:

-- Anlık lag ve durum
SHOW REPLICA STATUSG

-- performance_schema üzerinden daha ayrıntılı
SELECT CHANNEL_NAME, SERVICE_STATE, RECEIVED_TRANSACTION_SET
FROM performance_schema.replication_connection_status;

SELECT CHANNEL_NAME, SERVICE_STATE
FROM performance_schema.replication_applier_status;

-- Binary log boyutları (master'da)
SHOW BINARY LOGS;
SHOW MASTER STATUS;

Percona pt-heartbeat ile gerçek lag ölçümü:

SHOW SLAVE STATUS içindeki Seconds_Behind_Master değeri her zaman güvenilir değildir — SQL thread durduğunda sıfır gösterebilir. pt-heartbeat master'a gerçek zaman damgası yazar, replica'da okur:

# Master'da heartbeat başlat
pt-heartbeat --host=master_ip --database=uygulama_db   --user=root --password=SİFRE --update --daemonize

# Replica'da lag ölç
pt-heartbeat --host=replica_ip --database=uygulama_db   --user=root --password=SİFRE --monitor --master-server-id=1

Prometheus + mysqld_exporter ile sürekli izleme:

# mysqld_exporter kurulum (replica üzerinde)
wget https://github.com/prometheus/mysqld_exporter/releases/latest/download/mysqld_exporter-0.15.1.linux-amd64.tar.gz
tar xzf mysqld_exporter-*.tar.gz
./mysqld_exporter --config.my-cnf=.my.cnf &

# prometheus.yml — replica scrape
- job_name: 'mysql_replica'
  static_configs:
    - targets: ['replica_ip:9104']

Grafana'da izlenecek temel metrikler:

• mysql_slave_status_seconds_behind_master — replikasyon gecikmesi
• mysql_slave_status_slave_io_running — IO thread durumu (1 = çalışıyor)
• mysql_slave_status_slave_sql_running — SQL thread durumu
• mysql_global_status_binlog_cache_disk_use — binlog cache overflow

Replikasyon Hata Senaryoları

Senaryo 1: PRIMARY KEY çakışması

Row-based replikasyonda nadir görülür; ama schema drift varsa (replica'ya yanlışlıkla doğrudan yazma yapılmışsa) oluşabilir. Hata: Duplicate entry 'X' for key 'PRIMARY'.

-- GTID ile: hatalı transaction'ı boş commit ile atla
-- (SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; GTID modunda YASAK)
SET GTID_NEXT = 'source_uuid:hatalı_transaction_no';
BEGIN; COMMIT;              -- boş transaction ile GTID "uygulanmış" sayılır
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA;

Position-based modda (GTID kapalı):

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;  -- sadece 1 event atla
START SLAVE;

Uyarı: SQL_SLAVE_SKIP_COUNTER veri tutarsızlığına yol açabilir. Tek çözüm hatanın köküne inmek ve replica'yı master ile senkronize etmektir.

Senaryo 2: Schema drift

Replica'da DDL değişikliği yapılmışsa (ALTER TABLE farklı uygulanmış gibi) binlog event'leri uygulanamaz. Çözüm: replica'yı durdurup master dump'ından yeniden başlatmak.

Senaryo 3: GTID uyumsuzluğu

Master'da GTID varken replica'da yoksa (veya tersi): gtid_mode aynı yapılandırılmadan geçiş yapılırsa oluşur. MySQL 5.7.6+ online GTID enable/disable destekler ama sıralı geçiş gerektirir (OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON).

Senaryo 4: Binlog corruption

Disk veya ağ hatası sonucu oluşabilir. mysqlbinlog --verify-binlog-checksum mysql-bin.XXXXXX ile doğrulanır. Checkpoint öncesi bir binary log'dan replica sıfırlanır.

Failover Stratejisi

Manuel failover:

-- 1. Replica üzerinde replikasyonu durdur
STOP REPLICA;

-- 2. Read-only'yi kaldır
SET GLOBAL read_only    = OFF;
SET GLOBAL super_read_only = OFF;

-- 3. Bağlantıları yeni master'a yönlendir (DNS veya load balancer)
RESET REPLICA ALL;   -- Eski master bilgisini sil

Orchestrator: GitHub tarafından geliştirilen açık kaynak failover ve topoloji yönetim aracı. GTID ve binlog position tabanlı replikasyon topluluklarını haritalar, otomatik failover yapar. Web arayüzü ve REST API sunar.

MariaDB MaxScale: ProxySQL'e benzer; read/write split, connection pooling ve replikasyon farkında otomatik failover sağlar. MariaDB Galera ile birlikte en çok kullanılan araçtır.

MHA (Master High Availability Manager): Eski ama hâlâ kullanılan Perl tabanlı araç. GTID ile birlikte kullanımda bazı sınırlamalar var; Orchestrator tercih edilir.

Split-brain riski: Otomatik failover'da iki sunucu aynı anda master olduğunu zannedebilir. STONITH (Shoot The Other Node In The Head) mekanizması veya fencing ile önlenir. Basit kurulumlar için manuel failover + izleme alarmı tercih edilebilir.

ProxySQL ile Read/Write Split

ProxySQL, MySQL/MariaDB kümesinin önüne oturan bir proxy'dir; bağlantı havuzu ve sorgu yönlendirme sağlar.

# Ubuntu'da kurulum
wget https://github.com/sysown/proxysql/releases/download/v2.5.5/proxysql_2.5.5-ubuntu22_amd64.deb
dpkg -i proxysql_2.5.5-ubuntu22_amd64.deb
systemctl start proxysql

-- ProxySQL yönetim arayüzü (port 6032)
-- mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt='ProxySQL Admin> '

-- 1. Backend sunucuları ekle
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
  (1, '192.168.1.10', 3306),   -- hostgroup 1 = yazma (master)
  (2, '192.168.1.11', 3306),   -- hostgroup 2 = okuma (replica)
  (2, '192.168.1.12', 3306);   -- ikinci replica

-- 2. Replikasyon monitor kullanıcısı
UPDATE global_variables
  SET variable_value = 'monitor'
  WHERE variable_name = 'mysql-monitor_username';
UPDATE global_variables
  SET variable_value = 'monitor_şifre'
  WHERE variable_name = 'mysql-monitor_password';

-- 3. Sorgu kuralları: sadece SELECT → replica (hostgroup 2)
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
  VALUES (1, 1, '^SELECT', 2, 1);

-- 4. Uygulama kullanıcısı
INSERT INTO mysql_users (username, password, default_hostgroup)
  VALUES ('uygulama_user', 'uygulama_şifre', 1);   -- varsayılan: yazma

-- 5. Değişiklikleri uygula
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

Uygulama artık ProxySQL portuna (6033) bağlanır. SELECT sorguları otomatik olarak replica(lar)a, INSERT/UPDATE/DELETE ve BEGIN transaction'ları master'a yönlendirilir. Replica eklenip çıkarılması uygulamaya şeffaftır.

ProxySQL izleme:

-- Hangi sunucuya kaç sorgu gitti?
SELECT hostgroup, srv_host, Queries, Bytes_data_sent
FROM stats_mysql_connection_pool;

-- Geciktirilen veya hatalı sorgular
SELECT * FROM stats_mysql_query_digest
ORDER BY sum_time DESC LIMIT 10;

Buyukweb VDS Perspektifi

Buyukweb VDS (KVM + NVMe SSD, Bursa Tier 3 lokasyon) ile MySQL/MariaDB replikasyon senaryoları:

2 VDS arası replikasyon: İki VDS'i Buyukweb özel ağı veya WireGuard VPN üzerinden bağlayın. Bursa tek DC içinde latency 0,1-0,5 ms seviyesinde olduğundan asenkron replikasyon rahatlıkla çalışır. Semi-senkron replikasyon için de yeterli.

Multi-region: Buyukweb şu an tek lokasyon (Bursa) sunar; farklı fiziksel DC'ye replikasyon için dedicated planlama veya harici lokasyon gereklidir. VDS planlarıyla multi-region replikasyon mümkün değildir.

cPanel hosting'te replikasyon: Paylaşımlı MySQL kullanılır, root yetkisi yoktur. GRANT REPLICATION SLAVE yetkisini veremezsiniz; CHANGE MASTER TO çalıştırılamaz. cPanel hosting'te master-slave replikasyon kurulumu yapılamaz. Replikasyona ihtiyaç duyuyorsanız VDS geçişi şarttır.

Yönetilen veritabanı hizmeti: Buyukweb şu an yönetilen (managed) MySQL/MariaDB hizmeti sunmamaktadır. Replikasyon kurulumu ve bakımı size aittir; Buyukweb teknik destek ekibi (0850 302 60 70) VDS altyapısı konularında yardımcı olur, veritabanı katmanı yönetimi müşteri sorumluluğundadır.

Sıkça Sorulan Sorular

Asenkron mu, semi-senkron mu seçmeliyim?

Çoğu web uygulaması için asenkron yeterlidir. Master çöktüğünde birkaç transaction kaybolabileceğini tolere edebildiğiniz sürece — ki bu genellikle saniyeden azdır — asenkron daha iyi performans verir. Para işlemleri, sipariş kaydı gibi sıfır veri kaybı istenen sistemlerde semi-senkron tercih edin. Tam senkron istiyorsanız Galera gerekir.

GTID zorunlu mu?

Zorunlu değil ama yeni kurulumlar için şiddetle tavsiye edilir. Position-based replikasyonda failover el işlemiyle yapılır ve yanlış position girmek replikasyonu bozar. GTID ile failover otomatikleştirilebilir (Orchestrator gibi araçlarla); hata riski önemli ölçüde düşer.

ProxySQL olmadan okuma yükü dağıtılabilir mi?

Evet — uygulama katmanında iki farklı veritabanı bağlantısı tanımlayabilirsiniz: biri yazma (master), biri okuma (replica). Laravel, Django, Rails gibi framework'ler bu yapıyı native destekler. Ama bu yöntemi tercih ederseniz replica ekleme/çıkarma uygulama konfigürasyonu değiştirir. ProxySQL bu karmaşıklığı uygulama katmanından kaldırır.

Replikasyon yedek yerine geçer mi?

Hayır. Replikasyon bir veritabanı kopyasıdır, yedek değildir. Master'da yanlışlıkla DROP TABLE yapılırsa bu işlem replica'ya da replike edilir. Gerçek yedekleme için replica üzerinde düzenli mysqldump veya mariabackup alın; bu hem production'ı etkilemez hem de true backup sağlar.

MariaDB Galera mi, asenkron replikasyon mu?

İkisi farklı ihtiyaçlara yanıt verir. Galera: çok-lokasyonlu yazma, sıfır veri kaybı garantisi, otomatik failover — ama 3+ node şart, WAN üzerinde latency yüksek. Asenkron replikasyon: kurulumu basit, tek master + bir veya daha fazla replica, okuma ölçekleme odaklı. Buyukweb VDS üzerinde başlangıç için asenkron genellikle daha pratik; ihtiyaç büyüdüğünde Galera'ya geçilebilir.

Binlog ne kadar saklanmalı?

binlog_expire_logs_seconds = 604800 (7 gün) standart bir değerdir. Replica'nın en fazla kaç gün geride kalabileceğini düşünün; bu sürenin en az iki katı kadar binlog saklayın. Uzun retention disk kullanımını artırır; NVMe SSD'de 100 GB binlog tampon gerçekçidir. Çok kısa tutarsanız replica'yı sıfırdan kurmanız gerekebilir.

---

Veritabanı replikasyonu, doğru kurulduğunda okuma kapasitesini doğrusal olarak artıran ve yüksek erişilebilirlik temeli kuran bir altyapı bileşenidir. GTID ile modern kurulum, ProxySQL ile uygulama şeffaflığı ve pt-heartbeat ile gerçek lag izleme — bu üçü bir arada production-grade bir replikasyon yapısı oluşturur.

Teknik destek için: 0850 302 60 70 veya iletişim sayfamız.

İlgili Büyükweb Hizmetleri

Veritabanı replikasyonu ve yüksek erişilebilirlik için Türkiye lokasyonlu sunucu paketlerimiz:

• VDS Sunucu — root yetkili, MySQL/MariaDB replikasyon kurulabilir
• E5 v4 İşlemcili VDS — NVMe SSD, yüksek IOPS, veritabanı yoğun iş yükleri
• Fiziksel Dedicated — Tam kontrol, üretim sınıfı veritabanı altyapısı
• cPanel Web Hosting — MariaDB 10.6 LTS, paylaşımlı (replikasyon yok)

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.