2024.03.14

MariaDB

MariaDB Enterprise Server 10.6.17-12 GA版(リリース日:2024年3月11日)

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

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

注目すべき変更点

  • Galeraが26.4.17に更新されました。
  • AlmaLinux 8および9が正式にサポートされるようになりました。RHEL 8および9パッケージはAlmaLinuxに使用されます。
  • このリリースでのsecure_auth=0の廃止
  • 新しい変数 optimizer_adjust_secondary_key_costs
    • この変数は、オプティマイザーがInnoDBのクラスター化されたプライマリキーではなくセカンダリキーを誤って使用した場合のオプティマイザーの動作を変更します。
    • 新しい変数の様々な値:
      • optimizer_adjust_secondary_key_costs=0(デフォルト)
        • 現行モデルからの変更はありません
      • optimizer_adjust_secondary_key_costs=1
        • セカンダリインデックスのコストがプライマリキーのコストの少なくとも5倍であることを保証します
      • optimizer_adjust_secondary_key_costs=2
        • worst_seek最適化を無効にし、フィルターコストをわずかに調整します(フィルターが使用されている場合はコスト 1を追加します)
  • データベースに対してALL PRIVILEGESを持つユーザーには、そのデータベース内の全てのルーチン本体も表示されるようになります。
  • ネットワーク関連のエラーについてのより詳細なログが追加されました。これを有効にするためには、--log-warnings=4またはそれ以上を使用します。
  • sql_error_log_with_db_and_thread_info=ONが設定されている場合、スレッド IDとデータベースがSQLエラープラグインのログに追加されるようになりました。

修正された問題

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

  • FOREIGN KEYを使用したPRIMARY KEYのUPDATEでのBLOBの破損
  • インスタントADD COLUMNが最大レコード長を超えようとしたために失敗した後、テーブルが破損しました。
  • テーブルの作成、名前変更、削除が頻繁に行われる場合、バックアップを復元できません。mariadb-backup --prepareは失敗するか正常に終了する可能性がありますが、最近作成されたテーブルの一部のデータファイルが破損する可能性があります。
  • ALTERコマンドは、TOIに入る前に、テーブルの外部キーを収集しようとします。このため、待機中のキューにあるロック要求を無視するSHARED_HIGH_PRIO MDLロックを使用してメインテーブルを開きます。同じテーブル上で実行されているDML操作があり、実際のTOI操作も存在する場合、このTOI操作はDML操作をBFアボートしようとします。同時に、ALTERはまだTOIではなく、HIGH_PRIO MDLロックで実行されるため、待機中のTOI操作を無視してロックを取得し、TOIによって直接または中止されたDML操作によって即座にBFアボートされます。ALTERにはwsrepトランザクションがないため、トレッドにkilled状態を設定することでBFアボートになります。ただし、TOIに入る前に、ALTERは強制終了状態を確認しないため、複製されて、他のノードに正常に適用されますが、その後ローカルノードでロールバックされるため、不整合が発生します。
  • Galeraでbinlogエミュレーションが有効になっている場合、関連するストレージエンジンの1つがセーブポイントをサポートしていない時にSAVEPOINTを設定しようとすると、クラスター全体で不整合が発生する可能性があります。トランザクションの一部が他のノートにレプリケートされる可能性がありますが、ローカルステートメントのロールバックがトリガーされる可能性があります。
  • ALTER TABLE...IMPORT TABLESPACEを発行した後のInnoDBは、クラッシュセーフではなくなる可能性があります。
  • sql_mode=ORACLEを使用して仮想列を使用してテーブルが作成されると、sql_modeの異なる設定を使用している時にテーブルが変更される場合に、サーバーがクラッシュする可能性があります。
    • 仮想列は以下を使用して作成されている必要があります:
      • DECODE()
      • LTRIM()
      • RTRIM()
      • LPAD()
      • RPAD()
      • REPLACE()
      • SUBSTR()

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

  • ROW_FORMAT=COMPRESSEDを使用して破損したInnoDBテーブル内のBLOBにアクセスするとデッドロックが発生する可能性があります。
  • 空の結果セットを使用したINSERT .. FROM SELECTは、innodb_force_recovery=6またはinnodb_read_only=ONでクラッシュします。
  • innodb_fast_shutdown=0を指定したサーバーのシャットダウンは、サーバーの起動に失敗した後にハングする可能性があります。
  • MySQL 8.0のファイルを使用したALTER TABLE...IMPORT TABLESPACEで"unsupported meta-data version"というメッセージを表示しようとするとクラッシュします。
  • InnoDBシステムテーブルスペース内のテーブルに間違ったテーブル属性 PAGE_COMPRESSED=1が表示されます。
  • 列の変更と外部キーの追加を同時に行うと、MariaDBがforeign_key_checks=0でクラッシュします。
  • 場合によっては、Shutdown with async replicaの起動時にノードがクラスターから削除され、次のような診断が表示されることがあります:
    [ERROR] Slave SQL: Error 'WSREP has not yet prepared node for application use' on query

    および

    [ERROR] Slave SQL: Node has dropped from cluster, Gtid 1-1-1, Internal MariaDB error code: 1047" in the server log
  • CREATE TABLE ASの後、GaleraクラスターでGTIDが分岐する場合があります。
    これにより、その後、次のような診断が行われる可能性があります:

    [ERROR] mariadbd: Error writing file '/opt/maria10.1/binlog/BINLOG' (errno: 1950 "Unknown error 1950")"

    そして、ノードがクラッシュします:

    wsrep::transaction::before_rollback(): Assertion state() == s_executing || state() == s_preparing || state() == s_prepared || state() == s_must_abort || state() == s_aborting || state() == s_cert_failed || state() == s_must_replay` failed
  • SHOW SLAVE STATUSは、SHOWが発行される頃にに並列レプリカワーカーが強制終了されると、エラーが発生したレプリカをデッドロックする可能性があります。
  • ユーザー変数をNULLにしてSELECT BINLOG_GTID_POS(@binlog_file...)を実行すると、サーバーがクラッシュする可能性があります。
  • 特定のSQL構造を使用するクエリは、サーバーのクラッシュを引き起こす可能性があります。この構造は、テーブルのない行サブクエリと、最上位にUNION操作を持つサブクエリとの等価比較です:(SELECT 'foo', 'bar') = (SELECT col1, col2 FROM t1 ... UNION ...)
  • ORDER BYおよびセミ結合の最適化を伴うDELETEはクラッシュを引き起こす可能性があります。
  • クエリで派生したラテラルが行を返さないことが保証されている場合にクラッシュする可能性があります。
  • EXCHANGE PARTITIONを使用してパーティションをテーブルに置き換える時に、交換されるテーブルがパーティション化キーと一致しない仮想列を使用している場合、サーバーがクラッシュする可能性があります。
  • 仮想列を使用するテーブルでINSERT DELAYEDを使用すると、サーバーがクラッシュする可能性があります。
  • AS OFを使用して派生テーブルからSELECTを使用すると、サーバーがクラッシュする可能性があります。
  • プリペアドステートメントの比較でJSON_CONTAINS_PATHを使用すると、ステートメントの実行時にサーバーがクラッシュする可能性があります。
  • Spiderのインストール時にmariadbd --bootstrap / mariadb_install_dbがハングします。
  • イベントデータの一部が空の場合、レプリケーションユーザー変数イベントのBinlog ChecksumはZlibによってゼロに設定されます。このバグは、zlibライブラリを使用して構築されたサーバー上の他の修正のリグレッションです。これは、binlogからの読み取り時にユーザー変数イベントのチェックサム検証エラーとして表示される場合があります。
  • 2番目の準同期レプリカをプライマリに追加すると、プライマリが最初の既存のレプリカからACKを受信するまで、イベントを受信することなく接続時にハングする可能性があります。これは、プライマリで新しいトランザクションが発生しない場合、無期限になる可能性があります。
  • SpiderテーブルでLOCK TABLESが失敗した後、サーバーがDROP DATABASEでハングします。
  • サブクエリとウィンドウ関数を含むプリペアドステートメントがsql_mode = ONLY_FULL_GROUP_BYで実行されると、サーバーがクラッシュする可能性があります。
  • OPTIMIZE TABLEで2つの一時テーブルを使用し、プリペアドステートメントとして実行されると、サーバーがクラッシュする可能性があります。
  • 型変換が必要なパラメータを指定して別のSPを呼び出すSPを呼び出すと、サーバーがクラッシュする可能性があります。
  • SET GLOBAL innodb_log_file_sizeを使用してInnoDBログファイルサイズを変更するとハングする可能性があります。
  • クエリのWHERE句に同じテーブルの128を超える列に対する条件があり、optimizer_use_condition_selectivityが3以上で、use_stats_tablesがNEVERに設定されておらず、列の統計がANALYZE TABLEによって収集されている場合、サーバーがクラッシュする可能性があります。

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

  • SHOW WARNINGSは、InnoDBの以前のトランザクションからの間違った外部キー関連の警告/エラーを表示する可能性があります。
  • LIMIT ROWS EXAMINEDを使用したI_S.INNODB_SYS_TABLESからのクエリ時のmem_heap_create_block_funcでのLeakSanitizerエラー
  • LIMIT ROWS EXAMINEDを超えるI_S.INNODB_SYS_INDEXESからのクエリにより、rec_copy_prefix_to_buf_oldでER_UNKNOWN_ERRORエラーおよびLeakSanitizerエラーが発生します。
  • ALGORITHM=COPYを指定して存在しないFOREIGN KEYをDROPすると、予期しないER_ERROR_ON_RENAMEが発生します。
  • FOREIGN_KEY_CHECKSは、コピー以外の変更が無効なFK構造を作成するのを防止しません。
  • VARCHARが拡張されすぎて列接頭辞インデックスが使用される必要がある場合、VARCHAR列のセカンダリインデックスが破損する可能性があります。
  • Spider:有効なLEFT JOINで、ERROR 1064が発生します。
  • Spiderテーブルからのサブクエリを使用したクエリ時の構文エラー
  • SpiderがSEMI-JOINを認識しません。
  • wsrep_provider_optionsは、サーバーログの"Warning 1265 Data truncated for column 'VARIABLE_VALUE' at row 1"のような診断により、深くて長いディレクトリパスでトランケートされる可能性があります。
  • Mariadb-dumpオプションの--delete-master-logsが無視されます。
  • GTIDセマンティックを破壊するマルチソースレプリケーションフィルタ
  • wsrep_gtid_mode=ONが使用され、wsrep_gtid_domain_idが0以外の場合、mariabackupを使用したSST後、GTIDはドメインレベルとseq_noレベルの両方で矛盾します。
  • wsrep_gtid_modeがONに設定されている場合、wsrep_gtid_domain_idはブートストラップされたノード以外のノードでは無視されます。
  • LONG UNIQUE ... USING HASHをREPLACEと併用するとエラーが発生する可能性があります。
  • JSON_ARRAYAGG()は正しい文字セットを評価しないため、予期しない結果が生じる可能性があります。
  • Performance_schema.status_by_threadにはSSL関連のエントリがありません。これにより、select * from sys.session_ssl_status;の結果セットも空になります。
  • set rand_seed1、rand_seed2と組み合わせて使用すると、接続は次の接続で RAND()を制御できます。
  • REGEXP_REPLACEは、utf8mb4補助文字を'?'に変換します。
  • FEDERATEDテーブルの列のUPDATEは、テーブルにAUTO_INCREMENT列が含まれている場合、"ERROR 1296 (HY000): Got error 10000 'Error on remote system: 1143: UPDATE command denied to user 'xxx'@'x.x.x.x' for column 'id' in table 'x'' from FEDERATED"で失敗します。
  • 既存の準同期接続がアクティブな時に、最初にレプリカが準同期モードを無効にした(つまり、変数rpl_semi_sync_slave_enabled=OFFを設定した)場合、"Read semi-sync reply magic number error"警告がプライマリで表示され、その後、レプリカIOスレッドが停止します(STOP SLAVEまたはエラーの発生により)。
  • 列プレフィックスの一意のハッシュキーが正しく計算されていないため、CHECK TABLEでMyISAM/Ariaテーブルが破損していると表示されます。
  • mysql.slow_logはクエリの開始時刻ではなく、クエリの終了時刻を報告します。
  • mariadb-upgradeは、バンドルされたプラグインのmysql.pluginエントリを削除しません。エラーメッセージ"[ERROR] mariadbd: Plugin 'unix_socket' is already installed."がアップグレード時に表示されます。
  • ストレージエンジン Spiderがサーバー起動時にロードされる場合、Spider関連システムおよびステータス変数は使用できません。
  • SPIDERタイプのテーブルに対するクエリでは正規表現を使用できません。
  • インデックス付き仮想列の履歴をパージする時のメモリリーク
  • --target-dirオプションが--prepareと一緒に使用されていない場合、MariaDB Enterprise Backupが、Can't open shared library '/file_key_management.so' (errno: 2, cannot open shared object file: No such file, or directory)というエラーを表示することがあります。
  • データベース部分では、ストアドプロシージャ名の大文字と小文字が区別されません。同じデータベース名が小文字と大文字として使用されている場合、これにより間違ったストアドプロシージャが使用される可能性があります。
  • CREATE UNIQUE INDEXが正しくない"ERROR 1286 (42000): Unknown storage engine 'partition'"というエラーで失敗することがあります。
  • 接続に成功すると、グローバル変数 autocommit=0が設定されているにもかかわらず、サーバーはOKパケットのserver_statusにSERVER_STATUS_AUTOCOMMITを設定します。
  • spider_same_server_link=0が設定されていても、同じインスタンス上のテーブルを参照するSpiderテーブルを作成できる場合があります。
  • Spiderがテーブル構造の自動検出に失敗し、ERROR 12500 (HY000): unknownが表示されます。
  • Windowsでは、"InnoDB: Cannot open 'C:\xampp\mysql\data/ib_buffer_pool' for reading: No such file or directory"というエラーが表示されることがありました。
  • REGEXP_REPLACEが、ORACLEモードのREPLACEとは異なる空の文字列を扱います。
  • REPLACEは、テーブルの競合する行を全て削除することになっています。UNIQUE HASHの場合、REPLACEは競合する全ての行ではなく、競合する最初の行のみを削除します。
  • mariadbクライアントがSQLの実行にデータベースを使用していない場合、SQLエラープラグインはデータベースとして(null)を出力します。
  • Enterprise Audit Pluginは常にユーザー名を報告するとは限りません。

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

  • ALGORITHM=INPLACEを使用したALTERまたは新しいインデックスの追加により、テーブルスペースのファイルサイズが増加する可能性があります。
  • ワークロードが一時停止しない限り、履歴リストは縮小されません。
  • データディレクトリが4096バイトより小さいブロックサイズを使用するNFSサーバー上に存在する場合、InnoDBファイルの拡張を伴う操作は非常に遅くなる可能性があります。
  • ワーキングセットのサイズがinnodb_buffer_pool_sizeを超えると、サーバーが短時間停止する可能性があります。
  • 変更されていないUNDOログページへの不必要な書き込み
  • innodb_undo_log_truncate=ONはページ書き込みをブロックします。
  • innodb_undo_log_truncate=ONは高速シャットダウンを防止します。
  • buf_read_ahead_linear()の一部の呼び出しは役に立たないようです。
  • InnoDBの起動時に全ての.ibdファイルを開くと時間がかかる場合があります。
  • 適応型フラッシュの推奨では、ダーティ率とチェックポイント経過時間が無視されます。
  • 多くのパーティションを含むネストされたステートメントを実行すると速度が低下する可能性があります。
  • 完全なbuf_pool.flush_listの頻繁なスキャンによるパフォーマンスの低下

プラットフォーム

エンタープライズライフサイクルに合わせて、MariaDB Enterprise Server 10.6.17-12は次のプラットフォームに提供されます:

  • AlmaLinux 8 (x86_64, ARM64)
  • AlmaLinux 9 (x86_64, ARM64)
  • CentOS 7 (x86_64)
  • Debian 10 (x86_64, ARM64)
  • Debian 11 (x86_64, ARM64)
  • Debian 12 (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)
  • 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)

MariaDB Enterprise Serverの一部のコンポーネントは、全てのプラットフォームをサポートしているわけではありません。


MariaDB Enterprise Server 10.6.17-12のリリースノート(MariaDB社ウェブサイト):
https://mariadb.com/docs/server/release-notes/mariadb-enterprise-server-10-6/10-6-17-12/


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

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