CloudFormationでRDSを更新する時の注意 - Qiita
背景 CloudFormationで管理しているMariaDBインスタンスのパブリックアクセスを変更したかったのですが スタックファイル(json)から更新すると以下のエラーでハマりました。 CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename (DBインスタンス名) and update the stack again. 公式ドキュメントを読んで見ると InstanceIdentifier 重要 名前を指定すると、このリソースの置換が必要な更新はできません。中断が不要であるか、一定の中断が必要な更新であれば、行うことができます。リソースを置き換える必要がある場合は、新しい名前を指定します。 CloudFormationで、DBInstanceのInstanc
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
【新機能】RDS for PostgreSQLでもリージョン間レプリケーションが可能に！ | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 本日PostgreSQL for RDSでリージョン間レプリケーション（cross-region read replica）が可能になりましたので検証してみたいと思います。 リージョン間レプリケーション 元々RDSでは幾つかのDBエンジンにおいて、同一ネットワーク内でMaster-Slaveの様なレプリケーション構成を取ることが可能です。さらに別の地域へレプリケーションも可能なDBエンジンがありました。 今まではPostgreSQLは同一ネットワーク内のみ可能でしたが、今回のアップデートでリージョンを越えるレプリケーションが可能になりました。 Aurora MySQL MariaDB PostgreSQL（New !） リージョン間レプリケーションが可能になる事でディザスタ・リカバリ用途や、アクセスのレイテンシ低下などが期待できます。
Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
Amazon RDSのフェールオーバーを試してみたが – OpenGroove
Amazon RDSでDBインスタンスを開始するとき、コンソール画面でMulti-AZを選択するだけでホットスタンバイのDB構成が生成される。物理レプリケーションを行っていて完全同期とのことだが、管理者からスタンバイ側の実体にはアクセスできない。（で合ってるよね？）またスタンバイ側を読み取り専用DBとして使うこともできないので、レプリケーションというよりクラスタの現用系／待機系の構成に近い印象。負荷分散ではなく可用性実現のための仕組みと考えるべし。 ちなみにRDSでフェールオーバーが発生する基準は、Amazonサイトによると以下の通り。 フェールオーバーが発生する基準 プライマリ利用可能ゾーンの可用性損失 プライマリに対するネットワーク接続の喪失 プライマリ上でのコンピュートユニット障害 プライマリへのストレージ不良 DB インスタンスのコンピュートクラスの規模を拡大または縮小する ソフト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
