MariaDB 12.3 LTS Yenilikleri ve 12.x Serisinde Değişenler

LTS ve diğer sürüm türleri

Belgelerin indirme sayfasına göre MariaDB üç tür sürüm yayımlar: beş yıl bakım gören uzun süreli sürümler, bir yıl bakım gören kısa süreli sürümler ve rolling sürümler. Bakım süresi en uzun olan tür LTS olduğu için üretim sunucusunda sürüm seçerken önce bu süreyi kontrol etmek mantıklıdır.12.0, 12.1 ve 12.2 ile gelen özellikler 12.3 LTS'te de bulunur; bu yüzden aşağıda her özelliğin hangi ara sürümde ilk kez göründüğünü belgelerdeki yazımıyla veriyoruz. Bazı düzeltmeler ise LTS sürümlerine geriye taşınmıştır; örneğin innodb_buffer_pool_size_max varsayılanının 64 bit sistemlerde 8 TiB olması 10.11.17, 11.4.11, 11.8.7 ve 12.3.2 sürümlerinde birlikte geldi.

Optimizer: yeni tarz hint'ler ve join yeniden sıralama

12.x serisinin en görünür değişikliği, belgelere göre MariaDB 12.0 ve 12.1 ile gelen yeni tarz optimizer hint'leridir. Bunlar /*+ ... */ biçiminde, SELECT, UPDATE veya DELETE kelimesinin hemen arkasına yazılan özel yorumlardır ve sunucu genelindeki optimizer_switch ayarlarını değiştirmeden tek bir sorguyu ya da onun bir alt sorgusunu yönlendirir. Belgelerin verdiği sürüm bilgisine göre:

SELECT /*+ MAX_EXECUTION_TIME(2000) */ * FROM t1;

SELECT /*+ NO_MERGE(dt)*/ a, b
FROM (SELECT a, b FROM t1) AS dt
WHERE a < 3 AND b > 8;

Sorgu blokları QB_NAME() ile adlandırılabilir; belgelere göre konuma dayalı örtük blok adları (select_#n) 12.2'den itibaren kullanılabilir. MAX_EXECUTION_TIME ile ilgili bir ayrıntı: @@max_statement_time ayarlıysa hint yok sayılır ve uyarı üretilir. Hint'lerin nasıl doğrulanacağı ve EXPLAIN EXTENDED ile nasıl görüleceği EXPLAIN ve ANALYZE yazısında anlatılıyor.

Bir diğer optimizer yeniliği 12.3 ile gelen reorder_outer_joins bayrağıdır. 12.3 öncesinde optimizer, birbirinden bağımsız birden fazla LEFT JOIN içeren bir sorguda tabloları yazıldığı sırayla birleştirmek zorundaydı. Bu bayrak açıldığında optimizer daha ucuz bir sırayı deneyebilir. Varsayılan değeri OFF'tur; belgeler bayrağı açarken optimizer_prune_level=0 ayarlamanızı önerir; istisna, join'in çok sayıda (örneğin 10'dan fazla) tablo içermesidir.

SET optimizer_switch='reorder_outer_joins=ON';
SET optimizer_prune_level=0;

MariaDB 12.1'den itibaren, index'lerle kapsanan sanal sütun ifadeleri içeren ORDER BY ve GROUP BY sorgularında optimizer daha iyi planlar seçebilir; aynı iyileştirme tek tablolu UPDATE ve DELETE deyimleri için de geçerlidir. Optimizer izleme tarafında 12.1 ile optimizer_record_context değişkeni eklendi; varsayılanı OFF'tur.

InnoDB tabanlı binary log (12.3)

12.3'ün mimari açıdan en büyük değişikliği, binary log olaylarının InnoDB tarafından yönetilen, sayfa yapılı dosyalara yazılabilmesidir. Geleneksel düzende binary log ile InnoDB ayrı bileşenlerdi ve ikisini tutarlı tutmak için pahalı bir iki aşamalı commit (2PC) gerekiyordu. Yeni düzende binlog, InnoDB redo log ve çökme kurtarma mekanizmasına bağlanır; böylece 2PC ortadan kalkar ve çökmeden sonra binlog ile InnoDB her zaman birbiriyle tutarlı bir duruma döner. Belgelere göre sync_binlog seçeneğine artık gerek yoktur ve fiilen yok sayılır; innodb_flush_log_at_trx_commit=1 ile commit başına yalnızca tek bir eşgüdümlü fsync yapılır.

[mariadb]
log_bin
binlog_storage_engine=innodb

Belgeler bu biçimi ne zaman seçmemeniz gerektiğini de açıkça yazar: Galera Cluster desteği gerekiyorsa, uygulamalarınız dosya adı ve konum tabanlı replikasyon konumlarına bağlıysa ya da ortamınızda binlog dosyalarını doğrudan okuyan üçüncü taraf araçlar varsa geleneksel binlog'da kalın. İki biçim birbirini dışlar; eski binlog dosyaları geçişten sonra kullanılamaz. Replikaların, birincil sunucuyu yeni biçime geçirmeden önce en az 12.3'e yükseltilmiş olması gerekir. Replikalardaki relay log ise geleneksel uygulamayı kullanmaya devam eder. Binary log kavramları için binary log ve PITR yazısına, GTID kurulumu için replikasyon yazısına bakın.

Replikasyonda diğer 12.x değişiklikleri

• Sunucu düzeyinde varsayılan bağlantı parametreleri (12.3): CHANGE MASTER TO içindeki MASTER_CONNECT_RETRY, MASTER_HEARTBEAT_PERIOD, MASTER_SSL* ve MASTER_USE_GTID gibi seçenekler DEFAULT değeri alabilir; bu durumda değer, yapılandırma dosyasındaki ya da komut satırındaki karşılık gelen sunucu seçeneğinden okunur ve birden fazla kanal aynı ayarı paylaşabilir.
• MASTER_RETRY_COUNT (12.0): 12.0 öncesinde CHANGE MASTER bu seçeneği içermiyordu ve --master-retry-count sunucu seçeneği kullanılıyordu.
• Yeni sistem değişkenleri (12.0): master_info_file, replicate_same_server_id, show_slave_auth_info ve geçici tabloların hangi binlog biçimlerinde kaydedileceğini belirleyen create_tmp_table_binlog_formats. 12.0 ile geçici tabloların binlog kurallarının belirleyici hale geldiğini CREATE TABLE sayfası ayrıca anlatır.
• Farklı tablo tanımlarında sütun adıyla eşleme (12.3): birincil binlog_row_metadata=FULL ile yapılandırılmışsa ve replika 12.3 veya üzerindeyse satır olayları sütun adlarıyla eşlenebilir; slave_type_conversions için ERROR_IF_MISSING_FIELD değeri de 12.3 ile geldi.
• Yükseltme uyarısı: 12.3.2'ye yükseltilen bir replikada master_use_gtid ayarı DEFAULT değerine sıfırlanıyordu; belgelere göre 12.3.3'te düzeltildi.

SQL, veri tipleri ve fonksiyonlar

12.x serisinde Oracle uyumluluğunu artıran birkaç yeni yapı geldi. XMLTYPE 12.3 ile tanıtılan, XML verisi saklamak için bir veri tipidir; uzunluk parametresi almaz (XMLTYPE(100) hata verir), en fazla 4 GB tutar ve ilk uygulamasında XML doğrulaması veya şema denetimi yapmaz. Belgelere göre 12.3'te UPDATEXML ve CAST bu tipi döndürür.

CREATE TABLE t1(id INT, x xmltype);

Oracle desteği için 12.3'te eklenen TO_DATE() bir metni biçim dizesine göre datetime değerine çevirir; TO_CHAR() ile aynı biçim öğelerinin çoğunu kullanır, DEFAULT ... ON CONVERSION ERROR yan tümcesini ve NLS_DATE_LANGUAGE ile dil seçimini destekler (desteklenen diller arasında TURKISH da var). 12.2'de gelen TO_NUMBER() metni DOUBLE sayıya çevirir; biçimle eşleşmeyen girişte NULL döndürüp 1411 numaralı uyarıyı üretir. Yine 12.2 ile gelen TRUNC() bir tarihi güne, aya veya yıla göre keser. Belgelerdeki örnekler:

SELECT TO_NUMBER('$1,234,567.89', '$9,999,999.99');
+---------------------------------------------+
| TO_NUMBER('$1,234,567.89', '$9,999,999.99') |
+---------------------------------------------+
|                                  1234567.89 |
+---------------------------------------------+

SELECT TRUNC('2025-09-24 12:43','MM');
+--------------------------------+
| TRUNC('2025-09-24 12:43','MM') |
+--------------------------------+
| 2025-09-01 00:00:00            |
+--------------------------------+

TO_CHAR() fonksiyonunun davranışı da 12.0 ve 12.3'te genişledi; 12.3 sürümünde biçim dizesindeki FM öğesi kendisinden sonraki bileşenlerin dolgusunu kapatır ve birden fazla kez yazıldığında dolguyu sırayla açıp kapatır. 12.2'den itibaren JSON_DEPTH() için en fazla derinlik sınırı kalktı; önceki sürümlerde sınır 32'ydi. JSON fonksiyonlarının genel kullanımı MariaDB JSON fonksiyonları yazısında anlatılıyor.

Veri değiştirme tarafında 12.3, UPDATE deyimine CTE desteği getirdi. Belgelere göre bu, MySQL'in yaptığına benzer şekilde SQL standardının bir uzantısıdır ve CTE'ler diğer türetilmiş tablolar gibi salt okunurdur; yani CTE içindeki tabloların sütunlarını güncelleyemezsiniz. CTE yazımının temelleri için CTE ve WITH RECURSIVE yazısına bakın.

WITH cte1 AS (SELECT * FROM t1 WHERE c < 5),
     cte2 AS (SELECT * FROM t2 WHERE b < 5)
     UPDATE t3, cte1 SET t3.a = cte1.a WHERE cte1.b IN (SELECT b FROM cte2);

Programlanabilir nesneler

MariaDB 12.0'dan itibaren tek bir trigger birden fazla olay için tanımlanabilir. Gövde içinde INSERTING, UPDATING ve DELETING koşullarıyla trigger'ı hangi olayın tetiklediğini anlayabilirsiniz. Belgelerdeki örnek:

CREATE TRIGGER t1_b_any BEFORE INSERT OR UPDATE OR DELETE ON t1 FOR EACH ROW
BEGIN
  IF INSERTING THEN
    INSERT INTO t2 VALUES (NEW.a, 'INSERTING');
  ELSEIF UPDATING THEN
    INSERT INTO t2 VALUES (NEW.a, 'UPDATING');
  ELSEIF DELETING THEN
    INSERT INTO t2 VALUES (OLD.a, 'DELETING');
  END IF;
END

Saklı yordamlar tarafında 12.3, cursor'ların bir hazır deyim (prepared statement) adına bağlanabilmesini getirdi; böylece yordamlar içinde dinamik SQL ile cursor kullanmak mümkün hale geldi. Önceki sürümlerde cursor'lar yalnızca sabit SELECT deyimleri için tanımlanabiliyordu. 12.0.1 ile DECLARE TYPE ... IS TABLE OF ... INDEX BY sözdizimiyle ilişkisel diziler geldi. 12.3 ile gelen SET PATH ise saklı yordamların hangi şemalarda aranacağını belirler; varsayılan değer 'CURRENT_SCHEMA' olduğu için geleneksel davranış değişmez. Trigger ve yordamların temelleri için trigger yazısına ve stored procedure yazısına bakın.

SET PATH 'sys';
CALL optimizer_switch_on();

Hesaplar ve güvenlik

• SET SESSION AUTHORIZATION (12.0): SET USER yetkisi olan bir kullanıcı sunucuda başka bir kullanıcı olarak işlem yapabilir. Belgelere göre bu, hesap kilidini, süresi dolmuş parolayı, kimlik doğrulamayı ve REQUIRE SSL kontrollerini atlar; transaction, hazır deyim ve saklı yordam içinde çalışmaz. Yetkiyi yalnızca gerçekten ihtiyaç duyan yönetici hesaplarına verin.
• DROP USER davranışı (12.1): bağlı olan bir hesabı silerseniz hesap silinir ama bağlantı kapanana kadar etkin kalır ve deyim bir uyarıyla tamamlanır. Bağlantıyı KILL CONNECTION ile sonlandırmanız gerekir. Belgelerde anlatılan FORCE yan tümcesi Community Server'da bulunmaz.
• caching_sha2_password (12.1): MySQL'den taşınan hesapların parolalarını değiştirmeden kullanabilmek için uyumlu eklenti ve dört yeni sistem değişkeni geldi; ayrıntılar MySQL'den geçiş yazısında.
• ssl_passphrase (12.0): TLS sistem değişkenleri arasına eklendi; TLS yapılandırması için SSL/TLS yazısına bakın.
• Foreign key adları (12.1): foreign key sembol adının artık veritabanı genelinde değil, tablo başına benzersiz olması yeterli.

İstemciler ve araçlar

• mariadb istemcisi 12.0 ile --script-dir seçeneğini kazandı: source komutuyla çağrılan betikler için ayrı bir arama dizini belirlenebilir. İstemcinin diğer seçenekleri için komut satırı istemcisi yazısına bakın.
• mariadb-dump 12.1 ile -L, --wildcards seçeneğini kazandı: tablo veya veritabanı adlarında joker karakter kullanılabilir.
• mariadb-dumpslow 12.1'den itibaren dökümü JSON biçiminde yazabilir.
• mariadb-check 12.0'dan itibaren sequence nesnelerini destekler.

Uyumluluğu etkileyen değişiklikler

Yeni özelliklerin yanında bazı şeyler kaldırıldı veya değişti. big_tables, storage_engine ve large_page_size seçenekleri MariaDB 12.0'da kaldırıldı; storage_engine yerine default_storage_engine kullanılmalıdır. CONVERSION ve TO_DATE artık ayrılmış kelimedir. Ters yönde bir örnek de var: 1149 hata sayfasına göre ACCESSIBLE 12.0 öncesinde ayrılmıştı ve artık tırnaksız tablo adı olarak kullanılabilir. systemd servisi için MYSQLD_OPTS ortam değişkeni kullanımdan kaldırılmış olarak işaretlendi. 12.3'e yükselten Galera kullanıcılarının mariadb-server-galera paketini elle kurması gerekir. 12.3.3 ile, bir kaydı büyüten UPDATE işlemlerinde InnoDB'nin B-tree küçültüp küçültmeyeceğini belirleyen innodb_index_shrink değişkeni eklendi (varsayılan ON, önceki davranışla aynı).

Hangi özellik hangi sürümde? Özet

Sık yapılan hatalar

• 13.x özelliklerini 12.3'te beklemek: Belgelerde "MariaDB 13.0" olarak işaretlenen özellikler (örneğin innodb_log_archive) 12.3 LTS'te yoktur.
• InnoDB tabanlı binlog'u konum tabanlı replikasyonla kullanmak: Yeni biçim yalnızca GTID ile konumlandırma destekler ve Galera ile kullanılamaz.
• Replikaları yükseltmeden birincili yeni binlog biçimine geçirmek: Replikaların önce en az 12.3'e yükseltilmesi gerekir.
• DROP USER sonrası oturumun kapandığını sanmak: 12.1 ve sonrasında hesap silinir ama açık bağlantı KILL CONNECTION ile kapatılana kadar çalışır.
• reorder_outer_joins bayrağını açıp prune ayarını unutmak: Belgeler bayrakla birlikte optimizer_prune_level=0 önerir.
• XMLTYPE ile XML doğrulaması beklemek: İlk uygulama yalnızca saklama sağlar.
• Yeni ayrılmış kelimeleri gözden kaçırmak: CONVERSION veya TO_DATE adlı tırnaksız bir sütun 1064 hatası verir.

Sık Sorulan Sorular

12.3 LTS mi, yoksa rolling bir sürüm mü?

Bu yazının dayandığı belgelerde 12.3 güncel LTS sürümü olarak geçer; 11.8 ise yükseltme sayfasında "önceki uzun süreli bakım sürümü" olarak anılır. LTS sürümleri belgelere göre beş yıl bakım görür.

Yeni optimizer hint'lerini 11.8'de kullanabilir miyim?

Hayır. Yeni tarz hint'ler belgelere göre 12.0 ve 12.1 ile geldi. 11.8'de USE INDEX, FORCE INDEX, IGNORE INDEX ve STRAIGHT_JOIN gibi eski değiştiricileri kullanabilirsiniz.

InnoDB tabanlı binary log'u açmalı mıyım?

GTID replikasyonu kullanıyorsanız, Galera'ya ihtiyacınız yoksa ve binlog dosyalarını doğrudan okuyan bir araç kullanmıyorsanız belgeler yüksek işlem hacmi ve sıkı dayanıklılık için bu biçimi önerir. Mevcut bir sunucuyu geçirirken eski binlog dosyalarının kullanılamaz hale geleceğini hesaba katın.

12.x'te hangi seçenekler kaldırıldı?

11.8'den 12.3'e yükseltme sayfası big_tables, storage_engine ve large_page_size seçeneklerini listeler; üçü de 12.0'da kaldırıldı. Yapılandırma dosyanızda kalırlarsa sunucu başlamayabilir.

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 sürüm yükseltme · EXPLAIN ve optimizer hint'leri · MariaDB binary log · MariaDB replikasyon ve GTID · MariaDB nedir