タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど
AWSがMySQLのODBCドライバを開発、オープンソースで公開。純正ドライバ互換、Amazon Auroraでの高速なフェイルオーバー、AWSのシークレットやIAMのサポートなど AWS ODBC Driver for MySQLは、MySQLコミュニティが配布している純正のMySQL用ODBCドライバと置き換えて使える互換性を備えつつ、AWSでMySQLを利用する際により優れた機能と性能を実現できるように実装されています。 具体的には、Amazon Auroraにおけるフェイルオーバー時の再接続の高速化です。AWS ODBC Driver for MySQLはクラスタのトポロジーと各 データベースインスタンスがプライマリなのかレプリカなのかの役割のキャッシュを保持することで、接続先のデータベースインスタンスに障害が発生し、別のデータベースインスタンスへのフェイルオーバーが発生したときに
Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering
こんにちは、IT基盤部の川原﨑です。 私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。 はじめに 第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。 例えば、 イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する などです。 これはWebサーバだけにとどまらず、DBサーバについても同様です。 EC2上でMySQLを運用している環境では、フェイル
障害対応時に AWS Direct Connect を手動で VPN へとフェイルオーバーする手法について - サーバーワークスエンジニアブログ
営業部 佐竹です。 本日は、2021年9月2日 の 午前7時30分から午後1時42分までの間に発生していた「東京リージョンにおけるダイレクトコネクト（専用線：以下 DX と記載）障害に関する記事となります。 はじめに 影響範囲について 一時的な対応策 DX をダウンさせる 1-1. CGW で NIC を Shutdown する 1-2. 物理線を抜く 1-3. DX フェイルオーバーテストの実行 2021年10月5日 追記 BGP 設定で対応する 2-1. 広報経路を更新する その他の手法 参考情報 Personal Health Dashboard の履歴1 [4:00 PM PDT] [4:45 PM PDT] [6:49 PM PDT] [6:49 PM PDT] [9:56 PM PDT] Personal Health Dashboard の履歴2 [05:39 PM PDT]
AWS Advanced JDBC WrapperによるAurora Postgresの高速フェイルオーバー - エムスリーテックブログ
【 デジスマチーム ブログリレー1日目】 こんにちは。 デジスマチームの山本です。 クリニック向けDXサービスであるデジスマ診療のWeb フロントエンド・バックエンド・インフラを担当しています。 今回は先日AWSから発表されたaws-advanced-jdbc-wrapperについて紹介します。 はじめに AWS Advanced JDBC Wrapper 提供Plugin フェイルオーバーとは これまでのフェイルオーバー対策 AWS Advanced JDBC Wrapperを利用した場合のフェイルオーバー対策 Failover Connection Plugin Host Monitoring Connection Plugin 導入方法 Gradle(Kotlin)での依存先の追加 Spring Boot + HikariCPでの設定例 実際に動かしてみた 何も設定しない場合 設定後
[NEW]「Lambda-RDS」パターンももう怖くない！？フェイルオーバーももっと早くなるよ！ RDS Proxyがプレビュー公開されました！#reinvent | DevelopersIO
こんにちは、大阪オフィスのかずえです。現在ラスベガスで開催中のre:InventでAmazon RDS Proxyのリリースがアナウンスされました。（ただしプレビューです！） なにそれ？ 名前の通りRDS用のプロキシです。 スケーラビリティ、DB障害への耐久性、セキュリティの向上が期待できます。 現在のところRDS MySQLとAurora MySQLで利用可能です。RDS PostgreSQL と Aurora PostgreSQLは間も無くとのこと。 東京リージョンで早速使えます！ これまで アプリとDB(RDS)間はコネクションを張ることで通信します。 ですがこのコネクション、DBサーバーのメモリやCPUを食います。 例えばサーバーレスアーキテクチャーのアプリの場合、このコネクション数がものすごい数になることがあります。DBに負荷がかかってしまいます。遅くなったりスケーラビリティが制
![[NEW]「Lambda-RDS」パターンももう怖くない！？フェイルオーバーももっと早くなるよ！ RDS Proxyがプレビュー公開されました！#reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/098a01a332248d791825217579652e1b7f202bcb/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F12%2Freinvent2019_update_eyecatch.jpg)
AWS JDBC Driver の Failover Plugin を使って3秒でAurora DB ClusterのWriterをフェイルオーバーしてみた | DevelopersIO
Amazon Auroraのフェイルオーバー時間を短くしたい こんにちは、のんピ(@non____97)です。 皆さんはAmazon Auroraのフェイルオーバー時間を短くしたいなと思ったことはありますか? 私はあります。 Auroraのフェイルオーバー時間は60秒未満と言われています。しかし、「60秒では長すぎる。せめて10秒程度でフェイルオーバーは完了させたい。」といったこともあると思います。 フェイルオーバー時間を短くする方法はクライアント側でMariaDB Connector/JやPostgreSQL JDBC Driverなどのドライバーを使用したり、RDS ProxyやProxySQLなどプロキシを挟むパターンがあります。 他にもフェイルオーバー時間を短くする方法が何かないかと探しているとAWS公式ドキュメントにフェイルオーバー時間を短くするための方法がまとまっていました。
【新機能】Amazon RDS の高可用性構成で書き込み性能向上とフェイルオーバーが高速になる！新しい高可用性オプションの Multi-AZ DB Cluster が一般提供になりました | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程 RDS の新しい高可用性オプションである Multi-AZ DB Cluster が一般提供となったためレポートします。Multi-AZ DB Cluster は従来の高可用性オプションの Multi-AZ DB Instance と比較して書き込み性能の向上とフェイルオーバーの高速化が期待できるオプションです。 New Amazon RDS for MySQL & PostgreSQL Multi-AZ Deployment Option: Improved Write Performance & Faster Failover なおプレビュー時の紹介はこちらのエントリーです。 Multi-AZ DB Cluster RDS には従来高可用性のためのオプションとして Multi-AZ Instance がありました。従来の Mu
Cloudflareがデータセンターで大規模な停電が発生したことを報告、フェイルオーバーが機能してサービスへの影響はほぼ無し
2024年3月26日にCloudflareのデータセンターで大規模な停電が発生しましたが、ほとんどのサービスは全く影響を受けませんでした。どのように障害を防止したのかについてCloudflareが公式ブログに投稿しました。 Major data center power failure (again): Cloudflare Code Orange tested https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested 今回の停電事件の約5カ月前である2023年11月2日に、Cloudflareのオレゴン州ポートランド地域にあるデータセンターで停電が発生しました。この11月の停電では下記の14サービスにおいて、データの伝送経路を制御するコントロールプレーンが
「ネバーストップ」を旗印に掲げる大規模システム、東京証券取引所の「arrowhead（アローヘッド）」が2020年10月1日にシステム障害に見舞われ、1999年の取引全面システム化以来初となる全銘柄終日取引停止を余儀なくされた。原因は二重化していたNAS（Network Attached Storage）の1号機でメモリーの故障が発生し、さらに2号機単独運用への切り替えにも失敗したことだ。 サーバーやネットワークの冗長化は情報システムの信頼性を高めるための常套手段だ。しかしシステム障害を防ぐはずの二重化が正常に機能しないという事態はarrowheadのみならず、多くの大規模システムで発生しうる。なぜフェイルオーバーに失敗するのか。有効な自衛手段はあるのか。日経コンピュータの過去の障害事例記事を基に、失敗の要因や対策を明らかにしていく。 2012年、東京証券取引所は取引停止につながる大規模な
Amazon Aurora Global Databaseをリージョン間でフェイルオーバーさせてみた | DevelopersIO
Amazon Aurora Global Database はAmazon Aurora クラスターを複数の AWS リージョンにまたがって構築でき AWSリージョン障害時の災害復旧(DR;Disaster Recovery) 世界中からデータベースを高速に読み書き(データのローカリティ) などを実現できます。 今回は、大阪リージョンフルオープン記念として、東京・大阪リージョン間で Aurora Global Database のフェイルオーバーを試してみました。 Aurora Global Database の構成パターン Aurora Global Database はプライマリ・リージョンから別リージョンへ低レイテンシーにデータがレプリケートされます。 プライマリリージョンでは読み書きが可能です。 ストレージベースでレプリケートされるセカンダリリージョンでは主に以下の３パターンがあり
わずか数秒！RDS Proxy を Aurora 高速フェイルオーバーに利用する | DevelopersIO
RDS Proxy への接続ログ 1回目、2回目は 0.5 秒としていますが、sleep が 0.5 だと切れ目なく接続できてしまったので、実際には 0.5 未満 ということですね。 $ ./test.sh （中略） 2020-08-25 04:28:42.194083284 2020-08-25 04:28:42.211 ip-10-7-2-92 0 2020-08-25 04:28:42.696020168 2020-08-25 04:28:42.737 ip-10-7-2-92 0 2020-08-25 04:28:43.197867170 2020-08-25 04:28:44.272 ip-10-7-1-87 0 <-- ここで切り替わっている 2020-08-25 04:28:43.699713439 2020-08-25 04:28:44.273 ip-10-7-1-87 0
突然ですが皆さん、RDS、使ってますか？ こんにちは、クラウドエンジニアの大田です。 先月8月23日に起こった東京リージョンでの大規模障害が起きて久しいですね。 当初単一AZでの影響のみと考えられていた障害でしたが、 RDSやALBでのInternal Server Errorを吐いていたことが分かり、 障害の影響はマルチAZ配置のシステムにも波及していました。 「ウチはマルチAZでフェイルオーバーするから安心！」と思っていたらRDSが停止または自動再起動していた…という方もいらっしゃったのではないでしょうか。 さて、今回のテーマは「RDSのフェイルオーバー時の挙動を理解してみる」です。 主なゴールは、RDSのフェイルオーバー時の挙動を学び、安定稼働のためのヒントを得ていただくことです。 思考停止でとりあえずRDS使っとけ！的な風潮はありますが、やはり内部の動きを正確に理解しておかないと、
Amazon Route 53 によるフェイルオーバーと CloudFront と S3 構成のソリーページ設定について考えてみた | DevelopersIO
Amazon Route 53 によるフェイルオーバーと CloudFront と S3 構成のソリーページ設定について考えてみた シンプルな構成で Web サービス提供している環境に Sorry ページ（メンテナンスページ）を追加方法を考えていました。よくあるケースが故に実装方法は様々あります。 本ブログは Route 53 フェイルオーバールーティングで実装した際の考慮事項の備忘録です。 Sorry ページの実装方法は様々 Sorry ページ（メンテナンスページ）の一般的な実装を社内であたってみたところ様々な方法が挙がりました。社内の皆様ありがとうございます。 ALB の前に CloudFront を入れてオリジンフェイルオーバーしたり、ALB の固定レスポンスでシンプルな Sorry ページを返すなどのよく知られた方法があります。 AWS そのものの障害を考慮し AWS ではない G
やりたいこと 「https://www.xxxx.com/app/login」のようなURLで動作しているWEBアプリケーションに対して、障害時やサーバー停止時にsorryページをサーバーレスで自動で表示させたい。 今回は、Route53のフェイルオーバーを使用し、独自ドメインでSSL暗号化通信での障害発生時に自動でsorryページを表示する方法を紹介します。 はまったこと HTTPでのRoute53フェイルオーバーを使用したsorryページの表示は、セカンダリのAliasにS3のエンドポイントを指定することで可能でした。 しかしSSL通信でのHTTPSの場合、S3単体ではSSL証明書を扱うことができないため、フェイルオーバー時にセカンダリとして指定することができません。 この解決方法として、CloudFront経由でHTTPSをS3にリダイレクトする方法を紹介します。 CloudFron
って言うと語弊がありますが、デフォルトがPumaになってる昨今のRails、という意味で。 Rails Aurora フェイルオーバー でググると色々ヒットしますが、少々偏った情報が多いため、整理して残したいと思った次第です。 偏ったというのは、Unicornでしか使えない(古い)情報が多いから。 さて 問題事象をザックリ言うと フェイルオーバーによって、(Railsが)知らない間にREADERに降格してた元WRITERに対して更新クエリ投げちゃってエラーになる です。Auroraの各インスタンスはフェイルオーバーによって、IPアドレスはそのままでREADER⇔WRITERにスイッチするのですが、Railsがそれに追従できずにそのままコネクションをプーリングし続けるために発生する問題。 まず ググると行き着くのこちらでしょう https://github.com/sonots/active
【Security Hub修復手順】[ElastiCache.3] ElastiCache for Redis レプリケーショングループでは、自動フェイルオーバーを有効にする必要があります | DevelopersIO
こんにちは、AWS事業本部の平井です。 皆さん、お使いのAWS環境のセキュリティチェックはしていますか？ 当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介します。 本記事の対象コントロール [ElastiCache.3] ElastiCache for Redis レプリケーショングループでは、自動フェイルオーバーを有効にする必要があります [ElastiCache.3] ElastiCache for Redis replication groups should have automatic failover enabled 前提条件 本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。 AWS Security Hub
![【Security Hub修復手順】[ElastiCache.3] ElastiCache for Redis レプリケーショングループでは、自動フェイルオーバーを有効にする必要があります | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba983f76286d716c33249c5cd7c5d87259ff98a9/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Faws-security-hub.png)
Amazon Auroraデータベースは可用性に優れており、その高速なフェイルオーバーは売りの一つです。 Amazon Auroraの可用性に関するドキュメントによると、レプリカが1つ以上あると、フェイルオーバーによりレプリカがプライマリインスタンスに昇格し、60秒未満でフェイルオーバーが完了します。 DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、一般的なサービスの復元時間は 120 秒未満であり、多くの場合 60 秒未満で復元されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することを
AWS CDKで別リージョンにレプリケーション用S3バケットを作成するスタックをデプロイしてAmazon CloudFrontオリジンフェイルオーバーを設定する - NRIネットコムBlog
小西秀和です。 前回の記事、「AWS CDKで別リージョンにAWS Certificate Manager(ACM)証明書スタックをデプロイしてAmazon CloudFrontに設定する」では次の記事で紹介したリージョン間でパラメータを送受信する方法を使ってACM証明書をCloudFrontに設定する方法を紹介しました。 AWS CDKで別リージョンにスタックをデプロイしてパラメータをリージョン間で受け渡す方法 －AWS CDKカスタムリソースの実装例 今回はその記事の続編として、前回記事で作成したAWS CDKカスタムリソースを使用して、リージョンの異なる2つのS3バケットを作成し、Amazon CloudFrontオリジンフェイルオーバーを設定する方法を紹介します。 パラメータをクロスリージョンで扱うAWS CDKカスタムリソースについては元記事を参照してください。 ※本記事および当
[アップデート]Amazon Aurora Global Database は、（計画外の）フェイルオーバーができるようになりました | DevelopersIO
はじめに Amazon Aurora Global Database が（計画外の）フェイルオーバーできるようになりました。 以前はAWSマネジメントコンソール上からワンクリックで、計画的なフェイルオーバーが可能でしたが、今回のアップデートでは、リージョンレベルの障害時などの計画外のフェイルオーバーができるようになりました。 今回のアップデートにより、「計画外のフェイルオーバー」の名称が「フェイルオーバー」となり、「計画的なフェイルオーバー」の名称は「スイッチオーバー」に変更されました。 スイッチオーバー（計画的なフェイルオーバー） 運用保守やその他の計画された運用手順の確認や復旧訓練時に使用されます 他の変更を行う前にセカンダリ DB クラスターをプライマリと同期するため、RPO は 0 (データ損失なし) です。 NEW! フェイルオーバー（計画外のフェイルオーバー） プライマリリージ
![[アップデート]Amazon Aurora Global Database は、（計画外の）フェイルオーバーができるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d910a704fd77fa1631a41965d8633a247eccd8f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Famazon-aurora.png)
Amazon EventBridge にイベントを別リージョンに自動でフェイルオーバーするグローバルエンドポイントが追加されました | DevelopersIO
Amazon EventBridge にイベントを別リージョンに自動でフェイルオーバーするグローバルエンドポイントが追加されました イベント駆動アーキテクチャでもリージョン障害に対応したい こんにちは、のんピ(@non____97)です。 皆さんはイベント駆動アーキテクチャでもリージョン障害に対応したいと思ったことはありますか? 私はあります。 Amazon EventBridgeのイベントはリージョン内で閉じています。そのため、EventBridgeでリージョン障害が発生した場合に、別リージョンにシステムをフェイルオーバーしたとしても、障害が発生してからフェイルオーバーが完了するまでに発生したイベントを拾うことができません。 今回、Amazon EventBridge にイベントを別リージョンに自動でフェイルオーバーするグローバルエンドポイントが追加されました。 グローバルエンドポイント
RDSやAuroraのフェイルオーバー などのイベント情報は、RDSマネジメントコンソールやAWS CLIで確認コマンドを実行するなどで表示が可能です。 ただ、重要なイベントの発生はできるだけ早く検知したいと思うものです。 今回は、RDSのイベントサブスクリプション機能を使って、フェイルオーバーが発生した際にEメールで通知する設定方法を紹介します。 なんと、作業時間はたったの約5分!お手軽に設定できました。 前提条件 目的は、「指定されたDBクラスター でフェイルオーバー が発生したら、メールで通知を行う」です。 参照ドキュメント 下記のAWSドキュメントに記載されている手順を参考に、設定していきます。 一見、ドキュメントにはRDSの設定について書かれているようにも思えますが、Aurora クラスターも同様の手順で通知を設定できます。 検証環境 本記事では、通知対象のDBは作成済みの前提で
CloudFront オリジンフェイルオーバーによる高可用性の最適化 - Amazon CloudFront
高可用性が必要なシナリオでは、オリジンフェイルオーバーを使用するように CloudFront を設定できます。開始するには、プライマリとセカンダリの 2 つのオリジンを持つオリジングループを作成します。プライマリオリジンが使用できない場合、または障害を示す特定の HTTP レスポンスステータスコードを返す場合、CloudFront は自動的にセカンダリオリジンに切り替わります。 オリジンフェイルオーバーを設定するには、少なくとも 2 つのオリジンを持つディストリビューションが必要です。次に、1 つをプライマリとして設定した 2 つのオリジンを含むディストリビューションのオリジングループを作成します。最後に、オリジングループを使用するようにキャッシュ動作を作成または更新します。 オリジングループを設定して特定のオリジンフェイルオーバーオプションを設定する手順については、「オリジングループの作
[アップデート] AWS Elemental MediaLive で真っ暗な映像や無音をトリガーとした入力フェイルオーバーが可能になりました | DevelopersIO
こんにちは、大前です。 AWS Elemental MediaLive（以下 MediaLive）に（久々の）アップデートが来ましたので、お知らせします。 AWS Elemental MediaLive expands its automatic input failover capabilities TL;DR MediaLive の入力フェイルオーバーに関するアップデートだよ 入力フェイルオーバーさせる条件が増えたよ 映像が真っ黒、もしくは音声がない場合に入力フェイルオーバーをさせられる様になったよ 前提 まず前提として、2020/4 に MediaLive で入力に対するフェイルオーバーが出来る様になるアップデートがありました。今回のアップデートはこの拡張になるため、入力フェイルオーバーって何ぞ？ な方は以下ブログを先に参照ください。 [アップデート] AWS Elemental M
![[アップデート] AWS Elemental MediaLive で真っ暗な映像や無音をトリガーとした入力フェイルオーバーが可能になりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6142fc4a4ae8333d85e3addc0ee05bf4d84eba90/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-elemental-medialive.png)
RDSがフェイルオーバーした際、ECSで動作しているRuby on Railsを再起動する仕組みを構築した - Qiita
# アーカイブ化 # Lamdbanにファイルを取り込む場合、ZIPファイルで取り込む必要がある為、このリソースでZIPファイルを作成する data "archive_file" "db_failover" { # zipで固定 type = "zip" # 下記に指定したディレクトリ内のファイルは全てアーカイブ(zip化)される # source_dir = "${path.module}/任意のディレクトリー名" source_dir = "${path.module}/lambda_function" # アーカイブしたファイル(zipファイル)がこのパスに出力される # output_path = "${path.module}/任意のディレクトリー名/任意の名前が付与されたzipファイル" output_path = "${path.module}/archive/db_fail
vCenter High Availability (vCenter HA) の設定手順とフェイルオーバー時間について
vCenter Server Appliance (vCSA) について、バージョン6.5以降より、vCenter High Availability (vCenter HA) と呼ばれる冗長化機能が利用できるようになった。ちなみに、vCenter Serverの高可用性の手法については、VMware社の以下KBにてまとめられている。 サポート対象の vCenter Server 高可用性オプション (1024051) https://kb.vmware.com/s/article/1024051?lang=ja 今回、手順確認と動作確認を目的として、実際にvCSAを構築して、vCenter HAの設定をしてみた。また、実際にフェイルオーバーさせた際の、vCenter Serverが操作できなくなる時間をざっくり計測してみた。 実施環境 今回の環境は以下の通り。vCenter HAを構成す
AWS Elemental MediaLive の入力側フェイルオーバーを試してみた | DevelopersIO
こんにちは、大前です。 今日は、先日のアップデートで AWS Elemental MediaLive に追加された Input Failover を試してみたいと思います。 [アップデート] AWS Elemental MediaConnect と AWS Elemental MediaLive で入力ソースに対するフェイルオーバー設定が可能となりました！ やりたい事 下記のような、OBS で RTMP プッシュ入力を MediaLive で受け付け、HLS に変換して MediaStore に格納する様な構成を検討します。 この時、MediaLive に対する入力を 2つ作成し、片方を Primary、残りを Secondary に設定します。 Primary、Secondary 共に MediaLive に対して配信を行いつつ、Primary 側を落としたら Secondary に切り
DB インスタンスのフェイルオーバーが発生しました。原因を特定する方法を教えてください。 | DevelopersIO
困っていた内容 Amazon RDS のマルチ AZ 配置を使用しています。 一時的に DB インスタンスへの接続ができない状態が発生していたため、フェイルオーバーが発生していたと思われます。 DB インスタンスがフェイルオーバーした原因を特定する方法を教えてください。 どう対応すればいいの？ Service Health Dashboard の確認 AWS Service Health Dashboard 必ずしもリアルタイムではないため、現在発生している問題であれば以下確認を進める リージョン毎に情報提供されるので適切なリージョンを選択する Availability Zone （AZ）単位では情報提供されない AZと物理的な環境のマッピングはアカウント毎に異なるため アカウント A の ap-northeast-1a とアカウント B の ap-northeast-1a は物
ProxySQL入門、ProxySQLでDBサーバーの負荷分散とAuroraの高速フェイルオーバーに対応してみる - アクトインディ開発者ブログ
こんにちは、キエンです。 最近、DBサーバーの負荷分散とAuroraの高速フェイルオーバーの対策を調査した時、ProxySQLを検証しましたので、ご紹介します。 ProxySQLとは? ProxySQLはMySQLおよびfork（Percona ServerやMariaDBなど）用の高性能で高可用性のプロトコル対応プロキシです。ライセンスはGPLv3となっています。以下の主な特徴はあります。 クエリーキャッシュ クエリールーティング フェイルオーバーサポート ファイアーウォール ProxySQLの公開サイト ホームページ GitHub ウィキ ProxySQLの構成 ProxySQLの構成は複雑ですが、以下のニーズを満たすため使いやすい構成システムがあります。 設定を簡単に動的更新を許可する ゼロダウンタイムプロビジョニングが必要な大規模なインフラストラクチャでProxySQLを使用できる
Amazon API Gateway マルチリージョンフェイルオーバーの実装 | Amazon Web Services
Amazon Web Services ブログ Amazon API Gateway マルチリージョンフェイルオーバーの実装 本投稿は Implementing multi-Region failover for Amazon API Gateway (記事公開日: 2024 年 7 月 8 日) を翻訳したものです。 本投稿は、プリンシパルソリューションアーキテクト Marcos Ortiz と、シニアソリューションアーキテクト Khubyar Behramsha によって書かれています。 この投稿では、AWS コントロールプレーンの操作に依存することなく、信頼性の高いフェイルオーバー メカニズムを使用して、単一リージョンの API Gateway アーキテクチャからマルチリージョンのアーキテクチャに進化する方法を学びます。AWS Well-Architected ベストプラクティスは、
フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定 - Amazon Route 53
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定 Route 53 のヘルスチェックを使用して、フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) を設定できます。フェイルオーバー以外のいずれかのルーティングポリシー (またはルーティングポリシーの組み合わせ) を使用して、フェイルオーバー (アクティブ/アクティブ) を設定し、フェイルオーバールーティングポリシーを使用してフェイルオーバー (アクティブ/パッシブ) を設定します。 フェイルオーバー (アクティブ/アクティブ) すべてのリソースをほとんどの時間で利用できるようにするには、このフェイルオーバー設定を使用します。利用不可能になったリソースについては、Route 5
[Route53] フェイルオーバールーティングにてフェイルオーバーとフェイルバックが発生したことを検知する - Qiita
この記事について Route53にはフェイルオーバールーティングというルーティングポリシーがあります。 フェイルオーバールーティングには以下の３つの要素があります。 プライマリレコード セカンダリレコード ヘルスチェック ヘルスチェックではチェック対象のURL(もしくはIPアドレス)を指定して、HTTP/HTTPSリクエストを送信します。ステータスコードが200であればヘルスチェックが正常であると判定されます。それ以外のステータスコードの場合は異常と判定されます。 フェイルオーバールーティングではヘルスチェックを定期的に行い、ヘルスチェックが正常である場合はプライマリレコードのDNSクエリを返します。ヘルスチェックが異常の場合はセカンダリレコードのDNSクエリを返します。 プライマリレコードからセカンダリレコードへの切り替わりことをフェイルオーバーと呼びます。 ヘルスチェックが異常から正常
![[Route53] フェイルオーバールーティングにてフェイルオーバーとフェイルバックが発生したことを検知する - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a5eea61ebbe7df830abe09b6596dac10cd55bbc/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUm91dGU1MyU1RCUyMCVFMyU4MyU5NSVFMyU4MiVBNyVFMyU4MiVBNCVFMyU4MyVBQiVFMyU4MiVBQSVFMyU4MyVCQyVFMyU4MyU5MCVFMyU4MyVCQyVFMyU4MyVBQiVFMyU4MyVCQyVFMyU4MyU4NiVFMyU4MiVBMyVFMyU4MyVCMyVFMyU4MiVCMCVFMyU4MSVBQiVFMyU4MSVBNiVFMyU4MyU5NSVFMyU4MiVBNyVFMyU4MiVBNCVFMyU4MyVBQiVFMyU4MiVBQSVFMyU4MyVCQyVFMyU4MyU5MCVFMyU4MyVCQyVFMyU4MSVBOCVFMyU4MyU5NSVFMyU4MiVBNyVFMyU4MiVBNCVFMyU4MyVBQiVFMyU4MyU5MCVFMyU4MyU4MyVFMyU4MiVBRiVFMyU4MSU4QyVFNyU5OSVCQSVFNyU5NCU5RiVFMyU4MSU5NyVFMyU4MSU5RiVFMyU4MSU5MyVFMyU4MSVBOCVFMyU4MiU5MiVFNiVBNCU5QyVFNyU5RiVBNSVFMyU4MSU5OSVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NjBiZDAyZjFhMWVmZjNhM2VkYTQ2ODY4MGYwNjgzYTY%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwSzVLJTIwaW4lMjAlRTMlODIlQTIlRTMlODIlQTQlRTMlODMlQUMlRTMlODMlODMlRTMlODMlODglRTYlQTAlQUElRTUlQkMlOEYlRTQlQkMlOUElRTclQTQlQkUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTFkNDc2MjViNjE5Y2M0MDZjMzJkM2IwNzFkNjJjZDMw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D272f4bdd177456bd4bafc9553da2c00d)
[アップデート] AWS Elemental MediaConnect と AWS Elemental MediaLive で入力ソースに対するフェイルオーバー設定が可能となりました！ | DevelopersIO
こんにちは、大前です。 AWS Elemental MediaConnect と AWS Elemental MediaLive について、掲題のアップデートがありましたのでお知らせします。 AWS Elemental MediaConnect and MediaLive add input failover features 最近は MediaServices に関するアップデートが多いですね！ 簡単まとめ AWS Elemental MediaConnect のフローに対する入力にフェイルオーバー設定機能が追加されたよ AWS Elemental MediaLive のチャンネルの入力にフェイルオーバー設定機能が追加されたよ MediaServices を使用したライブ配信アーキテクチャの可用性をより高める事が出来るよ どんなアップデート？ AWS Elemental MediaCon
![[アップデート] AWS Elemental MediaConnect と AWS Elemental MediaLive で入力ソースに対するフェイルオーバー設定が可能となりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ebe4beaf573347d332e9c93962d0b239cf1a0902/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-elemental-mediaconnect.png)
アマゾン ウェブ サービス (AWS) の MySQL 用 Java (JDBC) ドライバーの一般提供が開始され、Amazon RDS または Amazon Aurora MySQL 互換エディションのデータベースクラスターで使用できるようになりました。このデータベースドライバーが、データベースクラスターのステータスをモニタリングし、クラスターのトポロジーをキャッシュすることで、フェイルオーバー時間を最小限に抑えます。 ノードに障害が発生した場合の DNS 名解決の速度を向上させるためにキャッシュが使用したことで、フェイルオーバー時間が数分から数秒に短縮しました。 MySQL JDBC ドライバーは、MySQL Connector/J に基づいており、MySQL デプロイをサポートします。このドライバーは コミュニティ版の MySQL ドライバーとドロップインの互換性があり、Maven、
やりたいこと ElastiCache for Redisの設計をしたい（まずは方式レベル） 用途はアプリケーションのセッション管理 可用性要件が高く、AZ障害の際にもダウンタイムを最小限にしたい 参考文献 公式ドキュメントだとこれがドンピシャ 2年前ですが分かりやすい公式スライド 基本のおさらいには安定のクラメソさんブログ これらより、まずは「クラスターモード」を採用すべきか否か、の判断のためフェイルオーバー所要時間を実測してみる。 試したこと 準備 非クラスターモードのRedisクラスターを作成 クラスター名：single-shard マルチAZ：有効 レプリカ数：2 AZの配置（ノード） プライマリ：ap-northeast-1a レプリカ1：ap-northeast-1a レプリカ1：ap-northeast-1c クラスターモードのRedisクラスターを作成 クラスター名：mult
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e42d360866a8ef193de27e43e50492da34de08d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgxJTg0JUUzJTgxJTg0JUU1JThBJUEwJUU2JUI4JTlCJUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUE3JTIwJTVCJTIwJTI0JTNGJTIwLWVxJTIwMCUyMCU1RCUyMCVFMyU4MiU4NCUyMCU1QiUyMCUyNCUzRiUyMC1uZSUyMDAlMjAlNUQlMjAlRTMlODElQUElRTMlODIlOTMlRTMlODElQTYlMjAlRTMlODIlQTglRTMlODMlQTklRTMlODMlQkMlRTUlODclQTYlRTclOTAlODYlRTMlODIlOTIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQUUlRTMlODElQUYlRTMlODIlODQlRTMlODIlODElRTMlODIlODglRTMlODElODYlRUYlQkMlODEmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWZhZDdkMjVkYjUxODQ5OWRhZDhiZWM3ZGMwN2ZlY2Q0%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrbzFua3NtJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zNDA2OWFjMTI5MDIyYmE1ZjY0OTI5ZGU2ZGUwNDU5Zg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D8f12358d68288246128c01d35bcfa4b1)
自動フェイルオーバーの失敗は珍しくない、二重化の限界を知り障害に備えよ
RDSのフェイルオーバー時の挙動を理解してみる | TF Lab - クラウド開発記録 -
HTTPS + Route53フェイルオーバーでsorryページを表示する - Qiita
最近のRailsからのAuroraフェイルオーバー | DevelopersIO
Amazon Auroraフェイルオーバー中のダウンタイムを調べてみた | DevelopersIO
Amazon Aurora のフェイルオーバー を E メールで通知する | DevelopersIO
アマゾン ウェブ サービスの MySQL 用の JDBC ドライバーで、より高速なデータベースフェイルオーバーを実現
ElastiCache for Redisのフェイルオーバー時間を計測してみた - Qiita
search.app
x.com
blog.adachin.me
maho3.dt.weblog.vc
cleverone.net
www.city.uji.kyoto.jp