もくじ
原則
Multi-AZで運用
- Multi-AZはスレーブのほうからバックアップを取得するので停止しない。
単一のインスタンスでは、自動バックアップ時にストレージアクセスに数秒のI/Oロックがかかるから、ただしロック中もクエリは消失しないことは安心出来ます。 - 設定変更、メンテナンス時間での停止時間の最小化
Multi-AZならダウンタイムが1~2分になるので最小化出来る
// 単一インスタンスなら10数分かかる場合がある - インスタンスサイズの変更
Multi-AZなら無停止でスケールアップが出来る
// 実際にスケールサイズが切り替わるまでに30分程度必要
Multi-AZでないならRDSのメリットは少ない、RDSを選択しない。
性能はシングルの方が速い、同期でレプリケーションしているのでコミットが遅くなる
設定の切り替え時の動作
- コンソールで設定を変更
- スレーブに変更が行われ完了
- 接続がマスターからスレーブ(一時マスター)に切り替わる
1~2分程度のダウンタイムが発生! - マスター設定が行われ完了
- 接続がスレーブからマスターに切り替わる
1~2分程度のダウンタイムが発生!
Auroraファースト
Auroraの仕様を許容出来る場合はAuroraを選択
- RDSと比べて3~5倍高速
RDSで問題になるパフォーマンスの問題がAuroraなら解決する可能性が高い
コストやRDS仕様を許容することが難しい場合
コストをかけれない、仕様を許容が出来ないならEC2でDBを運用することを選択する
- EC2を1インスタンスでWEBとDBサービスの運用
- EC2を2台構成にしてWEBサーバとDBサーバに役割を分けて運用
自動バックアップについての注意
- RDSの自動バックアップ(スナップショット)は、RDS本体を削除時に自動バックアップも消える!!
- 手動バックアップを行うこと
RDSは別のVPCに移動が出来る
移動したいとなったら移動が出来る。