必要に応じてAmazon RDSインスタンスを切り替えることができますか(アップグレードまたはダウングレードを意味しますか)、または新しいものを新しく作成して移行する必要がありますか?
はい、Amazon RDSインスタンスはmodify-db-instance
コマンド。データを移行する必要はありません。
Amazon RDSドキュメント から:
「必要なCPUの量がわからない場合は、db.m1.small DBインスタンスクラスから開始し、AmazonのCloudWatchサービスでCPU使用率を監視することをお勧めします。DBインスタンスがCPUバウンドの場合、より大きなDBに簡単にアップグレードできますrds-modify-db-instanceコマンドを使用したインスタンスクラス。
Amazon RDSは、次のメンテナンス時間中にアップグレードを実行します。メンテナンスウィンドウを待つのではなく、すぐにアップグレードを実行する場合は、-apply-immediatelyオプションを指定します。警告:DBインスタンスクラスを変更するには、DBインスタンスを短時間停止する必要があります。」
RE:停止時間:SQL Server 2012 RDSインスタンス(1TB非IOPSドライブ)があり、db.m1.xlargeからdb。 m3.xlarge(CPUを増やし、$$を減らした)ダウンタイムが4分を超えました。
注:AWSコンソールGUIからアップグレードを実行し、「Apply Immediately」を選択しましたが、停止が実際に始まるのは10分前でした。 RDSステータスは、更新を開始した直後に「変更中」を示し、待機時間と停止時間の間はこのままでした。
お役に立てれば!
グレッグ
予期しないトラフィックでヒットしたときに、中規模のRDSインスタンスから大規模なインスタンスにアップグレードしました(いいですね?)マルチAZインスタンスがあるため、2〜3分間停止しました。 Amazonのドキュメントでは、マルチAZインスタンスがある場合、ダウンタイムは短いと言われています。
興味のある方のために、RDSインスタンス(MySQL、15 GB HD、その他の標準パラメーター)を変更して、microからsmallに変更しました。ダウンタイム期間は5分でした。
RE:Outage Time:次の変更をすぐに要求して、postgresql 9.3をアップグレードしました。
完了までに約5時間この操作全体が必要でした。データベースには、アップグレードの時点で約100Gのデータが含まれています。 RDSコンソールのEventsセクションで、アップグレードの進行状況を監視できます。アップグレード中、RDSはいくつかのバックアップスナップショットを取得し、それらの進行状況はSnapsnotsセクションで監視できます。
SQL Server 2012を実行している200 GBの非IOPSデータを使用して、db.m3.largeからdb.m3.xlargeにアップグレードしたばかりです。ダウンタイムは約5分でした。
25Gのデータのdb.t2.smallからdb.t2.mediumへのMySQL RDSのアップグレードには6分かかりました。
大きなテーブル(約5,300万レコード)のAlterステートメントがあり、操作を完了できませんでした。
既存のサイズ使用量は48GBでした。 AWSで割り当てられたストレージを増やすことにしました-RDSインスタンスオペレーション全体が完了するのに2時間かかりました[〜#〜] mysql [〜#〜]db.r3.8xlarge 100Gから200Gまで
Alterステートメントは約40分かかりましたが、うまくいきました。
はい、アップグレード可能です。インスタンスサイズ約36 GB、クラスdb-m1-small、ストレージ200 GB、IOPSまたはマルチAZなしで、SQL Server 2008からSQL Server 2012にRDSインスタンスをアップグレードしました。ダウンタイムはありませんでした。このプロセスには10分しかかかりませんでした。
Multi-azでは、フェールオーバーがありますが、そうでない場合はスムーズになります。 3 TBのディスクを搭載したMulti-Az構成のPostgres 9.3での最新のdbインスタンスタイプのr3.4xlargeからr3.2xlargeへのダウングレードのタイムラインデータ(実際のデータは〜800Gのみ)
time (utc-8) event Mar 11 10:28 AM Finished applying modification to DB instance class Mar 11 10:09 AM Multi-AZ instance failover completed Mar 11 10:08 AM DB instance restarted Mar 11 10:08 AM Multi-AZ instance failover started