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

2024.09.11

MariaDB

MariaDB Enterprise Server 10.6.19-15 GA版（リリース日：2024年9月9日）

バックポート

  • MariaDB Enterprise Server 10.6.19-15以降では、InnoDBシステムテーブルスペース内の解放されたページが占めるスペースは、次のように、innodb_data_file_pathに:autoshrink属性を追加することで再利用できます：
    [mariadb]
    ...
    innodb_data_file_path=ibdata1:12M;ibdata2:50M:autoextend:autoshrink

    これにより、システムテーブルスペースは、その中の最後の割り当てられたページの後で、指定された最小サイズまで切り捨てられるようになります。

    以前のリリースシリーズでは、通常の操作中にInnoDBデータファイルのサイズが縮小されることはありません。OPTIMIZE TABLEを使用してテーブルを再構築することで.ibdファイルを縮小したり、SET GLOBAL innodb_undo_log_truncate=ONを使用してundoテーブルスペースファイルを縮小したりできました。

  • 数値ベースシステム間で数値を変換する関数CONV()は、現在、基数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 |
    +----------------+
  • JSON 関数 JSON_ARRAY_INTERSECT、JSON_OBJECT_TO ARRAY、および JSON_FILTER_KEYSは、このMariaDB Enterprise ServerリリースシリーズでのJSON関数の適用範囲を拡張するために、後のMariaDB Community Serverリリースシリーズからバックポートされました。
    • 新しいJSON関数 JSON_ARRAY_INTERSECT(, )は、2つのJSON配列の交差を見つけるために使用されます。
      例：

      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関数 JSON_OBJECT_TO_ARRAY()は、JSONドキュメントにある全てのJSONオブジェクトをJSON配列に変換するために使用されます。この場合、外側の配列の各項目は、オブジェクトの単一のキーと値のペアを表します。
      例：

      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関数 JSON_OBJECT_FILTER_KEYS(,)は、で定義されたキーのJSON文字列からキーと値のペアを返します。
      例：

      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文字列の比較が可能になります。
      例（json2にキーが存在するjson1のキー/値ペアのみを表示）：

      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関数 JSON_KEY_VALUE(,)は、JSONオブジェクトからキー/値ペアを抽出します。JSONパスパラメータは、一致する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 |
    +------+------+------+

注目すべき変更点

  • 新しいoptimizer_join_limit_pref_ratio最適化が追加され、JOINおよびORDER BY ... LIMIT構造を使用してクエリを効率的に処理できるようになりました。新しいシステム変数 optimizer_join_limit_pref_ratioは、最適化を無効にするためにデフォルトで0に設定されています。このオプションを有効にするためには、optimizer_join_limit_pref_ratioの値を0以外の値に設定します（値が大きいほど保守的になります。推奨値は100です）。
  • Galeraが26.4.19に更新されました。
    • GCSプロトコルバージョンが変更され、MariaDB Enterprise Clusterの個々のノードのダウングレードが防止されました。

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

  • このリリースには、MariaDB ColumnStoreエンジンバージョン 23.10.2が組み込まれています。

修正された問題

データ損失が発生する可能性があるもの

  • ROW_FORMAT=PAGE（デフォルト）のAriaテーブルに対するALTER TABLE、OPTIMIZE TABLE、またはREPAIR TABLEは、データファイルが4GBより大きい場合、失敗するか、テーブルが破損する可能性があります。
  • 同じサーバーバージョンで作成されたためアップグレードの必要がないテーブルに対してALTER TABLE CHECK PARTITION FOR UPGRADEを実行する時、同じテーブルに対して次のALTER TABLEを実行すると、サーバーがクラッシュします。
  • 圧縮行形式を使用するInnoDBテーブルが更新されると、テーブルが破損する可能性があります。

ハングまたはクラッシュを引き起こす可能性があるもの

  • SHOW CREATE DATABASEステートメントを使用すると、データベース名にUnicode文字が含まれている場合に、サーバーがクラッシュする可能性があります。
  • リモート接続がCREATE SERVERで設定されているSPIDERタイプのパーティションテーブルの場合、サーバー定義がDROP SERVERで削除されると、サーバーがクラッシュする可能性があります。
  • 複数のスレッドがSpiderをロードしてSpiderテーブルを作成しようとすると、MariaDBがクラッシュする可能性があります。
  • INNODB_DEFAULT_ROW_FORMAT=redundantで作成されたInnoDBテーブルに対してPAGE_COMPRESSEDオプションを有効にすると、サーバーがクラッシュします。
  • Rowidフィルター最適化を使用する予定のクエリは、クエリ最適化の特定の時点で何らかの要因によって異常終了すると、サーバーをクラッシュさせる可能性があります。このような終了の原因の例は次のとおりです：
    • KILLステートメントでクエリが強制終了される
    • ステートメントの実行が@@max_statement_time制限を超える
  • HAVING NOT 列 句を使用したクエリを実行すると、GROUP BY {{ ... SELECT ... GROUP BY 列 ... HAVING NOT 列}}でも"列"が使用される場合、サーバーがクラッシュする可能性があります。他の形式のHAVING句は影響を受けません。
  • 自動生成されたDELETEステートメントがMEMORYテーブルのバイナリログに追加され、レプリケーションが中断される可能性があります。トリガーが見つからない場合などではDELETEを実行できないため、レプリケーションが停止します。
  • レプリカにreplicate_do_dbが設定されていて、挿入など DMLの実行時にクライアントが別のデータベースにアクセスした場合に、XAトランザクションが使用されると、レプリケーションが失敗します。
  • XAトランザクションがレプリケートされ、レプリカで空のトランザクションが発生すると、チェーン設定でレプリケーションが失敗します。トランザクションの最初のフェーズであるXA STARTからXA PREPAREまではバイナリログに記録されませんが、XA COMMITはバイナリログに記録されるため、チェーン内のさらに先のレプリカでスタンドアロンXA COMMITクエリを実行するとエラーが発生します。
  • 次のようなHAVING句を含むクエリでは、サーバーがクラッシュする可能性があります：
    1. 同じ重要な定数（サブクエリなど）への参照が複数ある場合
    2. 条件プッシュダウン最適化が、HAVING句の参照の少なくとも1つをWHERE句に移動しようとする
  • クエリで派生テーブルが使用され（CTEまたはマージ可能なVIEWも機能する）、WHERE句で派生テーブルの列がCHARSET()またはCOERCIBILITY()関数の値と比較された場合、クエリで間違った結果が生成されたり、クラッシュしたりする可能性があります。原因は、派生条件プッシュダウン最適化によるこれらの関数の不適切な処理でした。
  • MariaDB Enterprise Custerでは、ノードが次のエラーでハングすることがあります： 
    "Deadlock found when trying to get lock; try restarting transaction, Error_code: 1213; handler error HA_ERR_LOCK_DEADLOCK; the event's master log FIRST, end_log_pos 1583, Internal MariaDB error code: 1213"

予期しない動作を引き起こす可能性があるもの

  • レプリカは、master.infoファイルからMASTER_PASSWORDの最初の41文字のみを読み取ります。パスワードの長さが41文字を超える場合、サーバーの再起動時にレプリカでアクセス拒否エラーが発生します。
  • Spiderテーブルにパーティションを追加すると、メモリ違反が発生する可能性があります。
  • MariaDBサーバーは、サーバーが致命的なシグナルを受け取った場合でも、新しい接続の作成を許可できます。
  • バッファプールに空きページがある限り、InnoDBのウォームアップが遅くなります。
    • innodb_buffer_pool_dump_at_shutdown=ONおよびinnodb_buffer_pool_load_at_startup=ONを使用する場合、InnoDBウォームアップは必要ありません
    • 実行時のスローダウンは確認されていません。
  • Mariabackupは、パスワードがコマンドラインオプションとして指定されている場合、パスワードをファイル xtrabackup_infoのtool_command設定に保存します。
  • 準同期バイナリログフェイルオーバーリカバリプロセスでは、プライマリサーバーのバイナリログを切り捨てる条件としてrpl_semi_sync_slave_enabled==TRUEを使用します。これは、サーバーがレプリカとしてレプリケーショントポロジに再度参加することを想定しているためです。ただし、rpl_semi_sync_master_enabled=1とrpl_semi_sync_slave_enabled=1の両方で設定されたサーバーの場合、プライマリが再起動されたばかりの場合（つまり、マスターとしての役割を保持している場合）、そのバイナリログを切り捨てて、そのレプリカがすでに受信して実行したトランザクションを削除することができます。
    • これが発生すると、レプリカが再接続した時に、そのgtid_slave_posが回復したプライマリのgtid_binlog_posより前になる可能性があり、レプリカの状態がプライマリの状態より前になるエラー状態になります。
    • オプション --init-rpl-roleを使用して、サーバーの初期ロールを定義します。可能なオプションは、MASTERとSLAVEで、デフォルトはMASTERです。これをSLAVEに設定することが、準同期リカバリでbinlogを切り捨てる条件になりました。これにより、再起動されたプライマリに対してrpl_semi_sync_master_enabledとrpl_semi_sync_slave_enabledの両方を設定できるようになり、--init-rpl-roleがSLAVEに設定されていない限り、トランザクションは失われません。
  • 派生テーブル内のユニオン内の列エイリアスを参照するグループ化演算子により、プリペアドステートメントで名前解決の問題が発生する可能性があります。
  • テーブル mysql.gtid_slave_posは、wsrep_gtid_mode=OFFが設定されていますが、 2つのMariaDB Enterprise Cluster間でレプリケートされます。
  • wsrep_sst_mariabackupは、SST中にユーザー定義のtmpdirではなく、/tmp dirを使用しています。
  • MariaDB Enterprise Clusterで、次の誤解を招くエラーメッセージが表示されます。Galeraはユーザースレッドを高優先度としてマークできるため、それらを強制終了できません： 
    You are not the owner of the thread ....
    • 現在は次のエラーメッセージが表示されます： 
      This is a high priority thread/query and cannot be killed without compromising the consistency of the cluster
  • 位置パラメータが配列にバインドされたINSERTステートメントをPSモードで実行すると、挿入される行のコピーを何らかのテーブルに配置するためにさらに別のINSERTステートメントを実行するBEFORE INSERTトリガーがある場合、挿入される行の数が正しくなくなる可能性があります。
  • 2つのMariaDB Enterprise Cluster（Galera）環境間で非同期レプリケーションを使用する場合、GTIDのドメインIDが誤って設定またはGaleraによって変更される可能性があります。

パフォーマンスに関連するもの

  • セカンダリインデックスを使用したクエリのパフォーマンスが向上しました。
  • 一部のLinuxシステムでは、データファイルを切り捨てるシステムコール ftruncate()のパフォーマンスの違いにより、クエリのパフォーマンスが低下します。ftruncate()がフラッシュを引き起こすためです。MariaDBは、その一時テーブルを定期的に空にするために"ftruncate"を使用しました。Split Materialized最適化を使用したクエリプランが最も影響を受けます。
  • NAME_CONST()を使用するか、ストアドプロシージャからクエリを実行してローカル変数を参照すると、プランが変更され、実行が遅くなる可能性があります。
  • データベースが多数のテーブルスペースを使用し、inndb_open_filesの値が既存のtable_spacesの数よりも小さい場合、ALTER TABLE ... IMPORT TABLESPACEに不必要な時間がかかることがあります。
  • Rowidフィルターの最適化は、後方インデックススキャンでは機能しません。このようなクエリプランを実行しようとすると、クエリのパフォーマンスが非常に遅くなります。オプティマイザーが後方インデックススキャンを使用することを決定した場合、Rowidフィルターの使用を無効にすることで修正されました。

プラットフォーム

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

  • AlmaLinux 8 (x86_64, ARM64)
  • AlmaLinux 9 (x86_64, ARM64)
  • Debian 11 (x86_64, ARM64)
  • Debian 12 (x86_64, ARM64)
  • Microsoft Windows (x86_64) (MariaDB Enterprise Clusterは除く)
  • Red Hat Enterprise Linux 8 (x86_64, ARM64)
  • Red Hat Enterprise Linux 9 (x86_64, ARM64, PPC64LE)
  • Rocky Linux 8 (x86_64, ARM64)
  • Rocky Linux 9 (x86_64, ARM64)
  • SUSE Linux Enterprise Server 12 (x86_64)
  • 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)

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

MariaDB Enterprise Server 10.6.19-15のリリースノート（MariaDB社ウェブサイト）：
https://mariadb.com/docs/server/release-notes/mariadb-enterprise-server-10-6/10-6-19-15/

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

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

一覧へ