TiDB 7.4.0 リリースノート

発売日:2023年10月12日

TiDB バージョン: 7.4.0

クイックアクセス: クイックスタート | インストールパッケージ

7.4.0 では、次の主要な機能と改善点が導入されています。

カテゴリー特徴説明
信頼性と可用性グローバルソートによるIMPORT INTOおよびADD INDEX操作のパフォーマンスと安定性を向上します (実験的) v7.4.0 より前は、 TiDB Distributed eXecution Framework (DXF)を使用したADD INDEXIMPORT INTOなどのタスクは、ローカライズされた部分的なソートを意味しており、最終的に TiKV は部分的なソートを補うために多くの追加作業を行うことになりました。これらのジョブでは、TiKV にロードする前に、TiDB ノードでソート用のローカル ディスク領域を割り当てる必要もありました。
v7.4.0 でのグローバル ソート機能の導入により、データは TiKV にロードされる前にグローバル ソートのために外部共有storage(このバージョンでは S3) に一時的に保存されます。これにより、TiKV が余分なリソースを消費する必要がなくなり、 ADD INDEXIMPORT INTOなどの操作のパフォーマンスと安定性が大幅に向上します。
バックグラウンドタスクのリソース制御(実験的) v7.1.0 では、ワークロード間のリソースとstorageのアクセス干渉を軽減するために、 リソース制御機能が導入されました。 TiDB v7.4.0 では、この制御をバックグラウンド タスクにも適用します。 v7.4.0 では、リソース コントロールは、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンライン DDL などのバックグラウンド タスクによって生成されたリソースを識別して管理するようになりました。これは最終的にはすべてのバックグラウンド タスクに適用されます。
TiFlash はストレージとコンピューティングの分離と S3 (GA) をサポートしますTiFlash の分散storageとコンピューティングアーキテクチャ、および S3 共有storageが一般提供されます。
  • TiFlash のコンピューティングとstorageを分割します。これは、Elastic HTAP リソース使用率のマイルストーンです。
  • S3 ベースのstorageエンジンの使用をサポートし、低コストで共有storageを提供できます。
SQL TiDB はパーティション タイプの管理をサポートしますv7.4.0 より前では、レンジ/リスト パーティション テーブルはTRUNCATEEXCHANGEADDDROPREORGANIZEなどのパーティション管理操作をサポートし、ハッシュ/キー パーティション テーブルはADDCOALESCEなどのパーティション管理操作をサポートします。

TiDB は、次のパーティション タイプ管理操作もサポートするようになりました。

  • パーティション化されたテーブルを非パーティション化テーブルに変換する
  • 既存のパーティション化されていないテーブルをパーティション化する
  • 既存のテーブルのパーティション タイプを変更する
MySQL 8.0 互換性: 照合順序utf8mb4_0900_ai_ciをサポートMySQL 8.0 の注目すべき変更点の 1 つは、デフォルトの文字セットが utf8mb4 であり、 utf8mb4 のデフォルトの照合順序がutf8mb4_0900_ai_ciであることです。 TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が強化され、デフォルトの照合順序を使用した MySQL 8.0 データベースからの移行とレプリケーションがよりスムーズになりました。
DB の操作と可観測性IMPORT INTOおよびADD INDEX SQL ステートメントを実行するためのそれぞれの TiDB ノードを指定します (実験的)既存の TiDB ノードまたは新しく追加された TiDB ノードのいずれかでIMPORT INTOまたはADD INDEX SQL ステートメントを実行するかどうかを柔軟に指定できます。このアプローチにより、残りの TiDB ノードからリソースを分離でき、ビジネス運営への影響を防ぎながら、前述の SQL ステートメントを実行するための最適なパフォーマンスを確保できます。

機能の詳細

スケーラビリティ

  • Distributed eXecution Framework (DXF) のバックエンドADD INDEXまたはIMPORT INTOタスクを並列実行するための TiDB ノードの選択をサポート (実験的) #46453 @ ywqzzy

    リソースを大量に消費するクラスターでADD INDEXまたはIMPORT INTOタスクを並行して実行すると、大量の TiDB ノード リソースが消費され、クラスターのパフォーマンスの低下につながる可能性があります。 v7.4.0 以降、システム変数tidb_service_scopeを使用して、 TiDB 分散実行フレームワーク (DXF)の下の各 TiDB ノードのサービス スコープを制御できます。複数の既存の TiDB ノードを選択することも、新しい TiDB ノードの TiDB サービス スコープを設定することもでき、すべての並列ADD INDEXおよびIMPORT INTOタスクはこれらのノードでのみ実行されます。このメカニズムにより、既存のサービスへのパフォーマンスへの影響を回避できます。

    詳細については、 ドキュメンテーションを参照してください。

  • Partitioned Raft KVstorageエンジンの強化 (実験的) #11515 #12842 @ ビジージェイ @ トニーシュクキ @ タボキー @ バッファフライ @ 5kbps @ SpadeA-Tang @ ノールーシュ

    TiDB v6.6.0 では、実験的機能として Partitioned Raft KVstorageエンジンが導入されています。これは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存し、各リージョンのデータは個別の RocksDB インスタンスに独立して保存されます。

    v7.4.0 では、TiDB は Partitioned Raft KVstorageエンジンの互換性と安定性をさらに向上させます。大規模なデータ テストを通じて、DM、 Dumpling、 TiDB Lightning、TiCDC、 BR、PITR などの TiDB エコシステム ツールおよび機能との互換性が保証されます。さらに、パーティション化されたRaft KVstorageエンジンは、読み取りと書き込みの混合ワークロード下でより安定したパフォーマンスを提供し、書き込み負荷の高いシナリオに特に適しています。さらに、各 TiKV ノードは 8 コア CPU をサポートし、8 TB データstorageと 64 GBメモリで構成できるようになりました。

    詳細については、 ドキュメンテーションを参照してください。

  • TiFlash は、分散storageおよびコンピューティングアーキテクチャ(GA) #6882 @ ジェイ・ソン・ファン @ ジンヘリン @ ブリーズウィッシュ @ リデジュ @ カルビンネオ @ ロイド・ポティガーをサポートしています。

    v7.0.0 では、 TiFlashに実験的機能として分散storageおよびコンピューティングアーキテクチャが導入されています。一連の改善により、 TiFlashの分散storageおよびコンピューティングアーキテクチャが v7.4.0 から GA になります。

    このアーキテクチャでは、 TiFlashノードは 2 つのタイプ (コンピューティング ノードと書き込みノード) に分けられ、S3 API と互換性のあるオブジェクトstorageをサポートします。どちらのタイプのノードも、コンピューティング容量またはstorage容量に合わせて個別にスケーリングできます。分離されたstorageとコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザ ヒントの指定など、結合されたストレージとコンピューティングアーキテクチャと同じ方法でTiFlashを使用できます。

    TiFlashの分離されたstorageとコンピューティングアーキテクチャと、結合されたstorageとコンピューティングアーキテクチャは、同じクラスター内で使用したり、相互に変換したりすることはできないことに注意してください。 TiFlash を展開するときに使用するアーキテクチャを構成できます。

    詳細については、 ドキュメンテーションを参照してください。

パフォーマンス

  • JSON 演算子MEMBER OFを TiKV #46307 @ wshwsh12にプッシュダウンするサポート

    • value MEMBER OF(json_array)

    詳細については、 ドキュメンテーションを参照してください。

  • 任意のフレーム定義タイプのウィンドウ関数のTiFlash #7376 @ xzhangxian1008へのプッシュダウンをサポート

    v7.4.0 より前では、 TiFlash はPRECEDINGまたはFOLLOWING含むウィンドウ関数をサポートしておらず、そのようなフレーム定義を含むすべてのウィンドウ関数をTiFlashにプッシュダウンすることはできません。 v7.4.0 以降、 TiFlash はすべてのウィンドウ関数のフレーム定義をサポートします。この機能は自動的に有効になり、関連する要件が満たされると、フレーム定義を含むウィンドウ関数が自動的にTiFlashにプッシュダウンされて実行されます。

  • クラウド ストレージ ベースのグローバル ソート機能を導入して、並列実行時のADD INDEXおよびIMPORT INTOタスクのパフォーマンスと安定性を向上させます (実験的) #45719 @ wjhuang2016

    v7.4.0 より前では、分散実行フレームワーク (DXF) でADD INDEXIMPORT INTOようなタスクを実行する場合、各 TiDB ノードは、エンコードされたインデックス KV ペアとテーブル データ KV ペアをソートするために大量のローカル ディスク領域を割り当てる必要がありました。ただし、グローバルな並べ替え機能がないため、プロセス中に異なる TiDB ノード間および個々のノード内でデータが重複する可能性があります。その結果、TiKV はこれらの KV ペアをstorageエンジンにインポートする間、常に圧縮操作を実行する必要があり、これがADD INDEXIMPORT INTOのパフォーマンスと安定性に影響を与えます。

    v7.4.0 では、TiDB にグローバルソート機能が導入されています。エンコードされたデータをローカルに書き込んでそこで並べ替えるのではなく、データはクラウドstorageに書き込まれてグローバルに並べ替えられるようになりました。並べ替えが完了すると、インデックス付きデータとテーブル データの両方が TiKV に並行してインポートされるため、パフォーマンスと安定性が向上します。

    詳細については、 ドキュメンテーションを参照してください。

  • 非プリペアド ステートメント (GA) #36598 @ qw4990の実行プランのキャッシュをサポート

    TiDB v7.0.0 では、同時 OLTP の負荷容量を向上させるための実験的機能として、準備されていないプラン キャッシュが導入されています。 v7.4.0 では、この機能は GA になります。実行プラン キャッシュはより多くのシナリオに適用されるため、TiDB の同時処理能力が向上します。

    準備されていないプラン キャッシュを有効にすると、追加のメモリと CPU オーバーヘッドが発生する可能性があり、すべての状況に適しているとは限りません。 v7.4.0 以降、この機能はデフォルトで無効になっています。 tidb_enable_non_prepared_plan_cache使用して有効にし、 tidb_session_plan_cache_sizeを使用してキャッシュ サイズを制御できます。

    さらに、この機能はデフォルトでは DML ステートメントをサポートしておらず、SQL ステートメントに特定の制限があります。詳細については、 制限を参照してください。

    詳細については、 ドキュメンテーションを参照してください。

信頼性

  • TiFlash はクエリレベルのデータスピル#7738 @ ウィンドトーカーをサポートします

    v7.0.0 以降、 TiFlash は3 つの演算子 ( GROUP BYORDER BY 、およびJOIN ) のデータ スピルの制御をサポートします。この機能により、データ サイズが使用可能なメモリを超えた場合のクエリの終了やシステム クラッシュなどの問題が防止されます。ただし、各オペレーターの流出を個別に管理するのは煩雑であり、全体的なリソース制御にとって非効率的になる可能性があります。

    v7.4.0 では、 TiFlash にクエリレベルのデータ流出が導入されました。 TiFlashノード上のクエリのメモリ制限をtiflash_mem_quota_query_per_nodeに設定し、データ スピルをトリガーするメモリ比率をtiflash_query_spill_ratioに設定すると、クエリのメモリ使用量を簡単に管理でき、 TiFlashメモリリソースをより適切に制御できます。

    詳細については、 ドキュメンテーションを参照してください。

  • ユーザー定義の TiKV 読み取りタイムアウト#45380 @ クレイジークス520をサポート

    通常、TiKV はリクエストを数ミリ秒以内に非常に迅速に処理します。ただし、TiKV ノードでディスク I/O ジッターやネットワークレイテンシーが発生すると、リクエストの処理時間が大幅に増加する可能性があります。 v7.4.0 より前のバージョンでは、TiKV リクエストのタイムアウト制限は固定されており、調整できません。したがって、TiKV ノードで問題が発生した場合、TiDB は固定期間のタイムアウト応答を待つ必要があり、その結果、ジッター中のアプリケーション クエリのパフォーマンスに顕著な影響が生じます。

    TiDB v7.4.0 では、新しいシステム変数tikv_client_read_timeoutが導入されており、これにより、TiDB がクエリで TiKV に送信する RPC 読み取りリクエストのタイムアウトをカスタマイズできます。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信されたリクエストが遅延した場合、TiDB はタイムアウトを早めてリクエストを他の TiKV ノードに再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザ ヒント/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */使用して、TiDB が TiKV RPC 読み取りリクエストを送信するためのタイムアウトを設定することもできます。この機能強化により、TiDB は不安定なネットワークまたはstorage環境に適応する柔軟性が得られ、クエリのパフォーマンスが向上し、ユーザー エクスペリエンスが向上します。

    詳細については、 ドキュメンテーションを参照してください。

  • オプティマイザー ヒント#45892 @ ウィノロスを使用した一部のシステム変数値の一時的な変更をサポートします。

    TiDB v7.4.0 では、MySQL 8.0 と同様のオプティマイザー ヒントSET_VAR()が導入されています。 SQL ステートメントにヒントSET_VAR()含めることにより、ステートメントの実行中にシステム変数の値を一時的に変更できます。これは、さまざまなステートメントの環境を設定するのに役立ちます。たとえば、リソースを大量に消費する SQL ステートメントの並列処理を積極的に増やしたり、変数を使用してオプティマイザーの動作を変更したりできます。

    ヒントSET_VAR()システム変数を使用して、変更できるシステム変数を見つけることができます。明示的にサポートされていない変数を変更すると、予期しない動作が発生する可能性があるため、変更しないことを強くお勧めします。

    詳細については、 ドキュメンテーションを参照してください。

  • TiFlash はリソース制御#7660 @ グオシャオゲをサポートします

    TiDB v7.1.0 では、リソース制御機能が一般提供され、TiDB と TiKV にリソース管理機能が提供されます。 v7.4.0 では、 TiFlash はリソース制御機能をサポートし、TiDB の全体的なリソース管理機能を向上させます。 TiFlashのリソース制御は、既存の TiDB リソース制御機能と完全な互換性があり、既存のリソース グループは TiDB、TiKV、およびTiFlashのリソースを同時に管理します。

    TiFlashリソース制御機能を有効にするかどうかを制御するには、 TiFlashパラメーターenable_resource_controlを構成します。この機能を有効にすると、 TiFlash はTiDB のリソース グループ構成に基づいてリソースのスケジューリングと管理を実行し、リソース全体の合理的な割り当てと使用を保証します。

    詳細については、 ドキュメンテーションを参照してください。

  • TiFlash はパイプライン実行モデル (GA) #6518 @ シーライズをサポートします。

    v7.2.0 以降、 TiFlash にはパイプライン実行モデルが導入されています。このモデルは、すべてのスレッド リソースを集中管理し、タスクの実行を均一にスケジュールすることで、リソースの過剰使用を回避しながらスレッド リソースの利用率を最大化します。 v7.4.0 では、 TiFlashによりスレッド リソース使用量の統計が改善され、パイプライン実行モデルが GA 機能となり、デフォルトで有効になります。この機能はTiFlashリソース制御機能と相互に依存しているため、TiDB v7.4.0 では、以前のバージョンでパイプライン実行モデルを有効にするかどうかの制御に使用されていた変数tidb_enable_tiflash_pipeline_model削除されています。代わりに、 TiFlashパラメータtidb_enable_resource_controlを構成することで、パイプライン実行モデルとTiFlashリソース制御機能を有効または無効にすることができます。

    詳細については、 ドキュメンテーションを参照してください。

  • オプティマイザモード#46080 @ 時間と運命のオプションを追加

    v7.4.0 では、TiDB に新しいシステム変数tidb_opt_objective導入され、オプティマイザが使用する推定方法を制御します。デフォルト値moderate 、オプティマイザの以前の動作を維持し、ランタイム統計を使用してデータの変更に基づいて推定を調整します。この変数がdeterminateに設定されている場合、オプティマイザーは実行時の修正を考慮せずに統計のみに基づいて実行計画を生成します。

    長期的に安定した OLTP アプリケーション、または既存の実行計画に自信がある状況の場合は、テスト後にdeterminateモードに切り替えることをお勧めします。これにより、計画変更の可能性が減ります。

    詳細については、 ドキュメンテーションを参照してください。

  • TiDB リソース制御は、バックグラウンド タスクの管理をサポートします (実験的) #44517 @ グロルフ

    データのバックアップや自動統計収集などのバックグラウンド タスクは優先度は低いですが、多くのリソースを消費します。これらのタスクは通常、定期的または不定期にトリガーされます。実行中に大量のリソースが消費されるため、オンラインの優先度の高いタスクのパフォーマンスに影響します。 v7.4.0 以降、TiDB リソース制御機能はバックグラウンド タスクの管理をサポートします。この機能により、オンライン アプリケーションに対する優先度の低いタスクのパフォーマンスへの影響が軽減され、合理的なリソース割り当てが可能になり、クラスターの安定性が大幅に向上します。

    TiDB は、次のタイプのバックグラウンド タスクをサポートします。

    • lightning : TiDB LightningまたはIMPORT INTOを使用してインポート タスクを実行します。
    • br : BRを使用してバックアップおよび復元タスクを実行します。 PITR はサポートされていません。
    • ddl : Reorg DDL のバッチ データ ライトバック フェーズ中のリソース使用量を制御します。
    • stats : 手動で実行されるか、TiDB によって自動的にトリガーされる統計を収集するタスク。

    デフォルトでは、バックグラウンド タスクとしてマークされているタスク タイプは空であり、バックグラウンド タスクの管理は無効になっています。このデフォルトの動作は、TiDB v7.4.0 より前のバージョンの動作と同じです。バックグラウンド タスクを管理するには、 defaultリソース グループのバックグラウンド タスクの種類を手動で変更する必要があります。

    詳細については、 ドキュメンテーションを参照してください。

  • ロック統計が一般公開 (GA) #46351 @ こんにちはラスティンになりました

    v7.4.0 では、 ロック統計一般提供されます。現在、運用上のセキュリティを確保するために、統計のロックとロック解除には統計の収集と同じ権限が必要です。さらに、TiDB は特定のパーティションの統計のロックとロック解除をサポートしており、柔軟性が向上します。データベース内のクエリと実行プランに自信があり、変更が発生しないようにしたい場合は、統計をロックして安定性を高めることができます。

    詳細については、 ドキュメンテーションを参照してください。

  • テーブル#46695 @ コードプレイにハッシュ結合を選択するかどうかを制御するシステム変数を導入します。

    MySQL 8.0 では、新機能としてテーブルのハッシュ結合が導入されています。この機能は主に、2 つの比較的大きなテーブルと結果セットを結合するために使用されます。ただし、トランザクション ワークロード、またはMySQL 5.7で実行されている一部のアプリケーションの場合、テーブルのハッシュ結合はパフォーマンス リスクを引き起こす可能性があります。 MySQL は、ハッシュ結合をグローバル レベルで選択するかセッション レベルで選択するかを制御するoptimizer_switchを提供します。

    v7.4.0 以降、TiDB ではテーブルのハッシュ結合を制御するためにシステム変数tidb_opt_enable_hash_joinが導入されています。これはデフォルトで有効になっています ( ON )。実行計画内のテーブル間のハッシュ結合を選択する必要がないことが確実な場合は、変数をOFFに変更して、実行計画のロールバックの可能性を減らし、システムの安定性を向上させることができます。

    詳細については、 ドキュメンテーションを参照してください。

SQL

  • TiDB はパーティション タイプ管理#42728 @ むじょんをサポートします

    v7.4.0 より前は、TiDB のパーティション テーブルのパーティション タイプを変更できません。 v7.4.0 以降、TiDB は、パーティション化テーブルから非パーティション化テーブルへ、または非パーティション化テーブルからパーティション化テーブルへの変更をサポートし、パーティション タイプの変更をサポートします。したがって、パーティションテーブルのパーティション タイプと数を柔軟に調整できるようになりました。たとえば、 ALTER TABLE t PARTITION BY ...ステートメントを使用してパーティション タイプを変更できます。

    詳細については、 ドキュメンテーションを参照してください。

  • TiDB は、 ROLLUP修飾子とGROUPING関数#44487 @ アイリンキッドの使用をサポートしています。

    WITH ROLLUP修飾子とGROUPING関数は、多次元データの要約のためのデータ分析でよく使用されます。 v7.4.0 以降、 GROUP BY句でWITH ROLLUP修飾子とGROUPING関数を使用できるようになりました。たとえば、 SELECT ... FROM ... GROUP BY ... WITH ROLLUP構文でWITH ROLLUP修飾子を使用できます。

    詳細については、 ドキュメンテーションを参照してください。

DB操作

  • 照合順序utf8mb4_0900_ai_ciおよびutf8mb4_0900_bin #37566 @ ヤンケオ @ ジムララ @ bb7133をサポート

    TiDB v7.4.0 では、MySQL 8.0 からのデータ移行のサポートが強化され、2 つの照合順序utf8mb4_0900_ai_ciutf8mb4_0900_binが追加されています。 utf8mb4_0900_ai_ciは MySQL 8.0 のデフォルトの照合順序です。

    TiDB v7.4.0 では、MySQL 8.0 と互換性のあるシステム変数default_collation_for_utf8mb4も導入されています。これにより、utf8mb4 文字セットのデフォルトの照合順序を指定できるようになり、 MySQL 5.7以前のバージョンからの移行またはデータ レプリケーションとの互換性が提供されます。

    詳細については、 ドキュメンテーションを参照してください。

可観測性

  • セッション接続 ID とセッション エイリアスのログ#46071 @ ルクワンチャオへの追加をサポート

    SQL 実行の問題のトラブルシューティングを行う場合、多くの場合、TiDBコンポーネントログの内容を関連付けて、根本原因を特定することが必要になります。 v7.4.0 以降、TiDB は、TiDB ログ、スロー クエリ ログ、TiKV 上のコプロセッサからのスロー ログなどのセッション関連ログにセッション接続 ID ( CONNECTION_ID ) を書き込むことができます。セッション接続 ID に基づいていくつかのタイプのログの内容を関連付けることで、トラブルシューティングと診断の効率を向上させることができます。

    さらに、セッションレベルのシステム変数tidb_session_aliasを設定すると、上記のログにカスタム識別子を追加できます。アプリケーション識別情報をログに挿入するこの機能を使用すると、ログの内容をアプリケーションと関連付け、アプリケーションからログへのリンクを構築し、診断の難易度を下げることができます。

  • TiDB ダッシュボードは、テーブル ビュー#1589 @ バーリンでの実行プランの表示をサポートします。

    v7.4.0 では、TiDB ダッシュボードは、診断エクスペリエンスを向上させるために、テーブル ビューの[スロー クエリ]ページと[SQL ステートメント]ページでの実行プランの表示をサポートします。

    詳細については、 ドキュメンテーションを参照してください。

データ移行

  • IMPORT INTO機能#46704 @ D3ハンターを強化

    v7.4.0 以降、 IMPORT INTOステートメントにCLOUD_STORAGE_URIオプションを追加してグローバルソート機能 (実験的) を有効にすることができます。これにより、インポートのパフォーマンスと安定性が向上します。 CLOUD_STORAGE_URIオプションでは、エンコードされたデータのクラウドstorageアドレスを指定できます。

    さらに、v7.4.0 では、 IMPORT INTO機能により次の機能が導入されています。

    • Split_Fileオプションの構成をサポートします。これにより、大きな CSV ファイルを複数の 256 MiB の小さな CSV ファイルに分割して並列処理できるようになり、インポートのパフォーマンスが向上します。
    • 圧縮された CSV および SQL ファイルのインポートをサポートします。サポートされている圧縮形式には、 .gzip.gz.zstd.zst 、および.snappyが含まれます。

    詳細については、 ドキュメンテーションを参照してください。

  • Dumpling は、データを CSV ファイルにエクスポートするときにユーザー定義のターミネータをサポートします#46982 @ GMHDBJD

    v7.4.0 より前では、 Dumpling はデータを CSV ファイルにエクスポートするときに行末記号として"\r\n"を使用します。その結果、ターミネータとして"\n"を認識する特定のダウンストリーム システムでは、エクスポートされた CSV ファイルを解析できないか、ファイルを解析する前に変換にサードパーティ ツールを使用する必要があります。

    v7.4.0 以降、 Dumpling には新しいパラメータ--csv-line-terminatorが導入されています。このパラメータを使用すると、データを CSV ファイルにエクスポートするときに必要なターミネータを指定できます。このパラメータは"\r\n""\n"をサポートします。以前のバージョンとの一貫性を保つために、デフォルトのターミネータは"\r\n"です。

    詳細については、 ドキュメンテーションを参照してください。

  • TiCDC は Pulsar #9413 @ ヤムチナ @ 東門へのデータの複製をサポートします

    Pulsar は、リアルタイム データ ストリーミング エクスペリエンスを大幅に強化する、クラウドネイティブの分散型メッセージ ストリーミング プラットフォームです。 v7.4.0 以降、TiCDC は、Pulsar とのシームレスな統合を実現するために、 canal-json形式での Pulsar への変更データのレプリケートをサポートします。この機能により、TiCDC は、TiDB の変更を簡単にキャプチャして Pulsar に複製する機能を提供し、データ処理と分析機能の新たな可能性を提供します。特定のビジネス ニーズを満たすために、Pulsar から新しく生成された変更データを読み取って処理する独自のコンシューマ アプリケーションを開発できます。

    詳細については、 ドキュメンテーションを参照してください。

  • TiCDC は、クレーム チェック パターン#9153 @ 3エースショーハンドを使用して大きなメッセージの処理を改善します

    v7.4.0 より前では、TiCDC は Kafka の最大メッセージ サイズ ( max.message.bytes ) を超える大きなメッセージをダウンストリームに送信できませんでした。 v7.4.0 以降、Kafka をダウンストリームとして使用してチェンジフィードを構成する場合、大きなメッセージを保存するための外部storageの場所を指定し、外部storage内の大きなメッセージのアドレスを含む参照メッセージを Kafka に送信できます。コンシューマは、この参照メッセージを受信すると、外部storageアドレスからメッセージの内容を取得できます。

    詳細については、 ドキュメンテーションを参照してください。

互換性の変更

注記:

このセクションでは、v7.3.0 から現在のバージョン (v7.4.0) にアップグレードするときに知っておく必要がある互換性の変更について説明します。 v7.2.0 以前のバージョンから現在のバージョンにアップグレードする場合は、中間バージョンで導入された互換性の変更も確認する必要がある場合があります。

行動の変化

  • v7.4.0 以降、TiDB は MySQL 8.0 の重要な機能と互換性があり、 version()​​接頭辞8.0.11が付いているバージョンを返します。

  • TiFlash が以前のバージョンから v7.4.0 にアップグレードされた後は、元のバージョンへのインプレース ダウングレードはサポートされません。これは、v7.4 以降、 TiFlash はPageStorage V3 のデータ圧縮ロジックを最適化し、データ圧縮中に生成される読み取りおよび書き込みの増幅を軽減し、これにより基礎となるstorageファイル名の一部が変更されるためです。

  • TSO タイムスタンプの論理部分を抽出できるようにするTIDB_PARSE_TSO_LOGICAL()関数が追加されました。

  • information_schema.CHECK_CONSTRAINTSテーブルは、MySQL 8.0 との互換性を向上させるために追加されました。

システム変数

変数名種類の変更説明
tidb_enable_tiflash_pipeline_model削除されましたこの変数は、 TiFlashパイプライン実行モデルを有効にするかどうかを制御するために使用されました。 v7.4.0 以降、 TiFlashリソース制御機能が有効になると、 TiFlashパイプライン実行モデルが自動的に有効になります。
tidb_enable_non_prepared_plan_cache修正済みさらにテストを行った後、デフォルト値をONからOFFに変更します。これは、準備されていない実行プランのキャッシュが無効になることを意味します。
default_collation_for_utf8mb4新しく追加されたutf8mb4文字セットのデフォルトの照合順序を制御します。デフォルト値はutf8mb4_binです。
tidb_cloud_storage_uri新たに追加されましたグローバルソートを有効にするクラウドstorageURI を指定します。
tidb_opt_enable_hash_join新たに追加されましたオプティマイザーがテーブルのハッシュ結合を選択するかどうかを制御します。デフォルトの値はONです。 OFFに設定すると、オプティマイザは、他に利用可能な実行プランがない限り、テーブルのハッシュ結合の選択を回避します。
tidb_opt_objective新しく追加されたこの変数は、オプティマイザーの目的を制御します。 moderate TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持しており、オプティマイザはより多くの情報を使用してより適切な実行プランを生成しようとします。 determinateモードはより保守的になる傾向があり、実行計画がより安定します。
tidb_request_source_type新しく追加された現在のセッションのタスク タイプを明示的に指定します。これはリソース制御によって識別および制御されます。例: SET @@tidb_request_source_type = "background"
tidb_schema_version_cache_limit新しく追加されたこの変数は、TiDB インスタンスにキャッシュできる過去のスキーマ バージョンの数を制限します。デフォルト値は16です。これは、TiDB がデフォルトで 16 個の履歴スキーマ バージョンをキャッシュすることを意味します。
tidb_service_scope新しく追加されたこの変数はインスタンスレベルのシステム変数です。これを使用して、 TiDB 分散実行フレームワーク (DXF)の下の TiDB ノードのサービス スコープを制御できます。 TiDB ノードのtidb_service_scope backgroundに設定すると、DXF は、その TiDB ノードがADD INDEXIMPORT INTOなどの DXF タスクを実行するようにスケジュールします。
tidb_session_alias新しく追加された現在のセッションに関連するログのsession_alias列の値を制御します。
tiflash_mem_quota_query_per_node新しく追加されたTiFlashノード上のクエリの最大メモリ使用量を制限します。クエリのメモリ使用量がこの制限を超えると、 TiFlash はエラーを返し、クエリを終了します。デフォルト値は0で、制限がないことを意味します。
tiflash_query_spill_ratio新しく追加されたTiFlash クエリレベルの流出のしきい値を制御します。デフォルト値は0.7です。
tikv_client_read_timeout新しく追加されたTiDB がクエリで TiKV RPC 読み取りリクエストを送信するときのタイムアウトを制御します。デフォルト値0は、デフォルトのタイムアウト (通常は 40 秒) が使用されることを示します。

コンフィグレーションファイルのパラメータ

コンフィグレーションファイルコンフィグレーションパラメータ種類の変更説明
TiDBenable-stats-cache-mem-quota修正済みデフォルト値がfalseからtrueに変更されました。これは、TiDB 統計をキャッシュするためのメモリ制限がデフォルトで有効になることを意味します。
TiKV[`rocksdb.[defaultcfwritecflockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720)
TiKV[`rocksdb.[defaultcfwritecflockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720)
TiFlashflash.compact_log_min_gap新しく追加された現在のRaftステート マシンによって進められたapplied_indexと、最後のディスク スピル時のapplied_indexギャップがcompact_log_min_gapを超えると、 TiFlash はTiKV からのCompactLogコマンドを実行し、データをディスクにスピルします。
TiFlashprofiles.default.enable_resource_control新しく追加されたTiFlashリソース制御機能を有効にするかどうかを制御します。
TiFlashstorage.format_version修正済みデフォルト値を4から5に変更します。新しい形式では、より小さなファイルを結合することで物理ファイルの数を減らすことができます。
Dumpling--csv-line-terminator新しく追加されたCSV ファイルの目的のターミネータを指定します。このオプションは"\r\n""\n"をサポートします。デフォルト値は"\r\n"で、これは以前のバージョンと一致しています。
TiCDCclaim-check-storage-uri新しく追加されたlarge-message-handle-optionclaim-checkに設定する場合、 claim-check-storage-uri有効な外部storageアドレスに設定する必要があります。そうしないと、変更フィードの作成でエラーが発生します。
TiCDClarge-message-handle-compression新しく追加されたエンコード中に圧縮を有効にするかどうかを制御します。デフォルト値は空であり、有効になっていないことを意味します。
TiCDClarge-message-handle-option修正済みこの構成項目により、新しい値claim-checkが追加されます。 claim-checkに設定すると、TiCDC Kafka シンクは、メッセージ サイズが制限を超えた場合に外部storageへのメッセージの送信をサポートし、外部storage内のこの大きなメッセージのアドレスを含むメッセージを Kafka に送信します。

廃止された機能

  • マイダンパー v7.5.0 で非推奨となり、その機能のほとんどはDumplingに置き換えられました。 mydumper の代わりにDumpling を使用することを強くお勧めします。
  • TiKV インポーターは v7.5.0 で非推奨になります。代わりにTiDB Lightningの物理インポート モードを使用することを強くお勧めします。

改善点

  • TiDB

    • パーティション化されたテーブルに対するANALYZEオペレーションのメモリ使用量とパフォーマンスを最適化する#47071 #47104 #46804 @ ホーキングレイ
    • 統計ガベージコレクション#31778 @ ウィノロスのメモリ使用量とパフォーマンスを最適化します。
    • インデックス マージ交差のプッシュダウンlimit最適化して、クエリ パフォーマンス#46863 @ アイリンキッドを向上させます。
    • コスト モデルを改善して、 IndexLookupのテーブル取得タスク#45132 @ qw4990が含まれる場合に、誤ってフル テーブル スキャンを選択する可能性を最小限に抑えます。
    • 結合除去ルールを最適化して、 join on unique keys #46248 @ 修正データベースのクエリ パフォーマンスを向上させます。
    • 実行失敗を避けるために、複数値インデックス列の照合順序をbinaryに変更します#46717 @ ヤンケオ
  • TiKV

  • PD

    • TSO トレース情報を最適化して、TSO 関連の問題の調査を容易にする#6856 @ ティエンチャイアマオ
    • メモリ使用量を削減するための HTTP クライアント接続の再利用をサポート#6913 @ ノールーシュ
    • バックアップ クラスターが切断されたときにクラスター ステータスを自動的に更新する PD の速度が向上しました#6883 @ ディスク化
    • リソース制御クライアントの構成取得方法を強化し、最新の構成を動的に取得できるようにしました#7043 @ ノールーシュ
  • TiFlash

    • TiFlash書き込みプロセス#7564 @ カルビンネオのスピル ポリシーを最適化することで、ランダム書き込みワークロード中の書き込みパフォーマンスを向上させます。
    • TiFlash #8068 @ カルビンネオのRaftレプリケーション プロセスに関するメトリクスを追加します。
    • ファイル システムの i ノード#7595 @ ホンユニャンが枯渇する可能性を避けるために、小さなファイルの数を減らします。
  • ツール

    • バックアップと復元 (BR)

      • リージョンリーダーの移行が発生したときに PITR ログ バックアップの進行状況のレイテンシーが増加する問題を緩和します#13638 @ ユジュンセン
      • HTTP クライアント#46011 @ レヴルスMaxIdleConnsおよびMaxIdleConnsPerHostパラメータを設定することにより、ログ バックアップおよび PITR 復元タスクの接続再利用のサポートを強化します。
      • PD または外部 S3storage#42909 @ レヴルスへの接続に失敗した場合のBRのフォールト トレランスを向上させます。
      • 新しい復元パラメータを追加しますWaitTiflashReady 。このパラメータが有効な場合、 TiFlashレプリカが正常に複製された後に復元操作が完了します#43828 #46302 @ 3ポインター
      • ログバックアップの CPU オーバーヘッドを削減resolve lock #40759 @ 3ポインター
    • TiCDC

      • ADD INDEX DDL 操作を複製する実行ロジックを最適化して、後続の DML ステートメントのブロックを回避します#9644 @ スドジ
    • TiDB Lightning

      • リージョン分散フェーズ#46203 @ ミタルリシャブ中のTiDB Lightningの再試行ロジックを最適化します。
      • データ インポート フェーズ#46253 @ ランス6716中のno leaderエラーに対するTiDB Lightningの再試行ロジックを最適化します。

バグの修正

  • TiDB

    • ハッシュ パーティション#45889 @ 定義2014ではないテーブルに対してBatchPointGet演算子が誤った結果を返す問題を修正します。
    • BatchPointGet演算子がハッシュ パーティション テーブル#46779 @ ジフフストに対して誤った結果を返す問題を修正
    • TiDB パーサーが状態のままになり、解析エラー#45898 @ qw4990が発生する問題を修正します。
    • EXCHANGE PARTITIONが制約#45922 @ むじょんをチェックしない問題を修正
    • tidb_enforce_mppシステム変数が正しく復元できない問題を修正#46214 @ djshow832
    • LIKE節の_ #46287 #46618 @ 定義2014と誤って処理される問題を修正
    • TiDB がスキーマ#46325 @ ヒヒヒヒヒの取得に失敗した場合にschemaTsが 0 に設定される問題を修正
    • AUTO_ID_CACHE=1#46444 @ ティエンチャイアマオに設定するとDuplicate entry発生する場合がある問題を修正
    • AUTO_ID_CACHE=1#46454 @ ティエンチャイアマオに設定すると、panic後の TiDB の回復が遅くなる問題を修正
    • AUTO_ID_CACHE=1#46545 @ ティエンチャイアマオに設定されている場合、 SHOW CREATE TABLEnext_row_idが正しくない問題を修正
    • サブクエリ#45838 @ djshow832で CTE を使用するときに解析中に発生するpanicの問題を修正します。
    • EXCHANGE PARTITION失敗するかキャンセルされると、パーティション テーブルに対する制限が元のテーブルに残る問題を修正します#45920 #45791 @ むじょん
    • リスト パーティションの定義でNULLと空の文字列#45694 @ むじょんの両方の使用がサポートされていない問題を修正します。
    • パーティション交換#46492 @ むじょん時にパーティション定義に準拠しないデータを検出できない問題を修正
    • tmp-storage-quota設定が有効にならない問題を修正#45161 #26806 @ wshwsh12
    • WEIGHT_STRING()関数が照合照合順序#45725 @ ドヴィーデンと一致しない問題を修正
    • インデックス結合のエラーによりクエリがスタックする可能性がある問題を修正します#45716 @ wshwsh12
    • DATETIMEまたはTIMESTAMP列を数値定数#38361 @ イービン87と比較するときに動作が MySQL と矛盾する問題を修正
    • 符号なし型とDuration型定数#45410 @ wshwsh12を比較するときに発生する誤った結果を修正しました。
    • アクセス パス プルーニング ロジックがREAD_FROM_STORAGE(TIFLASH[...])ヒントを無視し、 Can't find a proper physical planエラー#40146 @ アイリンキッドを引き起こす問題を修正します。
    • GROUP_CONCATORDER BY#41986 @ アイリンキッドを解析できない問題を修正
    • 深くネストされた式に対して HashCode が繰り返し計算され、メモリ使用量が増加し、OOM #42788 @ アイリンキッドが発生する問題を修正します。
    • CAST に精度の損失がない#45199 @ アイリンキッドのときに、 cast(col)=range条件によってフルスキャンが発生する問題を修正します。
    • MPP 実行プランの Union を介して集計がプッシュダウンされると、結果が正しくない#45850 @ アイリンキッドという問題を修正します。
    • in (?)のバインディングがin (?, ... ?) #44298 @ qw4990と一致しない問題を修正
    • non-prep plan cacheが実行プラン#47008 @ qw4990を再利用するときに接続照合照合順序が考慮されないことによって発生するエラーを修正
    • 実行されたプランがプラン キャッシュ#46159 @ qw4990にヒットしない場合に警告が報告されない問題を修正します。
    • plan replayer dump explainがエラー#46197 @ 時間と運命を報告する問題を修正
    • CTE を使用して DML ステートメントを実行するとpanic#46083 @ ウィノロスが発生する可能性がある問題を修正
    • 2 つのサブクエリ#46160 @ qw4990を結合するときにTIDB_INLJヒントが有効にならない問題を修正
    • MERGE_JOINの結果が正しくない問題を修正#46580 @ qw4990
  • TiKV

    • Titan が有効になっているときに TiKV が起動できず、 Blob file deleted twiceエラーが発生する問題を修正します#15454 @ コナー1996
    • スレッド自主監視パネルとスレッド非自主監視パネル#15413 @ SpadeA-Tangにデータがない問題を修正
    • raftstore-applys #15371 @ コナー1996が増加し続けるデータ エラーを修正
    • リージョン#13311 @ ジグアンの不正なメタデータによって引き起こされる TiKVpanic問題を修正
    • sync_recoveryからsync #15366 @ ノールーシュに切り替えた後に QPS が 0 に低下する問題を修正
    • オンライン安全でないリカバリがタイムアウト#15346 @ コナー1996で中止されない問題を修正
    • CpuRecord #15304 @ オーバーヴィーナスによって引き起こされる潜在的なメモリリークの問題を修正
    • バックアップ クラスターがダウンし、プライマリ クラスターがクエリされると"Error 9002: TiKV server timeout"が発生する問題を修正します#12914 @ コナー1996
    • プライマリ クラスターが#12320 @ ディスク化回復した後に TiKV を再起動すると、バックアップ TiKV がスタックする問題を修正します。
  • PD

  • TiFlash

  • ツール

    • バックアップと復元 (BR)

      • バックアップ失敗時の誤解を招くエラー メッセージresolve lock timeoutが実際のエラーを隠蔽する問題を修正#43236 @ ユジュンセン
      • PITR を使用して暗黙的な主キーを回復すると競合が発生する可能性がある問題を修正#46520 @ 3ポインター
      • PITR を使用してメタ KV を回復するとエラー#46578 @ レヴルスが発生する可能性がある問題を修正
      • BR統合テスト ケース#46561 @ ピュアリンドのエラーを修正
    • TiCDC

      • PD のスケールアップおよびスケールダウン中に TiCDC が無効な古いアドレスにアクセスする問題を修正します#9584 @ フビンジ @ 東門
      • 一部のシナリオで変更フィードが失敗する問題を修正#9309 #9450 #9542 #9685 @ ひっくり返る @ CharlesCheung96
      • アップストリーム#9430 @ スドジの 1 つのトランザクションで複数の行の一意のキーが変更されると、レプリケーション書き込みの競合が発生する可能性がある問題を修正します。
      • アップストリーム#9476 #9488 @ CharlesCheung96 @ 東門の同じ DDL ステートメントで複数のテーブルの名前が変更されると、レプリケーション エラーが発生する問題を修正します。
      • CSV ファイル#9609 @ CharlesCheung96で中国語の文字が検証されない問題を修正
      • すべての変更フィードが削除された後、上流の TiDB GC がブロックされる問題を修正#9633 @ スドジ
      • scale-outが有効になっている場合、 #9665 @ スドジの場合にノード間で書き込みキーが不均等に分散される問題を修正します。
      • 機密ユーザー情報がログ#9690 @ スドジに記録される問題を修正
    • TiDB データ移行 (DM)

      • DM が大文字と小文字を区別しない照合順序#9489 @ ヒヒヒヒヒとの競合を正しく処理できない問題を修正します。
      • DM バリデーターのデッドロック問題を修正し、再試行#9257 @ D3ハンターを強化しました。
      • 失敗した DDL がスキップされ、後続の DDL が実行されない場合、DM から返されるレプリケーション ラグが増大し続ける問題を修正します#9605 @ D3ハンター
      • オンライン DDL #9587 @ GMHDBJDをスキップすると、DM がアップストリーム テーブル スキーマを適切に追跡できない問題を修正します。
      • 楽観的モード#9588 @ GMHDBJDでタスクを再開すると、DM がすべての DML をスキップする問題を修正します。
      • DM が楽観的モード#9788 @ GMHDBJDでパーティション DDL をスキップする問題を修正
    • TiDB Lightning

      • TiDB Lightning がテーブルNONCLUSTERED auto_incrementとテーブルAUTO_ID_CACHE=1をインポートした後、データを挿入するとエラーが返される問題を修正します#46100 @ ティエンチャイアマオ
      • checksum = "optional" #45382 @ lyzx2001の場合でもチェックサムがエラーを報告する問題を修正
      • PDクラスタアドレスが#43436 @ リチュンジュに変更されるとデータインポートが失敗する問題を修正

貢献者

TiDB コミュニティの以下の貢献者に感謝いたします。

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.