注目すべき変更点
- aria_log_dir_pathシステム変数は読み取り専用として追加されます。
- --aria-log-dir-pathコマンドラインオプションがmariadb-backupに追加されました。
- core_fileシステム変数のデフォルト値がNoneからOFFに変更されました。
- このリリース以降、innodb_buffer_pool_filenameシステム変数は読み取り専用となり、動的に変更できなくなります。
- 以前のリリースでは、innodb_buffer_pool_dump_at_shutdownが有効になっている場合、SUPER権限を持つユーザーはinnodb_buffer_pool_filenameシステム変数の値を動的に変更できました：
SET GLOBAL innodb_buffer_pool_filename='SOME_FILE_PATH' - このリリース以降、サーバーを起動する前に、設定ファイルでinnodb_buffer_pool_filenameシステム変数を設定する必要があります：
[mariadb]
innodb_buffer_pool_filename=SOME_FILE_PATH
- 以前のリリースでは、innodb_buffer_pool_dump_at_shutdownが有効になっている場合、SUPER権限を持つユーザーはinnodb_buffer_pool_filenameシステム変数の値を動的に変更できました：
- デフォルトでは、mariadb-backupはログスキャンに関するメッセージを出力しなくなりました。
- 以前のリリースでは、次のようなメッセージが過剰に出力されることがありました：
>> log scanned up to (LSN) - このリリース以降、ログスキャンに関するメッセージは、--verboseが有効な場合にのみ出力されます。
- 以前のリリースでは、次のようなメッセージが過剰に出力されることがありました：
- aria_log_dir_pathシステム変数は読み取り専用として追加されます。
- パフォーマンススキーマインストゥルメントを使用して、非同期データ ページI/Oに使用されるInnoDBの内部スレッドプールでのミューテックス競合を監視できるようになりました。
- このリリース以降、wait/synch/mutex/innodb/tpool_cache_mutexインストゥルメントを有効にして、read_slotsおよびwrite_slotsの内部tpool::cache::m_mtxミューテックスの競合を追跡できるようになりました。
- performance_schemaが有効な場合、performance_schema.setup_instrumentsテーブル内のインストゥルメントのENABLED列を変更することで、wait/synch/mutex/innodb/tpool_cache_mutexインストゥルメントを有効にできます：
UPDATE performance_schema.setup_instruments
SET ENABLED='YES'
WHERE NAME='wait/synch/mutex/innodb/tpool_cache_mutex'; - インストゥルメントが有効になっている場合、ミューテックス待機に関する詳細は、他のパフォーマンススキーマテーブル（performance-schema.events_waits_current、performance-schema.events_waits_history、performance-schema.events_waits_history_longなど）から取得できます。
- パフォーマンススキーマインストゥルメンテーションを有効にすると、パフォーマンスのオーバーヘッドが発生する可能性があるため、運用システムでパフォーマンススキーマを有効にする場合は特に注意する必要があります。
- InnoDBページのフラッシュ速度が向上しました。
- InnoDBの内部パフォーマンスが向上しました。
- InnoDBのパージスレッドが、まだ再利用されていないキャッシュされたUNDOページを検出すると、そのページは解放されます。このアプローチにより、一部のページ書き込みが回避され、バックアップと復元のパフォーマンスが向上します。また、UNDOログページを保存する時に、システムテーブルスペースまたは一時テーブルスペースが不必要に増大するのを防ぎます。
- InnoDBバッファプール内のページ分割を監視するために、Innodb_buffer_pool_pages_splitステータス変数が追加されました。
ストレージ エンジンの変更
- このリリースには、MariaDB ColumnStoreエンジンのバージョン 23.02.3が組み込まれています。
修正された問題
データ損失が発生する可能性があるもの
- バックアップがmariadb-backupで作成され、aria_log_dir_pathが設定されている場合、Ariaログはバックアップにコピーされません。
- プライマリキーのないテーブルに対してシステムのバージョン管理が有効になっている場合、テーブルへの変更が適切にレプリケートされません。
- パーティションテーブルにNOPAD照合順序を使用する列のプレフィックスインデックスが含まれている場合、ORDER BYを使用したクエリは間違った順序で行を返す可能性があります。
- 一部の照合では、一意制約がUNIQUE(..) USING HASHで定義されている場合、重複値が受け入れられます。
- ROW_FORMAT=REDUNDANTのInnoDBテーブルがDDLステートメントによって再構築されている時、キャッシュされたDML操作をその再構築されたテーブルに適用しようとしている間に、サーバーがクラッシュする可能性があります。
- 長いUniqueは、Unicode照合順序では正しく機能しません。（照合順序の点で）等しい文字列は、文字列の長さが異なる場合、等しくないものとして比較されます。
- innodb_buffer_pool_filenameが空の文字列に設定されている場合、サーバーはシャットダウン中にdatadirを削除しようとします。
- このリリース以降、innodb_buffer_pool_filenameシステム変数は読み取り専用となり、動的に変更できなくなります。
- UNIQUEインデックスの定義にPERIODが含まれている場合、テーブルがutf8mb4_unicode_nopad_ci照合順序を使用すると、重複キーエラーが誤って発生する可能性があります。
- Galeraでは、値がNEXTVAL()関数を使用してInnoDBシーケンスから取得されると、WSREPスレッド間のメタデータロックの競合によりサーバーがクラッシュする可能性があります。
- 以前のリリースでは、クラッシュの前に次のログメッセージがログに報告されました：
[Note] WSREP: MDL BF-BF conflict
[ERROR] Aborting
- 以前のリリースでは、クラッシュの前に次のログメッセージがログに報告されました：
ハングまたはクラッシュを引き起こす可能性があるもの
- mariadb-backupを使用してバックアップが準備されると、バッファプールをフラッシュするスレッドとREDOログファイルを削除するスレッドの間の競合状態が原因でユーティリティがハングする可能性があります。
- Galeraでは、トランザクションが異なるストレージエンジン（サーバーの内部2フェーズコミットプロトコルをサポートしているものとサポートしていないもの）を使用する複数のテーブルを変更すると、アサーションエラーでノードがクラッシュします。
- 以前のリリースでは、このシナリオでのクラッシュ中に、次のアサーションエラーがMariaDBエラーログに書き込まれます：
int wsrep::transaction::ordered_commit(): Assertion `state() == s_committing' failed.
- 以前のリリースでは、このシナリオでのクラッシュ中に、次のアサーションエラーがMariaDBエラーログに書き込まれます：
-
- このリリース以降、Galeraが有効になっている場合、混合トランザクションは次のエラーメッセージで拒否されます：
ERROR HY000: Transactional commit not supported by involved engine(s)
- このリリース以降、Galeraが有効になっている場合、混合トランザクションは次のエラーメッセージで拒否されます：
- InnoDBがクラッシュリカバリ中に大量のメモリを使用すると、バッファプールをフラッシュするスレッドとリカバリを実行するスレッドの間の競合状態によりサーバーがハングする可能性があります。
- Galeraでは、ストリーミングレプリケーションがwsrep_trx_fragment_sizeシステム変数を設定することによって有効にされると、バックアップロックまたはユーザーレベルのロックが解放される時にサーバーがクラッシュする可能性があります。
- UPDATEまたはDELETEがROW_FORMAT=COMPRESSEDを指定してInnoDBテーブルからロールバックされると、サーバーがクラッシュする可能性があります。
- 文字セットが定義されていない文字列に対してLEFT()関数が呼び出されると、サーバーがクラッシュする可能性があります。
- Galeraでは、状態スナップショット転送（SST）に対して、wsrep_sst_method=mariabackupが設定され、encrypt=4が有効になっている時に、ドナーノードにインストールされているsocatのバージョンが1.7.4.0以降である場合、SSTが失敗する可能性があります。
- 以前のリリースでは、インストールされているsocatのバージョンが1.7.4.0以降の場合、SSTが失敗し、ドナーノードのMariaDBエラーログに次のエラーが記録されることがありました：
E Failed to set SNI host "" - このリリース以降、SSTスクリプトがドナーノードでsocatリスナーを開始する時に、インストールされているsocatのバージョンが1.7.4.0以降であれば、no-sni=1を設定することでエラーが防止されます。
- 以前のリリースでは、インストールされているsocatのバージョンが1.7.4.0以降の場合、SSTが失敗し、ドナーノードのMariaDBエラーログに次のエラーが記録されることがありました：
- オプティマイザトレースが有効な時に、ビューが複数テーブルの更新の一部である場合、サーバーがクラッシュする可能性があります。
- ビュー定義にUNIONが含まれており、そのビューがサーバー側のプリペアドステートメントを使用してクエリされる時に、オプティマイザがビューの実行に条件をプッシュダウンすると、文字セットの変換中にサーバーがクラッシュする可能性があります。
- レプリカサーバーがMASTER_USE_GTID=slave_posを指定してプライマリサーバーに接続する時に、プライマリサーバーに復号化できない暗号化されたバイナリログがある場合、セグメンテーション違反によりプライマリサーバーがクラッシュします。
- 以前のリリースでは、プライマリノードは全てのバイナリログを反復処理して、要求されたGTIDを探しました。バイナリログの1つを復号化できない場合、サーバーはクラッシュします。
- このリリース以降、このシナリオでプライマリノードがバイナリログの復号化に失敗すると、バイナリログの反復処理が停止され、ER_MASTER_FATAL_ERROR_READING_BINLOGエラーコードと次のエラーメッセージが表示されるエラーが発生します：
Got fatal error 1236 from master when reading data from binary log: 'Could not set up decryption for binlog.'
- Galeraでは、wsrep_trx_fragment_sizeシステム変数を設定してストリーミングレプリケーションを有効にすると、特定のフラグメントサイズが指定される時にサーバーがクラッシュする可能性があります。
- IN(..)述語を含む単一テーブルDELETEに対してEXPLAIN EXTENDEDが実行されると、サーバーがクラッシュする可能性があります。
- slave_parallel_threadsを0より大きく設定して並列レプリケーションを有効にすると、エラーが発生した後にレプリカの並列レプリケーションワーカースレッドがハングする可能性があります。
- 以前のリリースでは、このシナリオでサーバーがハングすると、SHOW SLAVE STATUSの出力にはエラーが発生したことが示されましたが、出力にはI/OスレッドとSQLスレッドの両方が実行中であることが示されました。
SHOW SLAVE STATUS\G *************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
..
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
..
Last_Errno: 1062
Last_Error: Could not execute Write_rows_v1 event on table TABLE_NAME; Duplicate entry 'VALUE' for key 'KEY_NAME', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log LOG_FILE, end_log_pos END_LOG_POS
.. - このシナリオでは、この問題により並列レプリケーションワーカースレッドの1つがテーブルを閉じている状態でハングするため、SHOW PROCESSLISTの出力には、1つのワーカースレッドがその状態で無期限に表示されます：
SHOW PROCESSLIST; +------+--------------+--------------------+------+--------------+-------+-----------------------------------------------+------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+------+--------------+--------------------+------+--------------+-------+-----------------------------------------------+------------------+----------+
..
| 2394 | system user | | NULL | Slave_worker | 50852 | closing tables | NULL | 0.000 |
..
+------+--------------+--------------------+------+--------------+-------+-----------------------------------------------+------------------+----------+
- 以前のリリースでは、このシナリオでサーバーがハングすると、SHOW SLAVE STATUSの出力にはエラーが発生したことが示されましたが、出力にはI/OスレッドとSQLスレッドの両方が実行中であることが示されました。
- オプティマイザがセミ結合の分割方法を選択すると、サーバーがクラッシュする可能性があります。
- Galeraでは、クラスターノードでCREATE TEMPORARY SEQUENCEが実行され、バイナリログが有効になっていると、サーバーがクラッシュします。
- Galeraでは、書き込みセットが認証に失敗し、バイナリログが有効になっている場合、WSREPアプライヤスレッドによって使用されるWSREPシーケンス番号（クラスター全体のトランザクションID）が、競合状態によりノードのXID（内部トランザクションID）と同期しなくなる可能性があります。これにより、ノードがクラッシュする可能性があります。
- 以前のリリースでは、書き込みセットが認証に失敗し、バイナリログが有効になっている場合、コミット順序の解放が早すぎる可能性があるため、WSREPアプライヤスレッドはWSREPシーケンス番号を順序どおりに同期できませんでした。
- Galeraでは、wsrep_trx_fragment_sizeシステム変数を設定してストリーミングレプリケーションが有効にされ、CREATE TABLE .. SELECTが実行されると、サーバーがクラッシュする可能性があります。次のアサーションが、クラッシュ中にMariaDBエラーログに書き込まれます：
Assertion `mode_ == m_high_priority' failed in void wsrep::client_state::after_applying() - このリリース以降、サーバーはこのシナリオでのCREATE TABLE .. SELECTを禁止し、次のエラーメッセージを含むER_NOT_ALLOWED_COMMANDエラーコードを生成します：
ERROR 42000: CREATE TABLE AS SELECT is not supported with streaming replication
- このリリース以降、サーバーはこのシナリオでのCREATE TABLE .. SELECTを禁止し、次のエラーメッセージを含むER_NOT_ALLOWED_COMMANDエラーコードを生成します：
- Galeraでは、接続がハンドラーインターフェイスを使用してテーブル上でトランザクションを開始する場合、クライアントが切断されるとサーバーがクラッシュする可能性があります。
以前のリリースでは、クライアントが切断されると、サーバーはトランザクションをロールバックし、トランザクション終了後にハンドラーインターフェイスが存続すると予想していたロックを含む全てのロックを解放しました。これにより、サーバーがクラッシュすることがありました。- 以前のリリースでは、クラッシュ中に次のアサーションがMariaDBエラーログに書き込まれます：
void close_thread_table(THD*, TABLE**): Assertion `thd->mdl_context.is_lock_owner(MDL_key::TABLE, table->s->db.str, table->s->table_name.str, MDL_SHARED)' failed.
- 以前のリリースでは、クラッシュ中に次のアサーションがMariaDBエラーログに書き込まれます：
- Galeraでは、SSTドナーが非プライマリ状態に変わると、SSTが適切に終了されず、ドナーノードがクラッシュします。
- 以前のリリースでは、クラッシュ中に次のエラーメッセージとアサーションがMariaDBエラーログに書き込まれます：
[Warning] WSREP: server: NODE_NAME unallowed state transition: connected -> joined
void wsrep::server_state::state(wsrep::unique_lock
- 以前のリリースでは、クラッシュ中に次のエラーメッセージとアサーションがMariaDBエラーログに書き込まれます：
- グループに対してDISTINCTと集計関数を使用するクエリが実行されると、サーバーがクラッシュする可能性があります。
- サーバー側のプリペアドステートメントを使用して、ビューを参照し、HAVING句を含むクエリを実行すると、クエリの2回目の実行時にサーバーがクラッシュする可能性があります。
- InnoDBパージスレッドがコミットされていないインデックスに変更バッファを使用しようとすると、サーバーはアサーションで終了します。
- rowid_filtering最適化がパーティションテーブルで使用されると、サーバーはアサーションで終了します。
- InnoDBストレージエンジンでは、innodb_undo_log_truncate=ONが設定されていると、サーバーがハングする可能性があります。
- ROWNUM()関数を使用してクエリを処理する時に、クエリがそのFROMリストで、ORDER BY句を含む複数のテーブルに対してSELECTとして定義されたマージ可能ビューへの参照を使用する場合、サーバーがクラッシュする可能性があります。
- InnoDBテーブルでROW_FORMAT=COMPRESSEDが使用される場合、ページの分割時にサーバーがハングする可能性があります。
- マージ可能なビューでORDER BYを使用してROWNUM()関数を実行するクエリを処理する時、準備フェーズでチェックされた特定の条件下では、ビューをマージするのではなく実体化することが決定される場合があります。この場合、ビュー用に作成されたTABLE_LIST構造の派生フィールドは0のままでした。その結果、マテリアライズドビューの範囲解析を防止するガード条件が期待どおりに機能せず、サーバーがクラッシュしました。
- DDLがInnoDBテーブルで実行されると、DDL操作とInnoDB履歴のパージとの間のデッドロックが原因でサーバーがハングする可能性があります。
- ビューでROWNUM()関数を実行するクエリを処理すると、サーバーがクラッシュする可能性があります。
- InnoDBストレージエンジンでは、データファイルの数がinnodb_open_filesシステム変数で指定された制限を超えると、DROP TABLEによってI/Oエラーが発生する可能性があります。
- InnoDBテーブルスペース暗号化が有効で、DROP TABLEが実行されると、バックグラウンドドロップスレッドとバックグラウンド暗号化スレッドの間の競合状態によりサーバーがクラッシュする可能性があります。
- InnoDBストレージエンジンでは、フルテキストテーブル上のDDLとINSERTの間で競合状態が発生し、これによりサーバーがクラッシュする可能性があります。
- Galeraでは、XAトランザクションが使用されると、クラスターノードがクラッシュする可能性があります。
- mariadb-backupを使用してバックアップを作成する時に、InnoDBシステムテーブルスペース（デフォルト ibdata1）が非常に大きい場合、サーバーがクラッシュする可能性があります。
- Galeraでは、ノード上でOPTIMIZE TABLEが実行されると、WSREPスレッド間のメタデータロックの競合によりサーバーがクラッシュする可能性があります。
- 以前のリリースでは、クラッシュの前に次のログメッセージがログに報告されました：
[Note] WSREP: MDL BF-BF conflict
[ERROR] Aborting
- 以前のリリースでは、クラッシュの前に次のログメッセージがログに報告されました：
予期しない動作を引き起こす可能性があるもの
- InnoDBが二重書き込みバッファからREDOログファイルにデータを書き込む時に、Innodb_data_writeステータス変数が適切にインクリメントされません。
- XA PREPAREがレプリカのGTID状態の更新に失敗すると、並列レプリケーションが中断されます。
- InnoDBがinnodb_open_filesよりも多くのデータファイルを開いた時、パフォーマンスの低下により、追加のデータファイルを開くと予想よりも時間がかかります。
- 二重引用符を含むキー値を指定してJSON_OBJECTAGG関数が呼び出されると、二重引用符文字はエスケープされません。
- optimizer_switch='not_null_range_scan=on'が指定されている場合、空のテーブルでLEFT JOINが実行されると、結果が不正確になる可能性があります。
- クエリにGROUP BY句が含まれており、クエリがテーブルのプライマリキーに対して集計関数を呼び出す場合、GROUP BY句がインデックスを使用して評価されると、結果が不正確になる可能性があります。
- Galeraでは、クラスターノードでクエリキャッシュが有効になっており、ノードで通常のMariaDBレプリケーションが設定されている場合、レプリケーションによってテーブルが変更された時にクエリキャッシュエントリーが適切に無効になりません。
- mariadb-backupを使用してバックアップが作成されると、ユーティリティはaria_log_controlファイルを読み取り専用モードではなく読み取り／書き込みモードで開きます。
- システム結合タイプを使用する複数テーブルUPDATEに対してEXPLAIN EXTENDEDが実行されると、出力が正しくなくなる可能性があります。
- クエリにDISTINCTが指定され、SUM()関数を使用した式が含まれている場合、間違った結果が返されます。
- ビューの定義にHAVING句が含まれている場合、ビューからの選択がエラーで失敗する可能性があります。
- 以前のリリースでは、クエリがER_VIEW_INVALIDエラーコードと次のエラーメッセージが表示されるエラーを発生させることがありました：
View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
- 以前のリリースでは、クエリがER_VIEW_INVALIDエラーコードと次のエラーメッセージが表示されるエラーを発生させることがありました：
- ビューの定義に集計関数が含まれている場合、ビューからの選択がエラーで失敗することがあります。
- 以前のリリースでは、クエリがER_INVALID_GROUP_FUNC_USEエラーコードと次のエラーメッセージが表示されるエラーを発生させることがありました：
ERROR 1111 (HY000): Invalid use of group function
- 以前のリリースでは、クエリがER_INVALID_GROUP_FUNC_USEエラーコードと次のエラーメッセージが表示されるエラーを発生させることがありました：
- ビューの定義に単一値サブクエリとしてテーブル値コンストラクター（TVC）が含まれている場合、ビューからの選択がエラーで失敗することがあります。
- 以前のリリースでは、クエリがER_VIEW_INVALIDエラー コードと次のエラーメッセージが表示されるエラーを発生させることがありました：
View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
- 以前のリリースでは、クエリがER_VIEW_INVALIDエラー コードと次のエラーメッセージが表示されるエラーを発生させることがありました：
- ビューの定義が相関のないサブクエリに集計関数を含む場合、間違った結果が返されます。
- DELETEステートメントにHAVING句を含むサブクエリが含まれる、または、DELETEステートメントがWHERE句内に集計関数を含む場合、ステートメントはエラーで失敗する可能性があります。
- 以前のリリースでは、クエリによってER_INVALID_GROUP_FUNC_USEエラーコードと次のエラーメッセージが表示されるエラーが発生することがありました：
ERROR 1111 (HY000): Invalid use of group function
- 以前のリリースでは、クエリによってER_INVALID_GROUP_FUNC_USEエラーコードと次のエラーメッセージが表示されるエラーが発生することがありました：
- InnoDBテーブルスペースが破棄されている場合、information_schema.INNODB_SYS_INDEXESからの選択はエラーで失敗します。
- 以前のリリースでは、ER_UNKNOWN_ERRORエラーコードのエラーが発生しました：
ERROR 1105 (HY000): Unknown error - このリリース以降、エラーは返されず、結果には破棄されたテーブルスペースのPAGE_NO列とSPACE列にNULLが含まれます。
- 以前のリリースでは、ER_UNKNOWN_ERRORエラーコードのエラーが発生しました：
- innodb_undo_directoryが相対パスに設定されている場合、そのパスはmariadb-backup --copy-backによって適切に使用されません。
- 以前のリリースでは、UNDOログは現在の作業ディレクトリと比較した相対パスにコピーされていました。
- このリリース以降、UNDOログはdatadirと比較した相対パスにコピーされます。
- UNIX_TIMESTAMP(CURRENT_TIME())が実行されると、間違った値が返されます。
- 以前のリリースでは、NULLが返されました。
- Galeraでは、wsrep_sst_method='mariabackup' が設定されている場合、systemdはPIDの不一致に関するエラーを生成します。
- 以前のリリースでは、systemdによって次のエラーが発生することがありました。BACKUP_PIDはMariaDB Enterprise BackupのPID、SERVER_PIDはMariaDB Enterprise ServerのPIDです：
Got notification message from PID BACKUP_PID, but reception only permitted for main PID SERVER_PID
- 以前のリリースでは、systemdによって次のエラーが発生することがありました。BACKUP_PIDはMariaDB Enterprise BackupのPID、SERVER_PIDはMariaDB Enterprise ServerのPIDです：
- UPDATEに、インデックスのないVARCHAR列に対する範囲条件を含むWHERE句が含まれる場合、エラーが発生します。
- 以前のリリースでは、ER_DATA_TOO_LONGエラーコードのエラーが発生し、次のエラーメッセージが表示されます：
ERROR 1406 (22001): Data too long for column 'COLUMN_NAME' at row 1
- 以前のリリースでは、ER_DATA_TOO_LONGエラーコードのエラーが発生し、次のエラーメッセージが表示されます：
- SLAVE_Parallel_threadsが0より大きく、SHOW SLAVE STATUSが実行されると、接続は初期化されていないミューテックスの取得を試行する可能性があります。
- 以前のリリースでは、競合状態により、並列レプリケーションワーカースレッドのミューテックスが初期化される前に取得される可能性がありました。
- ucs2_general_mysql500_ci照合順序は、古いバージョンのMySQLとの互換性を目的としており、's'の後に's'が誤ってソートされます。
- EXPLAIN EXTENDEDがINSERT、UPDATE、DELETE、またはREPLACEとともに実行される場合、クエリテキストを含む警告は出力されません。
- rowid_filtering最適化が正しく適用されない場合があります。
- 部分バックアップを準備する場合、MariaDB Enterprise Backupは、バックアップから除外されているために欠落していることが予想される InnoDBテーブルスペースファイルが欠落していることに関するエラーメッセージを生成します。
- フルテキストインデックスが存在する状態でINSERT .. SELECTを実行すると、コミット中の他の全てのコミットがハングします。
- information_schema.INNODB_SYS_TABLESPACESでは、UNDOテーブルスペースが間違った名前で表示されます。
- 以前のリリースでは、名前は.//undo00Nでした。
- このリリース以降、名前はinnodb_undo00Nになります。
- フルテキストインデックスを含むテーブルに対するコミット操作中のメモリ管理が正しくありません。
- インデックスを使用してSELECT DISTINCT .. WITH TIESを実行すると、不正な結果が生成されます。
- InnoDBテーブルへの一括挿入が実行される時、トランザクションセーブポイントは解放されません。
- InnoDBの一括挿入操作中に外部キーチェックと一意のチェックが無効になっている場合、ER_KEY_NOT_FOUNDエラーが散発的に発生します。
- InnoDBテーブルでUPDATEが実行されると、競合状態が原因でトランザクションがハングする可能性があります。
- 並列レプリケーションでは、ワーカースレッドの起動時にパフォーマンススキーマにワーカースレッドに関する一貫性のない詳細が含まれる可能性があります。
- InnoDBストレージエンジンを使用すると、セカンダリインデックスを使用するクエリの実行が大幅に遅くなる可能性があります。
- このリリースより前（10.6.8以降）、セカンダリインデックスを使用するクエリのパフォーマンスは、セカンダリインデックスからの読み取りのロックを実装するコードによって影響を受ける可能性がありました。
- このリリース以降、パフォーマンス低下の原因となっていた条件が削除されたため、永続テーブルを変更しなかったロックトランザクションは0のトランザクション IDを持つことができます。
- InnoDB一時テーブルに書き込んだ後、InnoDB一時テーブルスペース内のスペースは再利用されません。
- innodb_adaptive_flushingが有効な場合、アダプティブフラッシュがinnodb_adaptive_flushing_lwmを超えた後に常に呼び出されるとは限りません。
- mariadb-backupを使用してバックアップを作成する場合、ログにギャップがあるとユーティリティがAriaログファイルのコピーに失敗することがあります。
- 以前のリリースでは、バックアップログに次のようなメッセージが含まれる場合がありました：
Found aria log file: aria_log.00000001, current: 1, min: 1, max: 1
Found aria log file: aria_log.00000004, current: 4, min: 1, max: 4
Found 4 aria log files, minimum log number 1, maximum log number 4, last log number 4
Stop scanning aria tables.
..
error: cannot open file ./aria_log.00000002
Error: copy_file() failed.
Error on copying ./aria_log.00000002 aria log file.
Skip copying 3 aria log file due to error
Skip copying 4 aria log file due to error
- 以前のリリースでは、バックアップログに次のようなメッセージが含まれる場合がありました：
インターフェースの変更
- aria_log_dir_pathシステム変数が追加されました。
- core_fileシステム変数のデフォルト値がNoneからOFFに変更されました。
- innodb_buffer_pool_filenameシステム変数がYesからNoに動的に変更されました。
- Innodb_buffer_pool_pages_splitステータス変数が追加されました。
- mariadb-backup --aria-log-dir-pathコマンドラインオプションが追加されました。
プラットフォーム
エンタープライズライフサイクルに合わせて、MariaDB Enterprise Server 10.6.14-9は次のプラットフォームに対して提供されます：
- CentOS 7 (x86_64)
- Debian 10 (x86_64, ARM64)
- Debian 11 (x86_64, ARM64)
- Red Hat Enterprise Linux 7 (x86_64)
- Red Hat Enterprise Linux 8 (x86_64, ARM64)
- Red Hat Enterprise Linux 9 (x86_64, ARM64)
- 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)
Windowsパッケージは、現在、このリリースでは利用可能ではありません。
MariaDB Enterprise Serverの一部のコンポーネントは、全てのプラットフォームをサポートしていない場合があります。
MariaDB Enterprise Server 10.6.14-9のリリースノート（MariaDB社ウェブサイト）：
https://mariadb.com/docs/server/release-notes/mariadb-enterprise-server-10-6/10-6-14-9/
MariaDBプロダクト・サポート・サービス
MariaDBプロダクト・サポート・サービスは、MariaDBおよびその関連製品をご利用されているお客様へ、必要なソフトウェアや専門的なサポートなどを提供するサービスです。