53

RDS インスタンスのアップグレードに関していくつか質問があります。

  1. インスタンスを小規模から大規模にアップグレードするときのダウンタイムはどれくらいですか。インスタンスタイプ (小、大、特大) を変更したときのダウンタイムは比較的似ていますか、それともタイミングを変更するデータベースサイズなどの決定要因がありますか。
  2. RDS を使用してダウンタイムを回避してインスタンス タイプをアップグレードする方法を誰かが共有できますか? それはRDSでも可能ですか？崖っぷちや大局的なものだけを詳細に記述する必要はありません。
  3. より多くのディスク容量を割り当てた場合、ダウンタイムはありますか?
4

3 に答える 3

59

これはStackOverflowのトピックに関する質問ではないと思いますが、とにかくいくつかの情報があります。

  1. これは重要であり、データベースのサイズによって異なります。1時間以上かかることもあります。また、スナップショットの作成、スナップショットからの復元があり、マルチazの作成には約2時間かかります。

  2. これは、現在どのように構成されているかによって異なります。マルチAZがすでに有効になっている場合は、インスタンスのアップグレードが実際にスレーブで発生し、次にフェイルオーバーが発生してから、新しいスレーブが更新されます。これにより、実際のダウンタイムは約1〜2分になります。スレーブでのインスタンスのアップグレードには通常約10〜20分かかりますが、このセットアップではダウンタイムはありません。フェイルオーバーを実行する場合、Amazonは内部でDNSスワップを実行して、RDSエンドポイントが適切なマシンを指すようにします。そのため、DBを指すWebプロセスを再起動して、DBに再接続し、新しいDNSルックアップからの新しいIP。

于 2011-02-02T10:21:48.280 に答える
21

db.t1.micro > db.m1.small : 8m30s

Engine:    mysql
Storage:    6GiB
Backups:    Yes
Multi A-Z:  No

データベースのサイズ/タイプは、ダウンタイムに大きく影響するようです。

于 2013-09-09T02:50:37.240 に答える
11

1. 個人的な経験では、15 GB のインスタンスを小規模から大規模に移行する場合、正確には 57 分かかります。正直に言うと、こんなに長くなるとは思っていませんでした。更新: アップグレード前にポイント イン タイム バックアップを切り替えると、プロセスが大幅にスピードアップすることがわかりました

2、アップグレードを行う前に MULTI AZ を作成するとうまくいくと思いますが、ダウンタイムも発生しないことを願っています。質問は、他のものなしでアップグレードできるかどうかです...

3 はい、でも 100% 確信があるわけではありません

于 2011-02-01T23:40:02.687 に答える