TiDB 8.0.0 リリースノート

発売日: 2024年3月29日

TiDB バージョン: 8.0.0

クイックアクセス: クイックスタート

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

カテゴリ機能/拡張機能説明
スケーラビリティとパフォーマンススケーラビリティを向上させるための PD の分解 (実験的)配置Driver(PD) には、TiDB クラスターの正常な動作を確保するための重要なモジュールが複数含まれています。クラスターのワークロードが増加すると、PD 内の各モジュールのリソース消費も増加し、これらのモジュール間の相互干渉を引き起こし、最終的にはクラスターの全体的なサービス品質に影響を及ぼします。v8.0.0 以降、TiDB は PD 内の TSO モジュールとスケジュール モジュールを個別にデプロイ可能なマイクロサービスに分割することで、この問題に対処しています。これにより、クラスターの規模が拡大しても、モジュール間の相互干渉を大幅に削減できます。このアーキテクチャにより、はるかに大きなワークロードを持つ、はるかに大規模なクラスターが可能になりました。
より大規模なトランザクションのためのバルク DML (実験的)大規模なクリーンアップ ジョブ、結合、集計などの大規模なバッチ DML ジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模な規模で制限されていました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、OOM の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データのロードに使用する場合、インポート、ロード、および復元操作とは異なります。
クラスター スナップショットの復元速度の高速化 (GA)この機能により、 BR はクラスターのスケールの利点を最大限に活用し、クラスター内のすべての TiKV ノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスター内の大規模データセットの復元速度が大幅に向上します。実際のテストでは、この機能によりダウンロード帯域幅が飽和し、ダウンロード速度が 8 ~ 10 倍、エンドツーエンドの復元速度が約 1.5 ~ 3 倍向上することが示されています。
テーブル数が膨大である場合のスキーマ情報のキャッシュの安定性を向上 (実験的)マルチテナント アプリケーションの記録システムとして TiDB を使用している SaaS 企業は、多くの場合、相当数のテーブルを保存する必要があります。以前のバージョンでは、100 万以上のテーブル数を処理することは可能でしたが、全体的なユーザー エクスペリエンスが低下する可能性がありました。TiDB v8.0.0 では、 auto analyze用の優先キューを実装することで状況が改善され、プロセスの柔軟性が高まり、より広範なテーブルにわたって安定性が向上しています。
DB 操作と可観測性インデックス使用統計の監視をサポート適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されています。この機能は、データベース内のインデックスの効率を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDC がシンプルプロトコルのサポートを追加TiCDC では、新しいプロトコルである Simple プロトコルが導入されています。このプロトコルは、DDL および BOOTSTRAP イベントにテーブル スキーマ情報を埋め込むことで、インバンド スキーマ追跡機能を提供します。
TiCDC がDebezium 形式プロトコルのサポートを追加TiCDC は、新しいプロトコルである Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクに公開できるようになりました。

機能の詳細

スケーラビリティ

  • PD はマイクロサービス モード (実験的) #5766 @ ビンシビンをサポートします

    v8.0.0 以降、PD はマイクロサービス モードをサポートします。このモードでは、PD のタイムスタンプ割り当て機能とクラスター スケジューリング関数が、独立してデプロイできる個別のマイクロサービスに分割されるため、PD のパフォーマンス スケーラビリティが向上し、大規模クラスターにおける PD のパフォーマンス ボトルネックが解消されます。

    • tsoマイクロサービス: クラスター全体に対して単調に増加するタイムスタンプ割り当てを提供します。
    • schedulingマイクロサービス: 負荷分散、ホットスポット処理、レプリカ修復、レプリカ配置など、クラスター全体のスケジュール関数を提供します。

    各マイクロサービスは独立したプロセスとしてデプロイされます。マイクロサービスに複数のレプリカを構成すると、マイクロサービスはプライマリ/セカンダリ フォールト トレラント モードを自動的に実装し、サービスの高可用性と信頼性を確保します。

    現在、PD マイクロサービスはTiDB Operator を使用してのみデプロイできます。PD がスケールアップでは解決できない重大なパフォーマンスボトルネックになる場合は、このモードを検討することをお勧めします。

    詳細についてはドキュメント参照してください。

  • Titanエンジン#16245 @ コナー1996の使いやすさを向上

    • Titan BLOB ファイルと RocksDB ブロック ファイルの共有キャッシュをデフォルトで有効にします ( shared-blob-cacheデフォルトはtrueです)。これにより、 blob-cache-size個別に構成する必要がなくなります。
    • Titan エンジンを使用するときにパフォーマンスと柔軟性を向上させるために、 min-blob-sizeblob-file-compression 、およびdiscardable-ratio動的に変更することをサポートします。

    詳細についてはドキュメント参照してください。

パフォーマンス

  • BR はスナップショットの復元速度を向上します (GA) #50701 @ 3ポインター @ リーヴルス

    TiDB v8.0.0 以降、スナップショット復元速度の高速化が一般提供 (GA) され、デフォルトで有効になっています。BRは、粗粒度のリージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SST ファイルのダウンロードと取り込み操作の相互影響の軽減、テーブル統計の復元の高速化など、さまざまな最適化を実装することで、スナップリージョン復元速度を大幅に向上させます。実際のケースのテスト結果によると、単一の TiKV ノードのデータ復元速度は 1.2 GiB/s で安定し、1 時間以内に 100 TiB のデータを復元できます。

    これは、高負荷環境でもBR が各 TiKV ノードのリソースを最大限に活用できるため、データベースの復元時間が大幅に短縮され、データベースの可用性と信頼性が向上し、データ損失やシステム障害によるダウンタイムとビジネス損失が削減されることを意味します。復元速度の向上は、多数の goroutine の並列実行に起因しており、特にテーブルやリージョンが多い場合は、メモリ消費量が大幅に増加する可能性があることに注意してください。BR クライアントを実行するには、メモリ容量が大きいマシンを使用することをお勧めします。マシンのメモリ容量が限られている場合は、より細粒度のリージョン分散アルゴリズムを使用するBRをお勧めします。また、粗粒度のリージョン分散アルゴリズムは外部storage帯域幅を大量に消費する可能性があるため、外部帯域幅が不足して他のアプリケーションに影響が出ないようにする必要があります。

    詳細についてはドキュメント参照してください。

  • 以下の関数をTiFlash #50975 #50485 @ 宜ビン87 @ 風の話し手にプッシュダウンすることをサポートします

    • CAST(DECIMAL AS DOUBLE)
    • POWER()

    詳細についてはドキュメント参照してください。

  • TiDBの並列HashAggアルゴリズムはディスクスピル(実験的) #35637 @ 翻訳者をサポートします

    以前のバージョンの TiDB では、HashAgg 演算子の同時実行アルゴリズムはメモリ内でのみ処理できます。その結果、TiDB は大量のデータをメモリ内で処理する必要があります。データ サイズがメモリ制限を超えると、TiDB は非並列アルゴリズムのみを選択でき、同時実行によるパフォーマンス向上は実現されません。

    v8.0.0 では、TiDB の並列 HashAgg アルゴリズムがディスク スピルをサポートしています。どのような並列条件でも、HashAgg 演算子はメモリ使用量に基づいてデータ スピルを自動的にトリガーできるため、パフォーマンスとデータ スループットのバランスをとることができます。現在、実験的機能として、TiDB はディスク スピルをサポートする並列 HashAgg アルゴリズムを有効にするかどうかを制御するtidb_enable_parallel_hashagg_spill変数を導入しています。この変数がON場合、有効であることを意味します。この変数は、将来のリリースで機能が一般提供された後には非推奨になります。

    詳細についてはドキュメント参照してください。

  • 自動統計収集のための優先キューを導入する#50132 @ ハイラスティン

    オプティマイザ統計を最新の状態に維持することが、データベース パフォーマンスを安定させる鍵です。ほとんどのユーザーは、最新の統計を収集するために TiDB が提供する自動統計収集に依存しています。自動統計収集では、すべてのオブジェクトの統計の状態を確認し、異常なオブジェクトをキューに追加して順次収集します。以前のバージョンでは、順序はランダムであったため、より価値のある候補が更新されるまでの待機時間が長くなり、パフォーマンスが低下する可能性がありました。

    v8.0.0 以降、自動統計収集では、さまざまな条件と組み合わせてオブジェクトの優先順位を動的に設定し、新しく作成されたインデックスや定義が変更されたパーティション テーブルなど、より適切な候補が優先的に処理されるようにします。さらに、TiDB はヘルス スコアが低いテーブルを優先し、キューの先頭に配置します。この機能強化により、収集の順序がより合理的になり、古い統計によって発生するパフォーマンスの問題が軽減されるため、データベースの安定性が向上します。

    詳細についてはドキュメント参照してください。

  • 実行プランキャッシュの制限をいくつか削除#49161 @ ミョンス @ qw4990

    TiDB はプランキャッシュサポートしており、これは OLTP システムのレイテンシーを効果的に削減でき、パフォーマンスにとって重要です。v8.0.0 では、TiDB はプラン キャッシュに関するいくつかの制限を取り除きました。次の項目を含む実行プランをキャッシュできるようになりました。

    この機能強化により、プラン キャッシュの使用例が拡張され、複雑なシナリオにおけるデータベース全体のパフォーマンスが向上します。

    詳細についてはドキュメント参照してください。

  • オプティマイザは複数値インデックスのサポートを強化します#47759 #46539 @ アレナトルクス @ 時間と運命

    TiDB v6.6.0 では、JSON データ型のクエリ パフォーマンスを向上させるために複数値インデックス導入されています。v8.0.0 では、オプティマイザーは複数値インデックスのサポートを強化し、複雑なシナリオでクエリを最適化するためにそれらを正しく識別して利用できるようになりました。

    • オプティマイザは、多値インデックスの統計情報を収集し、その統計を使用して実行プランを決定します。SQL ステートメントで複数の多値インデックスを選択できる場合、オプティマイザはコストの低いインデックスを識別できます。
    • OR使用して複数のmember of条件を接続する場合、オプティマイザーは各 DNF 項目 ( member of条件) の有効なインデックス部分パスを一致させ、Union を使用してこれらのパスを結合してIndex Merge形成できます。これにより、より効率的な条件フィルタリングとデータ フェッチが実現します。

    詳細についてはドキュメント参照してください。

  • 低精度TSO #51081 @ テーマの更新間隔の設定をサポート

    TiDB の低精度TSO機能では、定期的に更新される TSO がトランザクション タイムスタンプとして使用されます。古いデータの読み取りが許容されるシナリオでは、この機能により、リアルタイム パフォーマンスを犠牲にして小さな読み取り専用トランザクションの TSO 取得のオーバーヘッドが削減され、高同時読み取りの能力が向上します。

    v8.0.0 より前では、低精度 TSO 機能の TSO 更新間隔は固定されており、実際のアプリケーション要件に応じて調整することはできません。v8.0.0 では、TiDB は TSO 更新間隔を制御するシステム変数tidb_low_resolution_tso_update_interval導入しています。この機能は、低精度 TSO 機能が有効な場合にのみ有効になります。

    詳細についてはドキュメント参照してください。

可用性

  • プロキシコンポーネントTiProxyが一般提供(GA)される#413 @ 翻訳者 @ xhebox

    TiDB v7.6.0 では、実験的機能としてプロキシコンポーネントTiProxy が導入されています。TiProxy は、クライアントと TiDBサーバーの間にある TiDB の公式プロキシコンポーネントです。TiDB の負荷分散機能と接続永続化関数を提供し、TiDB クラスターのワークロードのバランスをよりとり、メンテナンス操作中にデータベースへのユーザー アクセスに影響を与えないようにします。

    v8.0.0 では、TiProxy が一般提供され、署名証明書の自動生成と監視関数が強化されています。

    TiProxy の使用シナリオは次のとおりです。

    • TiDB クラスターのローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス操作中は、TiDB サーバーに変更が発生し、クライアントと TiDB サーバー間の接続が中断されます。TiProxy を使用すると、これらのメンテナンス操作中に接続を他の TiDB サーバーにスムーズに移行できるため、クライアントに影響が及ぶことはありません。
    • TiDBサーバーへのクライアント接続は、他の TiDB サーバーに動的に移行できません。複数の TiDB サーバーのワークロードが不均衡な場合、クラスター全体のリソースは十分であるものの、特定の TiDB サーバーでリソースが枯渇し、レイテンシーが大幅に増加する状況が発生する可能性があります。この問題に対処するために、TiProxy は接続の動的移行を提供します。これにより、クライアントに影響を与えることなく、接続を 1 つの TiDBサーバーから別の TiDB サーバーに移行できるため、TiDB クラスターの負荷分散が実現します。

    TiProxy はTiUP、 TiDB Operator、および TiDB Dashboard に統合されており、構成、展開、保守が容易になります。

    詳細についてはドキュメント参照してください。

構文

  • 大量のデータを処理するための新しい DML タイプをサポート (実験的) #50215 @ エキシウム

    v8.0.0 より前のバージョンでは、TiDB はコミットする前にすべてのトランザクション データをメモリに保存します。大量のデータを処理する場合、トランザクションに必要なメモリがボトルネックとなり、TiDB が処理できるトランザクション サイズが制限されます。TiDB は非トランザクション DML を導入し、SQL ステートメントを分割してトランザクション サイズの制限を解決しようとしていますが、この機能にはさまざまな制限があり、実際のシナリオでは理想的なエクスペリエンスを提供しません。

    TiDB は、v8.0.0 以降、大量のデータを処理するための DML タイプをサポートしています。この DML タイプは、実行中にタイムリーに TiKV にデータを書き込み、すべてのトランザクション データをメモリに継続的にstorageことを回避し、メモリ制限を超える大量のデータの処理をサポートUPDATEます。この DML タイプは、トランザクションの整合性を確保し、標準 DML と同じ構文を使用します。1、3、5、およびREPLACE INSERTステートメントはDELETEこの新しい DML タイプを使用して大規模な DML 操作を実行できます。

    この DML タイプはパイプライン化された DML機能によって実装され、自動コミットが有効になっているステートメントにのみ影響します。システム変数tidb_dml_typeを設定することで、この DML タイプを有効にするかどうかを制御できます。

    詳細についてはドキュメント参照してください。

  • テーブル作成時にデフォルトの列値を設定する式の使用をサポート (実験的) #50936 @ ジムララ

    v8.0.0 より前では、テーブルを作成するときに、列のデフォルト値は文字列、数値、日付に制限されていました。v8.0.0 以降では、いくつかの式をデフォルトの列値として使用できます。たとえば、列のデフォルト値をUUID()に設定できます。この機能により、より多様な要件を満たすことができます。

    詳細についてはドキュメント参照してください。

  • div_precision_incrementシステム変数#51501 @ いびん87をサポート

    MySQL 8.0 は、 /演算子を使用して実行された除算演算の結果のスケールを増やす桁数を指定する変数div_precision_incrementをサポートします。v8.0.0 より前の TiDB ではこの変数はサポートされておらず、除算は小数点以下 4 桁まで実行されます。v8.0.0 以降では、TiDB はこの変数をサポートします。除算演算の結果のスケールを増やす桁数を必要に応じて指定できます。

    詳細についてはドキュメント参照してください。

DB操作

  • PITR は Amazon S3 オブジェクト ロック#51184 @ リドリスをサポートします

    Amazon S3 オブジェクト ロックは、指定された保持期間中にバックアップ データが誤ってまたは意図的に削除されるのを防ぎ、データのセキュリティと整合性を強化します。v6.3.0 以降、 BR はスナップショット バックアップ用の Amazon S3 オブジェクト ロックをサポートし、フル バックアップのレイヤーをさらに強化します。v8.0.0 以降、PITR も Amazon S3 オブジェクト ロックをサポートします。フル バックアップでもログ データ バックアップでも、オブジェクト ロック機能により、より信頼性の高いデータ保護が保証され、データのバックアップとリカバリのセキュリティがさらに強化され、規制要件を満たすことができます。

    詳細についてはドキュメント参照してください。

  • セッションレベル#50653 @ ホーキングレイで非表示のインデックスを可視化する機能をサポート

    デフォルトでは、オプティマイザは非表示のインデックス選択しません。このメカニズムは通常、インデックスを削除するかどうかを評価するために使用されます。インデックスを削除した場合のパフォーマンスへの影響が不明な場合は、インデックスを一時的に非表示に設定し、必要なときにすぐに表示に戻すオプションがあります。

    バージョン 8.0.0 以降では、セッション レベルのシステム変数tidb_opt_use_invisible_indexesからON設定して、現在のセッションで非表示のインデックスを認識できるようになりました。この機能を使用すると、最初にインデックスを可視化し、次に現在のセッションでシステム変数を変更して他のセッションに影響を与えずにテストすることで、新しいインデックスを作成してそのパフォーマンスをテストできます。この改善により、SQL チューニングの安全性が高まり、本番データベースの安定性が向上します。

    詳細についてはドキュメント参照してください。

  • 一般的なログを別のファイルに書き込むことをサポート#51248 @ 定義2014

    一般ログは、実行されたすべての SQL ステートメントをログに記録して問題の診断に役立てる、MySQL 互換の機能です。TiDB もこの機能をサポートしています。変数tidb_general_log設定することで有効にできます。ただし、以前のバージョンでは、一般ログの内容は他の情報とともに TiDB インスタンス ログにのみ書き込むことができたため、ログを長期間保存する必要があるユーザーにとっては不便でした。

    v8.0.0 以降では、構成項目log.general-log-fileを有効なファイル名に設定することで、一般ログを指定されたファイルに書き込むことができます。一般ログは、インスタンス ログと同じローテーションおよび保持ポリシーに従います。

    さらに、履歴ログ ファイルが占有するディスク領域を削減するために、TiDB v8.0.0 ではネイティブ ログ圧縮オプションが導入されています。構成項目log.file.compressionからgzip設定すると、 gzip形式を使用してローテーションされたログを自動的に圧縮できます。

    詳細についてはドキュメント参照してください。

可観測性

  • インデックス使用統計の監視をサポート#49830 @ ヤンケオ

    適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、現在の TiDB ノード上のすべてのインデックスの統計情報を記録するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルが導入され、次の情報が含まれます。

    • インデックスをスキャンするステートメントの累積実行回数
    • インデックスにアクセスする際にスキャンされる行の総数
    • インデックスをスキャンする際の選択分布
    • インデックスへの最終アクセス時刻

    この情報を使用すると、オプティマイザーによって使用されていないインデックスや選択性が低いインデックスを識別し、インデックス設計を最適化してデータベースのパフォーマンスを向上させることができます。

    さらに、TiDB v8.0.0 では、MySQL と互換性のあるビューsys.schema_unused_indexesが導入されています。このビューには、TiDB インスタンスの最後の起動以降に使用されていないインデックスが表示されます。v8.0.0 より前のバージョンからアップグレードされたクラスターの場合、 sysスキーマとビューは自動的に作成されません。 sys.schema_unused_indexesを参照して手動で作成できます。

    詳細についてはドキュメント参照してください。

Security

  • 保存時の TiKV 暗号化は Google キー管理サービス (Cloud KMS) (実験的) #8906 @ 栄光をサポートします

    TiKV は、保存データの暗号化技術を使用して保存データを暗号化することで、データのセキュリティを確保します。セキュリティのための保存データの暗号化の中核は、キー管理です。v8.0.0 以降では、Google Cloud KMS を使用して TiKV のマスターキーを管理し、Cloud KMS に基づく保存データの暗号化機能を確立して、ユーザーデータのセキュリティを強化できます。

    Google Cloud KMS に基づいて保存時の暗号化を有効にするには、Google Cloud でキーを作成し、TiKV 構成ファイルの[security.encryption.master-key]セクションを構成する必要があります。

    詳細についてはドキュメント参照してください。

  • TiDB ログ感度低下を#51306 @ xhebox強化

    TiDB ログの感度低下の強化は、ログ ファイル内の SQL テキスト情報をマークすることに基づいており、ユーザーがログを表示するときに機密データを安全に表示されるようになります。ログ情報を感度低下させるかどうかを制御して、さまざまなシナリオで TiDB ログを安全に使用できるようにし、ログ感度低下を使用する際のセキュリティと柔軟性を高めることができます。この機能を使用するには、システム変数tidb_redact_logMARKERに設定します。これにより、TiDB ログ内の SQL テキストがマークされます。ログを表示すると、マーカーに基づいて機密データが安全に表示されるため、ログ情報が保護されます。

    詳細についてはドキュメント参照してください。

データ移行

  • TiCDC はシンプルプロトコル#9898 @ 3エースショーハンドのサポートを追加します

    TiCDC では、新しいプロトコルである Simple プロトコルが導入されています。このプロトコルは、DDL および BOOTSTRAP イベントにテーブル スキーマ情報を埋め込むことで、インバンド スキーマ追跡機能を提供します。

    詳細についてはドキュメント参照してください。

  • TiCDC は Debezium フォーマットプロトコル#1799 @ そよ風のようなのサポートを追加します

    TiCDC は、Debezium スタイルの形式でイベント メッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクに公開できるようになりました。これにより、現在 Debezium を使用して MySQL からデータをプルし、下流処理に使用しているユーザーにとって、MySQL から TiDB への移行が簡素化されます。

    詳細についてはドキュメント参照してください。

  • DM は、ソース データベースとターゲット データベースのパスワードを暗号化および復号化するために、ユーザーが提供する秘密キーの使用をサポートします#9492 @ D3ハンター

    以前のバージョンでは、DM は比較的セキュリティの低い組み込みの固定秘密鍵を使用していました。v8.0.0 以降では、上流および下流のデータベースのパスワードを暗号化および復号化するための秘密鍵ファイルをアップロードして指定できます。また、必要に応じて秘密鍵ファイルを置き換えて、データ セキュリティを強化することもできます。

    詳細についてはドキュメント参照してください。

  • IMPORT INTO機能を強化するためにIMPORT INTO ... FROM SELECT構文をサポートします (実験的) #49883 @ D3ハンター

    以前のバージョンの TiDB では、クエリ結果をターゲット テーブルにインポートするにはINSERT INTO ... SELECTステートメントしか使用できませんでしたが、これは大規模なデータセットのシナリオでは比較的非効率的でした。v8.0.0 以降では、 IMPORT INTO ... FROM SELECT使用してSELECTクエリの結果を空の TiDB ターゲット テーブルにインポートできるようになり、 INSERT INTO ... SELECTの最大 8 倍のパフォーマンスが実現され、インポート時間が大幅に短縮されます。

    さらに、 IMPORT INTO ... FROM SELECT使用して、 AS OF TIMESTAMPでクエリされた履歴データをインポートすることもできます。

    詳細についてはドキュメント参照してください。

  • TiDB Lightning は競合解決戦略を簡素化し、 replace戦略 (実験的) #51036 @ 翻訳者を使用して競合するデータの処理をサポートします。

    以前のバージョンでは、 TiDB Lightning には論理インポート モードが1つのデータ競合解決戦略 、物理インポート モードが2つのデータ競合解決戦略あり、理解して構成するのは簡単ではありませんでした。

    v8.0.0 以降、 TiDB Lightning物理インポート モードの競合検出の旧バージョン戦略が廃止され、 conflict.strategyパラメータを介して論理インポート モードと物理インポート モードの両方の競合検出戦略を制御できるようになり、このパラメータの構成が簡素化されました。さらに、物理インポート モードでは、インポート時に主キーまたは一意キーの競合のあるデータが検出された場合に、 replace戦略で最新のデータを保持し、古いデータを上書きできるようになりました。

    詳細についてはドキュメント参照してください。

  • グローバルソートが一般提供(GA)され、 IMPORT INTOのパフォーマンスと安定性が大幅に向上しました#45719 @ ランス6716

    v7.4.0 より前では、 分散実行フレームワーク (DXF)使用してIMPORT INTOタスクを実行する場合、ローカルstorageスペースが限られているため、TiDB は TiKV にインポートする前にデータの一部のみをローカルでソートします。その結果、TiKV にインポートされたデータが大幅に重複し、インポート中に TiKV で追加の圧縮操作を実行する必要があり、TiKV のパフォーマンスと安定性に影響します。

    v7.4.0 で導入された Global Sort の実験的機能により、TiDB はインポートするデータを TiKV にインポートする前に一時的に外部storage(Amazon S3 など) に保存してグローバルソートできるため、インポート中に TiKV の圧縮操作を行う必要がなくなります。v8.0.0 では、Global Sort が GA になります。この機能により、TiKV のリソース消費が削減され、 IMPORT INTOのパフォーマンスと安定性が大幅に向上します。Global Sort を有効にすると、各IMPORT INTOタスクで 40 TiB 以内のデータのインポートがサポートされます。

    詳細についてはドキュメント参照してください。

互換性の変更

注記:

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

  • TiUPによってデプロイされたデフォルトの Prometheus バージョンを 2.27.1 から 2.49.1 にアップグレードします。
  • TiUPによってデプロイされたデフォルトの Grafana バージョンを 7.5.11 から 7.5.17 にアップグレードします。
  • GA ではないがデフォルトで有効になっている監視関連のスケジューラを削除します#7765 @ rleungx

行動の変化

  • ユーザーの潜在的な接続問題を防ぐために、Security強化モード (SEM) でrequire_secure_transportからON設定を禁止します#47665 @ 天菜まお
  • DM では、暗号化と復号化の固定秘密鍵が削除され、暗号化と復号化の秘密鍵をカスタマイズできるようになります。アップグレード前にデータソース構成移行タスクの構成で暗号化パスワードが#9492されている場合は、追加の操作についてはDM 暗号化と復号化のための秘密鍵をカスタマイズするのアップグレード手順を参照する必要があります。7 @ D3ハンター
  • v8.0.0 より前では、 ADD INDEXCREATE INDEX ( tidb_ddl_enable_fast_reorg = ON ) のアクセラレーションを有効にすると、エンコードされたインデックス キーは16の固定同時実行性で TiKV にデータを取り込みますが、これは下流の TiKV 容量に応じて動的に調整することはできません。v8.0.0 以降では、 tidb_ddl_reorg_worker_cntシステム変数を使用して同時実行性を調整できます。デフォルト値は4です。以前のデフォルト値16と比較すると、新しいデフォルト値では、インデックス付きキーと値のペアを取り込むときのパフォーマンスが低下します。このシステム変数は、クラスターのワークロードに基づいて調整できます。

MySQL 互換性

  • KEYパーティション タイプは、パーティション フィールドの空のリストを持つステートメントをサポートします。これは、MySQL の動作と一致しています。

システム変数

変数名タイプを変更説明
tidb_disable_txn_auto_retry非推奨v8.0.0 以降、このシステム変数は非推奨となり、TiDB は楽観的トランザクションの自動再試行をサポートしなくなりました。 悲観的なトランザクションモードを使用することをお勧めします。楽観的ミスティック トランザクションの競合が発生した場合は、エラーをキャプチャして、アプリケーションでトランザクションを再試行できます。
tidb_ddl_version名前を変更TiDB DDL V2 を有効にするかどうかを制御します。v8.0.0 以降では、この変数の名前は、その目的をより適切に反映するためにtidb_enable_fast_create_tableに変更されています。
tidb_enable_collect_execution_info修正済みインデックスの使用統計を記録するかどうかのコントロールを追加します。デフォルト値はONです。
tidb_redact_log修正済みTiDB ログとスロー ログを記録するときに、SAL テキスト内のユーザー情報を処理する方法を制御します。値のオプションは、 OFF (ログ内のユーザー情報を処理しないことを示す) とON (ログ内のユーザー情報を非表示にすることを示す) です。ログ内のユーザー情報をより豊富に処理する方法を提供するために、v8.0.0 では、ログ情報のマーク付けをサポートするMARKERオプションが追加されました。
div_precision_increment新しく追加された/演算子を使用して実行された除算演算の結果のスケールを増やす桁数を制御します。この変数は MySQL と同じです。
tidb_dml_type新しく追加されたDML ステートメントの実行モードを制御します。値のオプションは"standard""bulk"です。
tidb_enable_auto_analyze_priority_queue新しく追加された優先キューを有効にして、統計を自動的に収集するタスクをスケジュールするかどうかを制御します。この変数を有効にすると、TiDB は統計を最も必要とするテーブルの統計収集を優先します。
tidb_enable_parallel_hashagg_spill新しく追加されたTiDB が並列 HashAgg アルゴリズムのディスク スピルをサポートするかどうかを制御します。 ONの場合、並列 HashAgg アルゴリズムのディスク スピルをトリガーできます。 この変数は、この機能が将来のリリースで一般に利用可能になったときに非推奨になります。
tidb_enable_fast_create_table新しく追加されたTiDB はテーブル作成を高速化します有効にするかどうかを制御します。有効にするには値をONに設定し、無効にするにはOFFに設定します。デフォルト値はONです。この変数を有効にすると、TiDB はCREATE TABLE使用してテーブル作成を高速化します。
tidb_load_binding_timeout新しく追加されたバインディングの読み込みのタイムアウトを制御します。バインディングの読み込みの実行時間がこの値を超えると、読み込みは停止します。
tidb_low_resolution_tso_update_interval新しく追加されたTiDB キャッシュタイムスタンプの更新間隔を制御します。
tidb_opt_ordering_index_selectivity_ratio新しく追加されたSQL 文にORDER BYLIMIT句があり、一部のフィルタ条件がインデックスでカバーされていない場合に、SQL 文ORDER BYに一致するインデックスの推定行数を制御します。デフォルト値は-1で、このシステム変数を無効にすることを意味します。
tidb_opt_use_invisible_indexes新しく追加された現在のセッションでオプティマイザがクエリの最適化に非表示のインデックス選択できるかどうかを制御します。変数がONに設定されている場合、オプティマイザはセッションでクエリの最適化に非表示のインデックスを選択できます。
tidb_schema_cache_size新しく追加されたスキーマ情報のキャッシュに使用できるメモリの上限を制御し、過剰なメモリの占有を回避します。この機能を有効にすると、必要なテーブルをキャッシュするために LRU アルゴリズムが使用され、スキーマ情報によって占有されるメモリが効果的に削減されます。

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

コンフィグレーションファイルコンフィグレーションパラメータタイプを変更説明
ティビinstance.tidb_enable_collect_execution_info修正済みインデックスの使用統計を記録するかどうかのコントロールを追加します。デフォルト値はtrueです。
ティビtls-version修正済みこのパラメータは"TLSv1.0""TLSv1.1"サポートしなくなりました。現在は"TLSv1.2""TLSv1.3"のみをサポートしています。
ティビlog.file.compression新しく追加されたポーリング ログの圧縮形式を指定します。デフォルト値は null で、ポーリング ログは圧縮されません。
ティビlog.general-log-file新しく追加された一般ログを保存するファイルを指定します。デフォルトは null で、一般ログはインスタンス ファイルに書き込まれます。
ティビtikv-client.enable-replica-selector-v2新しく追加されたRPC 要求を TiKV に送信するときに、リージョンレプリカ セレクターの新しいバージョンを使用するかどうかを制御します。デフォルト値はtrueです。
ティクヴlog-backup.initial-scan-rate-limit修正済み最小値として1MiBの制限を追加します。
ティクヴraftstore.store-io-pool-size修正済みTiKV のパフォーマンスを向上させるためにデフォルト値を0から1に変更します。つまり、StoreWriter スレッド プールのサイズはデフォルトで1になります。
ティクヴrocksdb.defaultcf.titan.blob-cache-size修正済みv8.0.0 以降、TiKV はshared-blob-cache構成項目を導入し、デフォルトで有効になっているため、 blob-cache-size別途設定する必要はありません。 blob-cache-sizeの構成は、 shared-blob-cache falseに設定されている場合にのみ有効になります。
ティクヴsecurity.encryption.master-key.vendor修正済みサービス プロバイダーの使用可能なタイプとしてgcp追加します。
ティクヴrocksdb.defaultcf.titan.shared-blob-cache新しく追加されたTitan BLOB ファイルと RocksDB ブロック ファイルの共有キャッシュを有効にするかどうかを制御します。デフォルト値はtrueです。
ティクヴsecurity.encryption.master-key.gcp.credential-file-path新しく追加されたsecurity.encryption.master-key.vendorgcp場合、Google Cloud 認証認証情報ファイルへのパスを指定します。
TiDB Lightningtikv-importer.duplicate-resolution非推奨物理インポート モードで一意のキーの競合を検出して解決するかどうかを制御します。v8.0.0 以降では、 conflict.strategyに置き換えられます。
TiDB Lightningconflict.precheck-conflict-before-import新しく追加されたデータを TiDB にインポートする前に競合をチェックする前処理競合検出を有効にするかどうかを制御します。このパラメータのデフォルト値はfalseです。つまり、 TiDB Lightning はデータのインポート後にのみ競合をチェックします。このパラメータは、物理インポート モード ( tikv-importer.backend = "local" ) でのみ使用できます。
TiDB Lightninglogical-import-batch-rows新しく追加された論理インポート モードでトランザクションごとに挿入される行の最大数を制御します。デフォルト値は65536行です。
TiDB Lightninglogical-import-batch-size新しく追加された論理インポート モードでダウンストリーム TiDBサーバー上で実行される各 SQL クエリの最大サイズを制御します。デフォルト値は"96KiB"です。単位は KB、KiB、MB、または MiB です。
データ移行secret-key-path新しく追加されたアップストリームおよびダウンストリーム パスワードの暗号化と復号化に使用される秘密キーのファイル パスを指定します。ファイルには、64 文字の 16 進数 AES-256 秘密キーが含まれている必要があります。
ティCDCdebezium-disable-schema新しく追加されたスキーマ情報の出力を無効にするかどうかを制御します。このパラメータは、シンク タイプが MQ で、出力プロトコルが Debezium の場合にのみ有効です。

| TiCDC | tls-certificate-file | 新しく追加 | Pulsar が TLS 暗号化伝送を有効にするときに必要な、クライアント上の暗号化された証明書ファイルへのパスを指定します。 | | TiCDC | tls-key-file-path | 新しく追加 | Pulsar が TLS 暗号化伝送を有効にするときに必要な、クライアント上の暗号化された秘密キーへのパスを指定します。 |

システムテーブル

廃止された機能

  • v8.0.0 以降、 tidb_disable_txn_auto_retryシステム変数は非推奨となり、TiDB は楽観的トランザクションの自動再試行をサポートしなくなりました。代わりに、楽観的ミスティック トランザクションの競合が発生した場合は、エラーをキャプチャしてアプリケーションでトランザクションを再試行するか、代わりに悲観的なトランザクションモード使用することができます。
  • v8.0.0 以降、TiDB は TLSv1.0 および TLSv1.1 プロトコルをサポートしなくなりました。TLS を TLSv1.2 または TLSv1.3 にアップグレードする必要があります。
  • v8.0.0 以降、 TiDB Lightning物理インポート モードの競合検出の旧バージョン戦略が廃止され、 conflict.strategyパラメータを使用して論理インポート モードと物理インポート モードの両方の競合検出戦略を制御できるようになりました。競合検出の旧バージョンのduplicate-resolutionパラメータは、将来のリリースで削除される予定です。
  • 以降のリリースでは実行計画バインディングの自動進化再設計する予定であり、関連する変数と動作が変更されます。

改善点

  • ティビ

    • CREATE TABLE DDL文の実行パフォーマンスを10倍向上し、線形スケーラビリティ#50052 @ GMHDBJDをサポート
    • 16 IMPORT INTO ... FROM FILEタスクの同時送信をサポートし、ターゲット テーブルへの一括データ インポートを容易にし、データ ファイルのインポートの効率とパフォーマンスを大幅に向上させます#49008 @ D3ハンター
    • Sortオペレータ#47733 @ 翻訳者のディスクへのデータ書き込みのパフォーマンスを向上
    • ディスクへのデータのスピル中にクエリをキャンセルする機能をサポートし、データスピル機能の終了メカニズムを最適化します#50511 @ うわー
    • 複数の等条件を持つテーブル結合クエリを処理するときに、部分条件に一致するインデックスを使用してインデックス結合を構築することをサポートします#47233 @ ウィノロス
    • インデックスマージの機能を強化して、クエリ内のソート要件を識別し、ソート要件を満たすインデックスを選択します#48359 @ アイリンキッド
    • Apply演算子が同時に実行されない場合、TiDBではSHOW WARNINGS #50256 @ ホーキングレイを実行することで同時実行をブロックする演算子の名前を表示できます。
    • すべてのインデックスがpoint getクエリをサポートしている場合、クエリに最適なインデックスを選択して、 point getクエリのインデックス選択を最適化します#50184 @ エルサ0520
    • TiKV の高負荷時に広範囲にわたるタイムアウトを回避するために、統計を同期的にロードするタスクの優先度を一時的に高く調整します。タイムアウトにより、統計がロードされない可能性があります#50332 @ ウィノロス
    • PREPAREステートメントが実行プランキャッシュにヒットしない場合、TiDBではSHOW WARNINGS #50407 @ ホーキングレイを実行することでその理由を確認できます。
    • 同じデータ行が複数回更新された場合のクエリ推定情報の精度を向上#47523 @ テリー・パーセル
    • インデックスマージは、 AND述語#51778 @ 時間と運命に複数値インデックスとOR演算子を埋め込むことをサポートします。
    • force-init-stats trueに設定すると、TiDB は統計の初期化が完了するまで待機してから、TiDB の起動中にサービスを提供します。この設定により、HTTP サーバーの起動がブロックされなくなり、ユーザーは#50854 @ ホーキングレイ監視を継続できます。
    • MemoryTrackerはIndexLookup演算子#45901 @ ソロッツのメモリ使用量を追跡できます
    • MemoryTrackerはMemTableReaderExec演算子#51456 @ うわーのメモリ使用量を追跡できます
    • 大規模なテーブルをクエリするときに、KV 範囲からリージョンへの変換プロセスを高速化するために、PD からリージョンをバッチでロードする機能をサポート#51326 @ シーライズ
    • システムテーブルINFORMATION_SCHEMA.TABLESINFORMATION_SCHEMA.STATISTICSINFORMATION_SCHEMA.KEY_COLUMN_USAGEINFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTSのクエリパフォーマンスを最適化します。以前のバージョンと比較しうわー 、パフォーマンスは最大 100 倍向上しました。9 @ #50305
  • ティクヴ

    • TSOの検証と検出を強化して、構成や操作が不適切な場合のクラスターTSOの堅牢性を向上させる#16545 @ 翻訳
    • コミットされていないトランザクションの処理パフォーマンスを向上させるために、悲観的ロックのクリーンアップロジックを最適化します#16158 @ 翻訳
    • TiKV の統合ヘルスコントロールを導入して、異常な単一 TiKV ノードがクラスターアクセスパフォーマンスに与える影響を軽減しますtikv-client.enable-replica-selector-v2からfalseに設定することで#16297この最適化を無効にすることができます。5 #1104 #1167 @ ミョンケミンタ @ ジグアン @ クレイジーcs520
    • PDクライアントは、メタデータstorageインターフェースを使用して、以前のグローバル構成インターフェース#14484 @ ヒューシャープを置き換えます。
    • write cf stats #16245 @ コナー1996を通じてデータの読み込み動作を決定することでスキャンのパフォーマンスを向上させます。
    • Raft conf 変更プロセス中にノードが削除され、投票者が降格されたかどうか最新のハートビートをチェックして、この動作によってリージョンがアクセス不能にならないことを確認します#15799 @ トニー
    • パイプライン DML #16291 @ エキシウム用の Flush および BufferBatchGet インターフェイスを追加します。
    • cgroup CPU とメモリ制限の監視とアラートを追加#16392 @ ピンとb
    • リージョンワーカーとスナップショット生成ワーカー#16562 @ コナー1996 CPU モニタリングを追加します。
    • ピアのスローログを追加し、メッセージ#16600 @ コナー1996を保存します。
  • PD

  • TiFlash

  • ツール

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

      • brコマンドラインツールに新しい復元パラメータ--load-statsを導入し、統計#50568 @ リーヴルスを復元するかどうかを制御します。
      • brコマンドライン ツールに新しい復元パラメータ--tikv-max-restore-concurrencyを導入しました。これは、各 TiKV ノードのダウンロード ファイルと取り込みファイルの最大数を制御します。このパラメータは、ジョブ キューの最大長を制御することで、 BRノードのメモリ消費も制御します#51621 @ 3ポインター
      • 粗粒度のリージョン分散アルゴリズムを有効にして同時パラメータ#50701 @ 3ポインターを適応的に取得することで、復元パフォーマンスが向上します。
      • br #50927 @ リドリスのコマンドラインヘルプ情報にlogコマンドを表示します
      • 復元プロセス中にテーブル ID を事前割り当てして、テーブル ID の再利用を最大限にし、復元パフォーマンスを向上させる#51736 @ リーヴルス
      • OOM の問題を回避するために、 BR を使用するときは TiDB 内の GCメモリ制限チューナー機能を無効にします#51078 @ リーヴルス
      • より効率的なアルゴリズム#50613 @ リーヴルスを使用して、データ復元中に SST ファイルをマージする速度を向上します
      • データ復元中にバッチでデータベースを作成するサポート#50767 @ リーヴルス
      • ログバックアップ中にログとメトリックのグローバルチェックポイントの進行に影響を与える最も遅いリージョンの情報を出力します#51046 @ ユジュンセン
      • 大規模なデータセットのシナリオでRESTOREステートメントのテーブル作成パフォーマンスを向上#48301 @ リーヴルス
    • ティCDC

      • TiCDCがデータを複製する際のメモリ消費量を削減するために、 RowChangedEventのメモリ消費量を最適化します#10386 @ リデズ
      • 変更フィードタスク#10499 @ 3エースショーハンドの作成および再開時に start-ts パラメータが有効であることを確認します。
    • TiDB データ移行 (DM)

      • MariaDB プライマリ - セカンダリ レプリケーション シナリオでは、移行パスが MariaDB プライマリ インスタンス -> MariaDB セカンダリ インスタンス -> DM -> TiDB であり、 gtid_strict_mode = offで MariaDB セカンダリ インスタンスの GTID が厳密に増加していない場合 (たとえば、MariaDB セカンダリ インスタンスにデータが書き込まれている場合)、DM タスクはエラーless than global checkpoint positionを報告します。v8.0.0 以降、TiDB はこのシナリオと互換性があり、データを通常どおりにダウンストリームに移行できます#10741 @ ok江
    • TiDB Lightning

バグ修正

  • ティビ

    • データの変更がないのにauto analyzeが複数回トリガーされる問題を修正#51775 @ ハイラスティン
    • auto analyze同時実行が誤って#51749 @ ホーキングレイに設定されている問題を修正
    • 単一のSQL文を使用して複数のインデックスを追加することで発生するインデックスの不整合の問題を修正#51746 @ タンジェンタ
    • クエリでNATURAL JOIN #32044 @ アイリンキッドが使用される場合に発生する可能性のあるColumn ... in from clause is ambiguousエラーを修正します。
    • TiDB がgroup by #38756 @ ハイラスティンの定数値を誤って削除したために間違ったクエリ結果が発生する問題を修正しました。
    • LEADINGのヒントがUNION ALLステートメント#50067 @ ホーキングレイで有効にならない問題を修正
    • BIT型の列が一部の関数の計算に関係する場合にデコード失敗によりクエリ エラーが発生する可能性がある問題を修正しました#49566 #50850 #50855 @ ジフハウス
    • PD #50152 @ ジムララとの相互作用の問題により、 tiup cluster upgrade/start使用してローリング アップグレードを実行すると TiDB がpanicになる可能性がある問題を修正しました。
    • ORDER BY句でUNIQUEインデックス検索を実行するとエラー#49920 @ ジャッキーが発生する可能性がある問題を修正しました
    • 定数伝播#49440 @ ウィノロスENUMまたはSET型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました
    • クエリに Apply 演算子が含まれており、 fatal error: concurrent map writesエラーが発生すると TiDB がpanicになる可能性がある問題を修正しました#50347 @ シーライズ
    • 文字列型の変数に対するSET_VARの制御が無効になる可能性がある問題を修正#50507 @ qw4990
    • tidb_sysdate_is_now1 #49299 @ ホーキングレイに設定されている場合に、 SYSDATE()関数がプラン キャッシュ内の時間を誤って使用する問題を修正しました。
    • CREATE GLOBAL BINDINGステートメントを実行するときに、スキーマ名が大文字の場合、バインディングが有効にならない問題を修正しました#50646 @ qw4990
    • Index Path重複したインデックス#50496 @ アイリンキッドを選択する問題を修正
    • CREATE GLOBAL BINDING文にIN() #43192 @ キング・ディラン含まれている場合にPLAN REPLAYERバインディングのロードに失敗する問題を修正しました
    • 複数のanalyzeタスクが失敗した場合に失敗理由が正しく記録されない問題を修正#50481 @ ハイラスティン
    • tidb_stats_load_sync_wait ジフハウス#50872反映されない問題を修正
    • 複数のレベルのmax_execute_time設定が互いに干渉する問題を修正#50914 @ ジフハウス
    • 統計#50835 @ ハイラスティンの同時更新によって発生するスレッド セーフティの問題を修正しました。
    • パーティションテーブルでauto analyze実行すると TiDB がpanicを起こす可能性がある問題を修正#51187 @ ハイラスティン
    • SQL ステートメントのIN()に異なる数の値#51222 @ ホーキングレイが含まれている場合に SQL バインディングが機能しない可能性がある問題を修正しました。
    • TiDB が式#43527 @ ハイラスティン内のシステム変数の型を正しく変換できない問題を修正
    • force-init-stats#51473 @ ホーキングレイに設定されている場合に TiDB が対応するポートをリッスンしない問題を修正
    • determinateモード ( tidb_opt_objective='determinate' ) でクエリに述語が含まれていない場合、統計がロードされない可能性がある問題を修正しました#48257 @ 時間と運命
    • init-statsプロセスが TiDB をpanicに陥らせ、 load statsプロセスが#51581 @ ホーキングレイで終了する可能性がある問題を修正しました。
    • IN()述語にNULL #51560 @ ウィノロス含まれている場合にクエリ結果が正しくない問題を修正しました
    • DDL タスクに複数のテーブルが含まれる場合に、ブロックされた DDL ステートメントが MDLビューに表示されない問題を修正#47743 @ 翻訳:
    • テーブル上のANALYZEのタスクのうちprocessed_rowsが、そのテーブルの合計行数#50632 @ ホーキングレイを超える可能性がある問題を修正しました。
    • HashJoin演算子がディスク#50841 @ うわーにスピルできない場合に発生する可能性のある goroutine リークの問題を修正しました。
    • CTE クエリのメモリ使用量が制限#50337 @ グオシャオゲを超えた場合に発生する goroutine リークの問題を修正しました
    • 集計関数をグループ計算に使用した場合に発生する可能性のあるCan't find column ...エラーを修正#50926 @ qw4990
    • CREATE TABLEステートメントに特定のパーティションまたは制約が含まれている場合に、テーブル名の変更などの DDL 操作が停止する問題を修正しました#50972 @ lcwangchao
    • Grafana の監視メトリックtidb_statistics_auto_analyze_totalが整数#51051 @ ホーキングレイとして表示されない問題を修正しました。
    • tidb_server_memory_limit変数が変更された後にtidb_gogc_tuner_thresholdシステム変数がそれに応じて調整されない問題を修正#48180 @ ホーキングレイ
    • クエリにJOIN操作#42588 @ アイリンキッドが含まれる場合にindex out of rangeエラーが発生する可能性がある問題を修正
    • 列のデフォルト値が削除されている場合、列のデフォルト値を取得するとエラーが返される問題を修正#50043 #51324 @ クレイジーcs520
    • TiFlash の遅延マテリアライゼーションが関連列#49241 #51204 @ ロイド・ポティガーを処理するときに間違った結果が返される可能性がある問題を修正しました
    • バイナリ照合順序入力#50393 @ いびん87を処理するときにLIKE()関数が間違った結果を返す可能性がある問題を修正しました
    • 2 番目のパラメータがNULL #50931 @ シーライズの場合にJSON_LENGTH()関数が間違った結果を返す問題を修正しました
    • 特定の状況下で時間精度が失われるCAST(AS DATETIME)性がある問題を修正#49555 @ シーライズ
    • テーブルにクラスター化インデックス#51372 @ グオシャオゲがある場合に並列Applyで誤った結果が生成される可能性がある問題を修正しました。
    • 主キータイプがVARCHAR #51810 @ そよ風のようなの場合にALTER TABLE ... COMPACT TIFLASH REPLICA誤って終了する可能性がある問題を修正しました
    • EXCHANGE PARTITIONステートメント#47167 @ ジフハウスを使用してパーティション テーブルを交換するときに、 DEFAULT NULL属性のNULL値のチェックが正しく行われない問題を修正しました。
    • パーティションテーブル定義がUTF8以外の文字セット#49251 @ ヤンケオを使用する際に誤った動作を引き起こす可能性がある問題を修正
    • 一部のシステム変数#49461 @ ジフハウス INFORMATION_SCHEMA.VARIABLES_INFOテーブルに誤ったデフォルト値が表示される問題を修正
    • 一部のケースでデータベース名に空の文字列が使用された場合にエラーが報告されない問題を修正#45873 @ ヨシキポム
    • SPLIT TABLE ... INDEX文で TiDB がpanicを起こす可能性がある問題を修正#50177 @ 定義2014
    • KeyPartition種類のパーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正しました#50206 #51313 #51196 @ 時間と運命 @ ジフハウス @ ミョンス
    • ハッシュパーティションテーブルをクエリすると誤った結果が生成される可能性がある問題を修正#50427 @ 定義2014
    • オープントレースが正しく動作しない問題を修正#50508 @ 定義2014
    • ALTER INSTANCE RELOAD TLSエラー#50699 @ ドヴェーデンを報告したときにエラー メッセージが完全ではない問題を修正
    • 自動増分 ID #50819 @ 天菜まおを割り当てるときに、 AUTO_INCREMENT属性によって不要なトランザクション競合が発生し、ID が連続しなくなる問題を修正しました。
    • いくつかのエラー#50849 @ 天菜まおについて、TiDB ログ内のスタック情報が不完全になる問題を修正しました
    • LIMIT句の数値が大きすぎる場合に一部のクエリでメモリ使用量が過剰になる問題を修正#51188 @ 定義2014
    • TTL 機能により、データ範囲の分割が不正確になり、場合によってはデータ ホットスポットが発生する問題を修正しました#51527 @ lcwangchao
    • 明示的なトランザクション#51387 @ ヤンケオの最初の行にSETステートメントが表示された場合に有効にならない問題を修正しました
    • BINARYタイプの JSON をクエリすると、場合によってはエラーが発生する可能性がある問題を修正しました#51547 @ ヤンケオ
    • 有効期限#51675 @ lcwangchaoを計算するときに、TTL が夏時間調整の移行を正しく処理しない問題を修正しました。
    • 特定の条件下ではSURVIVAL_PREFERENCES属性がSHOW CREATE PLACEMENT POLICYステートメントの出力に表示されない可能性がある問題を修正#51699 @ lcwangchao
    • 無効な設定項目#51399 @ 定義2014が含まれている場合に設定ファイルが有効にならない問題を修正しました
  • ティクヴ

    • tidb_enable_row_level_checksum有効にすると TiKV がpanicになる可能性がある問題を修正#16371 @ 翻訳
    • 例外的な状況で休止状態のリージョンがすぐに起動しない問題を修正#16368 @ リクササシネーター
    • ノードをオフラインにする前に、リージョン内のすべてのレプリカの最後のハートビート時間をチェックすることで、1 つのレプリカがオフラインになるとリージョン全体が使用できなくなる問題を修正しました#16465 @ トニー
    • 最大値INT64より大きく最大値UINT64より小さい JSON 整数が TiKV によってFLOAT64として解析され、TiDB #16512 @ ヤンケオとの不整合が発生する問題を修正しました。
    • 監視メトリックtikv_unified_read_pool_thread_countにデータがない場合がある問題を修正#16629 @ ユジュンセン
  • PD

  • TiFlash

    • レプリカ移行中にPDとのネットワーク接続が不安定になり、 TiFlashがpanicになる可能性がある問題を修正#8323 @ ジェイソン・ファン
    • クエリが遅いためにメモリ使用量が大幅に増加する問題を修正#8564 @ ジンヘリン
    • TiFlashレプリカを削除して再度追加すると、 TiFlash #8695 @ ジェイソン・ファンでデータが破損する可能性がある問題を修正しました。
    • ポイントインタイムリカバリ(PITR)を実行した後、またはFLASHBACK CLUSTER TO実行した後にTiFlashレプリカデータが誤って削除され、データ異常#8777 @ ジェイソン・ファンが発生する可能性がある問題を修正しました。
    • ALTER TABLE ... MODIFY COLUMN ... NOT NULLを実行した後にTiFlash がパニックを起こし、null 許容列が#8419 @ ジェイソン・ファンに非 null 許容列に変更される問題を修正しました。
    • 分散storageとコンピューティングアーキテクチャで、ネットワーク分離後にクエリが永久にブロックされる可能性がある問題を修正#8806 @ ジンヘリン
    • 分散storageとコンピューティングアーキテクチャで、シャットダウン中にTiFlash がpanicになる可能性がある問題を修正#8837 @ ジェイソン・ファン
    • リモート読み取り#8685 @ ソロッツの場合にデータ競合によりTiFlash がクラッシュする可能性がある問題を修正しました
    • CAST(AS JSON)関数が JSON オブジェクト キー#8712 @ シーライズの重複を排除しない問題を修正しました。
    • チャンクエンコード#8674 @ いびん87中にENUM列目が原因でTiFlashがクラッシュする可能性がある問題を修正
  • ツール

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

      • リージョンがリーダーになった直後に分割またはマージされると、ログ バックアップ チェックポイントがスタックする問題を修正しました#16469 @ ユジュンセン
      • 極端なケースでフルバックアップがピアを見つけられなかった場合に TiKV がパニックになる問題を修正#16394 @ リーヴルス
      • 同じノード#50445 @ 3ポインターで TiKV IP アドレスを変更した後にログ バックアップが停止する問題を修正しました。
      • S3 #49942 @ リーヴルスからファイル コンテンツを読み取っているときにエラーが発生した場合にBR が再試行できない問題を修正しました。
      • データの復元に失敗した後、チェックポイントから再開するとエラーthe target cluster is not freshが発生する問題を修正#50232 @ リーヴルス
      • ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正#50839 @ ユジュンセン
      • TiKVノード#50566 @ リーヴルスにリーダーがいないためにデータの復元が遅くなる問題を修正
      • --filterオプションを指定した後でも、完全な復元を行うにはターゲット クラスターが空である必要があるという問題を修正しました#51009 @ 3ポインター
    • ティCDC

      • storageシンク#10352 @ チャールズ・チュン96の使用時に、storageサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。
      • 複数の変更フィード#10430 @ チャールズ・チュン96を同時に作成すると TiCDC がErrChangeFeedAlreadyExistsエラーを返す問題を修正しました
      • ignore-eventadd table partitionイベントをフィルタリングするように構成した後、TiCDC が関連パーティションの他のタイプの DML 変更をダウンストリーム#10524 @ チャールズ・チュン96に複製しない問題を修正しました。
      • アップストリームテーブル#10522 @ スドジTRUNCATE PARTITIONが実行された後に、changefeed がエラーを報告する問題を修正しました。
      • 変更フィードを再開するときにsnapshot lost caused by GC時間内に報告されず、変更フィードのcheckpoint-tsが TiDB #10463 @ スドジの GC セーフポイントよりも小さい問題を修正しました。
      • 単一行データのデータ整合性検証が有効になっている場合、タイムゾーンの不一致により TiCDC がTIMESTAMP種類のチェックサムを検証できない問題を修正#10573 @ 3エースショーハンド
      • 同期ポイントテーブルが誤って複製される可能性がある問題を修正#10576 @ アズドンメン
      • Apache Pulsarをダウンストリームとして使用する場合にOAuth2.0、TLS、mTLSを適切に有効化できない問題を修正#10602 @ アズドンメン
      • TiKV がリーダー#10584 @ アズドンメンをアップグレード、再起動、または排除したときに、チェンジフィードがスタックする可能性がある問題を修正しました。
      • DDL 文が頻繁に実行されるシナリオで、間違った BarrierTS が原因でデータが間違った CSV ファイルに書き込まれる問題を修正#10668 @ リデズ
      • KVクライアントのデータ競合によりTiCDCがpanicを起こす問題を修正#10718 @ アズドンメン
      • テーブルレプリケーションタスク#10613 @ チャールズ・チュン96をスケジュールするときに TiCDC がパニックになる問題を修正
    • TiDB データ移行 (DM)

      • アップストリームの主キーがバイナリタイプ#10672 @ GMHDBJDの場合にデータが失われる問題を修正しました
    • TiDB Lightning

      • TiKV スペース#43636 @ ランス6716をチェックすることで発生するパフォーマンス低下の問題を修正しました。
      • ファイルスキャン中に無効なシンボリックリンクファイルに遭遇すると、 TiDB Lightning がエラーを報告する問題を修正#49423 @ ランス6716
      • sql_mode #50757 @ GMHDBJDNO_ZERO_IN_DATEが含まれていない場合、 TiDB Lightning が0含む日付値を正しく解析できない問題を修正しました。

寄稿者

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

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