MariaDB MaxScale ile Yük Dengeleme Rehberi

Veritabanı katmanında yük dengeleme konusu, çoğu sysadmin’in “bunu sonra hallederiz” diyerek ertelediği ama prodüksiyon’da bir patlama yaşandıktan sonra aceleyle çözmeye çalıştığı konuların başında gelir. MariaDB MaxScale tam olarak bu sorunu çözmek için tasarlanmış, akıllı bir veritabanı proxy’si. Sadece bağlantıları dağıtmakla kalmıyor; sorgu tipine göre yönlendirme yapıyor, failover’ı otomatik hallediyor ve bütün bunları uygulama katmanından tamamen soyutlayarak yapıyor. Bu yazıda MaxScale’i sıfırdan kuracak, gerçek dünya senaryolarında nasıl yapılandırılacağını görecek ve prodüksiyona taşımadan önce bilmeniz gereken kritik detayları ele alacağız.

MaxScale Nedir ve Neden Kullanmalısınız?

MaxScale, MariaDB tarafından geliştirilen bir veritabanı proxy ve yük dengeleyicisidir. HAProxy gibi genel amaçlı yük dengeleyicilerden farkı, SQL’i anlıyor olması. Yani gelen bir sorgunun SELECT mi yoksa INSERT mi olduğunu anlayıp buna göre yönlendirme yapabiliyor.

Klasik bir Master-Slave kurulumunda yaşanan en büyük problem şu: Uygulamanız tek bir bağlantı noktasına bağlıdır ve slave sunucularınız büyük ihtimalle boş boş bekler. MaxScale bu sorunu çözerek:

Read/Write Splitting: SELECT sorgularını slave’lere, yazma sorgularını master’a gönderiyor
Otomatik Failover: Master düşerse bir slave’i otomatik olarak master’a terfi ettiriyor
Connection Pooling: Binlerce uygulama bağlantısını az sayıda gerçek veritabanı bağlantısına düşürüyor
Query Routing: Belirli şartlara göre sorguları farklı sunuculara yönlendiriyor
Monitoring: Sunucu sağlığını sürekli kontrol edip devre dışı olanları otomatik olarak dışarıda bırakıyor

Bütün bunları uygulama kodunuza tek bir satır dokunmadan yapabiliyor olmanız, MaxScale’i gerçekten güçlü kılıyor.

Kurulum Ortamının Hazırlanması

Bu yazıda şu topolojiyi kullanacağız:

db-master (192.168.1.10): MariaDB Master sunucu
db-slave1 (192.168.1.11): MariaDB Slave sunucu
db-slave2 (192.168.1.12): MariaDB Slave sunucu
maxscale (192.168.1.20): MaxScale proxy sunucu

Önce MaxScale sunucusunda kurulumu gerçekleştirelim. MariaDB’nin resmi repo’sunu eklememiz gerekiyor:

# MariaDB repo anahtarını ekle
curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

# MaxScale'i kur
sudo apt-get update
sudo apt-get install maxscale -y

# Servis durumunu kontrol et
sudo systemctl status maxscale

# MaxScale versiyonunu doğrula
maxscale --version

RPM tabanlı sistemler için:

# CentOS/RHEL için
sudo yum install maxscale -y

# RHEL 8/Rocky Linux için
sudo dnf install maxscale -y

MariaDB Sunucularında MaxScale Kullanıcısı Oluşturma

MaxScale’in çalışabilmesi için veritabanı sunucularında özel yetkilerle oluşturulmuş kullanıcılara ihtiyaç var. Bu kullanıcılar iki farklı amaçla kullanılıyor: biri izleme (monitoring), diğeri kullanıcı bilgilerini sorgulamak için.

Master sunucuda aşağıdaki işlemleri yapıyoruz:

-- MaxScale monitoring kullanıcısı
CREATE USER 'maxscale_monitor'@'192.168.1.20' IDENTIFIED BY 'Guclu_Sifre_1234!';
GRANT REPLICATION CLIENT ON *.* TO 'maxscale_monitor'@'192.168.1.20';
GRANT SHOW DATABASES ON *.* TO 'maxscale_monitor'@'192.168.1.20';

-- MaxScale router kullanıcısı (kullanıcı yetkilerini sorgular)
CREATE USER 'maxscale_router'@'192.168.1.20' IDENTIFIED BY 'Baska_Guclu_Sifre!';
GRANT SELECT ON mysql.* TO 'maxscale_router'@'192.168.1.20';
GRANT SHOW DATABASES ON *.* TO 'maxscale_router'@'192.168.1.20';

-- Değişikliklerin slave'lere replike olduğunu doğrula
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'maxscale_monitor'@'192.168.1.20';

Eğer MaxScale için bağlantı havuzu kullanacaksanız, maxscale_router kullanıcısının ek yetkilere ihtiyacı olabilir. MariaDB versiyonuna göre bu değişebilir, bu yüzden her zaman dokümantasyonu kontrol edin.

MaxScale Yapılandırma Dosyası

MaxScale’in ana yapılandırma dosyası /etc/maxscale.cnf konumunda bulunur. Bu dosyanın yapısını anlamak çok önemli çünkü her şey burada tanımlanıyor. Dosya mantıksal bloklara ayrılmış: sunucular, izleyiciler, servisler ve dinleyiciler.

sudo cp /etc/maxscale.cnf /etc/maxscale.cnf.backup
sudo nano /etc/maxscale.cnf

Temel bir yapılandırma dosyası şu şekilde görünüyor:

[maxscale]
# MaxScale global ayarları
threads=auto
log_augmentation=1
admin_host=127.0.0.1
admin_port=8989
admin_secure_gui=false

# Sunucu tanımlamaları
[db-master]
type=server
address=192.168.1.10
port=3306
protocol=MariaDBBackend

[db-slave1]
type=server
address=192.168.1.11
port=3306
protocol=MariaDBBackend

[db-slave2]
type=server
address=192.168.1.12
port=3306
protocol=MariaDBBackend

# Monitor konfigürasyonu - Sunucu sağlığını izler
[MariaDB-Monitor]
type=monitor
module=mariadbmon
servers=db-master,db-slave1,db-slave2
user=maxscale_monitor
password=Guclu_Sifre_1234!
monitor_interval=2000ms
auto_failover=true
auto_rejoin=true
enforce_read_only_slaves=true

# Read/Write Splitting servisi
[ReadWrite-Service]
type=service
router=readwritesplit
servers=db-master,db-slave1,db-slave2
user=maxscale_router
password=Baska_Guclu_Sifre!
max_slave_connections=100%
transaction_replay=true
transaction_replay_max_size=1Mi
causal_reads=true

# Listener - Uygulamanın bağlandığı nokta
[ReadWrite-Listener]
type=listener
service=ReadWrite-Service
protocol=MariaDBClient
port=4006

# Round-robin servisi (sadece okuma için)
[ReadOnly-Service]
type=service
router=readconnroute
servers=db-slave1,db-slave2
user=maxscale_router
password=Baska_Guclu_Sifre!
router_options=slave

[ReadOnly-Listener]
type=listener
service=ReadOnly-Service
protocol=MariaDBClient
port=4008

Yapılandırmayı uygulamadan önce syntax kontrolü yapalım:

# Yapılandırma dosyasını test et
maxscale --config-check /etc/maxscale.cnf

# MaxScale'i başlat
sudo systemctl start maxscale
sudo systemctl enable maxscale

# Log dosyasını izle
sudo tail -f /var/log/maxscale/maxscale.log

MaxScale REST API ile Yönetim

MaxScale’in güzel özelliklerinden biri kapsamlı bir REST API sunması. maxctrl komutu bu API’yi kullanarak size tam yönetim imkanı sağlıyor:

# Tüm sunucu durumlarını gör
maxctrl list servers

# Servisleri listele
maxctrl list services

# Monitor durumunu kontrol et
maxctrl list monitors

# Belirli bir sunucunun detaylı durumu
maxctrl show server db-master

# Aktif oturumları listele
maxctrl list sessions

# Sunucuyu bakım moduna al (bağlantı kabul etmez)
maxctrl set server db-slave1 maintenance

# Bakım modundan çıkar
maxctrl clear server db-slave1 maintenance

Prodüksiyonda bir slave sunucusunu bakıma almak istediğinizde akış şu şekilde olmalı: önce maintenance moduna alırsınız, mevcut bağlantıların kapanmasını beklersiniz, işlemi yaparsınız, sonra maintenance modunu kaldırırsınız. Bu sayede mevcut işlemleri kesmeden temiz bir bakım penceresi açabilirsiniz.

Gerçek Dünya Senaryosu: E-Ticaret Uygulaması

Bir e-ticaret sitesi için tipik senaryoya bakalım. Bu tip uygulamalarda okuma/yazma oranı genellikle 80/20 civarındadır. Ürün listeleme, arama, kullanıcı profili görüntüleme gibi işlemler okuma yoğunluklu; sipariş oluşturma, stok güncelleme, ödeme işlemleri ise yazma yoğunluklu.

MaxScale ile transaction bazlı yönlendirme yapılandırması:

[ECommerce-Service]
type=service
router=readwritesplit
servers=db-master,db-slave1,db-slave2
user=maxscale_router
password=Baska_Guclu_Sifre!

# Slave'lerin ne kadar geride kalabileceği (saniye)
max_slave_replication_lag=5

# Transaction replay - ağ kesintilerinde işlemi yeniden dene
transaction_replay=true
transaction_replay_max_size=1Mi
transaction_replay_timeout=30s

# Okuma sonrası tutarlılık garantisi
causal_reads=local
causal_reads_timeout=10s

# Bağlantı havuzu ayarları
connection_keepalive=300s
max_connections=1000

# Slave seçim stratejisi
slave_selection_criteria=LEAST_CURRENT_OPERATIONS

Bu yapılandırmada causal_reads=local ayarı kritik önem taşıyor. Bir kullanıcı sipariş verdiğinde, hemen ardından “siparişlerim” sayfasına gittiğinde o siparişi görebilmesi gerekiyor. causal_reads bu tutarlılığı session bazında garanti ediyor.

Otomatik Failover Yapılandırması

MaxScale’in en güçlü özelliklerinden biri de mariadbmon modülü ile gelen otomatik failover. Bu modül sürekli olarak sunucuları izliyor ve master düşerse otomatik olarak bir slave’i master’a terfi ettiriyor.

# Failover durumunu test etmek için önce master'ı simüle olarak durdur
# (Production'da bunu yapmayın!)
ssh [email protected] "systemctl stop mariadb"

# MaxScale loglarını izle - failover sürecini göreceksiniz
sudo tail -f /var/log/maxscale/maxscale.log | grep -E "failover|ERROR|WARNING|promoting"

# Yeni master'ı kontrol et
maxctrl list servers

# Eski master geri geldiğinde otomatik olarak slave olarak eklenmeli
ssh [email protected] "systemctl start mariadb"
maxctrl list servers

auto_rejoin=true ayarı sayesinde eski master geri döndüğünde MaxScale onu otomatik olarak yeni master’ın slave’i yapıyor. Bu ayarı dikkatli kullanın çünkü split-brain senaryolarında veri kaybına yol açabilir. Kritik uygulamalarda auto_failover ve auto_rejoin ayarlarını kapalı bırakıp failover’ı manuel olarak yönetmek daha güvenli olabilir.

Bağlantı Havuzu Optimizasyonu

MaxScale’in connection pooling özelliği, yüzlerce hatta binlerce uygulama bağlantısını çok daha az sayıda gerçek veritabanı bağlantısına indirgeyebilir. Bu özellikle PHP tabanlı uygulamalarda muazzam bir performans artışı sağlar çünkü PHP her istek için yeni bağlantı açar.

[Connection-Pool-Service]
type=service
router=readwritesplit
servers=db-master,db-slave1,db-slave2
user=maxscale_router
password=Baska_Guclu_Sifre!

# Connection pooling için idle_session_pool_size
idle_session_pool_size=10

# Havuzdaki bağlantıların ne kadar süre yaşayacağı
connection_keepalive=120s

# Maksimum bağlantı sayısı
max_connections=500

# Her sunucuya maksimum bağlantı
max_slave_connections=50

Bağlantı havuzunun etkinliğini ölçmek için MaxScale istatistiklerini takip edin:

# Servis istatistiklerini görüntüle
maxctrl show service ReadWrite-Service

# Tüm istatistikleri JSON formatında al
maxctrl --json show service ReadWrite-Service | python3 -m json.tool

# Bağlantı sayısını izlemek için basit bir script
watch -n 5 'maxctrl list servers --tsv | awk "{print $1, $4, $5}"'

SSL/TLS ile Güvenli Bağlantı

Prodüksiyon ortamında MaxScale ile veritabanı sunucuları arasındaki trafiği şifrelemek zorundasınız. İşte SSL yapılandırması:

[db-master]
type=server
address=192.168.1.10
port=3306
protocol=MariaDBBackend
ssl=true
ssl_cert=/etc/maxscale/certs/client-cert.pem
ssl_key=/etc/maxscale/certs/client-key.pem
ssl_ca_cert=/etc/maxscale/certs/ca-cert.pem
ssl_verify_peer_certificate=true

[ReadWrite-Listener]
type=listener
service=ReadWrite-Service
protocol=MariaDBClient
port=4006
ssl=true
ssl_cert=/etc/maxscale/certs/server-cert.pem
ssl_key=/etc/maxscale/certs/server-key.pem
ssl_ca_cert=/etc/maxscale/certs/ca-cert.pem

Sertifikaları oluştururken dikkatli olun. Common Name (CN) değeri sunucu IP adresi veya hostname ile eşleşmeli. Aksi halde ssl_verify_peer_certificate=true ayarıyla bağlantı reddedilir.

Monitoring ve Alerting Entegrasyonu

MaxScale REST API’si sayesinde Prometheus ile entegrasyon oldukça kolay. MaxScale 2.5 ve üzeri versiyonlarda built-in Prometheus metrik desteği geliyor:

# maxscale.cnf içinde Prometheus endpoint'ini aktif et
# [maxscale] bölümüne ekleyin:
# admin_host=0.0.0.0
# admin_port=8989

# Metriklere erişim testi
curl -u admin:mariadb http://localhost:8989/metrics

# Temel sağlık kontrolü scripti
cat > /usr/local/bin/maxscale-healthcheck.sh << 'EOF'
#!/bin/bash
MASTER_COUNT=$(maxctrl list servers --tsv | grep "Master" | wc -l)
if [ "$MASTER_COUNT" -ne 1 ]; then
    echo "CRITICAL: Master sunucu sayisi: $MASTER_COUNT"
    # Buraya alert mekanizmanizi ekleyin
    # Örnek: curl -X POST slack_webhook_url -d '{"text":"MaxScale ALERT: Master problemi!"}'
    exit 2
fi

SLAVE_COUNT=$(maxctrl list servers --tsv | grep "Slave" | wc -l)
if [ "$SLAVE_COUNT" -lt 1 ]; then
    echo "WARNING: Slave sunucu yok!"
    exit 1
fi

echo "OK: 1 Master, $SLAVE_COUNT Slave aktif"
exit 0
EOF

chmod +x /usr/local/bin/maxscale-healthcheck.sh

# Cron ile her dakika kontrol et
echo "*/1 * * * * root /usr/local/bin/maxscale-healthcheck.sh >> /var/log/maxscale-health.log 2>&1" >> /etc/crontab

Sık Karşılaşılan Sorunlar ve Çözümleri

Sorun 1: Slave Lag ve Dirty Read

MaxScale slave’lerin geride kalmasını max_slave_replication_lag ile kontrol eder. Ama bazen bu yetmez. Kritik okumalar için hint kullanabilirsiniz:

-- Bu sorguyu her zaman master'dan oku
SELECT /* maxscale route to master */ * FROM orders WHERE id = 12345;

-- Bu sorguyu slave'lerden oku (varsayılan davranış zaten bu)
SELECT /* maxscale route to slave */ * FROM products WHERE category_id = 5;

Sorun 2: MaxScale İzin Hataları

Çok sık karşılaşılan bir problem. Log’da “Access denied” görüyorsanız:

# MaxScale log seviyesini debug'a al
maxctrl alter maxscale log_debug true

# Kullanıcı yetkilerini kontrol et
maxctrl show dbusers ReadWrite-Service

# MariaDB tarafında yetkileri doğrula
mysql -h 192.168.1.10 -u maxscale_router -p -e "SHOW GRANTS;"

Sorun 3: Yapılandırma Değişikliklerini Canlıya Alma

# MaxScale'i yeniden başlatmadan yapılandırmayı yenile
# (Tüm parametreler dinamik değil, dikkatli olun)
maxctrl reload maxscale

# Alternatif olarak graceful restart
sudo systemctl reload maxscale

Yük Testi ve Performans Doğrulaması

Prodüksiyona geçmeden önce mutlaka yük testi yapın. mysqlslap ile basit bir test:

# MaxScale üzerinden yük testi
mysqlslap 
    --host=192.168.1.20 
    --port=4006 
    --user=testuser 
    --password=testpass 
    --concurrency=50 
    --iterations=100 
    --create-schema=loadtest 
    --auto-generate-sql 
    --auto-generate-sql-load-type=mixed 
    --auto-generate-sql-write-number=100 
    --auto-generate-sql-secondary-indexes=2 
    --number-of-queries=10000 
    --verbose

# Sonuçları karşılaştırmak için direkt bağlantı testi
mysqlslap 
    --host=192.168.1.10 
    --port=3306 
    --user=testuser 
    --password=testpass 
    --concurrency=50 
    --iterations=100 
    --auto-generate-sql 
    --number-of-queries=10000 
    --verbose

Yük testi sırasında MaxScale istatistiklerini ve sunucu dağılımını izleyin. Beklentiniz şu olmalı: okuma sorgularının büyük çoğunluğu slave’lere yönlenmeli, yazma sorguları ise yüzde yüz master’a gitmeli.

Sonuç

MaxScale, MariaDB ekosisteminde gerçekten production-grade bir çözüm. Basit bir yük dengeleyicinin çok ötesinde: SQL’i anlayan, failover’ı otomatik yöneten, bağlantı havuzunu akıllıca kullanan ve tüm bunları uygulama katmanından soyutlayan bir araç.

Kurulumda dikkat etmeniz gereken birkaç kritik nokta var. İzleme kullanıcısının yetkileri eksik olursa monitor modülü çalışmaz ve failover tetiklenmez. Replication lag ayarları çok sıkı tutulursa MaxScale tüm slave’leri devre dışı bırakabilir, çok gevşek tutulursa stale data okursunuz. auto_failover ve auto_rejoin ayarlarını üretim ortamına geçmeden önce staging’de iyice test edin.

Gerçek kazanımlar konuşmak gerekirse: okuma/yazma bölünmesi ile slave sunucularınızı aktif olarak kullanmaya başladığınızda master’ınızdaki yük dramatik biçimde düşer. Connection pooling ile binlerce PHP bağlantısını onlarca gerçek bağlantıya indirgediğinizde veritabanı sunucularınızın nefes aldığını göreceksiniz. Otomatik failover ile gece 3’te telefona koşmak yerine sabah log’lara bakıp “aa failover olmuş, düzelmiş” diyebilirsiniz.

MaxScale ücretsiz Community Edition ile başlayabilirsiniz, ama enterprise özellikler için (gelişmiş güvenlik filtreleri, performans şeması entegrasyonu vb.) lisanslı versiyona ihtiyacınız olacak. Çoğu küçük ve orta ölçekli deployment için Community Edition fazlasıyla yeterli.

MariaDB MaxScale ile Yük Dengeleme ve Yüksek Erişilebilirlik