AmazonAurora カスタムエンドポイントのフェールオーバー時の挙動についての検証 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 昨年11月にリリースされたAmazon Auroraのカスタムエンドポイントを運用していて、先日ある検証環境でフェールオーバーが起きた際に考慮していなかった事態が起きたので、仕様を確認するがてらカスタムエンドポイントのタイプ別にフェールオーバー時の挙動をまとめてみました。 カスタムエンドポイントについては下記をご参照ください。 自由にAuroraインスタンスを組み合わせて、用途別にAuroraのエンドポイントを管理出来る機能で、これまで泣く泣く続けていたmysqlのbinlogレプリ運用から解放されるようなうれしさがあります。 docs.aws.amazon.com 起きた事象 Auroraクラスタにフェールオーバーが発生した際に、当然リードレプリカがマスター昇格します。その際に、カスタムエンドポイントのノードが0になりカスタム
AWSでAZ障害が起きたのでなるべく影響を受けない構成の考えを書いておく - なんかかきたい
AZ障害は受け入れるしかないクラウド時代のインフラ ただの日記。 今日の昼、AWSを利用している人たちは大変だったところもあると思う。 AZの一つが丸々機能しなくなる大きなAWSの障害があり、AWSを利用して運用されていたサービスは多かれ少なかれ影響を受けることになった。 完全に雰囲気で書いてしまうが、今回のAZ障害で影響を受けたサービスは思ったより多かったように感じる。 というのもAWSではアベイラビリティーゾーンの障害は発生するものと考え、本番運用するのであれば、マルチAZ構成を取るのがベストプラクティスとされているので、 マルチAZ構成を取っていれば影響なんてないんじゃないの普通、と思ってしまうと思う。 インフラ屋さんでもそう思ってしまうし、インフラ屋さん以外ならなおさらなんで重くなるのかわからないと思う。 幸い自分の運用しているサービスでは影響が軽微だったので、完全に想像にはなって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
うっかりReduxのReducerまでコード分割しようとするとどうなるか – Eureka Engineering – Medium
