Amazon Aurora MySQL がリードレプリカの可用性を改善
Amazon Aurora MySQL 互換エディションは、ライターノードの再起動を通じて読み取りの可用性を維持するようになりました。これまでは、ライターノードが再起動すると、Aurora MySQL クラスター内のすべてのノードも再起動していました。本日のリリースにより、リーダーノードはライターノードの再起動中に読み取りリクエストを処理し続けるようになり、これによりクラスターでの読み取りの可用性が改善されます。 計画されたライターノードの再起動は、通常、binlog の有効化や無効化などの静的パラメータを適用するために行われます。これらの再起動を通じて読み取りの可用性を維持することは、ライター設定に変更を加えることによる影響を軽減するのに役立ちます。さらに、フェイルオーバーが発生した場合の可用性が向上します。この場合、リーダーノードは引き続き使用可能であり、新しく昇格したライターに再接続
Aurora MySQLのローカルストレージ不足で事故ったログ - takanamitoのブログ
日次でDB内のとあるテーブルのデータ全件をBigQueryに同期するバッチがあって RDS for MySQLからデータをselectしていたが、先日Aurora MySQL(5.6.10)に移行した直後から急にバッチがこけはじめた。 原因調査 バッチは使用しているMySQLクライアントの設定値(3600秒)に従ってタイムアウトし落ちていた。 バッチの実行時間帯のCloud Watchメトリクスを確認してみると AuroraのCPU使用率が30分間ほど平常値から外れて高くなっていた。 しかしバッチを実行しているEC2のネットワークインプットメトリックは特に変動がなく、Auroraからselectした結果を受け取れてなさそうなことも同時にわかった。 DBへの接続がタイムアウトするまでに1時間かかっているのに、selectによるCPU負荷が30分程度しか上昇していないので クエリが何らかの理由
［Auroraの落とし穴］フェイルオーバー時に接続先が切り替わらない
Amazon Web Services（AWS）のリレーショナルデータベースサービス「Amazon Aurora」のデータベースクラスターでは、1台以上のレプリカがある場合、プライマリーインスタンスに障害が発生すると、自動的にレプリカのうち優先度の高い1台がプライマリーインスタンスに昇格する。 このとき、リクエストが新しいプライマリーインスタンスに接続されるように、自動でクラスターエンドポイントのDNS（Domain Name System）レコードが更新される。これによって、フェイルオーバーを実現する。通常は、障害検知からフェイルオーバーは１分以内に完了する。 しかし、アプリケーション側でDNSのTTL（Time to live）を無視し、DNSレコードをキャッシュする設定になっている場合、このフェイルオーバーに追従できず、障害インスタンスにアクセスし続けてしまう場合がある。 なおレプリ
Auroraの高速フェイルオーバーと無停止での切り替え | BLOG - DeNA Engineering
こんにちは、IT基盤部の川原﨑です。 私の所属する第四グループでは、超大規模ゲームタイトルおよびゲームプラットフォームのインフラを運用しております。 そこでのAuroraの高速フェイルオーバーの仕組みと、実際に無停止で切り替えを行った手順について紹介させていただきます。 はじめに 第四グループでは、コストコントロールの一環でInstance数の増減・Instance Typeの変更を頻繁に実施しています。 例えば、 イベントなどでリクエスト増加が見込まれるときにInstance数を増やす、またはInstance Typeを1つ上のものに変更する リクエストが減少傾向にあれば、Instance数を減らす、またはInstance Typeを1つ下のものに変更する などです。 これはWebサーバだけにとどまらず、DBサーバについても同様です。 EC2上でMySQLを運用している環境では、フェイル
RDS for MySQL5.6 から Aurora（MySQL 5.6 互換）へ移行しました - Feedforce Developer Blog
ソーシャルPLUS 開発チームでインフラエンジニア をやっています id:mayuki123 です。気づけば入社から10ヶ月ほど経っていました。 ソーシャルPLUSのメッセージ機能については1年半ほど前にAurora移行を実施していますが、2019年2月中旬にメインのソーシャルログイン機能で利用している データベースをRDS for MySQL5.6からAmazon Aurora(MySQL 5.6 互換）に移行することが出来ました。 developer.feedforce.jp Auroraに移行する利点等は多くの方がまとめているかと思うので、今回はデータベース移行で実施した手順に着目して書こうと思います。 準備期間と移行作業の概要 データベース移行方法の選択 AWSのDMSとは AWSのDMSのリソースについて データロードの種類 新しいAurora環境の構築 データベースインスタンス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
