Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Core から Enterprise Edition へのアップグレード
既存の InfluxDB 3 Core クラスターを Enterprise Edition にアップグレードして、マルチノードデプロイ、長期データ保持、専用圧縮などの機能にアクセスできます。
**重要**
Core から Enterprise へのアップグレードは**、一方向のオペレーション**です。クラスターが Enterprise にアップグレードされると、それを Core エディションに戻すことはできません。
## 前提条件と要件
+ **初めてのエンタープライズアクティベーション**: AWS アカウントでエンタープライズライセンスを初めてアクティブ化する場合は、 を通じてアップグレードを実行する必要があります AWS マネジメントコンソール。この 1 回限りのコンソールアクティベーションにより、 アカウントのエンタープライズ機能が有効になります。
+ **以降のオペレーション**: コンソールの初回アクティベーション後、 アカウントは Enterprise に対して有効になります。その後、、API AWS CLI、または を使用して、追加の Core クラスターを Enterprise にアップグレードしたり、新しい Enterprise クラスターをデプロイしたりできます AWS マネジメントコンソール。
## を使用したアップグレード AWS マネジメントコンソール
1. にサインイン AWS マネジメントコンソール し、Timestream for InfluxDB コンソールを開きます。
1. ナビゲーションペインで、**[InfluxDB データベース]** を選択します。
1. アップグレードする Core クラスターを選択します。
1. **[Modify]** (変更) を選択します。
1. **Edition** で、**Enterprise** を選択します。
1. 変更を確認し、**クラスターの変更**を選択します。
## アップグレード中に何が起こるか
Core クラスターを Enterprise にアップグレードする場合:
1. **クラスターの再起動**: クラスターが再起動してエンタープライズエンジン設定を適用します。
1. **ノード設定**: クラスターノード数に応じて、クラスターは次のいずれかとして設定されます。
+ 単一ノードのエンタープライズクラスター (all-in-one: 1 つのノード上のライター、リーダー、コンパクタ)
+ 専用コンパクタを持つマルチノードエンタープライズクラスター (3 つ以上のノードを持つクラスターの場合)
1. **データ圧縮**: Enterprise 圧縮エンジンによって、既存のデータがバックグラウンドで徐々に圧縮されます。クラスターは、このプロセス中も引き続き使用できます。
**注記**
データ圧縮が追いつくために必要な時間は、現在のワークロードに関連する既存のデータの量、クラスターサイズ、インスタンスサイズ、使用可能な CPU とメモリのヘッドルームによって異なります。
**重要**
**アップグレード後の圧縮に関する容量の考慮事項**
**単一ノードクラスター**: Core 単一ノードクラスターを Enterprise にアップグレードすると、コンパクタはライターおよびリーダーと同じノードで実行されます。Core にはコンパクタが含まれていないため、アップグレード後に既存のデータをすべて圧縮する必要があります。これには、現在のワークロードが使用する以上の CPU およびメモリ容量が必要です。ノードに十分なヘッドルームがない場合、圧縮が読み取りおよび書き込みワークロードと競合し、パフォーマンスに影響する可能性があります。コンパクタに必要なリソースを提供するために、アップグレードの前または直後により大きなインスタンスタイプ ( から `db.influx.xlarge`など`db.influx.2xlarge`) にスケールアップすることを検討してください。圧縮が追いついたらスケールダウンできます。
**マルチノード (3 ノード) クラスター**: 3 ノードのエンタープライズクラスターにアップグレードすると、専用のコンパクタノードがプロビジョニングされます。ただし、圧縮されたデータからのクエリパフォーマンスの最適化など、Enterprise の利点は、コンパクタが既存のすべてのデータの処理を完了するまで実現されません。所要時間は、データベースに既に存在するデータの量、現在実行中のワークロード、コンパクタノードのインスタンスサイズと設定によって異なります。
**圧縮パフォーマンスのチューニング**: コンパクタが既存のデータをより迅速に処理できるように、パラメータグループで以下のエンタープライズ専用パラメータを調整できます。
+ `compaction-max-num-files-per-plan` – この値を増やして、コンパクタが圧縮サイクルごとにより多くのファイルを処理できるようにします。例えば、大きいインスタンス (db.influx.4xlarge 以上) では、 をデフォルト 500 から 1000～5000 に増やします。インスタンスサイズ別の推奨値[`compaction-max-num-files-per-plan`](compaction-max-num-files-per-plan.md)については、「」を参照してください。
+ `compaction-check-interval` – db.influx.4xlarge 以降では、デフォルトの 10 秒から 5 秒に減らして、コンパクタの評価をより頻繁に機能させます。
単一ノードクラスターの場合、すべてのロールが同じノードのリソースを共有するため、コンパクタにより多くの容量を与えるには、インスタンスタイプをスケールアップするのが最も効果的な方法です。マルチノードクラスターの場合、専用コンパクタノードは他のノードと同じインスタンスクラスを使用するため、クラスターのインスタンスタイプをスケーリングするとコンパクタ容量も増加します。圧縮パラメータの詳細については、「」を参照してください[カテゴリ 4: 圧縮](compaction-parameters.md)。
## 考慮事項
+ これは一方向のアップグレードです。Enterprise から Core にダウングレード**することはできません**。
+ 圧縮プロセスが十分な CPU とメモリのヘッドルームを追いつくことができるように、アクティビティが少ない期間にアップグレードを計画します。
+ **単一ノードクラスター**: アップグレードする前に、一時的により大きなインスタンスタイプにスケールアップして、コンパクタがワークロードに影響を与えずに既存のデータを圧縮するのに十分な CPU とメモリを確保することを検討してください。
+ **マルチノードクラスター**: コンパクタが既存のすべてのデータを処理しているアップグレード後の移行期間を想定します。完全なエンタープライズパフォーマンスのメリットは、圧縮が完了した後に実現されます。期間は、データ量、ワークロードの強度、インスタンスサイズによって異なります。
+ パラメータグループ`compaction-check-interval`で を増減することで`compaction-max-num-files-per-plan`、アップグレード後の圧縮を高速化できます。詳細については、「[カテゴリ 4: 圧縮](compaction-parameters.md)」を参照してください。
+ アップグレード後、 などのエンタープライズ機能を活用して、クラスター[クラスターのスケーリング](multi-node-scaling.md)を水平方向にスケーリングできます。