MySQL'de çoğaltma (replication), veritabanı işlemlerinin bir kaynak (master) sunucusundan bir veya daha fazla yineleyici (replica) sunucuya kopyalanması işlemidir. Semi-Synchronous (Yarı Eşzamanlı) Replication, MySQL'in güvenilirlik ve veri bütünlüğü arasında kritik bir denge kuran bir çoğaltma yöntemidir. Bu mekanizma, geleneksel asenkron çoğaltma ile teorik tam senkron çoğaltma arasında bir ara katman olarak işlev görür.
Temel mantığı, bir işlemin (transaction) kaynak sunucuda tamamlanabilmesi için en az bir yineleyici sunucunun bu işlemi aldığını ve kendi relay log'una yazdığını onaylamasını beklemektir. Bu onay gelene kadar, işlemi başlatan istemciye başarılı yanıtı dndürmede bir gecikme yaşanır. Bu bekleme, verinin en az iki düğümde (kaynak ve bir yineleyici) fiziksel olarak güvence altına alındığı anlamına gelir. Böylece, kaynak sunucuda oluşabilecek ani bir arıza durumunda, en son işlemlerin kaybolma riski büyük ölçüde azaltılır. Bu prensip, veri kaybına karşı sıfır tolerans gerektiren finansal sistemler veya işlem kayıtlarının kritik olduğu uygulamalar için hayati önem taşır.
Async ve Semi-Sync Karşılaştırması
MySQL'in varsayılan çoğaltma modu olan Asenkron Replication'da, kaynak sunucu bir işlemi tamamladıktan sonra, işlemin yineleyicilere ulaşıp ulaşmadığına bakmaksızın istemciye başarı yanıtını hemen gönderir. Çoğaltma, arka planda ve potansiyel olarak gecikmeli bir şekilde gerçekleşir. Bu model yüksek performans sunar, ancak kaynak sunucu arızalandığında, henüz yineleyiciye gönderilmemiş veya uygulanmamış işlemlerin kaybolması riski vardır. Bu, bir veri tutarsızlığı ve kaybı senaryosudur.
Semi-Sync Replication ise bu iki uç model arasındaki boşluğu doldurur. Performanstan küçük bir ödün vererek veri güvenliğini artırır. İstemciye yanıt dönülmeden önce bir onay mekanizması devreye girer. Bu iki model arasındaki temel farklar, aşağıdaki karşılaştırmalı tabloda net bir şekilde görülebilir. Her iki modelin de farklı kullanım senaryoları ve trade-off'ları bulunmaktadır.
| Karşılaştırma Kriteri | Asenkron Çoğaltma | Semi-Senkron Çoğaltma |
|---|---|---|
| Veri Güvenliği | Düşük. Veri kaybı riski vardır. | Yüksek. Veri kaybı riski minimize edilir. |
| Performans (Gecikme) | Yüksek. İstemciye anında yanıt verilir. | Orta. En az bir yineleyiciden onay beklenir. |
| Kullanım Amacı | Ölçeklendirme, yük dengeleme, yedekleme. | Veri bütünlüğü ve yüksek kullanılabilirlik. |
| Yapılandırma Karmaşıklığı | Basit. Varsayılan ayardır. | Göreceli olarak daha karmaşıktır. |
| Tolerans Senaryosu | Performans önceliklidir. | Veri tutarlılığı önceliklidir. |
Sonuç olarak, Semi-Sync modu, veri kaybı riskini kabul edilemez bulan ancak tam senkron modun getireceği ağır performans cezasını da göze alamayan sistemler için tasarlanmıştır. Performans ve güvenlik dengesi burada en önemli karar faktörüdür. Sistem mimarları, uygulamanın veri tutarlılığı gereksinimlerini ve kabul edilebilir gecikme sürelerini değerlendirerek hangi çoğaltma modunun uygun olduğuna karar vermelidir.
- Asenkron: "Yaz ve unut" mantığı. Hız önceliklidir.
- Semi-Senkron: "Yaz ve en az bir onay bekle" mantığı. Denge önceliklidir.
- Tam Senkron: "Yaz ve tüm onayları bekle" mantığı. Güvenlik mutlak önceliktir (MySQL'de varsayılan olarak yoktur).
Çalışma Mekanizması ve Aşamaları
Semi-Sync Replication'ın çalışma döngüsü, bir işlemin kaynak sunucudan yineleyiciye güvenli bir şekilde aktarılmasını garanti eden net adımlardan oluşur. Bu mekanizma, MySQL eklentisi (`rpl_semi_sync_master`) tarafından yönetilir ve çekirdek çoğaltma işlevselliğiyle entegre çalışır. Süreç, basit bir "gönder ve onayla" protokolünden daha karmaşıktır ve zaman aşımları ile geri dönüş mekanizmalarını içerir.
İlk aşama, kaynak sunucuda bir işlemin tamamlanmasıyla başlar. İşlem, kaynağın binary log'una yazılır. Semi-sync modu aktifse, kaynak sunucu bu işlemi yineleyicilere gönderir ve ardından, istemciye COMMIT onayını döndürmeden önce bir onay beklmeye geçer. Bu bekleme durumu, performans üzerinde doğrudan etki yaratır. Eğer herhangi bir yineleyici, işlemi alıp kendi relay log'una başarıyla kaydettiğine dair bir ACK (onay) sinyali gönderirse, kaynak sunucu beklemeden çıkar ve istemciye başarı yanıtını verir.
Kritik bir nokta, timeout (zaman aşımı) süresidir. `rpl_semi_sync_master_timeout` parametresi ile yapılandırılan bu süre (varsayılan 10 saniye), kaynak sunucunun bir yineleyiciden onay bekleyeceği maksimum süreyi belirler. Bu süre içinde onay gelmezse, semi-sync modu geçici olarak devre dışı kalır ve kaynak, standart asenkron çoğaltma moduna geri döner. Bu esneklik, bir yineleyici sunucunun arızalanması veya ağ sorunları nedeniyle tüm sistemin kilitlenmesini engeller. Yineleyici tekrar çevrimiçi olduğunda ve gecikme makul bir seviyeye indiğinde, sistem otomatik olarak tekrar semi-sync moduna geçiş yapabilir.
- 1. Adım (Gönderim): İşlem kaynak binary log'una yazılır ve yineleyicilere gönderilir.
- 2. Adım (Bekleme): Kaynak, en az bir yineleyiciden (ACK) onayı bekler.
- 3. Adım (Başarılı Onay): ACK alındığında, işlem istemciye onaylanır.
- 4. Adım (Zaman Aşımı): ACK zaman aşımına uğrarsa, sistem asenkron moda geçer.
Bu mekanizmanın bir diğer önemli varyasyonu, MySQL 5.7'den itibaren gelen Loss-less Semi-Synchronous Replication'dır. Bu gelişmiş modda, onay mekanizması daha da güçlendirilmiştir. Klasik semi-sync'te ACK, işlemin yineleyicinin relay log'una yazılmasından sonra gönderilirken, loss-less modda ACK, işlemin yineleyicinin disk tabanlı relay log'una (durable storage) yazıldıktan sonra gönderilir. Bu ince fark, yineleyici sunucunun da RAM'deki veriyi kaybetmesi durumunda dahi verinin korunmasını sağlayarak güvenliği bir üst seviyeye taşır.
Yapılandırma ve Kurulum Adımları
MySQL Semi-Sync Replication'ı etkinleştirmek, hem kaynak (master) hem de yineleyici (replica) sunucularda plugin'lerin yüklenmesini ve belirli sistem değişkenlerinin ayarlanmasını gerektirir. Temel asenkron çoğaltmanın zaten kurulu ve çalışır durumda olduğu varsayılarak, semi-sync'e geçiş adımları sistematik bir şekilde takip edilmelidir. Yapılandırma, dinamik değişkenler üzerinden gerçekleştirilebilir, bu da sunucuyu yeniden başlatmaya gerek kalmadan değişiklik yapılabilmesini sağlar.
İlk adım, gerekli plugin'leri yüklemektir. Plugin'lerin adları MySQL sürümüne göre değişiklik gösterebilir (örneğin, `rpl_semi_sync_source` ve `rpl_semi_sync_replica` gibi). Aşağıda, kaynak sunucuda semi-sync plugin'inin nasıl yükleneceğine dair bir SQL komut örneği verilmiştir. Yineleyici tarafında da benzer bir plugin yüklemesi yapılmalıdır.
-- KAYNAK SUNUCUDA (Master)
-- Semi-sync master plugin'ini yükle
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
-- Plugin'in yüklendiğini kontrol et
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE '%semi_sync%';
-- Semi-sync'i global olarak etkinleştir
SET GLOBAL rpl_semi_sync_master_enabled = ON;
-- Timeout süresini örneğin 1 saniye olarak ayarla (varsayılan 10000 ms)
SET GLOBAL rpl_semi_sync_master_timeout = 1000;
-- YİNELEYİCİ SUNUCUDA (Slave)
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled = ON;
-- Plugin etkinleştirildikten sonra, çoğaltma IO_THREAD'ini yeniden başlatmak gerekir.
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
Plugin'ler yüklendikten ve değişkenler ayarlandıktan sonra, kurulumun başarılı olup olmadığını doğrulamak esastır. Kaynak sunucuda `SHOW STATUS` komutu ile semi-sync ile ilgili istatistikler sorgulanabilir. `Rpl_semi_sync_master_status` değişkeninin değeri `ON` olmalıdır. Ayrıca, `Rpl_semi_sync_master_yes_tx` (onay alan işlem sayısı) ve `Rpl_semi_sync_master_no_tx` (zaman aşımına uğrayan işlem sayısı) gibi istatistikler, sistemin semi-sync modunda ne sıklıkla çalıştığını ve zaman aşımlarının olup olmadığını gösterir.
Kalıcılık sağlamak için, bu dinamik değişken ayarlarının sunucunun yapılandırma dosyasına (`my.cnf` veya `my.ini`) eklenmesi şiddetle tavsiye edilir. Aksi takdirde, sunucu yeniden başlatıldığında tüm ayarlar sıfırlanacak ve semi-sync devre dışı kalacaktır. Yapılandırma dosyasına eklenecek satırlar aşağıdaki gibidir. Bu adım, üretim ortamında sürekliliği garanti altına almak için kritiktir.
- Kaynak Sunucu my.cnf:
`[mysqld]`
`plugin-load="rpl_semi_sync_master=semisync_master.so"`
`rpl-semi-sync-master-enabled=1`
`rpl-semi-sync-master-timeout=1000` - Yineleyici Sunucu my.cnf:
`[mysqld]`
`plugin-load="rpl_semi_sync_slave=semisync_slave.so"`
`rpl-semi-sync-slave-enabled=1`
Avantajları ve Dezavantajları
Semi-Sync Replication'ın benimsenmesi, geleneksel asenkron çoğaltmaya kıyasla önemli faydalar sunar, ancak bunlar belirli maliyetler ve trade-off'lar karşılığında gelir. Sistem mimarlarının, bu teknolojiyi uygulamaya karar vermeden önce artılarını ve eksilerini detaylı bir şekilde tartması gerekir. Her iki tarafın da dengeli bir şekilde değerlendirilmesi, uzun vadede kararlı ve performanslı bir veritabanı altyapısının anahtarıdır.
En büyük avantajı, veri kaybı riskinin ciddi oranda azaltılmasıdır. Kaynak sunucuda meydana gelebilecek beklenmedik bir donanım arızası veya çökme durumunda, henüz yineleyicilere ulaşmamış işlemler kaybolabilir. Semi-sync, her başarılı işlem için en az bir yineleyicide fiziksel olarak kayıt altına alındığı garantisini vererek bu pencereyi neredeyse kapatır. Bu, finansl işlem kayıtları, sipariş onayları veya kullanıcı verileri gibi kritik verilerin korunması için vazgeçilmez bir özelliktir. İkinci önemli avantaj, yüksek kullanılabilirlik (high availability) stratejilerinin temelini güçlendirmesidir. Veri kaybı riski düşük olduğundan, bir yineleyici sunucuya yapılacak failover (aktarım) işlemi çok daha güvenli ve temiz bir şekilde gerçekleştirilebilir.
Ancak, bu güvenlik artışı bazı dezavantajları da beraberinde getirir. En belirgin olanı performans üzerindeki olumsuz etkidir. Her işlem için ağ üzerinden bir onay (ACK) paketi beklenmesi, doğal olarak gecikmeye (latency) neden olur. Bu gecikmenin miktarı, kaynak ile yineleyici arasındaki ağ gecikmesi (RTT - Round Trip Time) ile doğru orantılıdır. Coğrafi olarak dağıtılmış mimarilerde, bu gecikme yüzlerce milisaniyeye ulaşabilir ve uygulamanın genel yanıt sürelerini kabul edilemez seviyelere çıkarabilir. Ayrıca, kaynak sunucunun işlem gücünün bir kısmı, onayları yönetmek ve zaman aşımlarını izlemek için harcanır.
Bir diğer önemli dezavantaj ise kullanılabilirlik (availability) ile ilgilidir. Zaman aşımı mekanizması esneklik sağlasa da, eğer tek yineleyici arızalanır veya ağ bağlantısı tamamen koparsa ve timeout süresi aşılırsa, sistem otomatik olarak asenkron moda düşer. Bu süre zarfında, veri kaybı riski tekrar ortaya çıkar. Ayrıca, sadece bir yineleyiciden onay alındığı için, çoğunluk tabanlı karar mekanizmaları (çoklu yineleyici onayı gerektiren) bu modda kullanılamaz. Bu nedenle, semi-sync kullanırken güvenilir bir ağ altyapısı ve sağlam yineleyici sunucular kritik önem taşır.
- Artılar: Gelişmiş veri güvenliği, daha güvenilir failover, basit bir yapılandırma ile yüksek kazanç.
- Eksiler: Artan işlem gecikmesi (latency), ağ veya yineleyici bağımlılığı, tek noktadan gelen onayın sınırlığı.
Performans ve Kullanım Senaryoları
Semi-Sync Replication'ın performans etkisi, uygulamanın doğasına ve altyapı mimarisine bağlı olarak değişkenlik gösterir. Yazma yoğunluklu iş yükleri bu gecikmeden en çok etkilenir. Örneğin, saniyede binlerce küçük işlem gerçekleştiren bir sistemde, her işlem için eklenen 1-10 milisaniyelik gecikme, toplam iş hacminde (throughput) gözle görülür bir düşüşe neden olabilir. Okuma yoğunluklu sistemler ise, yazma performansındaki bu küçük düşüşten genellikle çok etkilenmezler. Performansı optimize etmek için, `rpl_semi_sync_master_timeout` değeri dikkatlice ayarlanmalıdır. Çok düşük bir değer, sık sık asenkron moda düşülmesine ve semi-sync faydasının kaybolmasına yol açarken, çok yüksek bir değer ise uygulamanın bir yineleyici arızasında uzun süre bloke olmasına neden olabilir.
Bu teknoloji, her senaryo için uygun değildir, ancak belirli kullanım durumlarında altın standart haline gelmiştir. Finans teknolojisi (FinTech) uygulamaları, para transferi veya borsa işlemleri gibi her işlemin mutlak kaydının tutulması gereken alanlarda semi-sync neredeyse zorunludur. E-ticaret platformlarında, müşteri sipariş onayı veya ödeme işlemi tamamlama gibi aşamalarda kullanılabilir; böylece bir arıza anında sipariş kaybı yaşanmaz. Ayrıca, düzenleyici kurumların sıkı veri koruma ve denetim izi (audit trail) gerekliliklerini karşılamak isteyen şirketler için değerli bir araçtır.
Coğrafi olarak yakın veri merkezleri arasında kurulan çoğaltma bağlantılarında semi-sync çok etkilidir, çünkü düşük ağ gecikmesi performans cezasını minimize eder. Buna karşılık, yüksek gecikmeli WAN bağlantıları üzerinden çalıştırılması önerilmez. Bu gibi durumlarda, daha gelişmiş çoğaltma topolojileri (gruplu çoğaltma - Group Replication) veya uygulama katmanında veri senkronizasyon stratejileri daha uygun olabilir. Sistem tasarımcıları, semi-sync'in sağladığı güvence seviyesinin, getirdiği karmaşıklık ve maliyetle orantılı olup olmadığını değerlendirmelidir.
Sık Karşılaşılan Sorunlar ve Çözümleri
Semi-Sync Replication üretim ortamında kullanılırken, yapılandırma hataları, ağ sorunları veya kaynak-yineleyici uyumsuzlukları nedeniyle çeşitli sorunlarla karşılaşılabilir. Bu sorunları proaktif bir şekilde tanımak ve çözmek, sistemin güvenilirliğini ve veri bütünlüğünü korumak açısından hayati öneme sahiptir. Sorun giderme süreci genellikle MySQL durum değişkenlerinin izlenmesi ve hata loglarının dikkatlice incelenmesiyle başlar.
En yaygın sorunlardan biri, Semi-Sync'in sürekli olarak asenkron moda düşmesidir. Bu durum, genellikle `Rpl_semi_sync_master_no_tx` istatistiğinin sürekli artmasıyla tespit edilir. Bunun ana nedeni, `rpl_semi_sync_master_timeout` değerinin, kaynak ile yineleyici arasındaki normal ağ gecikmesi ve yineleyicinin iş yükü için çok düşük ayarlanmış olmasıdır. Çözüm olarak, öncelikle ağ bağlantısının sağlığı ve yineleyici sunucudaki gecikme nedenleri (yavaş disk, yüksek CPU kullanımı) araştırılmalıdır. Ardından, timeout değeri kademeli olarak artırılabilir. Ancak, bu değerin aşırı yükseltilmesi, bir yineleyici arızasında uygulamanın uzun süre bloke olma riskini artıracağından dikkatli olunmalıdır.
Bir diğer kritik sorun, yineleyici sunucuda semi-sync plugin'inin etkinleştirilememesi veya çoğaltma iş parçacıklarının (IO_THREAD) başlatılamamasıdır. Bu durumda, MySQL hata logunda "Failed to enable semi-sync replication on slave" veya benzeri hatalar görülebilir. Bu sorunun kök nedenleri arasında plugin'in doğru şekilde yüklenmemesi, MySQL versiyon uyumsuzluğu veya binary log formatının (`binlog_format`) ROW veya MIXED dışında bir değere ayarlanmış olması sayılabilir. Çözüm, plugin yükleme komutlarının doğruluğunu teyit etmek, tüm sunucuların uyumlu MySQL sürümlerine yükseltilmesini sağlamak ve `binlog_format` ayarını kontrol etmektir. ROW tabanlı log formatı, semi-sync ile en iyi uyumluluğu sağlar.
Ağ paket kayıpları veya yüksek gecikme, ACK onaylarının düzensiz gelmesine veya hiç gelmemesine neden olabilir. Bu da periyodik zaman aşımlarına ve performans düşüşüne yol açar. Bu tür bir sorundan şüphelenildiğinde, kaynak ve yineleyici arasında sürekli bir ağ izleme ve ping/iperf gibi araçlarla gecikme testleri yapılmalıdır. Yüksek kullanılabilirlik gerektiren sistemlerde, kaynak ve yineleyiciyi aynı veri merkezi içinde veya çok düşük gecikmeli bağlantıya sahip veri merkezleri arasında konumlandırmak en iyi uygulamadır. Ayrıca, tek bir yineleyicinin onayına bağlı kalmamak için, birden fazla yineleyiciyi semi-sync için yapılandırmak ve `rpl_semi_sync_master_wait_for_slave_count` değişkenini kullanarak gereken minimum onay sayısını ayarlamak daha sağlam bir çözüm sunabilir.
Son olarak, performans sorunları yaşandığında, sorunun semi-sync'ten mi yoksa genel veritabanı yükünden mi kaynaklandığını ayırt etmek gerekir. `SHOW PROCESSLIST` komutu ile uzun süren işlemler incelenebilir ve yavaş sorgu logları analiz edilebilir. Eğer gecikme doğrudan semi-sync onay beklemesinden kaynaklanıyorsa, alternatif yüksek kullanılabilirlik çözümleri değerlendirilebilir. Örneğin, MySQL Group Replication veya InnoDB Cluster, çoğunluk onayı (consensus) temelli, yerleşik otomatik failover özellikli ve genellikle daha iyi yazma ölçeklenebilirliği sunan alternatifler olabilir. Ancak, bu çözümlerin getirdiği ek karmaşıklık ve kaynak gereksinimleri de dikkate alınmalıdır.