MariaDB Sürüm Yükseltme Rehberi: Hazırlık, mariadb-upgrade ve Geri Dönüş

Küçük sürüm ile ana sürüm yükseltmesinin farkı

MariaDB sürüm numarasında ilk iki bölüm ana sürümü, sonuncusu küçük (bakım) sürümü gösterir. 10.6.3'ten 10.6.4'e geçmek küçük sürüm yükseltmesidir; 11.8'den 12.3'e geçmek ise ana sürüm yükseltmesidir. Belgelere göre RPM paketleri yalnızca küçük sürümler arasında yerinde yükseltmeyi destekler; ana sürüm değişiminde eski RPM'leri kaldırıp yenilerini kurmanız gerekir. Debian ve Ubuntu paketlerinde de 12.3 yükseltme sayfası aynı sırayı önerir: önce eski mariadb-server paketini kaldırın, sonra yenisini kurun.

Ayrım mariadb-upgrade için de önemlidir. MariaDB 10.6.6 ve 10.7.2 ile gelen mariadb-upgrade 2.0, yükseltme işini yalnızca ana sürüm değiştiğinde yapar. Küçük sürüm yükseltmesinden sonra çalıştırırsanız araç işin zaten yapıldığını söyleyen bir mesajla çıkar. Belgelerdeki örnek mesaj şöyledir:

This installation of MariaDB is already upgraded to 10.11.4-MariaDB.
There is no need to run mysql_upgrade again for 10.11.11-MariaDB.
You can use --force if you still want to run mysql_upgrade.

Mesajın önerdiği gibi gerekirse --force ile çalıştırmayı zorlayabilirsiniz. Community Server'dan Enterprise Server'a aynı ana sürüm içinde geçmek de araç açısından küçük sürüm yükseltmesi sayılır.

Sürüm atlayabilir misiniz?

Eskiden her ana sürümün tek tek geçilmesi gerekiyordu. "General Upgrade Information" sayfasına göre güncel sürümlerde tek başına çalışan bir sunucuyu bulunduğunuz sürümden doğrudan hedef sürüme yükseltebilirsiniz; ara ana sürümleri veya LTS sürümlerini atlamak desteklenir ve test edilir. Buna karşın aradaki her ana sürümün "Incompatible Changes" bölümünü okumanız gerekir, çünkü uygulamanız kaldırılmış bir seçeneğe, değişmiş bir davranışa ya da yeni ayrılmış bir kelimeye takılabilir. Uygulamanızın uyumundan emin değilseniz belgeler sürümleri birer birer geçmeyi önerir; böylece sorunu getiren sürümü bulmak kolaylaşır.

Galera Cluster farklıdır. Küme açık kalarak yapılan yuvarlanan (rolling) yükseltmede her seferinde bir ana/LTS sürüm ilerlemeniz gerekir. Tüm kümeyi kapatabiliyorsanız bütün düğümleri hedef sürüme yükseltip kümeyi yeniden başlatabilirsiniz. Ayrıca 12.3 ve sonrasına yükselten Galera kullanıcılarının mariadb-server-galera (veya MariaDB-server-galera) paketini elle kurması gerekir; otomatik bağımlılık kaldırıldığı için standart yükseltme bu bileşeni getirmez. Galera ayrıntıları bu serinin kapsamı dışında, resmî Galera yükseltme belgelerine bakın.

Yükseltmeden önce: hazırlık listesi

• Sürüm notlarını okuyun: hedef sürümle aranızdaki her sürümün uyumsuz değişikliklerini gözden geçirin.
• Depolama motorlarını kontrol edin: hedef sürüm kullandığınız motorları desteklemelidir. Belgelerin örneği TokuDB'dir: MariaDB 10.6 ve sonrasında desteklenmez.
• Yedek alın: 12.3 yükseltme sayfası fiziksel yedek için mariadb-backup önerir. En azından, yükseltme değişikliklerinin çoğunun yapıldığı mysql sistem veritabanını mariadb-dump --add-drop-table mysql ile ayrıca yedekleyin.
• Temiz kapatma yapın: veri dosyaları sürümler arasında uyumlu olsa da kurtarma günlükleri uyumlu olmayabilir. innodb_fast_shutdown değeri 2 olmamalı (varsayılanı 1) ve innodb_force_recovery 3'ten küçük olmalıdır.
• Önce bir kopyada deneyin: düşürme (downgrade) sayfası, yükseltmeyi uygulamanızın normal yazma yüküyle önce bir test sunucusunda denemenin geri dönüş ihtiyacından kaçınmanın tek güvenilir yolu olduğunu vurgular.

mariadb-dump --add-drop-table mysql > mysql-sistem-yedek.sql

Temiz kapatmanın neden önemli olduğunu redo log sayfası açıkça gösterir. Çökme sonrası kirli kalmış bir günlük üzerinde yükseltme desteklenmez ve sunucu şu türde bir hatayla başlamayı reddeder:

[ERROR] InnoDB: Upgrade after a crash is not supported.
The redo log was created with MariaDB 10.6.23.
You must start up and shut down MariaDB 10.7 or earlier.

Yedekleme araçları için mariadb-backup ile fiziksel yedek yazısına ve mariadb-dump yazısına, genel strateji için veritabanı yedekleme stratejileri rehberine bakın.

Adım adım: 11.8'den 12.3'e yükseltme

Aşağıdaki sıra, 12.3 yükseltme sayfasındaki önerilen yöntemi Linux için izler. Depoyu MariaDB Corporation'ın mariadb_repo_setup betiğiyle kurduysanız ana sürümü değiştirmek için betiği yeniden çalıştırmanız yeterlidir. Betik varsayılan olarak en son kararlı sürümü yapılandırır; belirli bir seriye bağlı kalmak için Community Server'da sürüm numarasının önüne mariadb- ekleyerek --mariadb-server-version seçeneğini kullanırsınız.

curl -LsSO https://r.mariadb.com/downloads/mariadb_repo_setup
echo "${checksum} mariadb_repo_setup" | sha256sum -c -
chmod +x mariadb_repo_setup
sudo ./mariadb_repo_setup --mariadb-server-version="mariadb-12.3"

${checksum} yerine betik sürümünüzün belgelerde yayımlanan sağlama toplamını yazın. Deponuzu MariaDB Foundation'ın yapılandırma aracıyla eklediyseniz depo satırını yeni sürüme göre değiştirmeniz gerekir; ayrıntılar .deb kurulum sayfasında. Ardından Debian veya Ubuntu üzerinde şu adımlar gelir:

sudo systemctl stop mariadb
sudo apt-get remove mariadb-server
sudo apt update
sudo apt-get install mariadb-server

RHEL, CentOS Stream veya Fedora üzerinde kaldırma ve kurma komutları paket adının büyük harfli yazımıyla değişir:

sudo systemctl stop mariadb
sudo dnf remove MariaDB-server
sudo dnf install MariaDB-server

SLES ve OpenSUSE için aynı adımlar zypper ile yapılır. Kurulumdan sonra, sunucuyu başlatmadan önce yapılandırma dosyalarınızı gözden geçirip kaldırılmış seçenekleri temizleyin; bir sonraki bölümde 12.3 için bu seçenekler listeleniyor. Ardından sunucuyu başlatın ve mariadb-upgrade çalıştırın. Paket yöneticileri hakkında genel bilgi için apt ve dnf paket yönetimi rehberine, servis komutları için MariaDB systemd yazısına bakın.

sudo systemctl start mariadb
sudo mariadb-upgrade

11.8 ile 12.3 arasındaki uyumsuz değişiklikler

Belgelere göre 11.8'den yükseltme çoğu sunucuda sorunsuz geçer, ancak bazı değişiklikler etkileyebilir. Yapılandırma dosyalarında kullanıyorsanız şu seçenekleri kaldırmanız veya yeniden adlandırmanız gerekir:

Kaldırılmış bir seçenek dosyada kalırsa sunucu başlamayabilir. "What to Do if MariaDB Doesn't Start" sayfasına göre bu durumda hata günlüğünde unknown variable içeren bir satır görürsünüz; belgeler bunun yükseltmelerden sonra daha sık yaşandığını ve seçenek adlarının büyük/küçük harfe duyarlı olduğunu hatırlatır.

İkinci değişiklik yeni ayrılmış kelimelerdir: CONVERSION ve TO_DATE artık ayrılmış kelimedir. Bunları tırnaksız tablo, sütun veya değişken adı olarak kullanıyorsanız yükseltmeden önce ters tırnakla çevreleyin ya da yeniden adlandırın; aksi halde ilgili deyimler ayrıştırılamaz ve 1064 sözdizimi hatası alırsınız. Bu hatanın okunuşu MariaDB sık hatalar yazısında anlatılıyor.

Üçüncü değişiklik replikasyonla ilgilidir. 12.3 öncesi bir sürümden MariaDB 12.3.2'ye yükseltilen bir replikada CHANGE MASTER TO ... master_use_gtid ayarı taşınmaz ve DEFAULT değerine sıfırlanır. Belgelere göre bu 12.3.3'te düzeltilmiştir. Yükseltmeden sonra replikasyon yapılandırmanızı kontrol edin ve GTID kullanıyorsanız master_use_gtid değerini yeniden uygulayın. Replikasyon kurulumu için MariaDB replikasyon ve GTID yazısına bakabilirsiniz.

Replikasyon kullanan sistemlerde sıra

Belgelerin önerdiği sıra şöyledir: önce bir replikayı yükseltin ve sorunsuz çalıştığını doğrulayın, sonra diğer replikaları yükseltin. Ardından yükseltilmiş bir replikayı birincil (primary) sunucuya dönüştürün, eski birincili yükseltin ve rolleri yeniden düzenleyin. Bu sıranın nedeni, MariaDB replikasının birincilden daha yeni bir sürüm olabilmesidir; ters yön desteklenmez. Replikasyonunuz yoksa yedek alıp sunucuyu kapatarak yükseltme yaparsınız.

mariadb-upgrade ne yapar?

Sunucu yükseltmeyi hiçbir zaman kendisi yapmaz. Açılışta eski bir sistem tablosu veya sürüm uyumsuzluğu görürse yalnızca hata günlüğüne mariadb-upgrade çalıştırmanızı öneren bir mesaj yazar. Aracın ana işleri şunlardır:

• mysql veritabanındaki sistem tablolarını yeni sürüme getirmek; çoğu zaman bu birkaç tabloya yeni sütun eklemekten ibarettir ve çok hızlıdır.
• Tüm tabloların güncel olup olmadığını CHECK TABLE ... FOR UPGRADE ile kontrol etmek ve güncel olmayanlarda ALTER TABLE ... FORCE çalıştırmak. Bir tablo, index'inde kullanılan collation değiştiyse (nadir) ya da motorun biçimi değiştiyse (çok nadir) güncel sayılmaz.
• Eksik sistem tablolarını yeniden oluşturmak; var olan tablolardaki verilere dokunmaz.
• Sürüm numarasını veri dizinindeki mariadb_upgrade_info dosyasına yazmak (MariaDB 11.0 öncesinde mysql_upgrade_info). Bu dosya sayesinde aynı sürüm için tablo kontrolü tekrar yapılmaz.

Çoğu durumda araç birkaç saniyede biter; çok sayıda tablo veya değişen collation kullanan tablo varsa daha uzun sürebilir. Birden fazla kez çalıştırmanın sakıncası yoktur. Debian ve Ubuntu'da sunucu paketleri bir paket yükseltmesinden sonra yeni sunucu başladığında aracı arka planda --version-check ile kendisi çalıştırır. RPM tabanlı dağıtımlarda ve sunucuyu doğrudan systemd ya da mariadbd ile başlattığınızda araç otomatik çalışmaz; siz çalıştırmalısınız.

Bağlanma ve sık kullanılan seçenekler

mariadb-upgrade çalışan sunucuya sıradan bir istemci gibi bağlanır ve --user vermezseniz işletim sistemi kullanıcısı olarak değil root olarak bağlanır. Yeni kurulumlarda varsayılan olan unix_socket kimlik doğrulamasında aracı işletim sisteminin root kullanıcısıyla çalıştırırsınız; bu ayrıca veri dizinine yazma iznini de sağlar. Hesabın parolası varsa --password seçeneğini değersiz verip istemde parolayı yazarsınız.

sudo mariadb-upgrade
mariadb-upgrade --user=root --password
mariadb-upgrade --check-if-upgrade-is-needed
mariadb-upgrade --verbose --verbose
mariadb-upgrade --force

--check-if-upgrade-is-needed hızlı bir kontrol yapar ve yükseltme gerekiyorsa 0, gerekmiyorsa 1 döndürür; betiklerde işinize yarar. --verbose seçeneğini iki kez vermek bağlantı parametrelerini, üç kez vermek çalıştırılan CHECK, RENAME ve ALTER TABLE komutlarını da yazdırır. --upgrade-system-tables yalnızca mysql veritabanındaki sistem tablolarını günceller; diğer tabloların güncel olduğundan eminseniz süreyi kısaltır. Kimlik bilgilerini [mariadb-upgrade] grubuna yazacaksanız dosyayı yalnızca aracı çalıştıran kullanıcının okuyabileceği hale getirin ve iş bitince parolayı silin. Yükseltme sırasında yapılan komutlar varsayılan olarak binary log'a yazılmaz; bunu istiyorsanız --write-binlog kullanılır.

Yükseltmeden sonra kontrol listesi

• Hata günlüğünü okuyun: kullanımdan kalkmış seçenek uyarılarını dosyalarınızdan temizleyin. Günlüğün yeri için error log yazısına bakın.
• Uygulamanızı test edin: belgelere göre optimizer iyileştirmeleri sayesinde uygulama genellikle daha iyi çalışır, ama nadiren optimizer yanlış bir plan seçebilir. Böyle bir durumda EXPLAIN, optimizer trace veya optimizer_switch ile sorguyu düzeltebilirsiniz; ayrıntı EXPLAIN ve ANALYZE yazısında.
• Replikasyonu doğrulayın: özellikle 12.3.2'deki master_use_gtid sıfırlanmasını kontrol edin.
• Yeni özellikleri gözden geçirin: 12.x'te gelen hint'ler ve InnoDB tabanlı binary log gibi seçenekler planlamanızı etkileyebilir.

Bir şey ters giderse: felaket kurtarma adımları

Belgeler, beklenmedik bir sorun çıktığında denenebilecek bir yol tarif eder: mysql veri dizinindeki InnoDB tablolarını (gtid_slave_pos, innodb_table_stats, innodb_index_stats, transaction_registry) kaldırın, mysql dizinini mysql-old olarak taşıyın ve mariadb-install-db ile yenisini oluşturun. Bundan sonra eski kullanıcılarınızı geri eklemeniz gerekir; iş bitince mysql-old dizinini silersiniz. Bu adımlar kullanıcı ve yetki tanımlarını sıfırladığı için önceden mysql veritabanının dökümünü almış olmanız hayat kurtarır.

Geri dönmek (downgrade) neden zordur?

"Downgrading MariaDB" sayfası açık konuşur: sürüm düşürme resmî olarak desteklenmez ve MariaDB yerinde düşürmeyi test etmez. Disk biçimi, iç sistem tabloları ve motor mimarisi ana sürümler arasında geriye dönük uyumlu olacak diye bir garanti yoktur. Belgeler iki senaryo ayırır:

Birinci yol en basit ve en güvenilir olanıdır, çünkü ham dosyalar olduğu gibi geri gelir. İkinci yol risklidir: yeni sürümde alınan bir döküm eski sürümün reddettiği tanımlar içerebilir, bu yüzden geri yüklemeyi önce bir test sunucusunda doğrulamanız gerekir. Daha eski bir replikayı yeni bir birincile bağlayıp sonra onu terfi ettirmek de belgelerde anlatılır, ama replikasyonun düşürme yönü desteklenmez: eski replika, uygulayamadığı ilk deyime kadar normal çalışır ve süreç geç bir anda başarısız olabilir.

Bazı değişiklikler düşürmeyi doğrudan engeller. MariaDB 10.8'de redo log biçimi değişti ve 10.6 bu biçimi okuyamaz; bu yüzden 10.8 veya sonrasından kalan bir veri dizini 10.6 ile açılamaz. MariaDB 11.8'de gelen VECTOR veri tipi 11.4'te yoktur; böyle bir sütunu veya vektör index'i olan tablo 11.4'te açılamaz. Şifreli redo log kullananlar için de not var: 10.11.15, 11.4.9, 11.8.4 ve 12.1.2 ile gelen yeni şifreli günlük biçimini eski sürümler okuyamaz; daha eski bir sürüme dönmeden önce sunucuyu innodb_encrypt_log=OFF ile yeniden başlatıp temiz kapatmanız gerekir.

Sık yapılan hatalar

• Yedeksiz yükseltmek: Geri dönüşün tek güvenilir yolu yükseltme öncesi fiziksel yedektir.
• Hızlı çökme kapatmasıyla durdurmak: innodb_fast_shutdown=2 ile kapatılan sunucu üzerinde yükseltme yapmak kurtarma günlüğü uyumsuzluğuna yol açabilir.
• mariadb-upgrade adımını atlamak: Belgelere göre hata günlüğünde eksik sütun uyarıları, bulunamayan kayıtlar ya da Cannot load from mysql.proc. The table is probably corrupted. mesajı gibi sorunlar çıkabilir.
• mariadb-upgrade aracını kendi kullanıcınızla çalıştırmak: Araç veri dizinine yazabilmelidir ve unix_socket kullanan root hesabı için sudo gerekir.
• Eski seçenekleri dosyada bırakmak: big_tables veya storage_engine gibi kaldırılmış seçenekler 12.3'te başlatmayı engelleyebilir.
• Önce birincil sunucuyu yükseltmek: Replika birincilden yeni olabilir, tersi desteklenmez.
• Ayrılmış kelimeleri unutmak: CONVERSION veya TO_DATE adlı tırnaksız bir sütun 12.3'te sözdizimi hatası verir.

Sık Sorulan Sorular

10.11'den doğrudan 12.3'e geçebilir miyim?

Tek başına çalışan bir sunucu için belgeler ara sürümleri atlayarak doğrudan yükseltmeyi destekler. Yine de 10.11 ile 12.3 arasındaki her ana sürümün uyumsuz değişiklikler bölümünü okumanız gerekir. Galera kümesinde yuvarlanan yükseltme yapıyorsanız sürümleri tek tek geçmelisiniz.

mariadb-upgrade her küçük güncellemeden sonra gerekli mi?

Hayır. mariadb-upgrade 2.0 yalnızca ana sürüm değiştiğinde iş yapar. Küçük güncellemeden sonra çalıştırmanın zararı yoktur; araç iş gerekmediğini söyleyip çıkar.

Yükseltme sırasında sunucu ne kadar kapalı kalır?

Belgeler sayı vermez; mariadb-upgrade çoğu durumda birkaç saniyede biter, ama paket indirme ve kurulum süresi sisteminize bağlıdır. Kesintiyi en aza indirmek için replikalı bir düzende önce replikaları yükseltip rolleri değiştirme yöntemini kullanabilirsiniz.

Yükseltme başarısız olursa eski sürümü yeniden kurmak yeterli mi?

Genellikle hayır. Redo log biçimi, sistem tabloları veya yeni veri tipleri eski sürümün veri dizinini açmasını engelleyebilir. En güvenilir yol, yükseltmeden önce alınmış fiziksel yedeği eski sürümün temiz kurulumuna geri yüklemektir.

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 · MariaDB 12.3 LTS yenilikleri · mariadb-backup fiziksel yedek · MariaDB kurulumu · MariaDB replikasyon kurulumu · MySQL'den MariaDB'ye geçiş