Amazon Redshift の RG インスタンスでトラック変更を試してみた
はじめに
Amazon Redshift の RG インスタンスが Trailing Track で利用可能になりました。
RG インスタンスやメンテナンストラック（Current / Trailing）の概要については以下の記事を参照してください。
本記事では、RG インスタンスで Trailing Track のクラスターを作成し、Current Track への切替動作を検証しました。あわせて、逆方向（Current → Trailing）へ変更した場合の挙動も確認しています。
検証時点（2026年7月10日）のバージョン対応は以下の通りです。
| バージョン | パッチ | トラック | リリース日 |
|---|---|---|---|
| 1.0.331388 | Patch 201 | Trailing Track | 2026-06-16 |
| 1.0.343555 | Patch 202 | Current Track | 2026-06-29 |
| 1.0.347559 | Patch 203 | Current Track (最新) | 2026-07-06 |
参考: Amazon Redshift patch versions
検証内容
検証環境
- リージョン： us-east-1
- インスタンスタイプ： rg.xlarge × 2ノード
- 操作： AWS CLI のみ
Trailing Track でのクラスター作成
aws redshift create-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name trailing \
--master-user-password '********' \
--master-username admin \
--node-type rg.xlarge \
--number-of-nodes 2
約2.5分で available になりました。初期状態を確認します。
| 項目 | 値 |
|---|---|
| MaintenanceTrackName | trailing |
| ClusterRevisionNumber | 331388 (Patch 201) |
| NodeType | rg.xlarge |
| NumberOfNodes | 2 |
| Encrypted | true (AWS_OWNED_KMS_KEY) |
Trailing → Current Track への変更
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name current
実行直後、クラスターのステータスは available のままで、即時には反映されません。PendingModifiedValues にトラック変更が記録されます。
"PendingModifiedValues": {
"MaintenanceTrackName": "current"
}
トラック変更はメンテナンスウィンドウで適用されます。modify-cluster に --apply-immediately 相当のオプションはありません。今回はメンテナンスウィンドウを直近の時間帯（UTC）に変更したところ、そのウィンドウ開始時に適用がトリガーされました。
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--preferred-maintenance-window fri:14:33-fri:15:03
メンテナンスウィンドウの開始後、クラスターは modifying に変化し、約5分で available に復帰しました。
変更後の状態:
| 項目 | 変更前 | 変更後 |
|---|---|---|
| MaintenanceTrackName | trailing | current |
| ClusterRevisionNumber | 331388 (Patch 201) | 343555 (Patch 202) |
| PendingModifiedValues | {MaintenanceTrackName: "current"} |
{} |
Trailing → Current への変更により、クラスターバージョンが Patch 201 から Patch 202 にアップグレードされました。Patch 203 ではなく Patch 202 が適用されており、適用バージョンはタイミングやリージョンの展開状況に依存します。
Current → Trailing Track への変更試行
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name trailing
結果: API エラーにはならず、設定は受理されました。
"PendingModifiedValues": {
"MaintenanceTrackName": "trailing"
}
一見「戻せた」ように見えますが、メンテナンスウィンドウ適用後の結果は以下の通りです。
メンテナンスウィンドウ適用後の状態:
| 項目 | 値 |
|---|---|
| MaintenanceTrackName | current（変更されず） |
| ClusterRevisionNumber | 343555（変更されず） |
| PendingModifiedValues | {MaintenanceTrackName: "trailing"}（残ったまま） |
バージョンのダウングレードは発生しませんでした。 リクエストは受理されたものの、Patch 201 へのダウングレードは行われず、検証期間中は PendingModifiedValues も解消されないまま残りました。
公式ドキュメントの記載通り、Current Track リリースより後の新しい Trailing Track リリースが利用可能になるまで更新されない挙動です。
参考情報
以下は、Patch 198 以降の変更から、運用に影響し得る項目を抜粋したものです。
| 変更内容 | パッチ | 影響の可能性 |
|---|---|---|
| auto DISTKEY 割り当て対象の拡張 | 203 | Spectrum からの COPY、明示的列エンコーディング、空でないテーブルへの COPY でも主キーを持つテーブルが自動 DISTKEY 割り当ての対象になり得る |
| Python UDF のサポート終了 | 203 | パッチノートによると 2026年6月30日以降、Python UDF の EOL に関する変更が段階的に適用される予定。利用中の Python UDF がある場合は Lambda UDF や SQL UDF 等への移行要否の確認が必要 |
| MV auto-refresh の実行区分変更 | Patch 198 以降の Current Track | auto-refresh がバックグラウンド処理ではなくユーザークエリと同じ優先度で実行されるようになり、WLM キャパシティ設計に影響する可能性 |
| automatic vacuum の動作変更 | 203 | 非常に多くのテーブルを持つクラスターで automatic vacuum のバックグラウンド活動を削減し、過剰なメンテナンス活動が発生していたクラスターの安定性を改善 |
上記はいずれも公式パッチノートに基づく情報であり、個別の挙動は実測していません。詳細はパッチノートを参照してください。
まとめ
RG インスタンスが Trailing Track に対応したことで、Current Track での検証期間を確保しつつ、必要に応じて Current Track 側のリリースへ移行できるようになりました。リリース当初は Current Track のみの提供でしたが、今回の対応により、Trailing Track の利用を前提とする環境でも RG インスタンスを検討しやすくなりました。
