MariaDB Enterprise Server 10.6.7-3 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
注目すべき変更点
● InnoDBのクラッシュリカバリの改善
● Windowsでは、core_fileはデフォルトで有効になっています。
● innodb_change_bufferingのデフォルト値がnoneに変更されました。
● 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 ColumnStoreストレージエンジンバージョン 6.2.3が
組み込まれています。
このリリースには、MariaDB Xpandストレージエンジンバージョン 6.0.3が
組み込まれています。
修正された問題
＜データ損失が発生する可能性があるもの＞
● 一部の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 ''
● 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 ;
● innodb_flush_log_at_trx_commit=2およびinnodb_flush_method=O_DSYNCが
　設定されている場合、サーバーがアサーションエラーでクラッシュする可能性が
　ありました。
　　・MariaDBエラーログに、アサーションの失敗に関する次のメッセージが
　　　書き込まれる可能性がありました。
　　　InnoDB: Failing assertion: lsn >= log_sys.get_flushed_lsn()
● InnoDBがストレージにRAMディスクを使用しない場合、ログチェックポイント中に
　サーバーがハングすることがあります。
● Enterprise Spiderを使用している場合、メモリの破損が原因でサーバーが
　クラッシュする可能性があります。
● mariadbd --helpが実行されると、サーバーはAria制御ファイルを
　ロックしようとする可能性がありました。
　　・MariaDBエラーログには、これについて次のエラーメッセージが書き込まれる
　　　可能性がありました。
　　　[ERROR] mysqld: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 0 seconds
　　　[ERROR] Plugin 'Aria' init function returned error.
　　　[ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
● インデックスが削除され、INPLACEアルゴリズムを使用して別の位置にあるテーブルに
　再度追加され、そのテーブルがMEMORYストレージエンジンを使用している場合、
　サーバーがクラッシュする可能性があります。
● DDLステートメントにInnoDB FULLTEXTインデックスが含まれている場合、
　内部の競合状態によってサーバーがハングする可能性がありました。
● innodb_undo_log_truncate=ONが設定されている場合、サーバーがハングする
　可能性があります。
● DROP DATABASEが実行されると、InnoDBのSUBSTR()関数の範囲外の結果が原因で、
　サーバーがクラッシュする可能性があります。
＜予期しない動作を引き起こす可能性があるもの＞
● マルチバイト文字セットが使用される場合、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エラーコードで
　誤ってエラーを発生させます。
● システムバージョン管理されたテーブルが``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 ;
● クエリキャッシュが有効になっていて、CLIENT_EXTENDED_METADATA機能フラグを
　サポートしていない古いクライアントまたはコネクタが使用されている場合、
　不明なエラーでクエリが失敗する可能性があります。
　　・修正の一環として、CLIENT_EXTENDED_METADATA列が
　　　information_schema.QUERY_CACHE_INFOテーブルに
　　　追加されました。
● JSONが単一行のサブセレクトまたはハイブリッド関数（IF()やCOALESCE()など）で
　使用される場合、結果はJSONではなく通常の文字列と見なされる可能性がありました。
● インデックスを使用しないInnoDBテーブルの更新には、パフォーマンスの低下が
　見られます。
● MariaDB Enterprise Clusterでは、wsrep_gtid_mode=ONが設定され、
　server_idの値が新しい値に変更された場合、トランザクションは引き続き
　GTIDの古いserver_id値を使用します。
● OFFSETをSELECT DISTINCT、JOIN、およびIN(..)と組み合わせると、
　OFFSETは無視されます。
● 数値引数がCOLLATEに指定されている場合、
　サーバーは、character_set_connectionの照合ではなく、
　常にlatin1文字セットの照合を使用します。
　　・COLLATE句でcharacter_set_connectionの照合を指定すると、
　　　クエリは次のエラーメッセージを表示して失敗する可能性がありました。
　　　ERROR 1253 (42000): COLLATION ' …' is not valid for CHARACTER SET 'latin1'
● JSON関数を使用するクエリは、KILL QUERYで強制終了できず、
　max_statement_timeで指定された制限を尊重しません。
● Windowsインストーラは、選択したディレクトリが空かどうかをチェックしません。
　これにより、MariaDB Enterprise Serverが別のバージョンと同じディレクトリに
　インストールされる可能性があります。
● MariaDB Enterprise Serverが制限されたディレクトリにインストールされて
　いる場合、MariaDB Enterprise ServerのWindowsサービスは開始されません。
● innodb_read_only_compressedのデフォルト値がONからOFFに変更されました。
　　・InnoDBのCompressed行形式を使用しているユーザーの場合、
　　　この変更により、ユーザーが設定ファイルを更新する必要なく、
　　　MariaDB Enterprise Server 10.6以降にスムーズにアップグレードできます。
＜インストールとアップグレード＞
● mysql.AddGeometryColumnストアドプロシージャと
　mysql.DropGeometryColumnストアドプロシージャが
　古いデフォルトのDEFINER = 'root@localhost'を使用する場合、
　mariadb-upgradeは、新しいデフォルトのDEFINER = 'mariadb.sys@localhost'を
　使用するようにそれらを変更しません。
● MariaDBサーバーが10.2、10.3、または10.4からアップグレードされると、
　InnoDBはクラッシュセーフではない方法でREDOログ形式をアップグレードします。
● 'root'@'localhost'ユーザーアカウントが存在しない場合、
　mariadb-upgradeが失敗する可能性があります。
　　・出力には、次のエラーメッセージが表示される可能性がありました。
　　　ERROR 1449 (HY000) at line 832: The user specified as a definer ('root'@'localhost') does not exist
　　　FATAL ERROR: Upgrade failed
インターフェースの変更
● ER_VERS_NOT_ALLOWEDエラーコードが追加されました。
● innodb_buffer_pool_sizeシステム変数の最小値が5242880から2097152に
　変更されました。
● innodb_change_bufferingシステム変数のデフォルト値がallからnoneに
　変更されました。
● innodb_force_load_corruptedシステム変数が削除されました。
● 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に変更されました。
● innodb_read_only_compressedシステム変数のデフォルト値がONからOFFに
　変更されました。
● mariadb-upgrade --check-if-upgrade-is-neededコマンドラインオプションが
　追加されました。
● mariadbd --hashicorp-key-management-cache-timeout
　コマンドラインオプションが追加されました。
● mariadbd --hashicorp-key-management-cache-version-timeout
　コマンドラインオプションが追加されました。
● mariadbd --innodb-force-load-corruptedコマンドラインオプションが
　削除されました。
● mariadbd --rocksdb-ignore-datadic-errorsコマンドラインオプションが
　追加されました。
● rocksdb_ignore_datadic_errorsシステム変数が追加されました。
プラットフォーム
エンタープライズライフサイクルに合わせて、MariaDB Enterprise Server 10.6.7-3は
以下のプラットフォーム用に提供されています：
・CentOS 7 (x86_64)
・Debian 9 (x86_64 / ARM64)
・Debian 10 (x86_64 / ARM64)
・Debian 11 (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.6.7-3のリリースノート（MariaDB社ウェブサイト）：
https://mariadb.com/docs/release-notes/mariadb-enterprise-server-10-6/10-6-7-3/

---