MariaDB mi MySQL mi: 2025 Yılında Hangisini Seçmelisiniz

Yazar:komut.io ekibi
0 Yorum

Yıllarca her iki veritabanıyla da çalıştım ve şunu söyleyeyim: bu soru göründüğünden çok daha karmaşık. “MariaDB mi MySQL mi?” diye sorulduğunda çoğu insan beklediğim cevabı veriyor, ama gerçek dünyada kararı veren şey teknik özellikler listesi değil, mevcut altyapınız, ekibinizin alışkanlıkları ve iş gereksinimleriniz. 2025 yılına geldiğimizde iki veritabanı arasındaki makas düşündüğünüzden çok daha açılmış durumda. Gelin bunu gerçekten inceleyelim.

Kısa Tarihçe: Neden İki Farklı Proje Var?

MySQL, Oracle tarafından satın alındıktan sonra topluluk içinde ciddi bir rahatsızlık oluştu. MySQL’in baş mimarı Michael “Monty” Widenius, 2009 yılında MariaDB’yi fork’layarak bağımsız bir yol çizdi. İlk yıllarda iki proje neredeyse aynıydı ve geçiş tamamen transparandı. Bugün durum farklı. Yıllar içinde her iki proje de kendi yolunu çizdi ve artık bazı kritik noktalarda gerçek anlamda farklılaştılar.

Bu tarihçeyi bilmek önemli çünkü “MariaDB MySQL’in fork’u” deyip geçiştirenler, aslında 2019 sonrasında oluşan derin mimari ayrışmaları görmüyor.

Kurulum ve İlk Yapılandırma Karşılaştırması

Başlayalım. Ubuntu 22.04 üzerinde her iki veritabanını kurmak:

# MySQL 8.0 kurulumu
sudo apt update
sudo apt install mysql-server -y
sudo mysql_secure_installation

# MySQL servis durumu
sudo systemctl status mysql
sudo systemctl enable mysql
# MariaDB 10.11 LTS kurulumu
sudo apt install mariadb-server mariadb-client -y
sudo mysql_secure_installation

# MariaDB servis durumu
sudo systemctl status mariadb
sudo systemctl enable mariadb

İlk kurulumdan sonra dikkat etmeniz gereken şey yapılandırma dosyalarının yerleri. MySQL için /etc/mysql/mysql.conf.d/mysqld.cnf, MariaDB için ise /etc/mysql/mariadb.conf.d/50-server.cnf ana yapılandırma dosyasıdır.

# MySQL temel yapılandırma optimizasyonu
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
# MySQL 8.0 için temel production ayarları
[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
max_connections = 500
query_cache_type = 0
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
# MariaDB temel yapılandırma
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
# MariaDB 10.11 için temel production ayarları
[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
max_connections = 500
query_cache_type = 0
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
# MariaDB'ye özgü
aria_pagecache_buffer_size = 256M

Burada aria_pagecache_buffer_size parametresi dikkat çekici. MariaDB kendi geliştirdiği Aria storage engine’i için bu ayarı kullanıyor. MySQL’de böyle bir şey yok.

Gerçek Anlamda Ayrışan Noktalar

Yetkilendirme ve Kimlik Doğrulama

MySQL 8.0’dan itibaren varsayılan kimlik doğrulama eklentisi caching_sha2_password oldu. Bu değişiklik başlangıçta ciddi uyumluluk sorunlarına neden oldu. Eski PHP sürümleri, bazı ORM kütüphaneleri ve legacy uygulamalar bu eklentiyle düzgün çalışamıyordu.

# MySQL'de kullanıcı oluşturma ve eski uyumluluk
CREATE USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'guclu_sifre_2025';
GRANT ALL PRIVILEGES ON uygulama_db.* TO 'appuser'@'%';
FLUSH PRIVILEGES;

# Mevcut kullanıcının plugin'ini kontrol et
SELECT user, host, plugin FROM mysql.user;

MariaDB bu konuda daha geleneksel bir yol izledi ve mysql_native_password varsayılan olarak kaldı. Yeni projeler için bu bir avantaj mı dezavantaj mı tartışılabilir, ama legacy sistemlerle uğraşan sysadminler için MariaDB daha az baş ağrısı anlamına geliyor.

JSON Desteği: Beklentileri Düzeltelim

MySQL’in JSON desteği MariaDB’den gerçekten daha olgundu. MySQL 8.0, JSON’ı birinci sınıf veri tipi olarak destekliyor, indeksleyebiliyorsunuz ve JSON_TABLE() gibi güçlü fonksiyonlar var.

MariaDB 10.2’den itibaren JSON desteği eklendi ama uzun süre ikinci sınıf bir vatandaş gibi kaldı. Son sürümlerde bu fark kapandı ancak MySQL hâlâ öne çıkıyor.

-- MySQL'de JSON kullanımı
CREATE TABLE siparisler (
    id INT AUTO_INCREMENT PRIMARY KEY,
    musteri_id INT,
    ekstra_bilgi JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO siparisler (musteri_id, ekstra_bilgi)
VALUES (1, '{"kargo_tipi": "hizli", "not": "dikkatli paket"}');

-- JSON path ile sorgulama
SELECT musteri_id,
       JSON_UNQUOTE(JSON_EXTRACT(ekstra_bilgi, '$.kargo_tipi')) AS kargo
FROM siparisler
WHERE JSON_EXTRACT(ekstra_bilgi, '$.kargo_tipi') = 'hizli';

Galera Cluster: MariaDB’nin Güçlü Yanı

Eğer yüksek erişilebilirlik (HA) kuruyorsanız ve multi-master replication istiyorsanız, MariaDB Galera Cluster bu konuda daha olgun ve yaygın kullanılan çözüm.

# MariaDB Galera Cluster kurulumu (node 1)
sudo apt install mariadb-server galera-4 -y

# /etc/mysql/mariadb.conf.d/60-galera.cnf
sudo tee /etc/mysql/mariadb.conf.d/60-galera.cnf > /dev/null <<EOF
[galera]
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "production_cluster"
wsrep_cluster_address = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12"
wsrep_node_name = "node1"
wsrep_node_address = "192.168.1.10"
wsrep_sst_method = rsync
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
EOF

# İlk node'u başlatmak için
sudo galera_new_cluster

MySQL’de buna eşdeğer çözüm için InnoDB Cluster ve MySQL Router kombinasyonuna ihtiyaç duyuyorsunuz. Bu da ekstra kurulum ve öğrenme eğrisi anlamına geliyor.

Performans: Mitler ve Gerçekler

“MariaDB MySQL’den daha hızlı” ya da tersi şeklindeki kesin ifadeler yanlış. Performans farkı gerçekten iş yüküne göre değişiyor.

MariaDB’nin query optimizer’ı bazı karmaşık JOIN senaryolarında MySQL’den daha iyi sonuçlar üretebilir. Öte yandan MySQL 8.0’ın hash join implementasyonu bazı analitik sorgularda MariaDB’yi geride bırakıyor.

# Her iki sistemde sorgu planını inceleme
EXPLAIN FORMAT=JSON SELECT
    m.musteri_adi,
    COUNT(s.id) AS siparis_sayisi,
    SUM(s.tutar) AS toplam_tutar
FROM musteriler m
LEFT JOIN siparisler s ON m.id = s.musteri_id
WHERE s.created_at >= '2024-01-01'
GROUP BY m.id, m.musteri_adi
HAVING toplam_tutar > 10000
ORDER BY toplam_tutar DESC;

Gerçek bir benchmark yapmak istiyorsanız sysbench kullanın:

# sysbench kurulumu
sudo apt install sysbench -y

# Test veritabanı hazırlama
sysbench /usr/share/sysbench/oltp_read_write.lua 
  --mysql-host=localhost 
  --mysql-user=root 
  --mysql-password=sifreniz 
  --mysql-db=sbtest 
  --db-driver=mysql 
  --tables=10 
  --table-size=100000 
  prepare

# Testi çalıştırma (60 saniye)
sysbench /usr/share/sysbench/oltp_read_write.lua 
  --mysql-host=localhost 
  --mysql-user=root 
  --mysql-password=sifreniz 
  --mysql-db=sbtest 
  --db-driver=mysql 
  --tables=10 
  --table-size=100000 
  --threads=16 
  --time=60 
  run

Kendi altyapınızda bu testi çalıştırın. Genel internet benchmark’larına güvenmeyin çünkü donanım, OS tuning ve network konfigürasyonu sonuçları dramatik şekilde etkiliyor.

Uygulama Uyumluluğu: Dikkat Edilmesi Gerekenler

Burası kritik. MariaDB, MySQL uyumlu olduğunu söylüyor ve büyük ölçüde doğru. Ama 2025 itibarıyla bazı noktalarda MySQL bağımlısı olan uygulamalar var.

Oracle MySQL Cloud Service ile entegrasyon: AWS RDS MySQL, Google Cloud SQL, Azure Database for MySQL gibi yönetilen servisleri kullanıyorsanız ve bunların özgün MySQL davranışına ihtiyacınız varsa doğrudan MySQL tercih edin.

WordPress, Drupal, Laravel gibi yaygın framework’ler: Her ikisiyle de mükemmel çalışıyor. Burada fark yok.

Özel Oracle araçları: Oracle’ın kendi ekosistemi elbette MySQL’i öncelikli destekliyor.

# MySQL'den MariaDB'ye geçiş: mysqldump yöntemi
# Kaynak MySQL sunucusundan dump al
mysqldump -h kaynak_sunucu 
  -u root -p 
  --all-databases 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  > full_dump_$(date +%Y%m%d).sql

# MariaDB'ye import
mysql -h hedef_sunucu 
  -u root -p 
  < full_dump_$(date +%Y%m%d).sql

# Geçiş sonrası doğrulama
mysqlcheck -h hedef_sunucu -u root -p --all-databases

Geçiş yaparken mutlaka mysql_upgrade çalıştırmayı unutmayın ve sistem tablolarını kontrol edin. Özellikle caching_sha2_password ile oluşturulmuş kullanıcılar MariaDB’ye geçince sorun çıkarabilir.

2025’te Ekosistem ve Destek Durumu

Lisanslama

MySQL ikili lisans modeli kullanıyor: GPL ve ticari lisans. Eğer MySQL’i ticari bir kapalı kaynak uygulamada kullanıyorsanız Oracle’dan ticari lisans almanız gerekebilir. MariaDB’nin community versiyonu tamamen GPL ve ticari kullanımda lisans sorunu çıkarmıyor.

Ama bir nüans var: MariaDB Corporation da kurumsal özellikler için ücretli enterprise lisans sunuyor. Açık kaynak versiyonu bu özelliklerden yoksun.

Topluluk ve Geliştirme Hızı

MariaDB topluluk odaklı geliştirme yapıyor ve yeni özellikler MySQL’e kıyasla daha hızlı geliyor. Window functions, common table expressions (CTE) gibi özellikler MariaDB’ye önce geldi.

Öte yandan MySQL’in arkasında Oracle’ın mühendislik kaynakları var ve özellikle InnoDB geliştirmesi güçlü devam ediyor.

Dağıtım Desteği

# Desteklenen sürümleri kontrol etme
# MariaDB LTS sürümleri (2025 itibarıyla aktif)
# 10.11 LTS - 2028'e kadar destekli
# 11.4 LTS - 2029'a kadar destekli

# MySQL aktif sürümleri
# 8.0 - 2026 EOL
# 8.4 LTS - 2032'ye kadar destekli
# 9.x - Innovation serisi (production için dikkatli olun)

# Sürüm kontrol
mysql --version
mariadb --version

Debian/Ubuntu resmi depolarında MariaDB bulunurken MySQL için Oracle’ın kendi deposunu eklemeniz gerekiyor. Kurumsal ortamlarda ekstra depo eklemek bazen politika sorunlarına yol açabiliyor. Bu küçük ama gerçek bir pratik fark.

Hangi Senaryo İçin Hangisi?

Benim gözlemlerime göre şu şekilde düşünebilirsiniz:

MariaDB’yi tercih edin eğer:

  • Yüksek erişilebilirlik için Galera Cluster kuracaksanız
  • Oracle’dan bağımsız, topluluk odaklı bir çözüm istiyorsanız
  • Mevcut MySQL 5.7 altyapınızdan daha sorunsuz geçiş yapmak istiyorsanız
  • Bütçe kısıtınız var ve açık kaynak ekosistemi yeterliyse
  • RHEL/CentOS/Rocky Linux gibi dağıtımlarda resmi depo desteğini önemsiyorsanız

MySQL’i tercih edin eğer:

  • AWS RDS, Google Cloud SQL gibi yönetilen servisleri kullanacaksanız
  • Oracle ekosistemiyle entegrasyonunuz varsa
  • JSON tabanlı yoğun iş yükü çalıştırıyorsanız
  • Gelişmiş InnoDB özelliklerine ihtiyaç duyuyorsanız
  • Uygulamanızın MySQL sertifikasyonu varsa (bazı enterprise yazılımlar bunu şart koşuyor)

Monitoring ve Bakım

Her iki veritabanı için de benzer monitoring araçları kullanabilirsiniz. Prometheus + Grafana kombinasyonu ikisi için de mükemmel çalışıyor:

# MySQL Exporter kurulumu (her iki DB için kullanılabilir)
wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.15.1/mysqld_exporter-0.15.1.linux-amd64.tar.gz
tar xvf mysqld_exporter-0.15.1.linux-amd64.tar.gz
sudo mv mysqld_exporter-0.15.1.linux-amd64/mysqld_exporter /usr/local/bin/

# Monitoring kullanıcısı oluştur
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'izleme_sifresi' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

# Exporter yapılandırması
sudo tee /etc/mysqld_exporter.cnf > /dev/null <<EOF
[client]
user=exporter
password=izleme_sifresi
EOF

# Systemd servisi
sudo tee /etc/systemd/system/mysqld_exporter.service > /dev/null <<EOF
[Unit]
Description=MySQL Exporter
After=network.target

[Service]
User=prometheus
ExecStart=/usr/local/bin/mysqld_exporter 
  --config.my-cnf=/etc/mysqld_exporter.cnf 
  --collect.global_status 
  --collect.global_variables 
  --collect.slave_status 
  --collect.info_schema.processlist 
  --web.listen-address=:9104

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now mysqld_exporter

Sonuç

Şunu net söylemek gerekiyor: 2025 yılında bu iki veritabanı arasında “genel olarak daha iyi” diye bir cevap yok. Ama bazı pratik öneriler verebilirim.

Eğer sıfırdan bir proje kuruyorsanız ve belirli bir bağımlılığınız yoksa, altyapı yönetimi kolaylığı, Galera desteği ve topluluk odaklı geliştirme nedeniyle MariaDB 11.4 LTS iyi bir başlangıç noktası. Özellikle on-premises ortamlar için bu tercih mantıklı.

Eğer cloud-native bir yapı kuruyorsanız ve yönetilen servislerden yararlanacaksanız, MySQL 8.4 LTS çevresindeki ekosistem çok daha geniş ve yönetilen servis seçenekleri daha olgun.

Mevcut bir sistemi yönetiyorsanız gereksiz yere geçiş yapmayın. Her iki veritabanı da production için olgun ve güvenilir. Geçiş maliyeti genellikle elde edeceğiniz teorik faydadan fazla oluyor.

En önemli tavsiyem şu: Kendi kullanım senaryonuz için benchmark yapın, uygulamanızı her iki sistemde test edin, ekibinizin hangisiyle daha rahat çalıştığını değerlendirin. Sonra karar verin. İnternet’teki genel karşılaştırmalar değil, kendi ölçümleriniz karar vermenizi sağlamalı.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir