diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index 3bda1cafb8b68..a85db8d89591b 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -15,7 +15,7 @@ TiDB 7.5.0は長期サポートリリース(LTS)です。 以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。 -
| カテゴリ | 特徴 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | 複数のADD INDEXステートメントを並列実行することをサポートする | この機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント(XとY )を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。 |
| 信頼性と可用性 | グローバルソートの最適化(実験的、v7.4.0で導入) | TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。 |
| バックグラウンドタスクのリソース制御(実験的、v7.4.0で導入) | バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。 | |
| 暴走クエリを管理するためのリソース制御(実験的、v7.2.0で導入) | リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。 | |
| SQL | MySQL 8.0との互換性(バージョン7.4.0で導入) | MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。 |
| データベースの運用と可観測性 | TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されました | バージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク(DXF)もサポートしており、大規模なインポート時のインポート効率が向上します。 |
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します(GA)。 | 既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供(GA)されます。 | |
| DDLは一時停止および再開操作をサポートします(一般提供)。 | インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。 | |
| TiDB DashboardはTiKVのヒーププロファイリングをサポートしています | 従来、TiKVのメモリ不足(OOM)やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。 |
| カテゴリ | 特徴 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | 複数のADD INDEXステートメントを並列実行することをサポートする | この機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント(XとY )を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、列数の多いテーブル(ワイドテーブル)のシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。 |
| 信頼性と可用性 | グローバルソートの最適化(実験的、v7.4.0で導入) | TiDB v7.1.0 では、 分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。 |
| バックグラウンドタスクのリソース制御(実験的、v7.4.0で導入) | バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。 | |
| 暴走クエリを管理するためのリソース制御(実験的、v7.2.0で導入) | リソース制御は、リソースグループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソースグループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行計画ダイジェストで識別できます。v7.3.0 では、データベースレベルの SQL ブロックリストと同様に、既知の不正なクエリを事前に監視できるようになりました。 | |
| SQL | MySQL 8.0との互換性(バージョン7.4.0で導入) | MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。 |
| データベースの運用と可観測性 | TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されました | バージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク(DXF)もサポートしており、大規模なインポート時のインポート効率が向上します。 |
ADD INDEXおよびIMPORT INTO SQL文を実行するTiDBノードを指定します(GA)。 | 既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQL文を実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQL文の実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供(GA)されます。 | |
| DDLは一時停止および再開操作をサポートします(一般提供)。 | インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。 | |
| TiDB DashboardはTiKVのヒーププロファイリングをサポートしています | 従来、TiKVのメモリ不足(OOM)やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。 |
| カテゴリ | 機能/改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | クロスデータベースSQLバインディング | 同じスキーマを持つ数百ものデータベースを管理する場合、これらのデータベース間でSQLバインディングを適用する必要が生じることがよくあります。例えば、SaaSやPaaSのデータプラットフォームでは、通常、各ユーザーが同じスキーマを持つ個別のデータベースを操作し、それらに対して同様のSQLクエリを実行します。このような場合、各データベースごとにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等のすべてのデータベース間でバインディングを一致させることができる、データベース間SQLバインディングが導入されました。 |
| スナップショット復元速度を最大10倍向上(実験的) | BR v7.6.0では、クラスターのスナップショット復元を高速化するための、実験的粗粒度リージョン分散アルゴリズムが導入されました。TiKVノードが多数存在するクラスターでは、このアルゴリズムにより、ノード間で負荷がより均等に分散され、ノードごとのネットワーク帯域幅がより有効に活用されるため、クラスターのリソース効率が大幅に向上します。実際のいくつかの事例では、この改善により復元プロセスが最大約10倍高速化されています。 | |
| テーブル作成をバッチ処理で行う際の処理速度を最大10倍向上(実験的) | バージョン7.6.0で新しいDDLアーキテクチャが導入されたことで、バッチテーブル作成のパフォーマンスが最大10倍高速化され、目覚ましい改善が見られました。この大幅な機能強化により、多数のテーブルを作成するのに必要な時間が大幅に短縮されます。この高速化は、数十万から数十万ものテーブルが頻繁に発生するSaaS環境において特に顕著です。 | |
| アクティブなPDフォロワーを使用してPDのリージョン情報クエリサービスを強化する(実験的) | TiDB v7.6.0では、実験的機能"Active PD Follower"が導入されました。これにより、PDフォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PDリーダーのCPU負荷を軽減します。 | |
| 信頼性と可用性 | TiProxyのサポート(実験的) | TiProxyサービスを完全にサポートし、デプロイツールを介して簡単にデプロイできます。これにより、TiDBへの接続を管理および維持し、ローリング再起動、アップグレード、またはスケーリングイベント後も接続が維持されます。 |
| データ移行(DM)は、MySQL 8.0(GA)を正式にサポートします。 | これまで、DMを使用してMySQL 8.0からデータを移行する機能は実験的機能であり、本番環境では利用できませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に行えるようになりました。v7.6.0では、この機能が一般提供(GA)となります。 |
| カテゴリ | 機能/改善点 | 説明 |
|---|---|---|
| 拡張性とパフォーマンス | クロスデータベースSQLバインディング | 同じスキーマを持つ数百ものデータベースを管理する場合、これらのデータベース間でSQLバインディングを適用する必要が生じることがよくあります。例えば、SaaSやPaaSのデータプラットフォームでは、通常、各ユーザーが同じスキーマを持つ個別のデータベースを操作し、それらに対して同様のSQLクエリを実行します。このような場合、各データベースごとにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等のすべてのデータベース間でバインディングを一致させることができる、データベース間SQLバインディングが導入されました。 |
| スナップショット復元速度を最大10倍向上(実験的) | BR v7.6.0では、クラスターのスナップショット復元を高速化するための、実験的粗粒度リージョン分散アルゴリズムが導入されました。TiKVノードが多数存在するクラスターでは、このアルゴリズムにより、ノード間で負荷がより均等に分散され、ノードごとのネットワーク帯域幅がより有効に活用されるため、クラスターのリソース効率が大幅に向上します。実際のいくつかの事例では、この改善により復元プロセスが最大約10倍高速化されています。 | |
| テーブル作成をバッチ処理で行う際の処理速度を最大10倍向上(実験的) | バージョン7.6.0で新しいDDLアーキテクチャが導入されたことで、バッチテーブル作成のパフォーマンスが最大10倍高速化され、目覚ましい改善が見られました。この大幅な機能強化により、多数のテーブルを作成するのに必要な時間が大幅に短縮されます。この高速化は、数万から数十万ものテーブルが頻繁に発生するSaaS環境において特に顕著です。 | |
| Active PD Follower を使用してPDのリージョン情報クエリサービスを強化する(実験的) | TiDB v7.6.0では、実験的機能"Active PD Follower"が導入されました。これにより、PDフォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PDリーダーのCPU負荷を軽減します。 | |
| 信頼性と可用性 | TiProxyのサポート(実験的) | TiProxyサービスを完全にサポートし、デプロイツールを介して簡単にデプロイできます。これにより、TiDBへの接続を管理および維持し、ローリング再起動、アップグレード、またはスケーリングイベント後も接続が維持されます。 |
| データ移行(DM)は、MySQL 8.0(GA)を正式にサポートします。 | これまで、DMを使用してMySQL 8.0からデータを移行する機能は実験的機能であり、本番環境では利用できませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に行えるようになりました。v7.6.0では、この機能が一般提供(GA)となります。 |