MySQL'den MariaDB'ye Geçiş: Hazırlık, Döküm, Kullanıcılar ve Kontroller

Hedef MariaDB sürümünü seçmek

Master Guide'ın kontrol listesine göre MySQL 5.7'den geliyorsanız MariaDB 10.11 LTS veya 11.8 LTS, en uzun destek süresi kalan güvenli limanlardır. MySQL 8.0 veya 8.4'ten geliyorsanız MariaDB 11.8 LTS ya da yeni 12.3 LTS önerilir; bu sürümler 8.x dönemi uygulamaların ihtiyaç duyduğu özellik eşdeğerliğine en yakın olanlardır. Uyumluluk matrisinde ise MySQL 8.4 LTS için 10.11 veya 11.4 LTS hedeflerinden bahseden daha eski bir ipucu da bulunur. Seçimi yaparken iki sayfayı birlikte okuyun ve kullanacağınız sürümün desteğinin ne zamana kadar sürdüğünü kontrol edin. Belgelerin indirme sayfası uzun süreli sürümlerin beş yıl, kısa süreli sürümlerin bir yıl bakım gördüğünü belirtir.

Geçişi zorlaştıran başlıca farklar

Uyumluluk matrisi MySQL 8.0/8.4'ten gelenler için dört "anlaşma bozan" alan sayar: kimlik doğrulama, kaldırılmış değişkenler, GTID biçimi ve JSON. Aşağıdaki tablo matristeki en önemli satırları özetler:

Yapılandırma tarafında MariaDB, my.cnf ve my.ini dosyalarını okumaya devam eder ve MySQL 8.4'te kaldırılmış bazı eski değişkenleri takma ad olarak tutar. Belgeler bunu "MariaDB eski değişkenlere karşı MySQL 8.4'ten daha hoşgörülüdür" diye özetler. Yine de bir MySQL yapılandırma dosyasını olduğu gibi taşımadan önce satır satır gözden geçirmeniz gerekir; bilinmeyen bir değişken sunucunun başlamasını engelleyebilir. Seçenek dosyalarının okunma sırası için my.cnf yapılandırma dosyaları yazısına bakın.

Neden yerinde ikili değişim yapılamaz?

MariaDB tablo yapısı gibi meta verileri ayrı .frm dosyalarında saklar. MySQL 8.0 bu dosyaları kaldırıp yerine genel bir veri sözlüğü koydu. Bir MySQL 8.0 veya 8.4 sunucusunu durdurup MariaDB ikililerini aynı veri dizinine yönlendirirseniz MariaDB tabloları anlamak için .frm dosyalarını arar, bulamaz ve dizini boş görür ya da kritik hatalar verir; MySQL'in iç sözlük tablolarını okuyamaz. Belgeler 5.7 öncesi MySQL sürümlerinde yerinde geçişin teoride mümkün olduğunu, ama bu sürümlerin desteği bitmiş işletim sistemleri için derlendiğini ve bu yüzden önerilmediğini de ekler. Sonuç olarak gerçekçi yol döküm alıp geri yüklemektir.

Zorunlu yedekler

Master Guide geçişe iki tür yedek olmadan başlamamanızı söyler. Birincisi, sunucu durdurulmuşken alınmış /var/lib/mysql dizini kopyasıdır; ikili değişim başarısız olursa en hızlı geri dönüş yoludur. İkincisi tam bir mantıksal dökümdür. Bu döküm için MariaDB'nin mariadb-dump aracını değil, MySQL'in kendi mysqldump programını kullanın; belgelere göre mariadb-dump MySQL'e karşı kapsamlı olarak test edilmemiştir.

mysqldump --user=root --password --databases db1 db2 \
--single-transaction --routines --events \
--triggers --hex-blob > migration_dump.sql

--all-databases kullanmayın: bu seçenek MySQL'in sistem veritabanlarını da dökümün içine alır, oysa bu veritabanları MariaDB'dekilerden farklıdır ve yükleme sırasında hata verir. Bunun yerine taşınacak veritabanlarını --databases seçeneğinin ardından tek tek yazın. --single-transaction InnoDB tablolarında tabloları kilitlemeden tutarlı bir döküm sağlar, --hex-blob resim veya şifreli dizeler gibi ikili verileri doğru taşır, --routines, --events ve --triggers ise yalnızca satırların değil, veritabanındaki mantığın da taşınmasını sağlar.

Kullanıcıları ve yetkileri taşımak

Belgeler mysql sistem veritabanını bütünüyle taşımak yerine kaynak MySQL sunucusunda kullanıcıları ve yetkileri yeniden oluşturacak SQL komutlarını üretmeyi önerir. Master Guide'daki ilk sorgu mysql.user tablosunu okuyup her hesap için bir CREATE USER deyimi üretir: mysql_native_password kullanan hesapların parola özetini olduğu gibi taşır, caching_sha2_password veya sha256_password kullanan hesapların parolasını ise varsayılan bir değere sıfırlayıp süresini dolmuş olarak işaretler. Sorgunun ilk dalı şöyledir:

SELECT
    CASE
        WHEN plugin = 'mysql_native_password'
             AND authentication_string IS NOT NULL
             AND authentication_string <> ''
        THEN CONCAT(
            'CREATE USER IF NOT EXISTS ''', user, '''@''', host,
            ''' IDENTIFIED VIA mysql_native_password USING ''',
            authentication_string, ''';'
        )
        ELSE CONCAT(
            '-- SKIPPED unsupported plugin for ''', user, '''@''', host,
            ''': ', COALESCE(plugin, 'NULL')
        )
    END AS migration_sql
FROM mysql.user
WHERE user NOT IN ('mysql.sys','mysql.session','mysql.infoschema','root');

Belgelerdeki tam sorguda caching_sha2_password ve boş parola durumları için iki dal daha vardır; ayrıca genel, veritabanı, tablo ve prosedür düzeyindeki yetkiler için GRANT deyimleri üreten ikinci bir betik bulunur. Belgeler bu SQL'in geldiğiniz MySQL sürümüne göre değişebileceğini not eder. Üretilen çıktıyı MariaDB'de çalıştırmadan önce okuyun ve özellikle varsayılan parolayla oluşturulan hesapların ilk girişte parola değiştirmesini sağlayın.

Parolaları sıfırlamak istemiyorsanız MariaDB'nin MySQL uyumlu caching_sha2_password eklentisini kullanabilirsiniz. Belgelere göre bu eklenti MariaDB Community Server 11.4.9, 11.8.4 ve 12.1'den itibaren vardır, paketlerle birlikte gelir ama varsayılan olarak yüklü değildir. Yükledikten sonra hesabı MySQL'deki authentication_string değeriyle oluşturursunuz:

INSTALL SONAME 'auth_mysql_sha2';

CREATE USER user@host IDENTIFIED WITH caching_sha2_password USING 'authentication_string';

PARSEC MariaDB 11.6'dan itibaren kullanılabilir ve belgelere göre gelecekteki bir sürümde varsayılan olması planlanıyor. Master Guide, 11.8 LTS ve sonrasına geçişlerde kullanıcıları PARSEC'e taşımayı bir güvenlik adımı olarak önerir:

ALTER USER 'app_user'@'localhost' IDENTIFIED VIA parsec USING PASSWORD('secure_password');

Kimlik doğrulama eklentilerinin ayrıntıları ve unix_socket davranışı için MariaDB kimlik doğrulama yazısına, kullanıcı oluşturma ve yetki verme için CREATE USER ve GRANT ve REVOKE yazılarına bakın.

Geçiş gecesinden önce: SQL'i doğrulamak

Uygulamanız kritikse belgeler bir süre MySQL sunucusunda genel sorgu günlüğünü açıp gerçek trafiği yakalamanızı, bu sorguları bir MariaDB test kopyasında yeniden çalıştırmanızı ve MariaDB hata günlüğünde "Syntax Error" ya da "Unknown Function" mesajları aramanızı önerir. Bu, geçiş gecesi sürprizlerini önlemenin en somut yoludur. Bulduğunuz farklar genellikle ayrılmış kelimeler, MySQL'e özgü fonksiyonlar veya kaldırılmış sözdizimi olur.

Adım adım mantıksal geçiş

Mantıksal geçiş yeni bir sunucuya, farklı bir Linux dağıtımına veya yönetilen bir bulut ortamına taşınırken en iyi seçenektir. Veri metin tabanlı bir SQL betiğine aktarıldığı için ikili düzeydeki uyumsuzluklar süzülür ve tablolar ile index'ler MariaDB biçiminde baştan oluşturulur.

• 1. MySQL'den dışa aktarın: yukarıdaki mysqldump komutunu kullanın.
• 2. MariaDB'yi hazırlayın: yeni sunucuya MariaDB Community Server kurun (kurulum yazısı). Büyük bir içe aktarma için max_allowed_packet değerini en az 64M yapın, büyük BLOB sütunlarınız varsa daha da artırın. İndex oluşturmayı hızlandırmak için innodb_buffer_pool_size değerini geçici olarak kullanılabilir belleğin yüzde 70 ile 80'ine çıkarabilirsiniz.
• 3. MariaDB'ye yükleyin: döküm dosyasını yeni sunucuya aktarıp mariadb istemcisiyle içe aktarın.

[mariadb]
max_allowed_packet = 64M

mariadb -u root -p < migration_dump.sql

Disk alanınız kısıtlıysa ve iki sunucu arasında hızlı bir ağ varsa ara dosya oluşturmadan veriyi doğrudan akıtabilirsiniz. Belgeler bu yöntemin büyük veritabanlarında uzun sürebileceğini ve herhangi bir nedenle kesilirse genellikle kaldığı yerden devam edemeyeceğini, baştan başlamanız gerektiğini hatırlatır.

mysqldump --user=root --password --databases db1 db2 \
--single-transaction --routines --events \
--triggers --hex-blob | mariadb --host=new_server_ip --user=root --password

Yükleme sonrası büyük tabloların ve geçici bellek ayarlarının nasıl yapılandırılacağı InnoDB buffer pool yazısında anlatılıyor; içe aktarma sırasında buffer pool'u geçici olarak büyüttüyseniz iş bitince normal değerine döndürmeyi unutmayın.

Geçişten sonra: doğrulama ve iyileştirme

Veri taşındıktan sonra belgeler birkaç adım daha önerir. İlki optimizer istatistiklerini yeniden oluşturmaktır. MariaDB'nin maliyet tabanlı optimizer'ı MySQL'inkinden farklı olabilir; en verimli planların seçilmesi için tüm tabloları yeniden analiz edin. Belgeler bu adımı "çalışan" bir geçiş ile "hızlı çalışan" bir geçiş arasındaki fark olarak tanımlar.

mariadb-check -u root -p --analyze --all-databases

İkinci adım karakter seti ve collation kontrolüdür. Bir tablo eski MySQL varsayılanını, başka bir tablo MariaDB varsayılanını kullanıyorsa ikisi arasındaki bir JOIN collation uyuşmazlığı yüzünden index kullanmayı bırakabilir. Şu sorgularla sunucu ve sütun düzeyindeki collation'ları görebilirsiniz:

SHOW GLOBAL VARIABLES LIKE 'collation%';
SHOW VARIABLES LIKE 'collation%';
SELECT table_schema, table_name, column_name, collation_name
  FROM information_schema.columns
  WHERE collation_name IS NOT NULL
    AND table_schema NOT IN ('information_schema','performance_schema','mysql','sys')
  ORDER BY table_schema, table_name;

Uyuşmazlık bulursanız tabloları ve veritabanlarını ALTER TABLE ve ALTER DATABASE ile aynı collation'a getirin. Türkçe karakterler ve utf8mb4 için karakter seti ve collation yazısına bakın. Üçüncü adım başlangıç sırasında hata günlüğüne düşen "Deprecated" ve "Ignored" uyarılarını okumaktır. Dördüncüsü uygulama duman testidir: uygulamanız bağlanabiliyor mu, istemci ile sunucu aynı karakter setinde anlaşıyor mu?

JSON sütunlarınız MariaDB'de CHECK kısıtlı LONGTEXT olarak tutulur. Belgelere göre JSON_EXTRACT() kullanan sorgular MySQL'deki gibi çalışmaya devam eder, ancak yüksek hızlı JSON alan çıkarımına dayanan mantığı test etmeniz önerilir; ayrıntı için MariaDB JSON fonksiyonları yazısına bakın. İstemci kütüphaneleri genellikle değişmez: MariaDB MySQL ile protokol uyumludur ve JDBC, PHP PDO veya Python mysqlclient bağlayıcıları çalışmaya devam eder. Belgeler en iyi performans ve özellikler için resmî MariaDB bağlayıcılarına geçmeyi önerir.

Sık karşılaşılan sorunlar

Replikasyon tablosundaki satır önemli bir sınırı gösterir: MariaDB MySQL GTID'lerini kullanamaz. Geçiş sırasında bir süre karma bir ortam çalıştıracaksanız (örneğin MariaDB'yi bir MySQL birincilinin replikası olarak bağlayıp sonra terfi ettirmek) dosya adı ve konum tabanlı replikasyon planlamalısınız. MariaDB kendi tarafında hem MASTER hem REPLICA sözdizimini anlar. Replikasyon kurulumu için MariaDB replikasyon yazısına bakın.

MariaDB'yi MySQL ile aynı sunucuda çalıştırmak

Veritabanlarını ve uygulamaları tek tek taşımak istiyorsanız MariaDB'yi mevcut MySQL kurulumunun yanına kurabilirsiniz. "Installing MariaDB Alongside MySQL" sayfası bunu derlenmiş ikili tar.gz arşivini /opt altına açarak, ayrı bir veri dizini, ayrı bir kullanıcı, farklı bir port ve farklı bir soket ile yapar. Asıl fikir, MariaDB'nin yalnızca kendi yapılandırma dosyasını okumasını --defaults-file ile zorlamaktır. Sayfadaki asgari yapılandırma şöyledir:

[client]
port		= 3307
socket		= /opt/mariadb-data/mariadb.sock

[mysqld]
datadir         = /opt/mariadb-data
basedir         = /opt/mariadb
port		= 3307
socket		= /opt/mariadb-data/mariadb.sock
user            = mariadb

Bu sayfadaki örnekler eski sürümler ve eski bir init betiği üzerinden anlatıldığı için komutları bire bir kopyalamak yerine ilkeyi alın: iki sunucu aynı veri dizinini, portu veya soketi asla paylaşmamalıdır. Aynı veri dizinini iki süreç açmaya çalışırsa MariaDB Unable to lock ./ibdata1 error: 11 gibi hatalarla başlamayı reddeder. Güncel dağıtımlarda birden fazla örneği systemd ile yönetmek için MariaDB systemd yazısındaki çoklu örnek bölümüne bakabilirsiniz.

Sık yapılan hatalar

• MySQL 8.x veri dizinini MariaDB ile açmaya çalışmak: MariaDB, MySQL 8.0 ve sonrasının veri sözlüğünü okuyamaz.
• --all-databases ile döküm almak: MySQL sistem veritabanları MariaDB'ye yüklenirken hata verir.
• Dökümü mariadb-dump ile almak: Belgeler MySQL kaynağı için MySQL'in mysqldump aracını önerir.
• caching_sha2_password kullanıcılarını unutmak: Bu hesaplar ya yeni parolayla yeniden oluşturulmalı ya da MariaDB'nin uyumlu eklentisiyle taşınmalıdır.
• İstatistikleri yenilememek: Geçişten sonra yavaşlayan sorguların sık nedeni eski istatistiklerdir.
• Collation'ları karışık bırakmak: Farklı collation'lı sütunlar arasındaki join'ler index kullanamayabilir.
• GTID tabanlı karma replikasyon kurmaya çalışmak: İki GTID biçimi uyumsuzdur; konum tabanlı replikasyon kullanın.

Sık Sorulan Sorular

Geçiş başarısız olursa MySQL'e dönebilir miyim?

Evet, mariadb-upgrade çalıştırmadan önce sunucu dururken /var/lib/mysql dizininin fiziksel kopyasını aldıysanız. mariadb-upgrade sistem tablolarını değiştirdikten sonra MySQL ikililerini aynı veri dizinine geri yönlendiremezsiniz.

Uygulamamın bağlantı kodunu değiştirmem gerekir mi?

Genellikle hayır; MariaDB MySQL ile protokol uyumludur ve mevcut MySQL bağlayıcıları çalışır. Kimlik doğrulama eklentisi farklıysa bağlantı hataları alabilirsiniz; WordPress gibi uygulamalarda bu durumun belirtileri için WordPress veritabanı bağlantı hatası rehberine bakın.

MySQL 8.4 ile MariaDB 11.8 uyumlu mu?

Belgelere göre standart SQL ve veri açısından evet. Ancak MySQL 8.4 birçok eski davranışı kaldırırken MariaDB bunları hâlâ destekler; bu nedenle 8.4 için temizlenmiş bir yapılandırma veya uygulama MariaDB'de farklı davranışlarla karşılaşabilir.

JSON sütunlarım ne olacak?

MariaDB'de JSON, CHECK kısıtlı LONGTEXT için bir takma addır. SQL düzeyindeki JSON fonksiyonları büyük ölçüde uyumludur, ama depolama ve performans özellikleri farklıdır; JSON ağırlıklı sorguları test edin.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · MySQL ve PostgreSQL karşılaştırması · mariadb-dump ile yedekleme · MariaDB kimlik doğrulama eklentileri · MariaDB sürüm yükseltme · utf8mb4 ve collation