

 Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。

# Amazon Redshift でプロビジョニングされたクラスターとサーバーレスワークグループのトラック
<a name="tracks"></a>

Amazon Redshift が新しいバージョンをリリースすると、Amazon Redshift データウェアハウス (サーバーレスワークグループまたはプロビジョニングされたクラスター) のバージョンが更新されます。この際、データウェアハウスを最新のリリースに更新するか、認定済みの前のリリースに更新するかを選択することができます。

サーバーレスワークグループまたはプロビジョニングされたクラスターのトラックは、バージョン更新中に適用されるリリースバージョンを決定します。Amazon Redshift は、プロビジョニングされたクラスターを指定されたメンテナンスウィンドウ中に更新し、通常はサーバーレスワークグループをアイドル期間中に更新します。Redshift Serverless がワークグループを更新するタイミングの詳細については、「[サーバーレスワークグループの更新](#tracks-serverless-updating)」を参照してください。

Amazon Redshift が新しいバージョンをリリースすると、そのバージョンは*最新*のトラックに割り当てられ、前のバージョンは*直近*のトラックに割り当てられます。データウェアハウスのトラックを設定するには、次のいずれかの値を指定します。
+ **最新** – **最新**のトラックでは、最新の機能、セキュリティアップデート、パフォーマンス強化を備えた最新の認定リリースバージョンを使用します。
+ **直近** – **直近**のトラックでは、前の認定リリースを使用します。

例えば、サーバーレスワークグループが現在バージョン 1.0.2762 を実行し、Amazon Redshift が Redshift Serverless バージョン 1.0.3072 をリリースしているとします。トラック値が**最新**の場合、ワークグループはバージョン 1.0.3072 (最新リリース) に更新されます。トラック値を**直近**に設定した場合、次の直近トラックバージョンがリリースされるときにワークグループが更新されます。

直近トラック機能を使用すると、Amazon Redshift データウェアハウスのサブセットを直近トラックで実行できます。これにより、最新トラックに設定されているデータウェアハウスで 1～6 週間のテストと統合の検証を行ってから、直近トラックのデータウェアハウスにリリースを適用できます。デフォルトでは、Amazon Redshift はすべてのクラスターとワークグループを最新トラックに作成し、最新の認定リリースを利用します。ただし、Amazon Redshift の直近トラックを本番環境で使用し、最新トラックをテストおよび開発環境で使用すると、追加の労力と時間をかけて最新リリースを評価できます。直近のトラックは最大の安定性を保証し、本番環境のミッションクリティカルなワークロードに最適です。

**注記**  
直近のトラックバージョンは、短期間、最新のトラックバージョンと同じである場合があります。これは、最新のトラックが次のバージョンに進まない場合に起きます。通常、最新のトラックバージョンは直近のトラックバージョンより新しいものになります。

## トラックの切り替え
<a name="tracks-switching"></a>

Amazon Redshift リソースのトラックの変更は、通常 1 回限りの決定です。トラックを変更するときは注意が必要です。どの機能がどのデータウェアハウスバージョンにあるかについては、「[Amazon Redshift のクラスターバージョン](cluster-versions.md)」を参照してください。

トラックを **[直近]** から **[最新]** に変更すると、データウェアハウスは **[最新]** のトラックリリースバージョンに更新されます。データウェアハウスのトラックを **[直近]** に変更すると、次のようにデータウェアハウスが更新されます。
+ サーバーレスワークグループの場合、データウェアハウスのバージョンはアイドル期間中に更新されます。Redshift Serverless がワークグループのバージョンを更新する方法の詳細については、「[サーバーレスワークグループの更新](#tracks-serverless-updating)」を参照してください。
+ プロビジョニングされたクラスターの場合、**最新**のトラックリリースバージョンよりも新しいバージョンがリリースされるまで、データウェアハウスは更新されません。

## トラックと復元
<a name="tracks-restore"></a>

サーバーレスワークグループの場合、スナップショットはターゲットの Amazon Redshift データウェアハウスのトラックを継承します。例えば、直近のトラックに設定されたワークグループのスナップショットを作成し、そのスナップショットを最新のトラックに設定されたワークグループに適用すると、ワークグループのトラック設定は最新になります。

プロビジョニングされたクラスターの場合、スナップショットはソースの Amazon Redshift データウェアハウスのトラックを継承します。スナップショットの作成後にソースデータウェアハウスのトラックを変更した場合、スナップショットとソースデータウェアハウスは別のトラックに設定されます。スナップショットから復元すると、新しいデータウェアハウスは、スナップショットソースから継承されたトラックに設定されます。トラックは、復元オペレーションが完了した後で変更できます。

 データウェアハウスのサイズを変更しても、そのトラックには影響しません。

## サーバーレスワークグループの更新
<a name="tracks-serverless-updating"></a>

ワークグループが選択したトラックで新しいバージョンが使用可能になると、Amazon Redshift Serverless は通常、保留中のトラック更新リクエストがない限り、アイドル期間中に更新を適用します。ワークグループで 14 日以内にアイドル期間が発生しない場合、Redshift Serverless はバージョンの更新を強制します。

Redshift Serverless は、ワークグループを次の上位バージョンにのみ更新します。Redshift Serverless は、選択したワークグループのトラックのバージョンがワークグループの現在のバージョンより小さい場合でも、中間のバージョンをスキップしたりワークグループをダウングレードしたりしません。`Trailing` トラックが追いつかないかぎり、ワークグループはメジャーバージョンアップグレードを受け取りません。

例えば、`Current` トラックがバージョン 186 で、`Trailing` トラックのバージョンが 185 であるとします。ワークグループの `Track` 値が `Current` で、バージョンが 186 である場合、`Track` 値を `Trailing` に変更しても、Redshift Serverless はワークグループのバージョンを 185 にダウングレードしません。このシナリオでは、Redshift Serverless は `Trailing` トラックのバージョンが 186 以上になるまで、ワークグループをバージョン 186 に保持します。

トラックの変更が保留中の場合、Redshift Serverless は、トラックの変更を適用するまで、ワークグループを既存のトラックの次のメジャーバージョンに更新しません。トラックの変更が完了すると、Redshift Serverless はワークグループを新しいトラックの適切なバージョンに更新するための条件を評価します。

例えば、ワークグループが `Current` トラックに設定されていて、現在のトラックが 186 であり、ワークグループを `Trailing` トラックに変更した場合、Redshift Serverless はトラックの変更を適用した後、`Trailing` バージョンが 186 以上のバージョンに更新されるまでワークグループを更新しません。

**注記**  
スナップショットからの復元、KMS キーの変更、サイズ変更など、ワークグループに対する既存の操作は、既存のトラックでのみ発生します。Redshift Serverless は、サーバーレスオペレーションに保留中のトラックを使用しません。

保留中のトラックの切り替えリクエストがある場合、[UpdateWorkgroup](https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_UpdateWorkgroup.html) を使用して `track` パラメータを元の値に戻すことで、リクエストをキャンセルできます。

## バージョンの管理
<a name="managing-cluster-versions"></a>

トラックは一連のリリースを指します。Amazon Redshift データウェアハウスで**最新**のトラックか**直近**のトラックを使用するかを設定できます。データウェアハウスで**最新**のトラックを使用する場合、常に最新のリリースバージョンにアップグレードされます。リソースで**直近**のトラックを使用する場合、最後にリリースされたバージョンの直前にリリースされたリリースバージョンが常に実行されます。

プロビジョニングされたクラスターの場合、Amazon Redshift データウェアハウス の Amazon Redshift コンソールリストの **[リリースステータス]** 列は、リソースの 1 つがアップグレードに使用できるかどうかを示します。

## ワークグループバージョンまたはクラスターのバージョンの確認
<a name="cluster-version"></a>

Amazon Redshift コンソールを使用して、Amazon Redshift Serverless ワークグループのバージョンまたはプロビジョニングされたクラスターのバージョンエンジンを確認できます。

AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/) で Amazon Redshift コンソールを開きます。

------
#### [ Serverless workgroups ]

 サーバーレスワークグループの場合、ナビゲーションメニューで、**[ワークグループ]** を選択し、リストからワークグループ名を選択して詳細を開きます。ワークグループの詳細が表示されます。

------
#### [ Provisioned clusters ]

 プロビジョニングされたクラスターの場合、ナビゲーションメニューで **[クラスター]** を選択し、リストからクラスター名を選択して詳細を開きます。

クラスターの詳細が表示されます。これには、**[クラスターのパフォーマンス]**、**[クエリのモニタリング]**、**[データベース]**、**[データ共有]**、**[スケジュール]**、**[メンテナンス]**、**[プロパティ]** タブなどがあります。**[Maintenance]** (メンテナンス) タブを選択し、詳細を確認します。

 [**Maintenance (メンテナンス)**] セクションで、[**Current cluster version (現行のクラスターバージョン)**] を見つけます。

**注記**  
プロビジョニングされたクラスターの場合、コンソールには 1 つのフィールドにバージョン情報が表示されますが、Amazon Redshift API には 2 つのパラメータが表示されます。これらは、`ClusterVersion` パラメータと `ClusterRevisionNumber` パラメータです。詳細については、*Amazon Redshift API リファレンス*の「[クラスター](https://docs.aws.amazon.com/redshift/latest/APIReference/API_Cluster.html)」を参照してください。

------