TiDB 8.5.5 リリースノート
発売日：2026年1月15日
TiDBバージョン：8.5.5
機能
パフォーマンス
特定の損失のある DDL 操作 (
BIGINT → INTやCHAR(120) → VARCHAR(60)など) に対して大幅なパフォーマンス改善を導入します。データ切り捨てが発生しない場合、これらの操作の実行時間は数時間から数分、数秒、あるいはミリ秒に短縮され、数万倍から数十万倍のパフォーマンス向上を実現します。 #63366 @wjhuang2016 、@tangenta、@fzzf678最適化戦略は以下のとおりです。
- 厳密なSQLモードでは、TiDBは型変換中に発生する可能性のあるデータ切り捨てのリスクを事前にチェックします。
- データ切り捨てのリスクが検出されない場合、TiDBはメタデータのみを更新し、可能な限りインデックスの再構築を回避します。
- インデックスの再構築が必要な場合、TiDBはより効率的な取り込みプロセスを使用することで、インデックス再構築のパフォーマンスを大幅に向上させます。
以下の表は、114 GiB のデータと 6 億行のデータを含むテーブルに対するベンチマーク テストに基づいたパフォーマンス改善の例を示しています。テスト クラスタは、3 つの TiDB ノード、6 つの TiKV ノード、および 1 つの PD ノードで構成されています。すべてのノードは、16 個の CPU コアと 32 GiB のメモリで構成されています。
なお、上記のテスト結果は、DDL実行中にデータ切り捨てが発生しないという条件に基づいています。これらの最適化は、符号付き整数型と符号なし整数型間の変換、文字セット間の変換、またはTiFlashレプリカを持つテーブルには適用されません。
詳細については、 ドキュメントを参照してください。
外部キーが多数存在するシナリオにおける DDL パフォーマンスを改善し、論理 DDL パフォーマンスを最大 25 倍向上させます #61126 @GMHDBJD
バージョン8.5.5より前のバージョンでは、超大規模テーブル（例えば、外部キーを持つ数十万のテーブルを含む、合計1,000万のテーブルを持つクラスタなど）を扱うシナリオにおいて、論理DDL操作（テーブルの作成や列の追加など）のパフォーマンスが約4QPSまで低下することがありました。これは、マルチテナントSaaS環境における運用効率の低下につながっていました。
TiDB v8.5.5 はこれらのシナリオを最適化します。テスト結果によると、1,000 万テーブル（外部キーを持つテーブル 20 万テーブルを含む）という極限環境においても、論理 DDL 処理性能は一貫して 100 QPS を維持します。これは以前のバージョンと比較して 25 倍向上しており、超大規模クラスタの運用応答性を大幅に向上させます。
クエリパフォーマンスを向上させるため、インデックス検索をTiKVにプッシュダウンするサポート #62575 @lcwangchao
TiDBはv8.5.5以降、
IndexLookUp演算子をTiKVノードにプッシュダウンするために、オプティマイザのヒントの使用をサポートしています。これにより、リモートプロシージャコール（RPC）の数が減り、クエリのパフォーマンスが向上する可能性があります。実際のパフォーマンス向上はワークロードによって異なるため、検証にはテストが必要です。特定のテーブルに対してインデックス検索を TiKV にプッシュダウンするようにオプティマイザに明示的に指示するには、
INDEX_LOOKUP_PUSHDOWN(t1_name, idx1_name [, idx2_name ...])ヒントを使用できます。このヒントは、テーブルの AFFINITY 属性と組み合わせて使用することをお勧めします。たとえば、通常のテーブルにはAFFINITY="table"を、パーティション化されたテーブルにはAFFINITY="partition"を設定します。特定のテーブルに対して TiKV へのインデックス検索プッシュダウンを無効にするには、
NO_INDEX_LOOKUP_PUSHDOWN(t1_name)ヒントを使用します。詳細については、 ドキュメントを参照してください。
テーブルレベルのデータアフィニティをサポートしてクエリのパフォーマンスを向上させる（実験的） #9764 @lhy1024
バージョン 8.5.5 以降では、テーブルの作成または変更時に
AFFINITYテーブル オプションをtableまたはpartitionとして構成できます。このオプションを有効にすると、PD は同じテーブルまたは同じパーティションに属するリージョンを単一のアフィニティ グループにグループ化します。スケジューリング中、PD はこれらのリージョンのリーダー レプリカと投票者レプリカを少数の TiKV ノードの同じサブセットに配置することを優先します。このシナリオでは、クエリでINDEX_LOOKUP_PUSHDOWNヒントを使用することで、オプティマイザにインデックス ルックアップを TiKV にプッシュダウンするように明示的に指示でき、ノード間分散クエリによって発生するレイテンシーを削減し、クエリ パフォーマンスを向上させることができます。この機能は現在実験的であり、デフォルトでは無効になっています。有効にするには、PD 設定項目
schedule.affinity-schedule-limitを0より大きい値に設定してください。この設定項目は、PD が同時に実行できるアフィニティ スケジューリング タスクの最大数を制御します。詳細については、 ドキュメントを参照してください。
ポイントインタイムリカバリ（PITR）は、圧縮ログバックアップからのリカバリをサポートし、リストアを高速化します #56522 @YuJuncen
バージョン8.5.5以降、ログバックアップ圧縮機能にオフライン圧縮機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善が実現します。
- リカバリ性能の向上：SSTファイルをより迅速にクラスターにインポートできるようになりました。
- ストレージ容量の削減：圧縮処理中に冗長データが削除されます。
- アプリケーションへの影響を軽減：スナップショットベースのフルバックアップの頻度を減らすことで、RPO（リカバリポイント目標）を維持できます。
詳細については、 ドキュメントを参照してください。
バックアップからのシステムテーブルのリカバリを高速化 #58757 @Leavrth
バージョン8.5.5以降、 BRはバックアップからシステムテーブルを復元する際に、論理復元ではなく物理復元を使用するための新しい
--fast-load-sys-tablesパラメータを導入しました。このパラメータを有効にすると、 BRは既存のシステムテーブルにデータを復元するのではなく、既存のテーブルを完全に置き換えるか上書きするため、大規模な展開における復元パフォーマンスが大幅に向上します。詳細については、 ドキュメントを参照してください。
信頼性
ネットワークジッター時のTiKVにおけるスケジューリングの安定性を向上させる #9359 @okJiang
バージョン8.5.5以降、TiKVはネットワークの遅延ノードを検出してフィードバックするメカニズムを導入しました。このメカニズムが有効になっている場合、TiKVはノード間のネットワークレイテンシーをプローブし、ネットワーク遅延スコアを計算して、そのスコアをPDに報告します。PDはこのスコアに基づいてTiKVノードのネットワーク状態を評価し、それに応じてスケジューリングを調整します。TiKVノードでネットワークジッターが発生していることが検出されると、PDはそのノードへの新しいリーダーのスケジューリングを制限します。ネットワークジッターが続く場合、PDは影響を受けているノードから既存のリーダーを他のTiKVノードに積極的に移動させ、ネットワークの問題がクラスタに与える影響を軽減します。
詳細については、 ドキュメントを参照してください。
可用性
PD のクライアント サーキット ブレーカー パターンを導入する #8678 @Tema
TiDBは、再試行の集中や同様のフィードバックループによるPDリーダーの過負荷を防ぐため、サーキットブレーカーパターンを実装しました。エラー率が事前に定義されたしきい値に達すると、サーキットブレーカーは受信トラフィックを制限し、システムが回復して安定するようにします。サーキットブレーカーの制御には、
tidb_cb_pd_metadata_error_rate_threshold_ratioシステム変数を使用できます。詳細については、 ドキュメントを参照してください。
SQL
分散ジョブ
ADD INDEXの同時実行性とスループットを動的に変更するサポート #64947 @joechenrhTiDB バージョン v8.5.5 より前のバージョンでは、分散実行フレームワーク (DXF)
tidb_enable_dist_task有効になっている場合、実行中のTHREADジョブのBATCH_SIZE、MAX_WRITE_SPEED、またはADD INDEXパラメータの変更はサポートされていません。これらのパラメータを変更するには、実行中のADD INDEXジョブをキャンセルし、パラメータを再構成してからジョブを再送信する必要がありますが、これは非効率的です。バージョン8.5.5以降では、
ADMIN ALTER DDL JOBSステートメントを使用して、実行中の分散ADD INDEXジョブのこれらのパラメータを、ジョブを中断することなく、現在のワークロードとパフォーマンス要件に基づいて動的に調整できます。詳細については、 ドキュメントを参照してください。
データベース操作
TiKV の正常なシャットダウンをサポート #17221 @hujiatao0
TiKVサーバーをシャットダウンする際、TiKVはシャットダウン前に、設定可能なタイムアウト時間内にノード上のLeaderレプリカを他のTiKVノードに転送しようとします。デフォルトのタイムアウト時間は20秒で、
server.graceful-shutdown-timeout設定項目を使用して調整できます。タイムアウトに達しても一部のリーダーが正常に転送されなかった場合、TiKVは残りのLeader転送をスキップしてシャットダウンを続行します。詳細については、 ドキュメントを参照してください。
進行中のログ バックアップとスナップショットの復元の間の互換性を向上 #58685 @BornChanger
バージョン8.5.5以降では、ログバックアップタスクの実行中でも、前提条件を満たしていればスナップショット復元を実行できます。これにより、復元処理中に進行中のログバックアップを停止することなく続行でき、復元されたデータは進行中のログバックアップに正しく記録されます。
詳細については、 ドキュメントを参照してください。
ログ バックアップからのテーブル レベルの復元をサポート #57613 @Tristan1900
バージョン8.5.5以降では、フィルタを使用してログバックアップから個々のテーブルのポイントインタイムリカバリ（PITR）を実行できます。クラスタ全体ではなく特定のテーブルを特定の時点に復元することで、より柔軟で影響の少ないリカバリオプションが提供されます。
詳細については、 ドキュメントを参照してください。
可観測性
ステートメントサマリーテーブルとスロークエリログにストレージエンジン識別子を追加する #61736 @henrybw
TiKVとTiFlashの両方がクラスタにデプロイされている場合、データベースの診断やパフォーマンス最適化の際に、ストレージエンジンごとにSQLステートメントをフィルタリングする必要が生じることがよくあります。たとえば、 TiFlashに高負荷がかかっている場合、潜在的な原因を特定するために、 TiFlash上で実行されているSQLステートメントを識別する必要があるかもしれません。このニーズに応えるため、TiDBはv8.5.5以降、ステートメントサマリーテーブルとスロークエリログにストレージエンジン識別子フィールドを追加しました。
ステートメントサマリーテーブル表の新しいフィールド:
STORAGE_KV:1は、SQL ステートメントが TiKV にアクセスすることを示します。STORAGE_MPP:1は、SQL ステートメントがTiFlashにアクセスすることを示します。
スロークエリログの新しいフィールド:
Storage_from_kv:trueは、SQL ステートメントが TiKV にアクセスすることを示します。Storage_from_mpp:trueは、SQL ステートメントがTiFlashにアクセスすることを示します。
この機能は、特定の診断およびパフォーマンス最適化シナリオにおけるワークフローを簡素化し、問題特定効率を向上させます。
詳細については、ステートメントサマリーテーブルおよびスロークエリを特定するを参照してください。
セキュリティ
Azure Blob Storage へのBackup & Restore (BR) で Azure Managed Identity (MI) 認証をサポートする #19006 @RidRisR
バージョン8.5.5以降、 BRはAzure Blob Storageへの認証にAzure Managed Identity（MI）をサポートし、静的SASトークンが不要になりました。これにより、Azureのセキュリティベストプラクティスに準拠した、安全でキーレスな一時的な認証が可能になります。
この機能により、 BRとTiKVに組み込まれたBRワーカーは、Azureインスタンスメタデータサービス（IMDS）から直接アクセストークンを取得できるため、認証情報の漏洩リスクが軽減され、Azure上のSelf-Managedおよびクラウドデプロイメントの両方で認証情報のローテーション管理が簡素化されます。
この機能は、Azure Kubernetes Service (AKS) またはその他の Azure 環境で実行されている TiDB クラスターに適用されます。特に、バックアップおよび復元操作に対して厳格なセキュリティ制御が求められるエンタープライズ環境において有効です。
詳細については、 ドキュメントを参照してください。
互換性の変更
TiDBクラスタがv8.5.4で新規にデプロイされている場合（つまり、v8.5.3より前のバージョンからアップグレードされていない場合）、v8.5.5へスムーズにアップグレードできます。v8.5.5の変更点のほとんどは通常のアップグレードでは問題ありませんが、このリリースには動作の変更、MySQLとの互換性調整、システム変数の更新、構成パラメータの更新、システムテーブルの変更も含まれています。アップグレードする前に、このセクションをよくお読みください。
動作の変更
- バージョン8.5.5以降、TiDBはデータ復元時に対象テーブルを自動的に
restoreモードに設定します。restoreモードのテーブルでは、ユーザーによる読み取りまたは書き込み操作が禁止されます。復元が完了すると、TiDBはこれらのテーブルのモードを自動的にnormalに戻し、ユーザーが通常どおりテーブルを読み書きできるようにします。この動作により、復元プロセス中のタスクの安定性とデータの一貫性が確保されます。 - バージョン8.5.5以降、
--load-statsパラメータがfalseに設定されている場合、 BRは復元されたテーブルの統計情報をmysql.stats_metaテーブルに書き込まなくなりました。関連する統計情報を更新するには、復元後にANALYZE TABLE手動で実行してください。
MySQLとの互換性
- TiDB は v8.5.5 以降、テーブルまたはパーティションのデータアフィニティを制御するための新しい
AFFINITYプロパティをテーブルに導入しました。このプロパティはCREATE TABLEまたはALTER TABLEステートメントを使用して構成できます。詳細については、 ドキュメントを参照してください。 - バージョン8.5.5以降、TiDBではテーブルのアフィニティ情報を表示するための新しい
SHOW AFFINITYステートメントが導入されました。このステートメントはMySQL構文のTiDB拡張です。詳細については、 ドキュメントを参照してください。
システム変数
コンフィグレーションパラメータ
システムテーブル
- システムテーブル
INFORMATION_SCHEMA.TABLESおよびINFORMATION_SCHEMA.PARTITIONSに、データ親和性レベルを表示するための新しい列TIDB_AFFINITYが追加されます。
その他の変更点
TiDBのパフォーマンスを向上させるため、TiDBのGoコンパイラバージョンをgo1.23.6からgo1.25.5にアップグレードしてください。TiDB開発者の方は、スムーズなコンパイルを保証するために、Goコンパイラバージョンをアップグレードすることをお勧めします。
BR v8.5.5を使用して以前のTiDBバージョン（v8.5.4やv8.1.2など）でPITRリカバリを実行すると、ログリカバリ段階で失敗し、エラーが返される場合があります。
この問題により、データの完全バックアップと復元は影響を受けません。
ターゲットとなるTiDBクラスタのバージョンと一致するBRバージョンを使用することをお勧めします。たとえば、TiDB v8.5.4クラスタでPITRを実行する場合は、 BR v8.5.4を使用してください。
改善点
TiDB
IMPORT INTOのエンコードエラー発生時のエラーメッセージを改善し、ユーザーが問題をより正確に特定できるようにしました #63763 @D3Hunter- Parquetファイルの解析メカニズムを強化し、Parquet形式のデータのインポートパフォーマンスを向上させる #62906 @joechenrh
tidb_analyze_column_optionsのデフォルト値をALLに変更して、デフォルトですべての列の統計情報を収集します #64992 @0xPoeIndexHashJoin演算子の実行ロジックを最適化し、特定のJOINシナリオでインクリメンタル処理を使用することで、一度に大量のデータをロードすることを避け、メモリ使用量を大幅に削減し、パフォーマンスを向上させます。 #63303 @ChangRui-Ryan- 分散実行フレームワーク（DXF）における内部SQLステートメントのCPU使用率を最適化する #59344 @D3Hunter
expression.Contains関数のパフォーマンスを改善 #61373 @hawkingrei
TiKV
- ホットリードワークロード時のCPU飢餓を回避するために、統合リードプールにCPU認識スケーリングを導入する #18464 @mittalrishabh
- ネットワークレイテンシーを考慮したスコアを追加し、不安定なネットワーク状態のTiKVノードにリーダーをスケジュールしないようにする #18797 @okJiang
- リーダーが過半数の票を獲得した後、オフラインの非投票ピアを待たずにすぐに休止状態に入ることができるようにすることで、休止状態のリージョンの動作を最適化します #19070 @jiadebin
- TiKV OOM #18124 @3pointerを防ぐために、TiKVメモリ使用量が高いときにBRログ復元リクエストをスロットルします
PD
- PDメモリ使用量を削減し、監視システムへの負荷を軽減するために、カーディナリティの高いメトリクスを最適化します #9357 @rleungx
- タイムスタンプの前進とリーダー選出のロジックを最適化 #9981 @bufferflies
- ストレージエンジン (TiKV またはTiFlash) による TiKV ストア制限のバッチ構成をサポート #9970 @bufferflies
storeメトリックにpd_cluster_statusラベルを追加します #9855 @SerjKol80
ツール
バグ修正
TiDB
- TiDBが起動時に初期化バインディングを実行するために
tidb_mem_quota_binding_cache変数の最新値を読み取れない問題を修正しました #65381 @qw4990 extractBestCNFItemRangesで候補アイテムが誤ってスキップされ、クエリ範囲の計算が不正確になる問題を修正しました #62547 @hawkingreiplan replayerがバインディングをロードできない問題を修正 #64811 @hawkingreiPointGetメモリが十分な場合でもチャンクを再利用できず、不要なメモリ割り当てが発生する問題を修正しました #63920 @hawkingreiLogicalProjection.DeriveStatsがメモリを過剰に割り当てる問題を修正 #63810 @hawkingreiplan replayerがクエリのパニック時にダンプに失敗する問題を修正 #64835 @hawkingrei- TTLテーブルの
SHOW CREATE TABLE出力における属性の順序が特定のシナリオで誤って表示される問題を修正しました #64876 @YangKeao - TTLジョブの実行サマリー情報が、ジョブのタイムアウト時に空になる問題を修正 #61509 @YangKeao
- プランキャッシュが有効になっている場合に、相関サブクエリが予期しないフルテーブルスキャンを引き起こす可能性がある問題を修正 #64645 @winoros
- システムテーブルがテーブルヘルスモニタリング結果の誤りを引き起こす問題を修正#57176 、 #64080 @0xPoe
- 自動統計更新を無効にした後、
mysql.tidb_ddl_notifierテーブルをクリーンアップできない問題を修正します (tidb_enable_auto_analyze = OFF) #64038 @0xPoe newLocalColumnPoolで列が繰り返し割り当てられる問題を修正 #63809 @hawkingreisyncloadの失敗に関する無効な警告ログが生成される問題を修正 #63880 @0xPoe- トランザクションを実行中の接続を手動で終了すると、TiDBがpanicて異常終了する可能性がある問題を修正しました #63956 @wshwsh12
- TiFlashレプリカからキャッシュされたテーブルを読み取る際に、ゴルーチンとメモリリークが発生する可能性がある問題を修正しました #63329 @xzhangxian1008
ALTER TABLE child CHANGE COLUMNを実行して列を変更した後、外部キーが更新されない問題を修正しました #59705 @fzzf678- 以前の TiDB バージョンから
RENAME TABLEジョブ引数が正しくデコードされない問題を修正しました #64413 @joechenrh - BR復元が失敗した場合にAUTO_INCREMENT IDがリベースされない問題を修正 #60804 @joechenrh
- アップグレード中に TiDB ノードがスタックする可能性がある問題を修正 #64539 @joechenrh
- インデックスレコードが欠落している場合に管理者チェックでエラーが報告されない問題を修正 #63698 @wjhuang2016
MODIFY COLUMNを介して照合順序を変更するとデータインデックスの不整合が発生する問題を修正 #61668 @tangenta- DDL に埋め込まれた
ANALYZE機能が、複数のスキーマ変更を実行する際にトリガーされない可能性がある問題を修正します #65040 @joechenrh - 分散実行フレームワーク（DXF）タスクが
ADD INDEXジョブのキャンセル後にキャンセルされない問題を修正 #64129 @tangenta - 外部キーを含むテーブルのテーブル情報を読み込むかどうかを判断する際の検証ロジックが間違っている問題を修正しました #60044 @JQWong7
- テーブル情報をコピーする際に、外部キー関連フィールドの初期化が正しく行われない問題を修正しました #60044 @JQWong7
- 異なるデータベース間でテーブル名を変更した後に自動IDが正しく設定されない問題を修正 #64561 @joechenrh
- メタキーの処理ミスによりCPU使用率が高くなる問題を修正 #64323 @wjhuang2016
- スキーマファイルに末尾のセミコロンがない場合にTiDB Lightning がエラーを報告しない問題を修正 #63414 @GMHDBJD
- グローバルソートを有効にして
IMPORT INTOを実行すると、ファイルの読み込み中に無限ループが発生する問題を修正しました #61177 @CbcWestwolf IMPORT INTOの処理中に生成された列を処理する際にpanicが発生する問題を修正しました #64657 @D3Hunter- 単一の SQL ステートメントに複数の
AS OF TIMESTAMPが含まれている場合にエラーが誤って報告される可能性がある問題を修正しました #65090 @you06 information_schema.tablesをクエリする際に発生する可能性のある OOM 問題を修正するため、システム テーブルをクエリする際のメモリ使用量の監視を改善しました #58985 @tangentaclient-goの潜在的なメモリリークを修正 #65522 @bufferflies
- TiDBが起動時に初期化バインディングを実行するために
TiKV
- 分析リクエストの
KV Cursor Operationsメトリックが常に0になる問題を修正 #19206 @glorv - リーダー変更後にリージョンハートビートがリージョンサイズやキー統計情報をPDに誤って報告する可能性がある問題を修正 #19180 @glorv
- 安全でないリカバリが停止する問題を修正するため、安全でないリカバリ降格リストからTombstone TiFlashラーナーを削除します #18458 @v01dstar
- 連続書き込み中にスナップショットが繰り返しキャンセルされ、レプリカのリカバリがブロックされる問題を修正 #18872 @exit-code-1
- 流量制御しきい値の増加により圧縮速度が低下する問題を修正 #18708 @hhwyt
- 特殊なケースでRaftピアが予定より早く休止状態に入り、TiKV の再起動後にビジー状態が続き、リーダー転送がブロックされる問題を修正しました #19203 @LykxSassinator
- 分析リクエストの
PD
- ノードをオンラインにするプロセス中にノードが取り外せない可能性がある問題を修正します #8997 @lhy1024
- Leaderの転送が多数発生するとリージョンサイズが急激に変化する可能性がある問題を修正しました #10014 @lhy1024
- スケジューリング中に PD panicを引き起こす可能性がある問題を修正 #9951 @bufferflies
- インポート処理中にデータが不均衡になる可能性がある問題を修正 #9088 @GMHDBJD
- Active PD Follower機能を有効にした後、 Followerノードで失敗したリクエストが、再試行のためにLeaderノードに正しくフォールバックできない問題を修正しました。 #64933 @okJiang
- PDマイクロサービスモードで一部のリクエストが正しく転送されない問題を修正 #9825 @lhy1024
tsoおよびschedulingマイクロサービスにおける TLS 構成の読み込みエラーにより接続が失敗する可能性がある問題を修正しました。 #9367 @rleungx
TiFlash
- BRがデータを復元しているときにTiFlash がpanicになる問題を修正 #10606 @CalvinNeo
- BRがデータを復元するときにTiFlash が16 を超える CPU コアを完全に利用できない問題を修正 #10605 @JaySon-Huang
GROUP_CONCATがディスク流出をトリガーしたときにTiFlash が予期せず終了する可能性がある問題を修正 #10553 @ChangRui-Ryan
ツール
Backup & Restore (BR)
- クラスターに多数のリージョンが含まれている場合にログバックアップを有効にするとメモリ使用量が過剰になる問題を修正 #18719 @YuJuncen
- Azure SDK が環境から適切なキーを見つけられない問題を修正 #18206 @YuJuncen
restore pointの期間中に外部キーが正しく復元されない問題を修正します。 #61642 @Leavrth- バックアップとターゲットクラスタ間でシステムテーブルの照合順序に互換性がない場合にリストアが失敗する問題を修正するため、v6.5 から v7.5 への特権テーブルのリストアをサポートする
--sys-check-collationパラメータを追加しました。 #64667 @Leavrth restore logが失敗した後にrestore pointを実行できない問題を修正します（操作が安全な場合でも）。 #64908 @RidRisR- チェックポイントの
restore pointが、ログバックアップデータがフルバックアップと混在している場合にpanic可能性がある問題を修正 #58685 @YuJuncen
TiCDC
- ライターのクローズエラーが正しくキャプチャされないため、オブジェクトストレージへのレプリケーション中にデータが失われる可能性がある問題を修正します #12436 @wk989898
- パーティションテーブルで
TRUNCATE操作を複製すると、変更フィードが失敗する可能性がある問題を修正します #12430 @wk989898 - 複数テーブルの
RENAMEDDL ステートメントを複製する際に、下流の実行順序が正しくない可能性がある問題を修正します #12449 @wlwilliamx aws-sdk-go-v2依存関係のバージョンをアップグレードすることで、Glue Schema Registryの使用時に発生する可能性のある接続エラーを修正します #12424 @wk989898- TiKV CDCコンポーネントが再起動後にメモリ割り当てを正しく解放しないためにchangefeedタスクが停止する可能性がある問題を修正しました #18169 @asddongmen
- TiKV CDCでインクリメンタルスキャンタスクが蓄積された際に、gRPC接続がアイドル状態と誤判断されて予期せず閉じられる可能性がある問題を修正しました。 #18915 @asddongmen