eコマースのプロモーションやオンラインイベントなど、ビジネスで予測可能な短期的なトラフィックの急増が見込まれる場合、コンピューティングリソースの不足により、データベースでパフォーマンスのボトルネックが発生する可能性があります。永続的なアップグレードを行うと、トラフィックが減少した後にリソースの浪費につながる可能性があります。PolarDB の一時的なアップグレード機能を使用すると、指定された期間、サブスクリプションクラスターのコンピューティング仕様 (CPU とメモリ) を増やすことができます。クラスターはスケジュールされた時刻に自動的に元の仕様に戻るため、短期的なピークワークロードにコスト効率よく対応できます。
影響評価
一時的なアップグレードを実行する前に、サービスへの潜在的な影響を評価し、変更計画を作成します。
サービスへの影響
PolarDB クラスターの仕様を変更すると、ノードの再起動がトリガーされ、一時的な接続の中断や短時間のパフォーマンスの変動が発生する可能性があります。その影響は、お使いのクラスターが シームレスな切り替え機能をサポートしているかどうかと、バイナリロギング (binlog) が有効になっているかどうかによって異なります。
-
クラスターが シームレスな切り替え をサポートしていない場合、仕様変更中に約 20～30 秒の瞬断が発生する可能性があります。切り替えの前に、アプリケーションに接続再試行メカニズムがあることを確認してください。
-
クラスターが シームレスな切り替え をサポートしている場合、影響は binlog のステータスによって異なります。binlog が有効な場合、約 5～10 秒の瞬断が発生する可能性があります。binlog が無効な場合、パフォーマンスは 1～3 秒間ゼロに低下する可能性がありますが、接続とトランザクションは中断されません。
-
タスクの所要時間：変更タスクには、ノードあたり約 5 分かかります。たとえば、2 つのノードを変更するには約 10 分かかります。正確な所要時間は、クラスターの負荷、データベースとテーブルの数などの要因によって異なります。
-
レプリケーション遅延：変更中、読み取り専用ノードのデータレプリケーション遅延は、通常運用時よりも長くなる可能性があります。
-
データの安全性：設定変更はノードリソースを調整するだけで、クラスター内の既存データには影響しません。
-
再起動の順序：プライマリノードと読み取り専用ノードの両方の仕様を同時に変更する場合、システムはまず読み取り専用ノードを再起動し、次にプライマリノードを再起動します。このプロセス中にプライマリ/スタンバイの切り替えは発生しません。
ノード仕様の制限
クラスターの安定性と高可用性を確保するため、プライマリノードと読み取り専用ノードの仕様を設定する際には、以下の制限が適用されます。
-
少なくとも 1 つの読み取り専用ノードは、プライマリノードと同じ仕様である必要があります。
-
ホットスタンバイ が有効になっている読み取り専用ノードは、プライマリノードと同じ仕様である必要があります。
-
読み取り専用ノードのメモリは、プライマリノードのメモリの半分未満にすることはできません。
-
読み取り専用ノードの CPU コア数は、次の表に示す最小要件を満たす必要があります。
プライマリノードの CPU
読み取り専用ノードの最小 CPU
2
2
4
4
8
4
16
8
32
16
64
32
88
64
120
64
マルチマスタークラスター (Limitless) Edition は、上記の制限の対象外です。
その他の制限事項
-
一時的なアップグレード中に、追加のアップグレードを最大 1 回実行できます。
-
一時的なアップグレード中は、手動での設定変更、ノードの追加または削除、ノードの一時的な追加、自動スケーリング、またはクラスターのサブスクリプション解約などの操作は実行できません。
前提条件
開始する前に、以下の点を確認してください。
-
課金方法：対象クラスターは [サブスクリプション] クラスターである必要があります。
-
クラスターのステータス：対象クラスターは [実行中] である必要があり、ノードの追加や削除、マイナーバージョンのアップグレードなどの他の設定タスクが進行中でない必要があります。
-
保留中のタスク：ノードの追加や削除、設定変更などの他の設定変更タスクが 保留中 でないこと。
-
サービスリンクロールの権限付与: アカウントに PolarDB サービスリンクロール AliyunServiceRoleForPolarDB が作成されている必要があります。
手順
-
PolarDB コンソールにログインします。左側メニューで クラスター をクリックし、クラスターがある [リージョン] を選択します。
-
次のいずれかの方法で、設定の変更 (サブスクリプション) ページに移動します。
-
対象のクラスターを見つけ、操作 列の 設定の変更 をクリックします。
-
クラスター ID をクリックして 概要 ページに移動します。データベースノード セクションで、設定の変更 をクリックします。このページには、プライマリノードと読み取り専用ノードの仕様とステータスが表示され、[ノードの追加/削除] と [設定変更] へのリンクが表示されます。
-
-
設定の変更 (サブスクリプション) ダイアログボックスで、一時スペックアップ を選択し、OK をクリックします。
-
[一時的なアップグレード] ページで、現在の設定 と 有効期限 を確認し、次のパラメーターを設定します。
パラメーター
説明
[仕様]
アップグレード先のエディションを選択します。オプションには、汎用 と 専用 があります。
[Node]
アップグレードするノード (プライマリまたは読み取り専用) のアップグレード先の仕様を選択します。
説明少なくとも 1 つの読み取り専用ノードがプライマリノードと同じ仕様であることを確認する必要があります。他のノードの仕様は必要に応じて設定できます。
[ポイントの復元]
システムがクラスターをアップグレード前の仕様に自動的に復元する特定の時刻を設定します。
説明-
最小期間は 1 時間、最大期間は 14 日間です。14 日間を超えるアップグレードの場合は、手動での設定変更 を使用することを推奨します。
-
復元時刻は、クラスターの有効期限の少なくとも 1 日前である必要があります。たとえば、クラスターの有効期限が 1 月 10 日の場合、一時的なアップグレードの最新の復元時刻は 1 月 9 日です。
-
復元時刻は設定後に変更できません。パフォーマンスが不十分で期間を延長する必要がある場合は、復元時刻に達する前にもう一度アップグレードを実行できます。新しい[ポイントの復元]は、元の復元ポイントより少なくとも1時間遅い時刻に設定する必要があります。
-
-
利用規約を読み、今すぐ購入 をクリックして支払いを完了します。支払いが完了すると、アップグレードタスクが開始されます。
課金
一時的なアップグレードの料金は、新しい仕様と元の仕様の価格差に 1.5 のプレミアム係数を乗じて計算されます。計算式は次のとおりです。
ノードを N 日間一時的にアップグレードするための料金 = (新しい仕様の月額料金 - 元の仕様の月額料金) / 30 × 1.5 × N。
関連操作
永続的なアップグレードへの変換
アップグレードされた仕様を永続的に維持する必要がある場合、または ノードの追加または削除、ノードの一時的な追加、自動スケーリング、クラスターのサブスクリプション解約などの操作を実行する必要がある場合は、一時的なアップグレードを永続的なアップグレードに変換できます。変換後、クラスターは復元時刻に自動的にダウングレードされません。
-
手動変換：一時的なアップグレード期間中に、再度 [設定変更 (サブスクリプション)] ページに移動し、現在の仕様に対して 手動での設定変更 を実行します。
説明この操作は永続的な課金注文を生成するだけで、2 回目のサービス中断は発生しません。
-
ストレージ容量のスケールアップによる変換：一時的なアップグレード期間中にクラスターのストレージ容量を手動でスケールアップすると、システムは一時的なコンピューティング仕様を永続的な仕様に自動的に変換します。これは、ストレージを拡張した時点から新しいサブスクリプション料金で課金されることを意味します。ストレージをスケールアップする前に、この変更を慎重に評価してください。
アップグレード有効期限の表示
ページに移動後、クラスター ID で検索して注文タイプが 一時アップグレード の注文を見つけ、詳細を表示 をクリックして情報を表示します。
関連 API
|
API |
説明 |
|
PolarDB クラスターの仕様を一時的にアップグレードします。 |