Smart Style
0120-429-223
見積・お問合せ

2025.01.22

MariaDB

MariaDB Enterprise Server 11.4.4-2 GA版（リリース日：2025年1月16日）

概要

MariaDB Enterprise Server 11.4.4-2は、MariaDB Enterprise Server 11.4の最初のGAリリースです。

ここでリストされている変更は、MariaDB Enterprise Server 10.6.19-15に関連しています。

ストレージエンジンの変更

  • InnoDBストレージエンジンにより、InnoDBテーブルスペースをインポートするプロセスが簡素化されました。
    • このリリースより前では、プロセスは、テーブルを作成し、テーブルスペースを破棄し、それから、ALTER TABLE IMPORT TABLESPACEを実行することでした。
    • このリリース以降、必要なコマンドは、ALTER TABLE IMPORT TABLESPACEのみになります。
    • 例: 
      FLUSH TABLES t1 FOR EXPORT;
--copy_file $MYSQLD_DATADIR/test/t1.cfg $MYSQLD_DATADIR/test/t2.cfg
--copy_file $MYSQLD_DATADIR/test/t1.frm $MYSQLD_DATADIR/test/t2.frm
--copy_file $MYSQLD_DATADIR/test/t1.ibd $MYSQLD_DATADIR/test/t2.ibd
UNLOCK TABLES;
ALTER TABLE t2 IMPORT TABLESPACE;
  • InnoDBストレージエンジンを使用すると、InnoDBシステムテーブルスペース内の解放されたページが占有するスペースを再利用することができます。
    • このリリースより前は、InnoDBデータファイルは、通常の操作中に縮小することはありませんでした。.ibdファイルは、OPTIMIZE TABLEを使用してテーブルを再構築し、SET GLOBAL innodb_undo_log_truncate=ONを使用してテーブルスペースファイルをundoすることで縮小できました。
    • このリリース以降、innodb_data_file_pathシステム変数に :autoshrink属性が追加されました。
    • :autoshrinkを使用すると、InnoDBシステムテーブルスペースは、その中の最後の割り当てられたページの後で、指定された最小サイズまで切り捨てることができます。
    • 例えば、この構成では、InnoDBシステムテーブルスペースを12MiBまで縮小できます: 
      [mariadb]
...
innodb_data_file_path=ibdata1:12M;ibdata2:50M:autoextend:autoshrink
  • InnoDBストレージエンジンでは、システム変数の変更により、ログファイルとデータファイルの制御が向上します:
    • ログファイルの制御用に、innodb_log_file_bufferingおよびinnodb_log_file_write_throughシステム変数が追加されました。これらのシステム変数はブール値であり、サーバーの実行中に動的に設定できます。
    • データファイルの制御用に、innodb_data_file_bufferingおよびinnodb_data_file_write_throughシステム変数が追加されました。これらのシステム変数はブール値であり、サーバーの実行中に動的に設定できます。
    • innodb_flush_methodシステム変数は非推奨となり、削除されました。
  • InnoDBストレージエンジンでは、一括挿入のパフォーマンスが向上します。
  • InnoDBストレージエンジンでは、InnoDBのREDOログ形式を変更すると書き込み増幅が減り、パフォーマンスが向上する可能性があります。
  • InnoDBストレージエンジンでは、InnoDB変更バッファが削除されました:
    • 最新のストレージ速度では、InnoDB変更バッファはパフォーマンスの向上をもたらすのではなく、オーバーヘッドを増やす傾向があります。
    • InnoDB変更バッファを削除すると、内部リカバリプロセスも簡素化されます。
    • innodb_change_bufferingおよびinnodb_change_buffer_max_sizeシステム変数が削除されました。
    • Innodb_ibuf_discarded_delete_marks、Innodb_ibuf_discarded_deletes、Innodb_ibuf_discarded_inserts、Innodb_ibuf_free_list、Innodb_ibuf_merged_delete_marks、Innodb_ibuf_merged_deletes、Innodb_ibuf_merged_inserts、Innodb_ibuf_merges、Innodb_ibuf_segment_size、およびInnodb_ibuf_sizeステータス変数は削除されました。
  • InnoDBストレージエンジンでは、プレフィックスインデックスクエリの最適化が常に使用されます:
    • この機能は、もともとMariaDB Server 10.1でオプションの最適化として実装されていました。
    • Innodb_secondary_index_triggered_cluster_readsおよびInnodb_secondary_index_triggered_cluster_reads_avoidedステータス変数は削除されました。
  • InnoDBストレージエンジンでは、複数のUNDOテーブルスペースがデフォルトで有効になっているため、デフォルト構成ではサーバーの実行中にUNDOログを切り捨てることができます:
    • 切り捨てはシステムテーブルスペースのUNDOログには適用されません。
    • innodb_undo_tablespacesのデフォルトが0から3に変更されました。
    • スペースを再利用するためには、innodb_undo_log_truncate=ONを設定する必要があります。
    • innodb_undo_log_truncate=ONは、一部のワークロードのパフォーマンスに影響を与える可能性があります。このような場合、一時的に次の設定を行うことで、UNDO切り捨てを有効にすることができます: 
      SET GLOBAL innodb_undo_log_truncate=ON;
  • InnoDBストレージエンジンを使用すると、一時InnoDBテーブルスペースを再起動せずに縮小できるようになりました。
    • MariaDB Enterprise Server 11.4より前では、一時InnoDBテーブルスペースによって使用されるディスク領域を再利用するための唯一の方法は、サーバーを再起動することでした。一時テーブルスペースはサーバーを停止すると削除され、設定されたサイズで再作成されるためです。
    • ディスク領域を再利用できるようになりました。使用中のテーブルは削除されません。新機能をトリガーするコマンドは次のとおりです: 
      SET GLOBAL innodb_truncate_temporary_tablespace_now=1;

      例:

      CREATE TEMPORARY TABLE t1(f1 INT NOT NULL, f2 INT NOT NULL)ENGINE=InnoDB;
INSERT INTO t1 SELECT seq, seq FROM seq_1_to_65536;
DROP TABLE t1;
SELECT NAME, FILE_SIZE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES WHERE NAME="innodb_temp
orary";
      +------------------+-----------+
| NAME             | FILE_SIZE |
+------------------+-----------+
| innodb_temporary |  79691776 |
+------------------+-----------+
      SET GLOBAL INNODB_TRUNCATE_TEMPORARY_TABLESPACE_NOW= 1;
SELECT NAME, FILE_SIZE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES WHERE NAME="innodb_temp
orary";
      +------------------+-----------+
| NAME             | FILE_SIZE |
+------------------+-----------+
| innodb_temporary |  12582912 |
+------------------+-----------+
  • Spiderストレージエンジンでは、エンジン定義の属性 (テーブルオプション) が受け入れられます。以前は、Spiderではテーブルに対してCOMMENT経由でパラメータを指定する必要がありました:
    新しいテーブルオプション 古いCOMMENTオプション 説明
    REMOTE_DATABASE database リモートテーブルを含むリモートデータベース
    REMOTE_SERVER srv リモートテーブルを含むリモートサーバーのIPアドレスまたはホスト名
    REMOTE_TABLE tbl リモートテーブル
  • Spiderストレージエンジンのシステム変数のデフォルトが変更されました。
  • Spiderストレージエンジンでは、Spiderパラメータを指定するための推奨方法は、専用のSpiderテーブルオプションを使用することです。テーブルCOMMENT句の乱用は非推奨になりました。
  • MyRocksストレージエンジンでは、rocksdb_log_dirシステム変数で指定されたユーザー定義のディレクトリにログファイルを保存できます。

互換性の強化

  • ストアド関数のパラメータは、IN、OUT、INOUT、およびIN OUTで修飾できます:
    • パラメータがINで修飾されている場合、値は関数に渡されます。
    • パラメータがOUTで修飾されている場合、関数は呼び出し元に値を返します。
    • パラメータがINOUTまたはIN OUTで修飾されている場合、値は関数に渡され、関数も呼び出し元に値を返します。
    • OUT、INOUT、およびINOUTは、SETから呼び出される場合にのみ使用でき、SELECTから呼び出される場合は使用できません。
    • OUT、INOUT、およびINOUTを使用すると、関数が複数の値を返すことができるため、より複雑でネストされた関数が可能になります。
    • 以前のリリースでは、修飾子はストアドプロシージャではサポートされていましたが、ストアド関数ではサポートされていませんでした。
    • このリリース以降、修飾子は、ストアドプロシージャで以前使用されていたのと同じ構文を使用して、ストアド関数で受け入れられます。
    • sql_mode=ORACLEが設定されている場合、動作はOracleの動作に合わせて調整されます。
  • TIMESTAMPフィールドプロパティのデフォルトの動作が変更されました:
    • このリリースより前は、実装固有の動作がテーブルの最初のTIMESTAMP列に対してデフォルトで存在していました。この動作により、TIMESTAMPフィールドプロパティにDEFAULT current_timestamp() ON UPDATE current_timestamp()が追加されました。
    • このリリース以降、TIMESTAMPフィールドプロパティの実装固有の動作はデフォルトで無効になっています。explicit_defaults_for_timestampシステム変数のデフォルト値はOFFに変更されました。
    • この変更の結果、明示的なデフォルト値のない新しいTIMESTAMP列はDEFAULT NULLで作成されます。

運用の強化

  • オンラインスキーマ変更 (OSC) は、全てのスキーマ変更 (ALTER TABLE コマンド) を非ブロッキングにする新しいサーバー内部機能です。
    • OSCは、これまでサードパーティのソリューションで解決できた問題を運用上の影響を軽減する方法で対象としています。OSC実装のいくつかの側面は、運用上重要です:
      • OSCは内部でコピー適用置換を実行します: 最初に、変更されたテーブルがコピーされ、次にオンライン変更が適用されます。最後の変更を適用してテーブルの名前を変更すると、短いテーブルロックが発生します。このプロセスではバイナリログは使用されません。この問題に対するサードパーティのアプローチの中には、接続タイムアウトなどの要因の影響を受ける可能性のあるクライアント接続に依存するものもあるため、これは重要です。
      • OSCは非同期です: アプリケーションからの変更は、最初にオンライン変更バッファに格納されます。この問題に対するサードパーティのアプローチの一部は同期的であり、結果として他のトランザクションの実行に影響を与えるため、これは重要です。
      • OSCはトリガーレスです: ALTER TABLEが進行中の場合は、DML側のチェック用のサーバー内部ハンドラーのみが使用されます。ストアドルーチンに基づくINSERT、UPDATE、またはDELETEトリガーは使用されません。この問題に対するサードパーティのアプローチの一部はトリガーに依存しているため、これは重要です。
    • デフォルトでは、ALTER操作をINSTANTで実行できない場合、OSCが使用されます。OSCを使用できない場合は、別のアルゴリズムが使用されます。
    • ALTERステートメントでLOCK=NONEオプションが明示的に指定されている場合、または同等のステートメント ALTER ONLINE TABLEが使用されている場合、操作はOSCとして実行できる場合は実行され、それ以外の場合は失敗します。
    • この新しい動作のオーバーライドとして、old_modeシステム変数がLOCK_ALTER_TABLE_COPYで設定されている場合、LOCK=NONEが明示的に設定されていない時は、古い動作が優先されます。
  • ストアド ルーチンの呼び出しは、ストアド ルーチンが依存するオブジェクトのメタデータに対するすべての変更を反映します。
    • このリリースより前は、ストアドルーチンが変更されたオブジェクトからメタデータを更新する前に、再接続が必要でした。例えば、再接続がない場合: 
      CREATE TABLE t1 (id INT);
INSERT INTO t1 VALUES (100);
CREATE PROCEDURE p1() SELECT * FROM t1;
CALL p1;
      +------+
| id |
+------+
| 100 |
+------+
      ALTER TABLE t1 ADD COLUMN b INT DEFAULT 0;
CALL p1;
      +------+
| id |
+------+
| 100 |
+------+
      • このリリース以降、メタデータの変更は再接続なしで反映されます: 
        CREATE TABLE t1 (id INT);
INSERT INTO t1 VALUES (100);
CREATE PROCEDURE p1() SELECT * FROM t1;
CALL p1;
        +------+
| id |
+------+
| 100 |
+------+
        ALTER TABLE t1 ADD COLUMN b INT DEFAULT 0;
CALL p1;
        +------+------+
| id | b |
+------+------+
| 100 | 0 |
+------+------+
  • 一時テーブルがinformation_schema.TABLES、SHOW TABLES出力、およびSHOW TABLE STATUS出力に含まれるようになりました。
    • 例: 
      CREATE DATABASE test;
USE test;
CREATE TABLE t1 (id int);
CREATE TEMPORARY TABLE t2_temp (id int);
SHOW FULL TABLE;
      +----------------+-----------------+
| Tables_in_test | Table_type |
+----------------+-----------------+
| t2_temp | TEMPORARY TABLE |
| t1 | BASE TABLE |
+----------------+-----------------+
      SELECT table_schema, table_name, table_type FROM information_schema.TABLES WHERE table_schema='test';
      +--------------+------------+------------+
| table_schema | table_name | table_type |
+--------------+------------+------------+
| test | t2_temp | TEMPORARY |
| test | t1 | BASE TABLE |
+--------------+------------+------------+
  • 複数の行を挿入するINSERT操作に関して、エラーレポートが改善されました:
    • GET DIAGNOSTICSでは、ROW_NUMBERプロパティを使用して、エラーまたは警告の原因となった行番号を取得できます: 
      GET DIAGNOSTICS CONDITION 1 @failed_row=ROW_NUMBER;
  • 情報スキーマシステムテーブルの最適化:
    • PARAMETERSがクエリされ、WHERE句がSPECIFIC_SCHEMAおよびSPECIFIC_NAMEでフィルター処理される場合、インデックスがテーブル全体のスキャンを回避するために使用されます。
    • ROUTINESがクエリされ、WHERE句がROUTINE_SCHEMAおよびROUTINE_NAMEでフィルター処理される場合、インデックスがテーブル全体のスキャンを回避するために使用されます。
  • SHOW EXPLAIN FOR CONNECTION_IDは、別の接続で実行されているクエリのクエリプランを表示できます: 
    SHOW EXPLAIN FOR 1;
    • このステートメントはクエリ自体を警告として返します。これはSHOW WARNINGSを介して取得できます。
  • SHOW ANALYZE [FORMAT=JSON] FOR CONNECTION_IDは、別の接続で実行されているクエリを分析できます: 
    SHOW ANALYZE FOR 1;
  • ANALYZE FORMAT=JSONは、クエリオプティマイザーで費やされた時間を表示します。
  • mariadb-dumpでは、新しい --order-by-sizeコマンドラインオプションを使用して、テーブルをサイズ順にダンプできます (最小のテーブルが最初): 
    $ mariadb-dump \
--user=USER \
--password='PASSWORD' \
--all-databases \
--single-transaction \
--order-by-size
    • この新しいオプションは、--single-transactionコマンドラインオプションが指定され、頻繁に切り捨てられるテーブルがバックアップに含まれている場合に役立ちます。頻繁に切り捨てられるテーブルはサイズが小さくなる傾向があるため、それらのテーブルは早めにバックアップされ、バックアップがER_TABLE_DEF_CHANGEDエラー コードで失敗する可能性が低くなります。
  • transaction_isolationシステム変数を使用して、トランザクション分離を設定できるようになりました:
    • tx_isolationシステム変数は、別名として引き続き使用できますが、非推奨になっており、今後のリリースで削除される予定です。
  • transaction_read_onlyシステム変数を使用して、トランザクションを読み取り専用に設定できるようになりました。
  • プロセスリストに、ステートメントによって送信された行数が含まれるようになりました。情報スキーマ テーブル PROCESSLISTの新しい値 SENT_ROWSには、プロセスリストに表示される現在のステートメントによって送信された行数が含まれます。
    • 関数を含むSELECTSは、メインステートメントと全ての関数によって送信された行の合計数を表示します
    • ストアドプロシージャは、ストアドプロシージャステートメントごとに送信された行の合計数を表示します
    • INSERT RETURNINGとDELETE RETURNINGは、返されるデータセットに対して送信された行の合計数を表示します
    • 例: 
      select * from processlist\G
      *************************** 1. row ***************************
...
*************************** 2. row ***************************
ID: 6
USER: root
HOST: localhost
DB: test
COMMAND: Query
TIME: 1
STATE: Sending data
INFO: select * from t1
TIME_MS: 1340.406
STAGE: 0
MAX_STAGE: 0
PROGRESS: 0.000
MEMORY_USED: 89856
MAX_MEMORY_USED: 392544
EXAMINED_ROWS: 0
SENT_ROWS: 3895737
QUERY_ID: 436
INFO_BINARY: select * from t1
TID: 100
  • 後で分析するためにクライアントに送信されたエラーをログに記録するために使用されるSQLエラーログプラグインが強化されました。オプション sql_error_log_with_db_and_thread_info=ONが設定されている場合、ログファイルには、エラーのスレッドIDと現在のデフォルトスキーマも表示されるようになりました。
  • mariadb-dumpをオプション -T / --tab= とともに使用して、テーブルごとにタブ区切りのテキスト形式のデータファイルを生成する場合、新しいオプション --parallel (同義語 --use-threads) を使用して、複数のスレッドを並列に使用してテーブルデータを.txtファイルにダンプできます。
    • オプション --single-transactionが使用される場合も、並列処理が機能します。
  • オプション --parallelは、以前から使用可能であった--use-threadsの同義語としてmariadb-importに追加されました。

オプティマイザー

  • MariaDBクエリオプティマイザーは、ストレージエンジン固有のコストを理解した上で、コストベースの最適化を実行します:
    • クエリオプティマイザーは、デフォルトでSSDストレージが使用されていると想定するようになりました。ディスクアクセスのコストは上書きできます。
    • オプティマイザーのコストは、設定ファイル、コマンドラインパラメータ、またはSET SQLステートメントを使用して次のシステム変数を設定することで調整できます:
      システム変数 タイプ 説明
      optimizer_disk_read_cost エンジン ストレージから4Kブロックを読み取るのに必要な時間をマイクロ秒単位で設定します。デフォルト値は、400MB/秒でSSD読み取り用に調整されています。
      optimizer_index_block_copy_cost エンジン グローバルキャッシュ内のブロックをロックして、それをローカルキャッシュにコピーするためのコストを設定します。ブロックが既にキャッシュされているかどうかに関係なく、アクセスされる全てのブロックにコストが適用されます。
      optimizer_key_compare_cost エンジン 2つのキー値を比較するコストを設定します。
      optimizer_key_copy_cost エンジン キー値の検索中に、インデックスからローカルバッファにキー値をコピーするコストを設定します。
      optimizer_key_lookup_cost エンジン インデックス内のキーエントリを見つけるためのコストを設定します。
      optimizer_row_copy_cost エンジン インデックス内の次のキーエントリを見つけるためのコストを設定します。
      optimizer_rowid_compare_cost エンジン 2つのrowid値を比較するコストを設定します。
      optimizer_rowid_copy_cost エンジン インデックスからrowidをコピーするコストを設定します。
      optimizer_row_lookup_cost エンジン rowidに基づいて行を見つけるコストを設定します。rowidは、キーとともにインデックスに格納されます。
      optimizer_row_next_find_cost エンジン 次の行を見つけるコストを設定します。
      optimizer_scan_setup_cost セッション テーブルまたはインデックススキャンを開始するためのコストを設定します。デフォルトの低い値は、行数が非常に少ないテーブルに対してインデックスルックアップを使用するようにオプティマイザを設定します。
      optimizer_where_cost セッション 見つかった行ごとにWHERE句を実行するためのコストを設定します。この値が大きくなるにつれて、オプティマイザーはより少ない行を読み取るプランを選択する可能性が高くなります。
      • システム変数の前にストレージエンジン名を付けることで、ストレージエンジンごとにオプティマイザーコストを調整できます。
        • 各ストレージエンジンの現在のオプティマイザーコストは、information_schema.OPTIMIZER_COSTSを介してクエリできます。
  • 多数のeq_refテーブルを含むJOINの場合、クエリパフォーマンスが向上します:
    • 新しいシステム変数 optimizer_extra_pruning_depth
    • プルーン結合プレフィックスを有効にするために、システム変数 optimizer_prune_levelのデフォルトが1から2に変更されました
    • 新しいステータス変数 Optimizer_join_prefixes_check_calls
  • DATE()関数の戻り値を定数値と比較する時に、インデックスを使用できるようになりました。
  • 単一テーブルのUPDATEおよびDELETEで、セミ結合の最適化のメリットを享受できるようになりました。
  • 詳細なヒストグラムコレクションを備えたJSONヒストグラム:
    • histogram_type=JSON_HBが設定されている場合に有効になります。これが現在デフォルトです。
    • JSONヒストグラムにより、文字列データタイプの場合、または列のデータ分布が非常に不均一な場合に、より正確なデータ統計が得られます。
    • より正確なデータ統計により、オプティマイザーはより優れたクエリプランを作成でき、クエリが高速になります。

パーティショニング

  • テーブルは、ALTER TABLE .. CONVERT TABLE .. TO PARTITIONを使用してパーティションに変換できます: 
    ALTER TABLE partitioned_tab
CONVERT TABLE tab1
TO PARTITION part_name VALUES LESS THAN (1000000);
    • ALTER TABLE .. CONVERT TABLE .. TO PARTITION操作は、以前はMariaDB Enterprise Server 10.6.11-6にバックポートされました。
  • パーティションは、ALTER TABLE .. CONVERT PARTITION .. TO TABLEを使用してテーブルに変換できます: 
    ALTER TABLE partitioned_tab
CONVERT PARTITION part_name
TO TABLE tab1;
    • ALTER TABLE .. CONVERT PARTITION .. TO TABLE操作は、以前はMariaDB Enterprise Server 10.6.11-6にバックポートされました。
  • CREATE TABLE構文が拡張されたため、各パーティション定義でPARTITION キーワードはオプションになりました: 
    CREATE TABLE partitioned_tab (
col1 int
)
PARTITION BY RANGE(col1) (
part1 VALUES LESS THAN (1000000),
part2 VALUES LESS THAN (2000000),
part3 VALUES LESS THAN (3000000),
part4 VALUES LESS THAN (4000000),
part5 VALUES LESS THAN (5000000),
part_end VALUES LESS THAN MAXVALUE
);
  • エンジン定義の属性はパーティションごとに定義できます: 
    CREATE TABLE remote_spider_tab (
id INT,
str VARCHAR(255),
PRIMARY KEY(id)
) ENGINE=Spider
PARTITION BY RANGE(id) (
PARTITION east_part VALUES LESS THAN (100) REMOTE_SERVER="mdb-east.example.org" REMOTE_TABLE="tab1",
PARTITION west_part VALUES LESS THAN MAXVALUE REMOTE_SERVER="mdb-west.example.org", REMOTE_TABLE="tab1"
);
  • パーティションの交換やテーブルの変換は、パーティション式の検証なしでも可能になりました
    • この新しい機能は、パーティションルールが満たされていない場合に不整合が発生する可能性があるため、注意して使用する必要があります。
    • ALTER TABLEに新しく追加されたのは次の通りです: 
      EXCHANGE PARTITION partition_name WITH TABLE tbl_name [{WITH | WITHOUT} VALIDATION]
CONVERT TABLE normal_table TO partition_definition [{WITH | WITHOUT} VALIDATION]

システムのバージョン管理

  • INTERVALまたはLIMITでパーティション化されている場合、履歴パーティションの作成はAUTOキーワードを使用して自動化できます: 
    CREATE TABLE t1 (x int) WITH SYSTEM VERSIONING
PARTITION BY system_time INTERVAL 1 months AUTO;
    • 上記の例では、履歴行バージョンを格納するための新しい履歴パーティションが毎月作成されます。
  • --dump-historyコマンドラインオプションが指定されている場合、mariadb-dumpはシステムバージョン管理されたテーブルから履歴データをバックアップできます。
  • --as-ofコマンドラインオプションが指定されている場合、mariadb-dumpは特定の時点の履歴データのダンプを実行できます。
  • アプリケーション期間テーブルに関する詳細情報が、情報スキーマで利用できるようになりました
    • 新しいビュー PERIODおよびKEY_PERIOD_USAGEがinformation_schemaに追加されました。
      • ビュー PERIODSには、次の列が含まれます
        • TABLE_CATALOG
        • TABLE_SCHEMA
        • TABLE_NAME
        • PERIOD_NAME
        • START_COLUMN_NAME
        • END_COLUMN_NAME
          アプリケーション期間テーブル、期間に定義された名前、および開始および終了タイムスタンプに使用される列を一覧表示します。
      • ビュー KEY_PERIOD_USAGEには、次の列が含まれます
        • CONSTRAINT_CATALOG
        • CONSTRAINT_SCHEMA
        • CONSTRAINT_NAME
        • TABLE_CATALOG
        • TABLE_SCHEMA
        • TABLE_NAME
        • PERIOD_NAME
  • information_schemaのCOLUMNSビューに2つの新しい列が追加されました
    • IS_SYSTEM_TIME_PERIOD_START
    • IS_SYSTEM_TIME_PERIOD_END

SQLレベルの強化

  • ストアドルーチンのパッケージの一般的なサポートが追加されました
    • MariaDB Enterprise Server 11.4より前では、CREATE PACKAGE機能とCREATE PACKAGE BODYは、sql_mode = ORACLEでのみサポートされていました。これらは、現在はどのSQL モードでも使用できます。
    • 例: 
      DELIMITER $$

CREATE OR REPLACE PACKAGE myPkg
  PROCEDURE p1();
  FUNCTION f1() RETURNS INT;
END;

$$

CREATE OR REPLACE PACKAGE BODY myPkg

  -- variable declarations
  DECLARE v1 INT DEFAULT 1;
  DECLARE v2 INT DEFAULT 10;

  -- routine declarations
  PROCEDURE p1()
  BEGIN
    SELECT v1, v2;
  END;

  FUNCTION f1() RETURNS INT
  BEGIN
    RETURN v1;
  END;

  -- package initialization
  SET v1=v1 + 2;
END;
$$

DELIMITER ;

SELECT myPkg.f1();
      +------------+
| myPkg.f1() |
+------------+
| 3 |
+------------+
      CALL myPkg.p1();
      +------+------+
| v1 | v2 |
+------+------+
| 3 | 10 |
+------+------+

インデックス

  • 降順インデックスがサポートされています:
    • 複合インデックスと併用すると、定義された順序とは異なる順序で列に対してORDER BY操作を実行するクエリのパフォーマンスを大幅に向上させるために使用できます。
    • 以前のリリースでは、MariaDB Enterprise Serverは、ORDER BYのDESCオプションを既にサポートしていましたが、オプティマイザーは昇順インデックスを使用していました。複合インデックスの場合、オプティマイザーはインデックスを使用してファイルソートを実行する必要があります。
    • 例えば、次のサンプルテーブルを使用します: 
      CREATE TABLE sections (
top_level int,
sub_level int,
index top_asc_sub_asc (top_level ASC, sub_level ASC),
index top_asc_sub_desc (top_level ASC, sub_level DESC),
index top_desc_sub_asc (top_level DESC, sub_level ASC),
index top_desc_sub_desc (top_level DESC, sub_level DESC)
);
INSERT INTO sections VALUES
(1, 1), (1, 2), (2, 1), (2, 2),
(3, 1), (3, 2), (3, 3);
      • 複数の列に対してORDER BY .. ASCを実行しても、EXPLAIN出力に"Using index"と表示されます: 
        EXPLAIN SELECT * FROM sections
ORDER BY top_level ASC, sub_level ASC;
        +------+-------------+----------+-------+---------------+-----------------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+----------+-------+---------------+-----------------+---------+------+------+-------------+
| 1 | SIMPLE | sections | index | NULL | top_asc_sub_asc | 10 | NULL | 7 | Using index |
+------+-------------+----------+-------+---------------+-----------------+---------+------+------+-------------+
        • この変更により、複数の列に対してORDER BY .. ASC、.. DESCを組み合わせて実行すると、EXPLAIN 出力に"Using index"と表示されます: 
          EXPLAIN SELECT * FROM sections
ORDER BY top_level ASC, sub_level DESC;
          +------+-------------+----------+-------+---------------+------------------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+----------+-------+---------------+------------------+---------+------+------+-------------+
| 1 | SIMPLE | sections | index | NULL | top_asc_sub_desc | 10 | NULL | 7 | Using index |
+------+-------------+----------+-------+---------------+------------------+---------+------+------+-------------+

JSON

  • JSON_KEY_VALUE()は、JSONオブジェクトからキー/値のペアを抽出します。
    • 構文: JSON_KEY_VALUE(<json_doc>, <json_path>)
    • <json_path>は、キー/値のペアを返すJSONオブジェクトを指定します。例: 
      SELECT JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]');
      +-----------------------------------------------------------------------------+
| JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]') |
+-----------------------------------------------------------------------------+
| [{"key": "key1", "value": "val1"}, {"key": "key2", "value": "val2"}] |
+-----------------------------------------------------------------------------+

      • JSON_KEY_VALUE()は、JSON_TABLE()の引数として使用でき、結果セットにキーを追加します。例: 
        SELECT jt.* FROM JSON_TABLE(
JSON_KEY_VALUE('[[1, {"key1":"val1", "key2":"val2"}, 3], 2, 3]', '$[0][1]'),'$[*]'
COLUMNS (
k VARCHAR(20) PATH '$.key',
v VARCHAR(20) PATH '$.value',
id FOR ORDINALITY )) AS jt;
        +------+------+------+
| k | v | id |
+------+------+------+
| key1 | val1 | 1 |
| key2 | val2 | 2 |
+------+------+------+
  • JSON_ARRAY_INTERSECT()は、2つのJSON配列の交差部分を検索します。
    • 構文: JSON_ARRAY_INTERSECT(<array1>, <array2>)
    • 例: 
      SET @array1= '[1,2,3]';
SET @array2= '[1,2,4]';
SELECT json_array_intersect(@array1, @array2) as result;
      +--------+
| result |
+--------+
| [1, 2] |
+--------+
      SET @json1= '[[1,2,3],[4,5,6],[1,1,1]]';
SET @json2= '[[1,2,3],[4,5,6],[1,3,2]]';
SELECT json_array_intersect(@json1, @json2) as result;
      +------------------------+
| result |
+------------------------+
| [[1, 2, 3], [4, 5, 6]] |
+------------------------+
  • JSON_OBJECT_TO_ARRAY()は、JSONドキュメント内にある全てのJSONオブジェクトをJSON配列に変換します。
    • 構文: JSON_OBJECT_TO_ARRAY(<json_doc>)
    • 例: 
      SET @json1= '{ "a" : [1,2,3] , "b": {"key1": "val1", "key2": {"key3": "val3"}} }';
SELECT JSON_OBJECT_TO_ARRAY(@json1) as result;
      +-----------------------------------------------------------------------+
| result |
+-----------------------------------------------------------------------+
| [["a", [1, 2, 3]], ["b", {"key1": "val1", "key2": {"key3": "val3"}}]] |
+-----------------------------------------------------------------------+
    • 結果の配列は、JSON_ARRAY_INTERSECT()を使用して比較できます。例: 
      SET @json1='{"a":[1,2,3],"b":{"key1":"val1","key2":{"key3":"val3"}}}';
SET @json2='{"a":[1,2,3]}';
SELECT JSON_OBJECT_TO_ARRAY(@json1) into @array1;
SELECT JSON_OBJECT_TO_ARRAY(@json2) into @array2;
SELECT JSON_ARRAY_INTERSECT(@array1,@array2) as result;
      +--------------------+
| result |
+--------------------+
| [["a", [1, 2, 3]]] |
+--------------------+
  • JSON_OBJECT_FILTER_KEYS()は、配列内のキーのJSON文字列からキー/値のペアを返します。
    • 構文: JSON_OBJECT_FILTER_KEYS(<json_doc>,<array_keys>)
    • 例: 
      SET @json1= '{ "a": 1, "b": 2, "c": 3}';
SELECT JSON_OBJECT_FILTER_KEYS (@json1, ' ["b", "c"] ') as result;
      +------------------+
| result |
+------------------+
| {"b": 2, "c": 3} |
+------------------+
    • JSON_ARRAY_INTERSECT()とJSON_KEY()をJSON_OBJECT_FILTER_KEYS()の引数として使用すると、キー/値のペアではなく、同じキーのみが比較される2つのJSON文字列の比較が可能になります。例: 
      SET @json1= '{ "a": 1, "b": 2, "c": 3}';
SET @json2= '{"b" : 10, "c": 20, "d": 30}';
SELECT JSON_OBJECT_FILTER_KEYS (@json1, json_array_intersect(json_keys(@json1), json_keys(@json2))) as result;
      +------------------+
| result |
+------------------+
| {"b": 2, "c": 3} |
+------------------+
  • JSON_EQUALS()を使用すると、2つのドキュメントを比較し、それらが等しいかどうかを判断できます。
    • JSON_EQUALS()関数は、以前はMariaDB Enterprise Server 10.4.25-16、10.5.16-11、および10.6.8-4にバックポートされました。
  • JSON_NORMALIZE()を使用すると、2つのJSONドキュメントを正規化して比較しやすくすることができます。
    • 例えば、この関数は、JSONデータに一意のキーを定義する時に使用できます。
    • JSON_NORMALIZE()関数は、以前はMariaDB Enterprise Server 10.4.25-16、10.5.16-11、および10.6.8-4にバックポートされました。
  • JSON_OVERLAPS()を使用すると、2つのJSONドキュメントを比較し、共通のキーと値のペアまたは配列要素があるかどうかを判断できます。 
    SELECT JSON_OVERLAPS('{"A": 1, "B": {"C":2}}', '{"A": 2, "B": {"C":2}}') AS is_overlap;
    +---------------------+
| is_overlap |
+---------------------+
| 1 |
+---------------------+
  • JSON_SCHEMA_VALID()は、JSONスキーマドラフト2020に記載されているように、JSONドキュメントをJSONスキーマに対して検証するために使用できます。
    • この関数は、CHECK制約で使用して、JSONドキュメントが、必要な項目を含み、値が指定された範囲と長さ内にある場合にのみデータベースに保存されることを確認することもできます。
  • JSONパス式がJSON関数へのパラメータとして使用されている場合、負のインデックスを使用して、配列の末尾を基準としてJSON配列内の値にアクセスできます。 
    SELECT JSON_REMOVE(@json, '$.A[-10]')
  • JSONパス式がJSON関数へのパラメータとして使用されている場合、最後のインデックスを使用して、 JSON配列の最後の値にアクセスできます。 
    SELECT JSON_REMOVE(@json, '$.A[last]');
  • JSONパス式がJSON関数へのパラメータとして使用されている場合、インデックスの範囲を使用して、 JSON配列内のその範囲の値にアクセスできます。 
    SELECT JSON_REMOVE(@json, '$.A[1 to 3]');

データタイプ

  • TIMESTAMP値の範囲が '``2038-01-19 03:14:07 UTC``' から '``2106-02-07 06:28:15 UTC``' に拡張されました。
    • ストレージ形式は変更されておらず、タイムスタンプ値が古いタイムスタンプ範囲内にある限り、新しいテーブルは古いMariaDBサーバーで読み取ることができます。
  • INET4値をINET6値と比較し、INET6列に挿入できるようになりました。サーバーは必要に応じてINET4値をINET6に自動的に変換します。
  • UUIDをより効率的に保存するために、UUIDデータタイプが追加されました。
    • UUIDデータタイプは、以前はMariaDB Enterprise Server 10.6.9-5にバックポートされました。
  • INET4データタイプは、IPv4アドレスをBINARY(4)として保存するために追加され、各バイトに1つのオクテットが格納されます。
    • このデータタイプは次の機能を提供します:
      • 不正な値の検証
      • 比較
      • ソート
      • CAST()などの関数

関数

  • 関数 DATE_FORMAT()の新しいタイムゾーンオプション
    • 新しいオプション %Zおよび%zは、日付文字列にタイムゾーン情報を追加するための関数 "DATE_FORMAT(date, format)"の書式文字列に使用できます 
      DATE_FORMAT(date, format)
    • %Z タイムゾーンの省略形
    • %z UTCからの時間と分のオフセットを表す数値タイムゾーン +hhmm または -hhmm
    • 例: 
      SELECT DATE_FORMAT(NOW(), '%W %d %M %Y %H:%i:%s %Z %z');
      +--------------------------------------------------+
| DATE_FORMAT(NOW(), '%W %d %M %Y %H:%i:%s %Z %z') |
+--------------------------------------------------+
| Tuesday 21 November 2023 13:28:34 EST -0500 |
+--------------------------------------------------+
  • キー導出用のSQL関数 KDF()
    • 考えられる使用例は、ユーザーが指定したパスワードまたはパスフレーズから暗号化キーを生成することです。AES_ENCRYPTなどの暗号化関数の暗号化キーを生成するために使用できます。 
      KDF(key_str, salt [, {info | iterations} [, kdf_name [, width ]]])
      • kdf_nameは、"hkdf"または"pbkdf2_hmac"です
      • width (ビット単位) は、8で割り切れる任意の数値です
      • infoは、hkdfメソッドの非秘密パラメータであり、同じ秘密パスワードから異なる目的の異なる暗号化キーを生成できます
      • iterationsは、pbkdf2_hmacメソッドの正の数値パラメータです。値が大きいほど、パスワードをブルートフォースすることが難しくなります。
    • 例: 
      select hex(kdf('foo', 'bar', 'info', 'hkdf'));
      +----------------------------------------+
| hex(kdf('foo', 'bar', 'info', 'hkdf')) |
+----------------------------------------+
| 710583081D40A55F0B573A76E02D8975 |
+----------------------------------------+
      insert into tbl values (aes_encrypt(@secret_data, kdf("Passw0rd", "NaCl", "info", 'hkdf'), "iv"));
  • 関数 CONV()は、base 62までの変換をサポートするようになりました
    • 数値基数システム間で数値を変換する関数 CONV()は、base 62までの変換をサポートするようになりました。
    • これにより、大文字 A ～ Z、小文字 a ～ z、および数字 0 ～ 9へのエンコードへの変換が可能になります。
    • 以前の制限は、小文字を除いて36でした。
    • 例: 
      SELECT CONV(61,10,36);
      +----------------+
| CONV(61,10,36) |
+----------------+
| 1P |
+----------------+
      SELECT CONV(61,10,62);
      +----------------+
| CONV(61,10,62) |
+----------------+
| z |
+----------------+
  • AES_ENCRYPT() および AES_DECRYPT()では、初期化ベクトル (iv) およびブロック暗号化モード (mode)を指定できます。
    • このリリースより前のAES_ENCRYPT構文: AES_ENCRYPT(<str>, <key_str>)
    • このリリース以降のAES_ENCRYPT構文: AES_ENCRYPT(<str>, <key>, [, iv [, mode]])
    • このリリースより前のAES_DECRYPT構文: AES_DECRYPT(<str>, <key_str>)
    • このリリース以降のAES_DECRYPT構文: AES_DECRYPT(<str>, <key>, [, iv [, mode]])
    • block_encryption_modeシステム変数は、モードが関数の引数として指定されていない場合に使用されるモードを指定します。
    • 例えば、block_encryption_modeのデフォルトモードを使用する場合: 
      SELECT @@block_encryption_mode;

.. code-block:: cmp

   +-------------------------+
   | @@block_encryption_mode |
   +-------------------------+
   | aes-128-ecb             |
   +-------------------------+

.. code-block:: sql

   SELECT HEX(AES_ENCRYPT('MariaDB','mykey','vector')) as result;

.. code-block:: cmp

   +----------------------------------+
   | result                           |
   +----------------------------------+
   | CD0352A4B2FB18A592C04FF8CDA6C2F2 |
   +----------------------------------+

.. code-block:: sql

   SELECT AES_DECRYPT(x'CD0352A4B2FB18A592C04FF8CDA6C2F2','mykey','vector') as result;

.. code-block:: cmp

   +---------+
   | result  |
   +---------+
   | MariaDB |
   +---------+
      • 例えば、モードを引数として指定します: 
        SELECT HEX(AES_ENCRYPT('MariaDB','mykey','thisismy256vector','aes-256-cbc')) as result;
        +----------------------------------+
| result |
+----------------------------------+
| CD6C47183B89A813557BFD639A893CE3 |
+----------------------------------+
        SELECT AES_DECRYPT(x'CD6C47183B89A813557BFD639A893CE3','mykey','thisismy256vector','aes-256-cbc') as result;
        +---------+
| result |
+---------+
| MariaDB |
+---------+
  • RANDOM_BYTES()は、1 ～ 1024バイトの長さのバイナリ文字列を返します。
    • この非決定論的な値は、SSLライブラリの暗号論的に安全な疑似乱数ジェネレータ (CSPRNG) によって生成されるため、暗号化の使用に適した暗号化ランダムバイトの任意の長さの文字列を生成します。
  • NATURAL_SORT_KEY()を使用すると、文字列の自然なソートを実行できます。
    • 文字はアルファベット順にソートされますが、数字は「10」が「9」よりも大きくなるようにソートされます。
    • 例えば、「v10」は文字列「v9」の後に表示されます。
  • SFORMAT()は、指定されたオプションと値に基づいて文字列をフォーマットし、カスタムフォーマットされた文字列を生成します。 
    SELECT SFORMAT("MariaDB version {}", VERSION());
    • この関数は、Python、Rust、C++20と同様に、文字列のフォーマットにfmtlibライブラリを使用します。
  • CRC32()は、ISO 3309多項式を使用して、巡回冗長検査 (CRC)を32ビットの符号なし値として計算します。
    • オプションの2番目のパラメータを使用して、CRCを部分的に計算できるようになりました。CRC32('String')は、CRC32(CRC32('Str','ing'))に等しくなります。
    • CRC32C()は、代替Castagnoli多項式を使用してチェックサムを計算するために使用できます。

文字セットと照合順序

  • character_set_collationsシステム変数を使用すると、文字セットのデフォルトの照合順序をグローバルまたはセッションごとに変更できます。
    • このリリース以降、データベースオブジェクトに文字セットが定義されているが照合順序が定義されていない場合は常に、デフォルトの照合順序が使用されます。
    • このリリース以降、文字セットが定義されていない場合、デフォルトの照合順序は collation_serverシステム変数で指定されたものになります。 
      SET @@character_set_collations='utf8mb4=uca1400_ai_ci';
CREATE DATABASE test_with_charset CHARACTER SET utf8mb4;
CREATE DATABASE test;
SELECT SCHEMA_NAME,DEFAULT_COLLATION_NAME FROM SCHEMATA WHERE SCHEMA_NAME LIKE "test%";
      +-------------------+------------------------+
| SCHEMA_NAME | DEFAULT_COLLATION_NAME |
+-------------------+------------------------+
| test_with_charset | utf8mb4_uca1400_ai_ci |
| test | utf8mb4_general_ci |
+-------------------+------------------------+
  • 文字セット utf8mb3、utf8mb4、ucs2、utf16、およびutf32に対して、Unicode照合アルゴリズム (UCA) 14.0.0 に基づく照合が追加されました:
    • 1つの中立照合と22の言語固有の照合が追加されました。
    • アクセントを区別する、アクセントを区別しない、大文字と小文字を区別する、大文字と小文字を区別しない、パディングなしのバリエーションが追加されました。
    • 新しいUCA 14.0.0照合の照合名は、文字セットプレフィックスなしで指定できます。これは、文字セットプレフィックスがコンテキストから自動的に検出されるためです。例えば、utf8mb4_uca1400_german_as_ciの代わりにuca1400_german_as_ciを指定できます。文字セットプレフィックス付きの照合名は、新しいUCA 14.0.0照合で受け入れられますが、オプションです。
    • information_schema.COLLATIONSテーブルで新しいUCA 14.0.0照合に関するメタデータをクエリすると、COLLATION_NAME列には文字セットプレフィックスのない照合名が含まれ、CHARACTER_SET_NAME列にはNULLが含まれます。これは、これらの照合が複数の文字セットに適用できることを示します。
    • information_schema.COLLATION_CHARACTER_SET_APPLICABILITYテーブルで新しいUCA 14.0.0照合の文字セット適用性をクエリすると、COLLATION_NAME列にも文字セットプレフィックスのない照合名が含まれます。新しいFULL_COLLATION_NAME列が追加されました。この列には、新しいUCA 14.0.0照合を含む全ての照合の完全な照合名 (文字セットプレフィックス付き) が含まれます。
    • UCA照合の短縮パフォーマンスが向上しました。
    • utf8mb3およびutf8mb4文字セットのUCA照合パフォーマンスが向上しました。
  • Microsoft Windowsでは、MariaDBコマンドラインツールに完全なUnicodeサポートが含まれるようになりました。
    • Unicodeサポートは、Microsoft Windows 10 1909以降、Microsoft Windows 11、およびMicrosoft Windows Server 2020で利用できます。
    • my.ini設定ファイルが、UTF-8でエンコードされるようになりました。
    • mariadb.exeコマンドラインクライアントは、デフォルトの文字セットとしてutf8mb4を使用します。

セキュリティ機能

  • クライアントからサーバーへの接続では、デフォルトでSSL暗号化が必要になりました
    • SSL (より正確な用語はTLS ですが、実際にはSSLの方が一般的に使用されています) の使用は、MariaDB Enterprise Server 11.4で簡素化されました。
    • バージョン 11.4より前では、適切なSSL設定には、サーバーとそれに接続する全てのクライアントに対して複数の手動手順が必要でした。
    • 現在、クライアントは、一切の設定を行わずにサーバーの自己署名証明書を検証できます。サーバーはSSL証明書を完全に自動的に生成し、クライアントは必要に応じてそれを自動的に検証します。
    • デフォルトの設定では、暗号化されていない接続が拒否されるようになりました。
  • 新しい権限 SHOW CREATE ROUTINEにより、この権限を持つ全てのユーザーがストアドルーチンの定義を表示できるようになりました。
    • MariaDB Enterprise Server 11.4より前では、ユーザーは次の場合にのみルーチン、ストアド機能、または関数の定義を表示できました:
      • mysql.procsテーブルにSELECT権限が存在する場合
      • ユーザーがストアドプロシージャの定義者である場合
    • SHOW CREATE ROUTINE権限は、グローバルに、スキーマごとに、または個々のルーチンに付与できます。
    • 権限 SHOW CREATE ROUTINEのない例: 
      show grants;
      +--------------------------------------------------+
| Grants for user1@% |
+--------------------------------------------------+
| GRANT USAGE ON *.* TO `user1`@`%` |
| GRANT SELECT, EXECUTE ON `test`.* TO `user1`@`%` |
+--------------------------------------------------+
      show create procedure myProc \G
      *************************** 1. row ***************************
Procedure: myProc
sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Create Procedure: NULL
character_set_client: utf8mb3
collation_connection: utf8mb3_general_ci
Database Collation: utf8mb4_general_ci
    • 新しい権限 SHOW CREATE ROUTINEがある例: 
      show grants;
      +-----------------------------------------------------------------------+
| Grants for user1@% |
+-----------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `user1`@`%` |
| GRANT SELECT, EXECUTE, SHOW CREATE ROUTINE ON `test`.* TO `user1`@`%` |
+-----------------------------------------------------------------------+
      show create procedure myProc \G
      *************************** 1. row ***************************
Procedure: myProc
sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Create Procedure: CREATE DEFINER=`root`@`localhost` PROCEDURE `myProc`()
BEGIN
SELECT "My Definiton of a Stored Procedure";
END
character_set_client: utf8mb3
collation_connection: utf8mb3_general_ci
Database Collation: utf8mb4_general_ci
  • 特定のテーブルごとにユーザー権限を取得するためのSYSスキーマの新しいビュー
    • SYSスキーマのビュー privileges_by_table_by_levelには、ユーザー、スキーマ、テーブルごとの権限と権限レベルがリストされます。
    • 例: 
      CREATE DATABASE test;
use test;
CREATE TABLE t1 (id int);
CREATE USER user1;
GRANT SELECT, UPDATE ON *.* TO user1;
CREATE USER user2;
GRANT SELECT ON test.* TO user2;
CREATE USER user3;
GRANT SELECT ON test.t1 TO user3;
SELECT * FROM sys.privileges_by_table_by_level WHERE GRANTEE NOT LIKE "'root'@'%'";
      +--------------+------------+-------------+-----------+--------+
| TABLE_SCHEMA | TABLE_NAME | GRANTEE | PRIVILEGE | LEVEL |
+--------------+------------+-------------+-----------+--------+
| test | t1 | 'user1'@'%' | SELECT | GLOBAL |
| test | t1 | 'user1'@'%' | UPDATE | GLOBAL |
| test | t1 | 'user2'@'%' | SELECT | SCHEMA |
| test | t1 | 'user3'@'%' | SELECT | TABLE |
+--------------+------------+-------------+-----------+--------+
  • パスワード関連データの新しい情報スキーマテーブル
    • 新しい情報スキーマビュー USERSが追加されました。これを使用して、DBAはユーザーのパスワード関連情報についての洞察を得ることができます。この情報は次のために使用できます:
      • 期限切れが近づいているパスワードについて、または、間違ったパスワードの入力回数が原因でブロックされる恐れのあるアカウントについて、アプリケーションユーザーに通知するために
      • 無効なパスワードの入力回数が多すぎるためにブロックされたユーザーをDBAが照会するために
    • 新しいビューには、次のフィールドが含まれます:
      • USER ‐ ユーザー名とホストを含む文字列
      • PASSWORD_ERRORS ‐ 間違ったパスワードが入力された現在の数を示すカウンター
        • 正しいパスワードが入力されると0にリセットされます
        • max_password_errorsに達すると、アカウントはブロックされます
        • CONNECTION ADMIN権限を持つアカウントの場合はNULL
      • PASSWORD_EXPIRATION_TIME ‐ パスワードの有効期限が切れる日時、または、パスワードの有効期限が切れない場合はNULL
  • 新しい認証プラグイン ‐ PARSEC (Password Authentication using Response Signed with Elliptic Curves)
    • PARSECは、ソルト化されたパスワード、時間のかかるキー導出関数、および中間者攻撃者がクライアントの応答を制御できないようにするためのクライアント側のスクランブルを導入することによって、古い認証プラグインよりもセキュリティを向上させます。
    • 新しい認証プラグインを使用してユーザーを作成する方法の例: 
      CREATE USER 'MariaDBUser'@'%' IDENTIFIED VIA PARSEC USING PASSWORD('MyPassword123!');
    • この結果は次のようになります: 
      SHOW GRANTS FOR MariaDBUser@'%';
Grants for MariaDBUser@%
GRANT USAGE ON *.* TO `MariaDBUser`@`%` IDENTIFIED VIA parsec USING 'P0:lhXyNv1cIxpB8EnTxR7ON7S7:1l3rWRW1/jw45yrvYXB8eh02wzk7lcJcz4CMcWw2b+8'
  • password_reuse_checkプラグインは、ユーザーが以前そのユーザーに設定されていたパスワードを設定することを防ぐ方法を実装します。
    • password_reuse_check_intervalシステム変数は、パスワードを再利用できるまでの日数を指定します。
    • このプラグインは、リテラルパスワード文字列を使用してユーザーパスワードを設定するSQLステートメントにのみ影響します。ハッシュ化されたパスワード値を使用するSQLステートメントのパスワードをチェックすることはできません。
    • このプラグインは、mysql.password_reuse_check_historyシステムテーブルに保存されているパスワード履歴レコードを使用します。テーブルの各行には、暗号化ハッシュと日付が格納されます。ハッシュ化されたデータには、影響を受けるユーザーと設定されているパスワードに関する情報が含まれます。これは一方向の暗号化ハッシュであるため、格納されたデータを使用して、以前のパスワード値を抽出したり、履歴レコードがどのユーザーに関連付けられているかを抽出したりすることはできません。
    • password_reuse_checkプラグインは、以前はMariaDB Enterprise Server 10.4.25-16、10.5.16-11、および10.6.8-4にバックポートされました。
  • GRANT .. TO PUBLICを使用すると、システム上で現在認証されている全てのユーザーと新しく認証されたユーザーに権限を付与できます。
  • SHOW GRANTS FOR PUBLICは、publicに付与されている全ての権限を取得します。
  • SUPER権限から細かな権限が削除されました:
    ES 11.4.4-2以降、SUPERから細かな権限が削除されました
    READ ONLY ADMIN
    BINLOG ADMIN
    BINLOG MONITOR
    BINLOG REPLAY
    CONNECTION ADMIN
    FEDERATED ADMIN
    REPLICATION MASTER ADMIN
    REPLICATION SLAVE ADMIN
    SET USER
    SLAVE MONITOR
    • アップグレードすると、SUPER権限を持つ各ユーザーには、SUPERから削除された権限が付与されるため、ユーザーの機能は変更されません。
    • SUPER権限は、次のような特殊なケースで引き続き使用されます:
      • 明示的なキーなしでDES_ENCRYPT()およびDES_DECRYPT()を呼び出す
      • SET GLOBALを使用して特定のシステム変数を動的に変更する
      • 特定のデバッグ設定を変更する
    • この変更により、SUPER権限を持つユーザーがREAD ONLY ADMIN権限も持たない場合に読み取り専用レプリカに書き込みを試みても、読み取り専用レプリカの一貫性が保護されるようになりました。
      • 読み取り専用レプリカは、プライマリとの一貫性を保つためにread_only=1が設定されているレプリカ サーバーです。
      • SUPER権限を持つユーザーが読み取り専用レプリカサーバーへの書き込みアクセスを必要とする場合は、そのユーザーにREAD ONLY ADMIN権限を明示的に付与する必要があります。

MariaDBレプリケーション

  • サーバーインスタンスごとにバイナリログによって使用されるスペースを制限するための新しいオプション
    • 新しいシステム変数 max_binlog_total_size (別名 binlog_space_limit) により、全てのバイナリログの合計サイズが指定された閾値を超えた場合にバイナリログの消去が有効になります。
    • max_binlog_total_sizeのデフォルトは0で、制限がないことを意味します。
    • システム変数は、サーバーを再起動せずに変更できます。
  • 新しいシステム変数 --slave-connections-needed-for-purgeは、デフォルトで1に設定されています。
    • 少なくともその数のレプリカが接続され、消去されたバイナリログが不要になるまで、バイナリログの消去は行われません。
  • 新しいステータス変数 binlog_disk_useは、バイナリログによって現在使用されているディスク領域を提供します。
  • START REPLICA UNTILの新しいオプション SQL_BEFORE_GTIDSおよびSQL_AFTER_GTIDS
    • START REPLICA UNTILの新しいオプション SQL_BEFORE_GTIDSおよびSQL_AFTER_GTIDSを使用すると、ユーザーは指定されたGTID状態の前または後にレプリカが停止するかどうかを制御できます。
      • 構文は次のとおりです: 
        START SLAVE UNTIL (SQL_BEFORE_GTIDS|SQL_AFTER_GTIDS)="<gtid_list>"
      • SQL_BEFORE_GTIDS="<gtid_list>を指定すると、gtid_listで指定されたドメインごとに、レプリカは見つかったGTIDまでトランザクションを実行し、指定されたGTIDのトランザクションを実行せずに、そのドメインでのイベントの処理を直ちに停止します。全てのドメインが停止すると、レプリカは停止します。リストに指定されていないドメインから発生したイベントはレプリケートされません。
      • START SLAVE UNTIL SQL_AFTER_GTIDS="<gtid_list>は、MariaDB Enterprise Server 11.4より前の既知の動作であるSTART SLAVE UNTIL master_gtid_pos="<gtid_list>"のデフォルトの動作のエイリアスです。
      • レプリカは、リストに指定されたドメインIDから発生するトランザクションを実行し、UNTILリストに指定された全てのトランザクションが実行されると停止します。
  • バイナリログのGTIDにインデックスが作成されるようになりました。これにより、接続しているレプリカはバイナリログ全体をスキャンする必要なく開始位置を見つけることができます。
    • 新しいシステム変数 binlog_gtid_index (デフォルトはON) を使用すると、インデックスの作成を無効にできます。
    • 新しいシステム変数 binlog_gtid_index_page_size (デフォルトは4096) は、バイナリログGTIDインデックスに使用するページサイズを定義します。
    • 新しいシステム変数 binlog_gtid_index_span_min (デフォルトは65536) は、バイナリログGTIDインデックスのスパース性を制御します。
    • 新しいステータス変数 binlog_gtid_index_hitおよびbinlog_gtid_index_missは、監視目的で使用できます。missは、インデックスファイルが見つからないことを示します。
  • GTIDバイナリログイベントにスレッドIDが含まれるようになりました
    • スレッドIDと対応するステートメントをバイナリログから取得できるようになりました
    • mariadb-binlogの出力にもスレッドIDが含まれます
  • バイナリログフィルターオプション binlog-do-db、binlog-ignore-db、およびbinlog-row-event-max-sizeがシステム変数として表示されるようになりました。
    • 例: 
      SHOW GLOBAL VARIABLES WHERE
Variable_name LIKE 'binlog_do_db' OR
Variable_name LIKE 'binlog_ignore_db' OR
Variable_name LIKE 'binlog_row_event_max_size';
      +---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| binlog_do_db | |
| binlog_ignore_db | |
| binlog_row_event_max_size | 8192 |
+---------------------------+-------+
  • 全てのストレージエンジンで、ALTER TABLEは2つのフェーズに分割され、長時間実行されるDDLステートメントがレプリカでレプリケーションラグを発生させないようにします:
    • binlog_alter_two_phase=1を設定すると有効になりますが、これはデフォルトではありません。
    • 2フェーズのALTER TABLEは楽観的であるため、操作はプライマリサーバーで完了する前にレプリカ サーバーで開始されます。
    • プライマリサーバーのバイナリログには、2つのイベントが書き込まれます: 操作が開始される時にはSTART ALTERイベント、そして、操作が成功したか失敗したかに応じて、操作が終了した時にはCOMMIT ALTERイベントまたはROLLBACK ALTERイベントが書き込まれます。
  • デフォルトでは、レプリケーションはグローバルトランザクションID (GTID) を使用するため、レプリカはクラッシュセーフになります。
    • この変更は下位互換性に影響します。
    • 以前のリリースでは、MASTER_USE_GTIDを明示的に指定せずにCHANGE MASTER TOを実行すると、デフォルトではMASTER_USE_GTID=noになります。
    • このリリース以降、MASTER_USE_GTIDを明示的に指定せずにCHANGE MASTER TOを実行すると、デフォルトではMASTER_USE_GTID=slave_posになります。MASTER_USE_GTID=slave_posの場合、レプリカサーバーはgtid_slave_posシステム変数をGTID位置として使用します。
    • この変更により、次の操作を実行する時に新しい動作が発生する可能性があります:
      • MASTER_USE_GTIDを指定せずにCHANGE MASTER TOを使用して新しいレプリカを設定する
      • レプリカ設定でMASTER_USE_GTIDが明示的に設定されていない場合に、START REPLICAを使用して停止されたレプリカを新しく起動します。
      • RESET REPLICAを使用してレプリカをリセットする
    • MASTER_LOG_FILEとMASTER_LOG_POSが明示的に設定されている場合、MASTER_USE_GTID=noが暗黙的に設定されます。
  • mariadb-binlogの場合、開始位置と停止位置はGTIDとして指定できます: 
    $ mariadb-binlog --start-position='0-1-1001,1-2-1000' \
--stop-position='0-1-2000,1-2-1050' \
mariadb-bin.000001
    • --start-positionコマンドラインオプションは、開始GTID位置をGTIDのコンマ区切りリストとして設定できます。指定された各GTIDドメインの場合、GTID位置は排他的であるため、イベントは、そのシーケンス番号がそのドメインに指定されたシーケンス番号より大きい場合にのみ表示されます。
    • --stop-positionコマンドラインオプションは、終了GTID位置をGTIDのコンマ区切りリストとして設定できます。指定された各GTIDドメインの場合、GTID位置は包含的であるため、イベントは、そのシーケンス番号がそのドメインに指定されたシーケンス番号以上である場合にのみ表示されます。
    • どちらのコマンドラインオプションも、コンマ区切りリスト内の各GTIDに異なるドメインIDが必要です。
  • mariadb-binlogの場合、イベントはイベントのGTID内のドメインIDとサーバーIDに基づいてフィルターできます: 
    $ mariadb-binlog --do-domain-ids='0,1' \
--do-server-ids='1,2' \
mariadb-bin.000001
    • --do-domain-idsコマンドラインオプションは、読み取られるドメインIDをドメインIDのカンマ区切りリストとして設定できます。指定されたドメインIDのいずれかがイベントのGTIDにない場合、イベントは表示されません。
    • --ignore-domain-idsコマンドラインオプションは、無視されるドメインIDをドメインIDのカンマ区切りリストとして設定できます。指定されたドメインIDのいずれかがイベントのGTIDにある場合、イベントは表示されません。
      $ mariadb-binlog --start-position='0-1-1001,1-2-1000' \
      --stop-position='0-1-2000,1-2-1050' mariadb-bin.000001
    • --start-positionコマンドラインオプションは、開始GTID位置をGTIDのコンマ区切りリストとして設定できます。指定された各GTIDドメインの場合、GTID位置は排他的であるため、イベントは、そのシーケンス番号がそのドメインに指定されたシーケンス番号より大きい場合にのみ表示されます。
    • --stop-positionコマンドラインオプションは、終了GTID位置をGTIDのコンマ区切りリストとして設定できます。指定された各GTIDドメインの場合、GTID位置は包含的であるため、イベントは、そのシーケンス番号がそのドメインに指定されたシーケンス番号以上である場合にのみ表示されます。
    • どちらのコマンドラインオプションも、コンマ区切りリスト内の各GTIDに異なるドメインIDが必要です。

Galeraクラスター

以下の変更は、MariaDB Enterprise Server 11.4のGalera Clusterに関係します:

  • Galeraによる自動SSTユーザーアカウント管理
    • 新しいノードに完全なデータコピーを提供するために必要な状態スナップショット転送 (SST) 方式では、SSTプロセス中にリモートサーバー (ドナー) にアクセスするための専用アカウントが必要です。
    • MariaDB Enterprise Cluster (Galera) は、SST時にユーザーを内部的に作成するようになったため、アカウントを手動で作成する必要がなくなります。これにより、設定ファイルでユーザーとパスワードを指定する必要がなくなりました。Galeraによってユーザーが作成されると、必要な権限も確実に設定されます。
  • SHOW [FULL] PROCESSLISTおよびinformation_schema.PROCESSLISTの新しい接続状態は、接続の状態をより適切に反映します:
    接続状態 説明
    waiting to execute in isolation 接続はwsrep_osu_method=TOIのDDLステートメントを実行していますが、この操作では他の同時操作が先に完了する必要があるため、DDLステートメントを分離して実行できます。
    waiting for TOI DDL 別の接続はwsrep_osu_method=TOIのDDLステートメントを実行しているため、この接続はDDLステートメントが終了するまで待機する必要があります。
    waiting for flow control 接続はトランザクションをコミットしていますが、トランザクションはフロー制御のために現在一時停止されているため、接続はクラスターが追いついてトランザクションの一時停止を解除するのを待機しています。
    waiting for certification 接続はトランザクションをコミットしていますが、他のクラスターノードがトランザクションを認証するのを待機しています。
  • ノード状態の変更は、wsrep_status_fileシステム変数で設定されたマシン読み取り可能なJSONファイルに保存できます: 
    [mariadb]
wsrep_status_file=galera_status.json
    • JSONファイルは監視ツールで読み取ることができます。
    • wsrep_status_fileがパスに設定されている場合、ノード状態の変更は指定されたファイルに書き込まれます。
    • wsrep_status_fileがnoneに設定されている場合、この機能は無効になります。
  • [sst]オプショングループでprogressオプションを設定することにより、MariaDB Enterprise BackupベースのSSTの進行状況レポートを作成します: 
    [mariadb]
wsrep_sst_method=mariabackup
wsrep_debug=1

[sst]
progress=1
rlimit=100m
    • 進行状況レポートは、MariaDB Enterprise BackupベースのSSTでのみサポートされているため、wsrep_sst_method=mariabackupは設定される必要があります。
    • 進捗レポートは、wsrep_debug=1が設定されている場合にのみ有効です。
    • progress=1が設定されている場合、進捗レポートは標準エラー (stderr) に送信されます。
    • progressがパスに設定されている場合、進捗レポートは指定されたファイルに書き込まれます。
    • progressがnoneに設定されている場合、進捗レポートは無効になります。
    • rlimitを使用すると、バイト単位でレート制限を設定できます。値には、単位を表すサフィックスを使用できます。キロバイトの場合はk、メガバイトの場合はm、ギガバイトの場合はg、テラバイトの場合はtです。
    • SST進捗レポートには、pvユーティリティがインストールされている必要があります。
    • 進捗レポートが有効になっている場合、SST中に次のSST進捗メッセージがMariaDBログに書き込まれます:
    • wsrep_status_fileがnone に設定されている場合、この機能は無効になります。
  • [sst]オプショングループのprogressオプションを設定することで、MariaDB Enterprise BackupベースのSSTの進行状況レポートを作成します: 
    [mariadb]
wsrep_sst_method=mariabackup
wsrep_debug=1

[sst]
progress=1
rlimit=100m
    • 進行状況レポートは、MariaDB Enterprise BackupベースのSSTでのみサポートされるため、wsrep_sst_method=mariabackupは設定される必要があります。
    • 進行状況レポートは、wsrep_debug=1が設定されている場合にのみ有効です。
    • progress=1 が設定されている場合、進行状況レポートは標準エラー (stderr) に送信されます。
    • progressがパスに設定されている場合、進行状況レポートは指定されたファイルに書き込まれます。
    • progressがnone に設定されている場合、進行状況レポートは無効になります。
    • rlimitを使用すると、バイト単位でレート制限を設定できます。値には単位を表すサフィックスを使用できます。キロバイトの場合はk、メガバイトの場合はm、ギガバイトの場合はg、テラバイトの場合はtです。
    • SST進捗レポートには、pvユーティリティがインストールされている必要があります。
    • 進捗レポートが有効になっている場合、SST中に次のSST進捗メッセージがMariaDBログに書き込まれます:

プラットフォーム

エンタープライズライフサイクルに合わせて、MariaDB Enterprise Server 11.4.4-2は以下に対して提供されます：

  • Debian 11 (x86_64、ARM64)
  • Debian 12 (x86_64、ARM64)
  • Red Hat Enterprise Linux 8 (x86_64、ARM64)
  • Red Hat Enterprise Linux 9 (x86_64、ARM64、PPC64LE)
  • AlmaLinux 8 (x86_64、ARM64)
  • AlmaLinux 9 (x86_64、ARM64)
  • Rocky Linux 8 (x86_64、ARM64)
  • Rocky Linux 9 (x86_64、ARM64)
  • SUSE Linux Enterprise Server 15 (x86_64、ARM64)
  • Ubuntu 20.04 (x86_64、ARM64)
  • Ubuntu 22.04 (x86_64、ARM64)
  • Ubuntu 24.04 (x86_64、ARM64)
  • Microsoft Windows (x86_64) (MariaDB Enterprise Cluster (Galera) のサポートなし)
  • Red Hat UBI 8 (x86_64、ARM64)

Red Hat UBI 8は、Enterprise Server Dockerイメージの一部です。MariaDB Enterprise Cluster (Galera)またはMariaDB ColumnStoreをサポートしていません。

MariaDB Enterprise Serverの一部のコンポーネントは、全てのプラットフォームをサポートしていない可能性があります。

MariaDB Enterprise Server 11.4.4-2 リリースノート（MariaDB社ウェブサイト）：
https://mariadb.com/docs/server/release-notes/mariadb-enterprise-server-11-4/11-4-4-2/

MariaDBプロダクト・サポート・サービス

MariaDB
MariaDBプロダクト・サポート・サービスは、MariaDBおよびその関連製品をご利用されているお客様へ、必要なソフトウェアや専門的なサポートなどを提供するサービスです。

一覧へ

国内企業へのMySQLコンサルティング・
サポートにおいて
20年以上の支援実績、
導入企業はのべ1000社以上。
まずはお気軽にご相談ください。

資料請求

私たちの詳しい支援実績やサービス情報を無料でダウンロードできます

資料請求をする

見積り・お問合せ

MySQLやその他関連サービスについてスペシャリストが丁寧に対応します

お問合せをする