MariaDB Enterprise Server 10.4.12-6 GA版（リリース日：2020年3月2日）

修正されたセキュリティ脆弱性
　CVE / CVSS 3.0 ベーススコア
　CVE-2020-7221 / 7.8
　CVE-2020-2574 / 5.9

主な変更点
・MariaDB ColumnStore 1.4.3がこのリリースに含まれています。
・MariaDBサービスのsystemdの開始および停止タイムアウトが現在は900秒（15分）に設定されます。
・パラメータslave-run-triggers-for-rbrのENFORCEオプションを使用して、レプリカ上のテーブルで
　定義されたトリガーが、このテーブルにプライマリ（マスター）のトリガーが存在する場合に、
　行ベースレプリケーション（RBR）で実行されることを保証できるようになりました。
　LOGGINGオプションは既に存在しますが、プライマリ（マスター）上のこのテーブルにトリガーが
　存在しない場合にのみ、行ベースのレプリケーションのレプリカのトリガーを実行できます。
・Windows：datadirがネットワークリソースとして定義されている場合、エラーログにInnoDBによって
　記録される誤解を招くOSエラー203を削除しました。
・MariaDB Enterprise Cluster（Galera Library 26.4.4）の場合：
　■ socket.recv_buf_sizeの設定は、ソケットが接続または受け入れられた後に行われたため、効果的では
　　ありませんでした。また、デフォルト値により、TCP受信バッファの自動調整が無効になりました。
　　これは高帯域幅WANクラスタで準最適パフォーマンスにつながります。 socket.recv_buf_sizeの
　　デフォルト値がautoに変更され、カーネルがTCP受信バッファを調整できるようになりました。
　　送信バッファの調整を可能にするために、デフォルト値autoを持つ新しい変数socket.send_buf_sizeが
　　追加されました。

バグ修正
＜クラッシュ、ハング、ストールを引き起こす可能性があるもの＞
・サーバーの再起動中にInnoDBのリカバリでメモリ不足の状態が発生することがありました。再起動は
　innodb_buffer_pool_sizeを増やした後でのみ可能でした。
・大規模な挿入または更新のロールバック時、または、大規模な更新または削除の後にトランザクション
　履歴をパージするバックグラウンドタスク中に、サーバーがハングすることがありました。
・SPATIAL INDEXによるロールバック時またはトランザクション履歴をパージするバックグラウンド
　タスク中に、サーバーがハングすることがありました。
・ALTER TABLE ... IMPORT TABLESPACEを使用すると、まれにクラッシュが発生することがありました。
・binlog_checksum=CRC32（デフォルト）が設定されている場合に、SHOW BINLOG EVENTS FROM pos
　のパラメータposの値がバイナリログのイベントの開始を指していない場合、サーバーがクラッシュする
　可能性があります。
・RESET MASTERが実行され、レプリカがGTIDプロトコルを使用して再接続する時、準同期モードで
　実行されているレプリケーションプライマリ（マスター）がクラッシュすることがありました。
・slave-parallel-threadsが0より大きい値に設定されているレプリカからバックアップが取得されると
　MariaDB Enterprise Backupはデッドロックに遭遇することがありました。
・MariaDB Enterprise Backupは、FLUSH TABLESとUNLOCK TABLESと組み合わせて使用すると、
　クラッシュすることがありました。
・テーブルでオフラインデータファイル圧縮を実行すると、aria_packユーティリティがクラッシュ
　しました。
・wsrep_OSU_method=RSUおよびSESSION sql_log_bin=0でパーティションをドロップすると、
　MariaDB Enterprise Cluster（Galera）ノードがハングしました。
・slave-parallel-threadsが0より大きい値に設定されている時、レプリカ（スレーブ）サーバーの
　シャットダウンがハングすることがありました。
・SET STATEMENT max_statement_timeを使用してステートメントのタイムアウトを設定すると、
　クラッシュしました。
・実行中のサーバーのMariaDB Enterprise ClusterでGalera Cluster Replicationを有効にした後に
　wsrep_onシステムステータス変数に問い合わせると、クラッシュすることがありました。

＜予期しない動作を引き起こす可能性があるもの＞
・innodb_strict_mode=ON（デフォルト）の場合、InnoDBテーブルでTRUNCATEまたはOPTIMIZEを
　実行すると、予期しないSQLエラー Error (1118): Row size too largeが発生する可能性がありました。
・ウィンドウ関数と暗黙的なグループ化を使用するクエリは、間違った結果を返す可能性がありました。
・式でDISTINCT COUNT(*) OVER()を使用するクエリが間違った結果を返しました。
・スレッドプールでの非効率なスレッド処理は、そのスレッドプールを使用するアプリケーションに
　影響を与えます。
・MariaDB Enterprise Server設定ファイルmariadb-enterprise.cnfは、RPMパッケージの設定ファイル
　として登録されませんでした。
・ALTER USER IF EXISTSがSQL構文エラーを生成しました。
・ビューのフィールドを含む式とともにGROUP BYを使用するクエリは、間違った結果を返す可能性が
　ありました。
・MariaDB Enterprise Clusterでスクリプトmysql_tzinfo_to_sqlを実行すると、異なるノード間で
　タイムゾーン情報に一貫性がなくなることがありました。
・mariabackupで--use-memoryオプションを使用すると、メモリ不足が発生しました。
・範囲計画は、マルチ結合クエリに必ずしも使用されませんでした。
・システムのバージョン管理期間を定義するために使用される新しい最初の列を追加するために
　InnoDBテーブルでALTER TABLEを実行すると、予期しないエラーにつながる可能性がありました。
　これは、トランザクションベースのシステムバージョンが使用された時にのみ発生しました。
・MariaDB Enterprise Cluster（Galera Library 26.4.4）の場合：
　■ GCSは、そのノードがDONOR状態であってもJOINメッセージを配信しました。
　■ GCacheに、異なるクラスタからの混ざった履歴が含まれることがありました。
　■ GCommソケットのタイムスタンプチェック/ライブネスチェックにより、大規模なトランザクションの
　　レプリケーション中に誤検出が発生し、接続の切断が過剰に発生しました。
　■ 大規模なトランザクションは、セグメンテーションが設定された時に帯域幅を独占できたため、
　　セグメント中継者によって中継されるメッセージが遅延しました。この修正により、公平な
　　メッセージキューイングが実装されます。
　■ クォーラムの計算のバグにより、新しいプライマリビューの形成中にグループが再びマージおよび
　　パーティション分割されると、2つのプライマリ競合するプライマリコンポーネントが形成されました。

＜インストールまたはアップグレードに関連するもの＞
・設定ファイルにlc_messagesが設定されている場合、サーバーを起動できませんでした。

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

---