MariaDB Enterprise Server 10.4.24-15 GA版（リリース日：2022年3月14日）

修正されたセキュリティ脆弱性
　CVE　／　CVSSベーススコア
　CVE-2021-46668　／　5.5
　CVE-2021-46665　／　5.5
　CVE-2021-46664　／　5.5
　CVE-2021-46663　／　5.5
　CVE-2021-46661　／　5.5
　CVE-2021-46659　／　5.5
注目すべき変更点
● Windowsでは、core_fileはデフォルトで有効になっています。
● innodb_ft_cache_sizeおよびinnodb_ft_total_cache_sizeの最大値が
　80000000から1099511627776（1 TB）に変更されました。
● HashiCorp Key Managementプラグインに新しいシステム変数が追加されました。
　　・hashicorp_key_management_cache_timeoutは、キャッシュに格納されている
　　　キーの値が無効になるまでの時間（ミリ秒単位）を定義し、このデータを
　　　読み取ろうとすると、新しいリクエストがボールトサーバーに送信されます。
　　　値が0の場合、キーは常に無効と見なされますが、ボールトサーバーが使用できず、
　　　hashicorp_key_management_use_cache_on_timeoutが有効になっている場合は
　　　キーは引き続き使用されます。デフォルトでは、値は60000（1分）です。
　　・hashicorp_key_management_cache_version_timeoutは、キーの
　　　最新バージョン番号に関する情報（キャッシュに格納されている）が無効になり、
　　　この情報を読み取ろうとすると、新しいリクエストがボールトサーバーに
　　　送信されるまでの時間（ミリ秒単位）を定義します。値が0の場合、最新の
　　　キーバージョン番号に関する情報は常に無効と見なされますが、ボールトサーバーが
　　　使用できず、hashicorp_key_management_use_cache_on_timeoutが
　　　有効になっている場合は引き続き使用されます。デフォルトで、値は0です。
　　・最大限の柔軟性を実現するために、両方の新しいシステム変数を
　　　緩いプレフィックスで設定できます。
　　　[mariadb]
　　　loose_hashicorp_key_management_cache_timeout=120000
　　　loose_hashicorp_key_management_cache_version_timeout=120000
● Galeraが26.4.10に更新されました。
ストレージエンジンの変更
● このリリースは、MariaDB Enterprise Server 10.4でのMariaDB Enterprise ColumnStore
　1.4のサポートを終了します。
　　・MariaDBは、
　　　MariaDB Enterprise Server 10.6でMariaDB Enterprise ColumnStore 6を使用する
　　　または
　　　MariaDB Enterprise Server 10.5でMariaDB Enterprise ColumnStore 5を使用する
　　　ことをお勧めします。
修正された問題
＜データ損失が発生する可能性があるもの＞
● 一部のINFORMATION_SCHEMAテーブルの列は、SQL標準に準拠していないDEFAULT句で
　誤って宣言されています。
　　・したがって、sql_mode=EMPTY_STRING_IS_NULLが設定されている場合、
　　　CREATE TABLE .. SELECT .. FROM INFORMATION_SCHEMA...のようなクエリでは、
　　　次のようなレプリケーションエラーが発生する可能性があります。
　　　Error 'Invalid default value for 'TABLE_NAME'' on query. Default database: 'test'. Query: 'CREATE TABLE `t1` (`TABLE_NAME` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT ''
● ALTER TABLEステートメントがINPLACEアルゴリズムを使用して
　MyISAMまたはAriaのテーブルのインデックスの順序を変更すると、
　テーブルが破損する可能性があります。
● CREATE OR REPLACE SEQUENCEがバイナリログに書き込まれる時、ステートメントは
　DDLとしてフラグが立てられません。これにより、並列レプリケーションが有効に
　なっている場合、レプリカサーバーは安全でない方法でステートメントを実行します。
● MariaDB 10.3以前のバージョンからアップグレードした後、一部のトリガーの
　名前が空になり、トリガーを削除できません。
＜ハングまたはクラッシュを引き起こす可能性があるもの＞
● FULLTEXTインデックスがALGORITHM=INPLACEでInnoDBテーブルに追加され、
　インデックス付き列がtis620文字セットを使用する場合、サーバーは
　セグメンテーション違反（シグナル11）でクラッシュする可能性があります。
● 弱いメモリモデルを使用するARMアーキテクチャでMariaDBサーバーが使用されると、
　内部ハッシュテーブルの実装により、サーバーがセグメンテーション違反（シグナル11）
　でクラッシュする可能性があります。
● wsrep_sst_method=mariabackupおよびinnodb_force_recovery=1がGaleraを
　搭載したMariaDB Enterprise Clusterで設定されている場合、ジョイナーノードは
　SSTの実行に失敗します。
　　・SSTログには、障害に関連する次のメッセージが含まれます。
　　　mariabackup: The option "innodb_force_recovery" should only be used with "--prepare".
　　　mariabackup: innodb_init_param(): Error occurred.
● --stream=xbstreamが設定されている場合、MariaDB Enterprise Backupは、
　デッドロックのためにロック取得でハングする可能性があります。
● ストアドプロシージャがset関数を含むクエリで定義されており、set関数の唯一の
　引数がマージ可能ビューの列、派生テーブル、またはCTEへの外部参照である場合、
　ストアドプロシージャを2回実行するとサーバーがクラッシュする可能性があります。
● ビューまたはCTEでサブクエリを使用する特定のクエリに対して派生テーブルが
　作成されると、サーバーがセグメンテーション違反（シグナル11）でクラッシュする
　可能性があります。
● ストアドプロシージャがカーソルを使用して内部の一時テーブルを必要とする
　クエリ（ORDER BY句を含むクエリなど）を実行すると、セグメンテーション違反
　（シグナル11）が原因でサーバーがクラッシュする可能性があります。
● CTEまたは派生テーブルがクエリで使用されていない場合、
　サーバーがクラッシュする可能性があります。
● log_slow_verbosity = 'explain'が設定され、派生テーブルを参照するクエリが
　実行されると、クエリの実行プランをスロークエリログに書き込んでいる時に
　サーバーがクラッシュする可能性があります。
● ストアドプロシージャまたはプリペアドステートメントを使用して、
　GEOMETRY列を別のデータ型と比較する結合を実行するクエリを実行する場合、
　ストアドプロシージャまたはプリペアドステートメントを2回実行すると、
　サーバーがクラッシュする可能性があります。
● システムバージョン管理されたテーブルがcharacter_set_server=utf8mb4
　およびcollation_server=utf8mb4_unicode_1400_ciで作成されると、
　サーバーがクラッシュする可能性があります。
● システムバージョン管理されたテーブルがSYSTEM_TIMEによってパーティション化
　されている場合、DELETE FROM .. PARTITION(..)を実行すると、サーバーが
　クラッシュします。
● 次の条件が満たされた場合、プリペアドステートメントを2回実行すると、
　サーバーがクラッシュする可能性があります。
　　・in_predicate_conversion_thresholdシステム変数は、ある値nに設定する
　　　必要があります。
　　・クエリには、n個を超える文字列リテラルを含むIN(...)句が含まれている
　　　必要があります。
　　・クエリには文字セット変換が必要です。
● MariaDB Enterprise ClusterでSSTを正常に完了した後も、ドナーノードの
　wsrep_local_state_commentは'Donor/Desynced'と表示します。
● MariaDB Enterprise Clusterでは、REPAIR VIEWがinformation_schema.TABLESを
　参照するビューで実行されると、サーバーがクラッシュする可能性があります。
● ALTER TABLE .. ADD COLUMNを使用してInnoDBテーブルの真ん中に列を即座に
　追加し、次にテーブルスペースがFLUSH TABLES .. FOR EXPORTでエクスポートされ、
　次にテーブルスペースがALTER TABLE ..IMPORT TABLESPACEで再インポートされると、
　サーバーがクラッシュする可能性があります。
● optimizer_switch='not_null_range_scan=on'が設定されている時、
　InnoDBテーブルのインデックスを使用して、NULLと評価できる条件をチェックする
　場合、サーバーがクラッシュする可能性があります。
● SpiderテーブルがFLOAT列を使用している場合、サーバーはアサーションの失敗で
　クラッシュする可能性があります。
　　・MariaDBエラーログに、アサーションの失敗について次のエラーメッセージが
　　　書き込まれる可能性があります。
　　　Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
● MariaDB Enterprise Clusterでは、外部キー制約を定義する
　CREATE TABLEステートメントが他のクラスタノードに複製されると、
　ノードは、外部キー制約に影響を与える他のDMLステートメントと並行して
　ステートメントを適用できます。これにより、ノードはアサーションの失敗で
　失敗します。
● MariaDB Enterprise Clusterでは、2つのトランザクションが2つの別々の
　InnoDBテーブルから行を並行して削除し、外部キーにより、両方のトランザクションの
　削除が3番目のテーブルの同じ行にカスケードされると、サーバーがクラッシュして
　アサーションエラーが発生する可能性があります。
　　・以前のリリースでは、wsrep_slave_threads=1を設定することで、この問題を
　　　回避できました。
　　・MariaDBエラーログに、アサーションの失敗に関する次のエラーメッセージが
　　　書き込まれる可能性がありました。
　　　int wsrep::client_state::bf_abort(wsrep::seqno): Assertion `mode_ == m_local || transaction_.is_streaming()' failed.
　　　[ERROR] mysqld got signal 6 ;
● MariaDB Enterprise Clusterでは、ノードがmysql.slow_logシステムテーブルに
　書き込もうとし、wsrep_trx_fragment_sizeが0より大きい場合、サーバーが
　アサーションエラーでクラッシュする可能性があります。
　　・MariaDBエラーログに、アサーションの失敗に関する次のエラーメッセージが
　　　書き込まれる可能性がありました。
　　　int wsrep::client_state::after_row(): Assertion `state_ == s_exec' failed.
　　　[ERROR] mysqld got signal 6 ;
＜予期しない動作を引き起こす可能性があるもの＞
● マルチバイト文字セットが使用される場合、TINYTEXT列の最後の文字が
　切り捨てられる可能性があります。これにより、それは疑問符（'?）として
　表示されます。
● TIME列でALLキーワードを使用するサブクエリは、間違った結果を生成します。
● DATE列でALLキーワードを使用するサブクエリは、間違った結果を生成します。
● 浮動小数点リテラルが科学的記数法を使用して定義されており、トークンに
　特定の特殊文字も含まれている場合、パーサーは浮動小数点値を誤って解析し、
　それをリクエストから完全に削除します。
● 二重カプセル化されたCTEクエリが、CTEクエリでエイリアス化されたテーブルを
　読み取る関数を呼び出すと、サーバーはER_NO_SUCH_TABLEエラーコードのエラーを
　誤って発生させます。
● DELETEステートメントのサブクエリでCTEが使用されると、サーバーは
　ER_NO_DB_ERRORエラーコードのエラーを誤って発生させます。
● Galeraを搭載したMariaDB Enterprise ClusterがSSTを実行すると、
　SSTスクリプトは、その目的でssl_capathを使用する代わりに、TLS CA証明書の
　ディレクトリへのパスとしてssl_caを誤って読み取ろうとします。
● Galeraを搭載したMariaDB Enterprise ClusterがSSTを実行する場合、
　SSTスクリプトは常にlog_bin_indexを正しく解釈するとは限りません。
● インデックスがORDER BY .. LIMITクエリに使用される場合、オプティマイザは
　Range Checked for Each Record最適化を無効にしません。
● optimizer_switch='index_merge_sort_intersection=on'が設定されている
　場合、クエリ条件では完全なインデックスをスキャンする必要があるため、
　オプティマイザは役に立たないインデックスをマージすることを誤って選択する
　可能性があります。
● versionシステム変数が設定されている場合、MariaDB Connector/Cと
　mariadbクライアントは、MariaDBサーバーの拡張メタデータを適切に解釈しません。
　そのため、一部のSHOW ..の結果が右揃えになる可能性があります。
● INSERT .. SELECTステートメントが同じテーブルから選択して同じテーブルに
　挿入すると、行が2回カウントされます。そのため、行番号がエラーメッセージで
　誤って報告される可能性があります。
● レプリカサーバーのリレーログがローテーションされると、
　SHOW REPLICA STATUSのSeconds_Behind_Masterは、
　非常に高い誤った値を一時的に表示する可能性があります。
● information_schema.STATISTICSテーブルのcollation列が誤ってNULLとして
　読み取られます。
● 結合が大文字と小文字を区別しない照合を使用する式とバイナリ照合を
　使用するENUM列の比較を実行すると、比較が誤った照合を使用するため、
　結果が正しくなくなる可能性があります。
● innodb_buffer_pool_sizeがSET GLOBALで動的に変更されると、
　InnoDBは起動時に強制される最小値を強制しません。その結果、
　innodb_buffer_pool_chunk_sizeのいくつかの値を持つバッファプールが
　非常に小さくなる可能性があります。
● 一部のクエリ（UNION ALLを使用するクエリなど）でDATABASE()関数が
　使用されると、データベース名の最大文字数が64文字であっても、
　データベース名が34文字に切り捨てられる可能性があります。
● --skip-symbolic-linksまたは--disable-symbolic-linksが
　設定されている場合など、--symbolic-linksオプションが無効になっている場合でも、
　テーブルにDATA DIRECTORYオプションがある場合、InnoDBでは
　シンボリックリンクと.islファイルを作成できます。
● CREATE TABLE t1 LIKE t2が実行され、t2テーブルがMyISAMストレージエンジン
　またはAriaストレージエンジンを使用するパーティションテーブルであり、
　パーティションにDATA DIRECTORYオプションが定義されている場合、
　その操作はファイルシステムエラーで失敗します。
● sql_mode=ONLY_FULL_GROUP_BYが設定されている場合、
　一部のウィンドウ関数はER_MIX_OF_GROUP_FUNC_AND_FIELDSエラーコードで
　誤ってエラーを発生させます。
● サブクエリからの値を使用してJSON_COMPACT関数が呼び出された場合、
　その出力が常にJSONデータ型として返されるとは限りません。
● システムバージョン管理されたテーブルが``LIMIT句を使用して
　SYSTEM_TIME`でパーティション化されている場合、CHECK TABLEは
　誤ってエラーを返す可能性があります。
● WITH ROLLUPを使用するクエリでは、ラテラル派生最適化が無効になりません。
　これにより、GROUP BYを使用するクエリが誤った結果を返します。
● optimizer_switch='split_materialized=on'が設定されている場合、
　分割最適化を使用するクエリは間違った結果を返す可能性があります。
● 行がInnoDBテーブルから削除され、その後同じキーを持つ新しい行が
　別のトランザクションによってテーブルに挿入されると、InnoDBのMVCCコードは、
　変更を確認する必要があるトランザクションから新しい行を誤って非表示にする
　可能性があります。
　　・その結果、クエリは同じキーの別の新しい行を挿入しようとする可能性があり、
　　　その結果、ER_DUP_ENTRYエラーコードでエラーが発生します。
　　・レプリカサーバーでslave_parallel_modeが'optimistic'または
　　　'aggressive'に設定されている場合、SHOW REPLICA STATUSで
　　　次のエラーが発生する可能性があります。
　　　Last_Errno: 1062
　　　Last_Error: Error 'Duplicate entry 'VALUE' for key 'KEY_NAME'' on query. Default database: 'DATABASE_NAME'. Query: 'INSERT INTO ..'
● MariaDB Enterprise Auditでは、プリペアドステートメントを使用して
　監査ログを有効にすることはできません。
　　・以前のリリースでは、プリペアドステートメントを使用して
　　　server_audit_loggingシステム変数を設定すると、
　　　次のエラーメッセージが表示されて失敗していました。
　　　ERROR 1 (HY000): Logging cannot be enabled.
● プロキシユーザーが認証に使用される場合、サーバーは次のセキュリティ制御について
　プロキシユーザーアカウントを確認します。
　　・SSL/TLS要件
　　・アカウントのロック
　　・パスワードの有効期限
　　・このリリース以降、サーバーは上記のセキュリティ制御について
　　　元のユーザーアカウントを確認します。
● wsrep_osu_method='TOI'がMariaDB Enterprise Clusterで設定されている場合、
　ALTER SEQUENCEはDDLとして他のノードに複製されません。
● MariaDB Enterprise Clusterを使用すると、グループコミットロジックの
　競合状態により、クラスターノードが間違った順序でトランザクションを適用する
　可能性があり、サーバーがアサーションで失敗する可能性があります。
　　・MariaDB Error Logでは、アサーションの失敗に関するメッセージは
　　　次のようになります。
　　　void trx_rseg_update_wsrep_checkpoint(trx_rsegf_t*, const XID*, mtr_t*): Assertion `xid_seqno > wsrep_seqno' failed.
　　　[ERROR] mysqld got signal 6 ;
● デフォルトのoptimizer_use_condition_selectivity=4では、
　optimizer_switch='extended_keys=off'が設定されている場合を除き、
　オプティマイザはoptimizer_use_condition_selectivity=1よりも悪い
　実行プランを生成することがありました。
＜インストールとアップグレード＞
● wsrep_sst_method=mariabackupが設定されている時に、
　MariaDB Enterprise Backupが手動でアップグレードされない場合、
　MariaDB Enterprise Server 10.4にアップグレードした後に
　MariaDB Enterprise ClusterのSSTが失敗する可能性がありました。
● mysql.AddGeometryColumnストアドプロシージャと
　mysql.DropGeometryColumnストアドプロシージャが古いデフォルトの
　DEFINER = 'root@localhost'を使用する場合、mariadb-upgradeは、
　新しいデフォルトのDEFINER = 'mariadb.sys@localhost'を使用するように
　それらを変更しません。
インターフェースの変更
● ER_VERS_NOT_ALLOWEDエラーコードが追加されました。
● innodb_buffer_pool_sizeシステム変数の最小値が5242880から2097152に
　変更されました。
● innodb_ft_cache_size動的システム変数がNoからYesに変更されました。
● innodb_ft_cache_sizeシステム変数の最大値が80000000から1099511627776に
　変更されました。
● innodb_ft_total_cache_size動的システム変数がNoからYesに変更されました。
● innodb_ft_total_cache_sizeシステム変数の最大値が1600000000から
　1099511627776に変更されました。
● mysql_upgrade --check-if-upgrade-is-neededコマンドラインオプションが
　追加されました。
● mysqld --hashicorp-key-management-cache-timeoutコマンドラインオプションが
　追加されました。
● mysqld --hashicorp-key-management-cache-version-timeout
　コマンドラインオプションが追加されました。
● mysqld --rocksdb-ignore-datadic-errorsコマンドラインオプションが
　追加されました。
● rocksdb_ignore_datadic_errorsシステム変数が追加されました。
プラットフォーム
エンタープライズライフサイクルに合わせて、MariaDB Enterprise Server 10.4.24-15は
以下のプラットフォーム用に提供されています：
・CentOS 7 (x86_64)
・Debian 9 (x86_64 / ARM64)
・Debian 10 (x86_64 / ARM64)
・Microsoft Windows (x86_64) (MariaDB Enterprise Clusterを除く)
・Red Hat Enterprise Linux 7 (x86_64)
・Red Hat Enterprise Linux 8 (x86_64 / ARM64)
・SUSE Linux Enterprise Server 12 (x86_64)
・SUSE Linux Enterprise Server 15 (x86_64 / ARM64)
・Ubuntu 18.04 (x86_64 / ARM64)
・Ubuntu 20.04 (x86_64 / ARM64)

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

---