MaxScale ile MySQL Önüne Akıllı Proxy

· Cem Karadağ · 4 dk okuma · MySQL , MaxScale , MariaDB , Proxy , Yüksek Erişilebilirlik

Selamlar, bu yazımda MariaDB MaxScale'e bir göz atalım. MySQL veya MariaDB ile bir replikasyon kurmuşsanız, eninde sonunda 'şimdi okumaları replica'lara nasıl yollarım, primary düşünce kim bayrağı devralacak?' sorusuyla karşılaşıyorsunuz. HAProxy gibi katman 4 yük dengeleyiciler MySQL protokolünü anlamadığı için bu işi yarım yapıyor. MaxScale tam olarak bu boşluğa yerleşen, protokolü gerçekten anlayan bir veritabanı proxy'si.

MaxScale nedir, ne yapar?

Kısaca, MariaDB Corporation'ın geliştirdiği bir database proxy. Önüne aldığı MySQL veya MariaDB cluster'ının topolojisini gerçekten biliyor, sorguları parse edebiliyor, hangi sorgunun nereye gideceğine SELECT mi UPDATE mi olduğuna bakarak karar verebiliyor. Yani uygulamanız tek bir endpoint'e bağlanıyor; MaxScale arkada sizin yerinize 'bu okuma replica-2'ye gitsin, bu transaction primary'de çalışsın' diyebiliyor.

İçindeki en kritik üç parça şunlar:

  • readwritesplit router: SELECT'leri replica'lara, yazmaları primary'ye yönlendiriyor. Açık transaction varsa onu primary'de tutuyor.
  • mariadbmon monitor modülü: 2 saniyede bir sunuculara dokunuyor, replikasyonun durumunu izliyor, primary düşerse auto_failover=true ile yeni primary seçiyor.
  • Filter sistemi: Sorguyu loglama, yeniden yazma, throttling gibi işleri tak-çalıştır eklenti olarak ekliyorsunuz.

Tipik bir konfig nasıl görünüyor?

/etc/maxscale.cnf dosyasından konuşuyor. Şu şekilde basit bir kurulum:

[maxscale]
threads=auto

[primary]
type=server
address=10.0.1.10
port=3306
protocol=MariaDBBackend

[replica-1]
type=server
address=10.0.1.11
port=3306
protocol=MariaDBBackend

[replication-monitor]
type=monitor
module=mariadbmon
servers=primary,replica-1
user=mxs_monitor
password=monitorpass
monitor_interval=2000ms
auto_failover=true
auto_rejoin=true

[rw-split-service]
type=service
router=readwritesplit
servers=primary,replica-1
user=mxs_router
password=routerpass
master_failure_mode=fail_on_write
transaction_replay=true

[rw-split-listener]
type=listener
service=rw-split-service
protocol=MariaDBClient
port=3306

Buradaki transaction_replay=true benim severek kullandığım bir şey: primary düşüp failover olduğunda, açık ama henüz commit edilmemiş transaction'ları yeni primary'de tekrar oynatmayı deniyor. Tabii her senaryoda kurtaramıyor, ama uygulamanın Lost connection hatasıyla karşılaşma sıklığını gözle görülür şekilde azaltıyor.

Monitor ve router için backend'de iki ayrı kullanıcı tanımlamanız gerekiyor:

CREATE USER 'mxs_monitor'@'%' IDENTIFIED BY 'monitorpass';
GRANT REPLICATION CLIENT, RELOAD, PROCESS ON *.* TO 'mxs_monitor'@'%';

CREATE USER 'mxs_router'@'%' IDENTIFIED BY 'routerpass';
GRANT SELECT ON mysql.* TO 'mxs_router'@'%';
GRANT SHOW DATABASES ON *.* TO 'mxs_router'@'%';

Yönetimi için maxctrl CLI'si ve REST API var. Mesela bir replica'yı bakım için trafikten almak istediğinizde:

maxctrl set server replica-1 drain
maxctrl list servers

drain mevcut bağlantıların bitmesini bekleyip yeni bağlantı vermiyor. Bakım sonrası clear server replica-1 drain ile geri alıyorsunuz.

ProxySQL ile karşılaştırması ve lisans meselesi

Aklınıza gelen soru muhtemelen şu: 'ProxySQL varken neden MaxScale?'. Şahsi kanaatim, bu seçim çoğunlukla ekosisteme ve operasyonel tercihlere göre değişiyor:

  • ProxySQL, runtime'da SQL ile ayarlanıyor, GPL lisanslı ve özellikle saf MySQL dünyasında çok yaygın. Connection pooling ve query rewrite konusunda esnek.
  • MaxScale, dosya tabanlı konfig kullanıyor, MariaDB ve Galera farkındalığı ile geliyor, monitor + failover işini kutudan çıkar çıkmaz yapıyor. Ama 2.5'ten sonra BSL (Business Source License) lisansına geçti; ticari production kullanımı için sınırlamalar getiriyor, dört yıl sonra GPL'e dönüyor. Hukuk ekibinizin onaylaması gereken bir nokta.

Yani MariaDB ve replikasyon farkındalığı sizin için kritikse, MaxScale'in kutudan çıkan failover'ı çok kıymetli. Ama saf MySQL ile uğraşıyorsanız ve lisans zorlukları istemiyorsanız ProxySQL daha rahat bir tercih.

Sık karşılaşılan tuzaklar

  • Tek node için MaxScale kurmak: Tek primary varsa MaxScale'in size kazandıracağı somut bir şey yok. Bir katman daha eklemiş, gecikme yaratmış olursunuz. Anlamlı olması için en az bir replica şart.
  • auto_failover=true ile replikasyon kullanıcısını eksik bırakmak: Failover sırasında MaxScale yeni primary'yi seçtikten sonra eski primary'yi auto_rejoin ile geri çağırırken replication_user bilgisine ihtiyacı var. Boş bırakırsanız failover sonrası eski node yetim kalıyor.
  • Monitor user'a SUPER vermeyi unutmak: Bazı sürümlerde failover sırasında SET GLOBAL read_only çağrıları için bu yetki gerekiyor. Eksikse monitor düşmüyor ama failover sessizce başarısız oluyor.
  • MaxScale'i tek instance olarak çalıştırmak: Proxy'nin kendisi tek nokta hatasına dönüşüyor. En azından iki MaxScale + keepalived ya da bir TCP yük dengeleyici önerilir.

Kapanış

MaxScale, MySQL veya MariaDB önüne protokolü anlayan bir akıllı katman koymak istediğinizde ciddi bir aday. Bence çoğu küçük projede gereksiz; ama bir replica'nız varsa ve okuma yükünü dağıtmak, primary düşünce kimsenin elle müdahale etmesini istemiyorsanız, yatırdığınız zamanın karşılığını veriyor. Lisans tarafına dikkat, monitor kullanıcısının yetkilerini eksiksiz verin, gerisi konfigle çözülen bir mesele. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.