MySQL/MariaDB için coğrafi yedeklilik ve felaket kurtarma

Veri merkezinde bir yangın, uzun süreli bir enerji ya da ağ kesintisi, bir deprem… Tek lokasyonda çalışan bir veritabanı için bunların her biri saatlerce süren bir kesinti ve geri getirilemeyen veri demektir. Klasik çözüm, yedekleri ya da replikasyonu ikinci bir veri merkezine, yani felaket kurtarma merkezine (DRC) taşımaktır. Ancak felaket anında DRC’yi devreye almak çoğu zaman elle yapılan, dakikalar hatta saatler süren ve son işlemlerin kaybolabildiği bir süreçtir.

Mono olarak MySQL ve MariaDB veritabanlarını MariaDB Galera Cluster ile birden fazla veri merkezine yayıyoruz. Her lokasyonda verinin güncel bir kopyası bulunuyor, bir lokasyon tamamen kaybedildiğinde küme veri kaybetmeden ve elle müdahale gerektirmeden çalışmaya devam ediyor. Bu yazıda bu yapıyı nasıl kurduğumuzu, işletirken nelere dikkat ettiğimizi ve hizmetimizin neleri kapsadığını anlatıyoruz.

Klasik DRC mi, coğrafi dağıtık küme mi?

Tablodaki “veri kaybı yok”, commit edilmiş işlemler için geçerlidir: Galera bir işlemi ancak tüm lokasyonlara ulaştıktan sonra onaylar. Coğrafi dağıtık küme yedeğin yerini tutmaz; hatalı bir DELETE‘e karşı yedek yine gereklidir (aşağıda anlatıyoruz). Ama veri merkezi kaybı senaryosunda, felaket kurtarmayı “planlanmış bir operasyon” olmaktan çıkarıp altyapının kendiliğinden yaptığı bir şeye dönüştürür.

Kimler için?

• Kesintinin doğrudan gelir kaybı olduğu sistemler: e-ticaret, ödeme, poliçe ve hasar sistemleri, çağrı merkezi uygulamaları.
• Düzenlemeye tabi kurumlar: finans, sigorta, enerji ve kamu kurumları; iş sürekliliği ve ikincil merkez gerekliliklerini karşılarken verinin yurt içinde kalması gereken yapılar.
• DRC’si olan ama hiç tatbikat yapamayanlar: felaket kurtarma planı kâğıt üzerinde olan, gerçek bir kesintide çalışıp çalışmayacağından emin olamayan ekipler.
• Tek veritabanı sunucusuna bağımlı olanlar: sunucu bakımı, sürüm yükseltme ya da donanım arızasında tüm hizmeti durdurmak zorunda kalan yapılar.

Coğrafi yedekli mimari

   Lokasyon 1             Lokasyon 2             Lokasyon 3
  ┌──────────┐           ┌──────────┐           ┌──────────┐
  │  node-1  │◄─────────►│  node-2  │◄─────────►│  node-3  │
  │ (yazma)  │  S2S VPN  │ (yedek)  │  S2S VPN  │ (yedek)  │
  └────▲─────┘           └────▲─────┘           └────▲─────┘
       │                      │                      │
  ┌────┴─────────┐       ┌────┴─────────┐       ┌────┴─────────┐
  │ Uygulama     │       │ Uygulama     │       │ Uygulama     │
  │  └ ProxySQL  │       │  └ ProxySQL  │       │  └ ProxySQL  │
  │   (sidecar)  │       │   (sidecar)  │       │   (sidecar)  │
  └──────────────┘       └──────────────┘       └──────────────┘

Temel prensiplerimiz:

• Lokasyon başına bir node, tek sayıda lokasyon. Herhangi bir lokasyon kaybedildiğinde kalan iki node çoğunluğu (quorum) korur ve küme yazmaya devam eder.
• Senkron replikasyon. Bir işlem commit edildiğinde tüm lokasyonlara ulaşmış olur; felaket anında “son birkaç dakikanın verisi” diye bir kayıp olmaz.
• Lokasyonlar arası tüm trafik site-to-site (S2S) VPN üzerinden. Veritabanı portları hiçbir zaman internete açılmaz.
• Her uygulamanın yanında ProxySQL. Uygulama veritabanına doğrudan değil, yanındaki ProxySQL üzerinden bağlanır; failover uygulamaya görünmez.
• Tek yazıcı. Tüm node’lar yazabilir ama yazmalar tek node’a yönlendirilir; diğerleri yedek yazıcı ve okuma için kullanılır.

Lokasyon seçenekleri: Mono Cloud, hibrit veya kendi altyapınız

Coğrafi yedekliliğin ilk şartı birbirinden bağımsız lokasyonlardır. Bu lokasyonların nerede olacağı size kalmış; hizmetimiz altyapı sağlayıcısından bağımsız. Üç şekilde çalışıyoruz:

• Mimarinin tamamı Mono Cloud’da: Mono Cloud ANK1, IST1, IST2 ve IZM1 olmak üzere Türkiye’deki dört lokasyonda çalışıyor; verileriniz yurt dışına çıkmıyor. Veritabanı node’ları, uygulama sunucuları ve yedekler farklı Mono Cloud lokasyonlarına dağıtılıyor. Lokasyonlar arası bağlantı, IP planı ve izleme baştan bizim tarafımızda olduğu için kurulum hızlanıyor.
• Hibrit: Kurumun kendi veri merkezleri veya kullandığı bulut sağlayıcıyla birlikte. Mono Cloud lokasyonları eksik olan ikinci/üçüncü lokasyonu, quorum noktasını ya da DRC ayağını tamamlıyor. Kendi veri merkeziniz ve mevcut DRC’niz varsa, Mono Cloud’daki tek bir lokasyonu üçüncü nokta olarak ekleyip mevcut yapıyı otomatik failover yapabilen bir kümeye dönüştürebiliyoruz.
• Tamamen kendi altyapınızda: Kendi veri merkezleriniz, çalıştığınız yerli bulut sağlayıcılar ya da AWS, Google Cloud, Azure gibi global sağlayıcılarda. Tasarım, kurulum, geçiş, izleme ve operasyonu aynı şekilde üstleniyoruz; altyapı sözleşmeleriniz olduğu gibi kalıyor.

Her üç modelde de lokasyonlar arası bağlantı S2S VPN ile kuruluyor.

Uygulamalar kümeye nasıl bağlanır: ProxySQL sidecar

Klasik kurulumda veritabanının önünde ortak bir yük dengeleyici (HAProxy, keepalived ile VIP) durur. Coğrafi dağıtık mimaride bu yaklaşımın iki sorunu var: yük dengeleyici başlı başına bir tek hata noktası (SPOF) olur ve uygulamanın her sorgusu fazladan bir ağ adımı atar, çoğu zaman da başka bir lokasyona gider.

Bu yüzden ProxySQL’i uygulamanın yanında, sidecar olarak çalıştırıyoruz:

• VM’lerde: Her uygulama sunucusuna ProxySQL kuruluyor. Uygulama 127.0.0.1:3306 adresine bağlanıyor; hangi node’a gideceğine ProxySQL karar veriyor.
• Kubernetes’te: ProxySQL uygulamayla aynı cluster’da çalışıyor. Konfigürasyon ConfigMap’ten geliyor, kalıcı diske ihtiyaç duymuyor.

Bu yaklaşımın getirdikleri:

• Ortak bir proxy katmanı yok. Bir uygulama sunucusunun ProxySQL’i düşerse sadece o sunucu etkilenir.
• Felaket anında uygulamaya dokunulmaz. Yazıcı başka lokasyona taşınsa da uygulama hep yerel adrese bağlanır; DNS değişikliği, IP güncellemesi, yeniden deploy gerekmez.
• Bağlantı havuzu (connection pooling) yerelde. Kısa ömürlü bağlantılar ProxySQL’de biter, veritabanına uzun ömürlü ve sayısı kontrollü bağlantılar gider.

Galera’yı tanıyan yönlendirme

ProxySQL, mysql_galera_hostgroups ile node’ların Galera durumunu (wsrep_local_state, read_only, wsrep_desync, recv queue) kendisi izler ve node’ları otomatik olarak trafiğe alır ya da trafikten çıkarır:

-- 0: yazma, 1: okuma, 2: yedek yazıcı, 4: devre dışı
INSERT INTO mysql_galera_hostgroups
  (writer_hostgroup, backup_writer_hostgroup, reader_hostgroup, offline_hostgroup,
   active, max_writers, writer_is_also_reader, max_transactions_behind)
VALUES (0, 2, 1, 4, 1, 1, 1, 100);

-- Ağırlığı en yüksek node yazıcı olur
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES
  (0, 'node-1', 3306, 300),
  (0, 'node-2', 3306, 10),
  (0, 'node-3', 3306, 10);

INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE$', 0, 1),
       (2, 1, '^SELECT', 1, 1);

• max_writers=1: Farklı lokasyonlardan aynı satırlara yazmak çakışmaları ve geri almaları (rollback) artırır. Yazıcı her zaman tektir; yazıcı düşerse sıradaki en yüksek ağırlıklı node yazıcı olur.
• max_transactions_behind=100: Geride kalan node okuma trafiğinden çıkarılır, kullanıcı eski veri görmez.
• Okumalarda her lokasyonun ProxySQL’i kendi lokasyonundaki node’a daha yüksek ağırlık verir, böylece okumalar WAN’a çıkmaz.

Onlarca uygulama sunucusundaki ProxySQL’leri tek tek yönetmek yerine ProxySQL cluster özelliğiyle senkron tutuyoruz; bir ProxySQL’de yapılan değişiklik saniyeler içinde diğerlerine dağılıyor. Lokasyon bazında farklı okuma ağırlıkları kullanıldığında ProxySQL cluster’larını da lokasyon bazında kurguluyoruz.

Bir lokasyon kaybedildiğinde ne olur?

Galera bir bölünmede (partition) çoğunluğu tutan tarafı ayakta bırakır. Azınlıkta kalan taraf non-Primary duruma geçer ve sorgu kabul etmez; böylece iki tarafın birbirinden habersiz yazdığı “split-brain” durumu oluşmaz.

Üç lokasyonlu bir kümede yazıcı node’un bulunduğu lokasyon tamamen düştüğünde:

1. Kalan iki node, kaybolan node’u zaman aşımı sonunda kümeden çıkarır ve 2/3 çoğunlukla çalışmaya devam eder.
2. ProxySQL yazıcının erişilemediğini görür ve en yüksek ağırlıklı sağlam node’u yeni yazıcı yapar.
3. Uygulamalar yerel ProxySQL’e bağlanmaya devam eder; ayar değişikliği gerekmez.
4. Düşen lokasyon geri geldiğinde node, aradaki farkı (IST) alarak kümeye kendiliğinden katılır.

Topoloji seçenekleri:

• 3 lokasyon, 3 node: Bir lokasyon kaybında küme kesintisiz devam eder. Varsayılan önerimiz bu.
• İki veri merkezi + üçüncü lokasyonda hakem: Üçüncü lokasyonda tam bir veritabanı node’u yerine yalnızca oy kullanan hafif bir hakem (Galera Arbitrator) çalıştırılabilir.
• 2 node ana DC + 1 node DR: Ana DC giderse DR node’u azınlıkta kalır ve otomatik devralmaz, elle pc.bootstrap gerekir. Bu tercihi baştan net olarak belgeliyoruz.

Tüm lokasyonların aynı anda birbirini kaybettiği durum için de yazılı bir runbook’umuz var: en güncel seqno‘ya sahip node’u bulmak, grastate.dat içinde safe_to_bootstrap: 1 yapmak, galera_new_cluster ile başlatmak ve diğer node’ları sırayla katmak.

Aynı lokasyonda birden fazla node varsa gmcast.segment ile segment tanımlamak lokasyonlar arası trafiği azaltır. Lokasyon başına tek node olan kümelerde segmentin kazancı sınırlı.

Lokasyonlar arası mesafe ve performans

Senkron replikasyonun bedeli, her commit’in en uzaktaki node’a gidip gelmesini beklemesidir. Commit gecikmesi bu yüzden en uzaktaki node’a olan round-trip süresine (RTT) bağlıdır.

• Node’lar arası RTT 10 ms civarında ise OLTP yüklerinde fark edilir bir yavaşlama olmuyor. Türkiye içindeki lokasyonlar bu sınırın rahatça içinde kalıyor.
• RTT 50 ms ve üzerine çıktığında yoğun yazma yapan işler (toplu aktarım, gece batch’leri) birkaç kat yavaşlayabiliyor.
• Okumalar etkilenmez; yerel node’dan döner.

Bu yüzden lokasyon seçiminde ilk baktığımız şey, lokasyonlar arası gecikme ve hattın kararlılığı.

Ağ hazırlığı

Kurulum takviminin en uzun kısmı genellikle veritabanı değil, ağ bağımlılıklarıdır. Kuruluma başlamadan önce şunları tamamlıyoruz:

Portlar, iki yönde:

Sık gördüğümüz hata: 4567 açık, 4568 kapalı. Node kümeye katılıyor ama durum transferinde Connection refused ile düşüyor.

MTU. VPN tünelleri paket boyutunu düşürür. Küçük sorgular sorunsuz çalışırken büyük transferler zaman aşımına uğrayabilir. ping -M do -s <boyut> ile tünelden geçebilen en büyük paketi bulup tünel yönünde TCP MSS değerini sabitliyoruz:

iptables -t mangle -A POSTROUTING -d <uzak-ağ>/24 -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1398

Hat ölçümü. ping/mtr ile RTT ve paket kaybını, iperf3 ile bant genişliğini ölçüyoruz. Galera zaman aşımları ve veri taşıma planı bu değerlere göre belirleniyor.

Adres planı ve isim çözümleme. Yönetim VPN’leri ile kurum ağlarının adres blokları çakışmamalı. Her node’un kendi adı gerçek IP’ye çözülmeli; /etc/hosts içinde node adının 127.0.0.1‘e işaret etmesi durum transferlerini bozar.

TCP ayarları. WAN üzerinde daha kararlı aktarım için:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_slow_start_after_idle = 0

WAN için Galera ayarları

Varsayılan Galera zaman aşımları tek veri merkezi için tasarlanmıştır. Lokasyonlar arasında birkaç saniyelik bir dalgalanma, node’un gereksiz yere kümeden atılmasına ve uygulamada WSREP has not yet prepared node for application use hatalarına yol açabilir.

Başlangıç profilimiz:

[galera]
wsrep_on               = ON
wsrep_provider         = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_address  = gcomm://node-1,node-2,node-3
wsrep_sst_method       = mariabackup
wsrep_slave_threads    = 4
wsrep_retry_autocommit = 4
binlog_format          = row
innodb_autoinc_lock_mode = 2

wsrep_provider_options = "
  evs.suspect_timeout=PT10S;
  evs.inactive_timeout=PT20S;
  evs.install_timeout=PT15S;
  evs.inactive_check_period=PT1S;
  evs.send_window=1024;
  evs.user_send_window=512;
  gcs.fc_limit=260;
  gcs.fc_factor=1;
  gcs.max_packet_size=2097152;
  gcache.size=2G"

Zaman aşımlarını uzatmanın bir bedeli var: gerçekten çökmüş bir node da daha geç tespit edilir. Felaket anındaki devreye alma süresi ile gereksiz alarm arasındaki dengeyi ölçülen RTT ve paket kaybına göre kuruyoruz; değerleri hazır şablondan kopyalamıyoruz.

Mevcut veritabanınızı taşıma

Çoğu proje sıfırdan değil, tek sunucuda çalışan bir MySQL ya da MariaDB’den başlıyor. Geçişi, uygulamanın kesintisi yalnızca trafiğin yeni kümeye yönlendirildiği kısa pencereyle sınırlı kalacak şekilde planlıyoruz:

• Uyumluluk kontrolü. Galera yalnızca InnoDB tablolarını replike eder; MyISAM tabloları, birincil anahtarı olmayan tablolar ve sürüm farkları baştan envanterleniyor. MySQL’den MariaDB’ye geçişte SQL ve istemci uyumluluğu test ediliyor.
• Yöntemi ölçerek seçme. mysqldump, mariabackup + rsync ve mariabackup --stream seçeneklerini gerçek veri üzerinde deniyoruz. Fiziksel kopya, dump/restore’a göre genellikle birkaç kat hızlı; kaynak ve hedef sürümler uyumsuzsa (örneğin Percona XtraDB → MariaDB) mantıksal yönteme dönüyoruz.
• Yeni lokasyonları mevcut kümeye ekleme. Mevcut bir küme varsa yeni lokasyonlardaki node’ları önce kümeye katıyor, eşitlendikten sonra trafiği taşıyor ve eski node’ları sırayla kapatıyoruz.
• Süreyi önceden hesaplama. Bir node’un ilk eşitlemesi (SST) lokasyonlar arası bant genişliğine bağlıdır; iperf3 ölçümüyle bakım penceresini doğru planlıyoruz. Uzun süren eşitlemelerde systemd zaman aşımı (TimeoutStartSec) ve donör seçimi (wsrep_sst_donor) buna göre ayarlanıyor.

Yedekleme: coğrafi yedeklilik yedeğin yerini tutmaz

Galera bir DROP TABLE‘ı ya da hatalı bir UPDATE‘i milisaniyeler içinde tüm lokasyonlara taşır. Coğrafi dağıtık küme donanım ve lokasyon kaybına karşı korur, veri hatasına ve fidye yazılımına karşı korumaz. Bu yüzden her kümede ayrıca yedek alıyoruz.

Yedekleri kendi geliştirdiğimiz özgür yazılım monodb-backup (GPL-3.0, Go) ile alıyoruz:

• Kümeyi kilitlemeden yedek. mariadb-dump, --single-transaction --skip-lock-tables ile çalışır; global kilit almadığı için yedek sırasında yazmalar durmaz. Routine, trigger ve event’ler de yedeğe dahildir.
• Yazıcı olmayan node’dan. Yedek, yazıcı node yerine yedek node’lardan birinde çalışır; üretim yükü etkilenmez.
• Başka lokasyona. Yedekler S3 uyumlu nesne depolamaya (MinIO, Garage, AWS S3), SFTP veya rsync hedeflerine, istenirse aynı anda birden fazla hedefe gönderilir.
• Şifreleme ve saklama politikası. Yedekler 7z ile şifrelenebilir; günlük, haftalık ve aylık saklama sayıları ayrı ayrı belirlenir.
• Tablo bazında yedek. Büyük veritabanlarında tek bir tabloyu hızlıca geri dönebilmek için tablo bazında yedek alınabilir.
• Bildirim. Her yedeğin sonucu e-posta veya webhook ile bildirilir.

database: mysql
backupAsTables: true
archivePass: <şifreleme-parolası>
rotation:
  enabled: true
  period: week
  suffix: day
  keep:
    daily: 7
    weekly: 4
    monthly: 3
backupType:
  type: minio
  info:
    - endpoint: <başka-lokasyondaki-minio>
      bucket: db-backups
      path: galera
notify:
  webhook:
    enabled: true
    onlyOnError: true

Ürün hakkında daha fazla bilgi için MonoDB Backup sayfasına bakabilirsiniz.

Operasyonda dikkat ettiklerimiz

Felaket kurtarma planlarının çoğu felaket anında değil, sıradan bir günün operasyon hatasında sınanır. Kümelerimizde standart olarak uyguladıklarımız:

Otomatik yeniden başlatmaları kapatın. unattended-upgrades bir kütüphaneyi güncellediğinde needrestart MariaDB’yi yeniden başlatabilir. Bu birden fazla node’da kısa aralıklarla olursa küme quorum’u kaybedebilir. Tüm Galera node’larında:

# /etc/needrestart/conf.d/galera.conf
$nrconf{override_rc}{qr(^mariadb)} = 0;

Event’ler tek node’da. MariaDB event’leri replike olur ve diğer node’larda SLAVESIDE_DISABLED durumuna geçer. Aynı event’i her node’da çalıştırmak deadlock ve sertifikasyon beklemeleri üretir. Event’leri tek node’da aktif tutuyoruz; tutarlılığı monokit kontrol ediyor.

Konfigürasyon her node’da aynı. innodb_strict_mode gibi bir ayarın node’lar arasında farklı olması, aynı DDL’in bir node’da başarılı diğerinde hatalı olmasına ve tutarsız node’un kümeden atılmasına yol açar. Tüm node’ları aynı Ansible/AWX kaynağından yönetiyoruz.

Rolling upgrade. Sürüm yükseltmeleri önce test ortamında, sonra node node yapılıyor; küme yükseltme boyunca hizmet vermeye devam ediyor.

Disk ve kaynak limitleri. İçe aktarma, binlog ve yerel yedekler birleşince disk dolabilir; diski dolan node tüm kümeyi yavaşlatır. Disk alarmları, expire_logs_days ve systemd LimitNPROC gibi limitler kurulumun parçası.

Tatbikat. Felaket kurtarma planı ancak denendiğinde güvenilirdir. Coğrafi dağıtık kümede bir lokasyonu planlı olarak kapatıp failover’ı, geri dönüşü ve uygulama davranışını düzenli olarak doğruluyoruz.

İzleme: monokit mysqlHealth

Kümeleri kendi geliştirdiğimiz izleme aracı monokit ile izliyoruz. monokit’in mysqlHealth bileşeni her node’da dakikalık çalışıyor ve şunları kontrol ediyor:

Bir kontrol eşiği aştığında monokit alarmı webhook ile ekip sohbet kanalına (Zulip, Microsoft Teams) gönderiyor, durum düzeldiğinde de ayrıca bildiriyor. Flow control gibi müdahale gerektiren durumlarda destek sistemimizde otomatik iş kaydı açıp sorun düzeldiğinde kaydı kapatıyor. Sorgu seviyesindeki analizler için PMM kullanıyoruz.

Hizmet kapsamımız

MySQL/MariaDB için coğrafi yedeklilik ve felaket kurtarma projelerinde uçtan uca sorumluluk alıyoruz:

• Keşif ve RTO/RPO analizi: Hangi sistemde ne kadar kesinti ve veri kaybı kabul edilebilir; mevcut yapı, DRC ve düzenleyici gereklilikler.
• Mimari tasarım: Lokasyon seçimi (Mono Cloud, hibrit ya da tamamen kendi veri merkezleriniz ve bulut sağlayıcılarınız), quorum yapısı, ağ ve trafik yönlendirme.
• Ağ kurulumu: Lokasyonlar arası S2S VPN tünelleri, MTU ve güvenlik duvarı ayarları.
• Kurulum ve geçiş: Galera Cluster, ProxySQL sidecar, mevcut veritabanının minimum kesintiyle taşınması.
• Yedekleme: monodb-backup ile başka lokasyona şifreli yedek ve geri dönüş testleri.
• İzleme ve operasyon: monokit ve PMM ile izleme, 7/24 izleme ve müdahale seçenekleri, sürüm yükseltmeleri.
• Tatbikat: Düzenli lokasyon kapatma tatbikatları ve güncel runbook’lar.

Sık sorulan sorular

Felaket kurtarma merkezi (DRC) ile coğrafi dağıtık küme arasındaki fark nedir?

Klasik DRC, felaket anına kadar pasif bekleyen ve genellikle asenkron replikasyonla beslenen ikinci bir merkezdir; devreye alınması elle yapılır ve son işlemler kaybolabilir. Coğrafi dağıtık Galera Cluster’da tüm lokasyonlar aktiftir, replikasyon senkrondur ve bir lokasyon kaybedildiğinde küme otomatik olarak çalışmaya devam eder.

İki veri merkezi yeterli mi?

İki lokasyonlu bir yapıda aradaki bağlantı koptuğunda hangi tarafın yazmaya devam edeceğine güvenle karar verilemez. Otomatik failover için üçüncü bir oy gerekir; bu, üçüncü lokasyonda tam bir node ya da yalnızca oy kullanan hafif bir hakem (Galera Arbitrator) olabilir. Üçüncü lokasyon, çalıştığınız başka bir bulut sağlayıcıda ya da Mono Cloud’da olabilir.

MySQL kullanıyoruz, bu yapıya geçebilir miyiz?

Evet. MySQL kullanan uygulamaların çoğu uyumluluk testinden sonra MariaDB Galera Cluster’a geçebiliyor. MySQL’de kalınması gereken durumlarda aynı Galera altyapısını kullanan Percona XtraDB Cluster da bir seçenek. MySQL ve MariaDB arasındaki farklar için MariaDB / MySQL sayfamıza bakabilirsiniz.

Geçiş sırasında kesinti olur mu?

Yeni node’lar mevcut veritabanıyla eşitlendikten sonra trafik yeni kümeye yönlendirilir. Kesinti, bu yönlendirmenin yapıldığı kısa pencereyle sınırlı kalır ve önceden planlanmış bir bakım zamanına denk getirilir.

Lokasyonlar arası mesafe ne kadar olabilir?

Senkron replikasyon için lokasyonlar arası RTT’nin 10 ms civarında olması idealdir. Türkiye içindeki lokasyonlar bu sınırın içinde kalır. Kıtalar arası mesafelerde senkron yerine asenkron replikasyon tercih edilir.

Mono Cloud kullanmak zorunda mıyız?

Hayır. Kendi veri merkezlerinizde, çalıştığınız yerli veya global bulut sağlayıcılarda ya da bunların karışımında kurulum yapıyor ve işletiyoruz. Mono Cloud’u isterseniz tüm mimari için, isterseniz yalnızca eksik bir lokasyonu tamamlamak için kullanabilirsiniz. Lokasyonlar arası bağlantı her durumda S2S VPN ile sağlanıyor.

MySQL/MariaDB altyapınızı birden fazla lokasyona yaymayı düşünüyorsanız mimarinin tamamını Mono Cloud’un dört lokasyonunda kurabilir, kendi veri merkezlerinizle Mono Cloud’u birlikte kullanan hibrit bir yapı tasarlayabilir ya da tamamen mevcut veri merkezleriniz ve bulut sağlayıcılarınız üzerinde çalışabiliriz. Daha geniş kapsamlı çok bölgeli mimariler için Coğrafi Dağıtık Platform Tasarımı ve Yönetimi hizmetimizi, PostgreSQL tarafı için Patroni yazımızı inceleyebilirsiniz.