SameSite Updates
Confused? Start here. Developers: Check out our testing and debugging tips. Adding `SameSite=None; Secure` to your cookies? Check the list of incompatible clients here. Check the list of Frequently Asked Questions (FAQ) for common scenarios and use cases. Launch Timeline Last updated Mar 18, 2021. Latest update: Mar 18, 2021: The flags #same-site-by-default-cookies and #cookies-without-same-site-m
本番環境でダウンタイムを最小限にするためRDSをMulti-AZ構成にした後スケールアップを行う - Qiita
こんにちわ！OCEAN'Sの大庭です。 今回は、本番環境でRDSのスケールアップを行いましたのでその手順とログを紹介していきます 概要 まず、RDSがSingle-AZ構成のままスケールアップを行うと、 インスタンス停止 インスタンスタイプの変更（スケールアップ） インスタンス起動 となってしまい、DBサイズにもよるがサービスダウンタイムが10分弱はかかってしまいます。 そのため、今回は以下の方法でスケールアップを行います RDSをMulti-AZ構成に変更 RDSのスケールアップ プライマリにフェイルバック RDSをMulti−AZに変更 まず、RDSをMulti−AZ構成に変更する。 Multi-AZ構成への変更はダウンタイムが発生しませんが、 シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への最初の変換時にパフォーマンスに大きな影響が出るこ
RDSフェイルオーバーによるダウンタイムの実測（PostgreSQL編） | 技術畑 | 情報畑でつかまえて
RDSフェイルオーバーによるダウンタイムの実測（PostgreSQL編） オンプレミスなシステムをAWSに移行する際など、DBサーバにはRDSを使うかという点がよく議論になります。RDSは非常に便利ですが、導入の検討段階で「定期メンテナンスやフェイルオーバーでダウンタイムが発生するからNGになった」という話をよく聞きます。 ダウンタイムはどの程度か、という話はAWSの公式サイトにも記述があり、「通常」60～120秒とされています。可用性担保を使命とするエンジニアとしては、この「通常」という言葉がとても気になりますよね。 ということで、今回はRDSのフェイルオーバーによるダウンタイムを実測してみました。
マルチAZ構成のRDS(MySQL)を強制フェイルバックさせてみた | DevelopersIO
はじめに AWSチームのすずきです。 マルチAZ構成で作成されたRDS(MySQL)は、メンテナンスウィンドウによるインスタンスタイプやストレージ容量の変更後、 マスタDBの稼働するアベイラビリティーゾーン(AZ)がフェイルオーバーにより変化する事があります。 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた EC2とRDS間の通信がクロスAZとなる事で、レイテンシの増加やAZ間のネットワーク転送費(0.01$/GB)が問題となる環境で、 手動フェイルオーバーを実施する機会がありましたので紹介させて頂きます。 構成図 EC2、RDS間の通信がクロスAZとなった環境(右)、フェイルバックにより復旧させました。 操作 再起動 手動(強制)フェイルオーバは、RDSの再起動で実施します。 「フェイルオーバし再起動」をチェックし、再起動を行います。 通常、数分でフェイルオーバが完了、
拡張モニタリングを使用した OS メトリクスのモニタリング - Amazon Relational Database Service
Enhanced Monitoring を使用すると、DB インスタンスのオペレーティングシステムをリアルタイムでモニタリングできます。さまざまなプロセスまたはスレッドが CPU をどのように使用しているかを確認するには、Enhanced Monitoring メトリクスが役立ちます。 Enhanced Monitoring の概要 Amazon RDS には、DB インスタンスが実行されているオペレーティングシステム (OS) のリアルタイムのメトリクスが用意されています。RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報をコンソールに表示できます。各インスタンスでモニタリングするメトリクスを管理し、要件に応じてダッシュボードをカスタマイズできます。拡張モニタリングメトリクスの説明については、「拡張モニタリングの OS メトリクス」を参照してください。 RDS は、拡張
RDSのフェイルオーバー時の挙動を理解してみる | TF Lab - クラウド開発記録 -
突然ですが皆さん、RDS、使ってますか？ こんにちは、クラウドエンジニアの大田です。 先月8月23日に起こった東京リージョンでの大規模障害が起きて久しいですね。 当初単一AZでの影響のみと考えられていた障害でしたが、 RDSやALBでのInternal Server Errorを吐いていたことが分かり、 障害の影響はマルチAZ配置のシステムにも波及していました。 「ウチはマルチAZでフェイルオーバーするから安心！」と思っていたらRDSが停止または自動再起動していた…という方もいらっしゃったのではないでしょうか。 さて、今回のテーマは「RDSのフェイルオーバー時の挙動を理解してみる」です。 主なゴールは、RDSのフェイルオーバー時の挙動を学び、安定稼働のためのヒントを得ていただくことです。 思考停止でとりあえずRDS使っとけ！的な風潮はありますが、やはり内部の動きを正確に理解しておかないと、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
