Amazon Aurora への移行検証の中で、RDS for MySQL にできて Aurora にできないことを見つけました。 MySQL との高い互換性は確認できたのですが、運用する上でハマりそうです。 レプリケーションを一時停止できない MySQL にはレプリケーションを一時停止するために STOP SLAVE が用意されています。 RDS の場合は権限がないため mysql.rds_stop_replication というストアドプロシージャを使います。 mysql.rds_stop_replication - Amazon Relational Database Service どういうときにレプリケーションを止めたいかというと、分析のためにある時点(たとえば深夜 0 時)の全データをエクスポートしたいときです。 RDS の Restore to Point in Time (
You have been redirected here because the page you are trying to access has been archived. AWS re:Post is a cloud knowledge service launched at re:Invent 2021. We've migrated selected questions and answers from Forums to AWS re:Post. The thread you are trying to access has outdated guidance, hence we have archived it. If you would like up-to-date guidance, then share your question via AWS re:Post.
概要 Amazon Aurora 事例祭りの事例紹介ということで、1年ほど前にクラブレコチョクのシステムをOracle RACからAmazon Auroraへ移行したので、それについてお話しさせていただきました。 内容 こちらが発表のスライドになります。 アジェンダとしては、 レコチョクとクラブレコチョクについて Auroraを選択した理由 どのようにAuroraへ移行したか どのようにAuroraを運用しているか Auroraに期待するところ といった感じでお話しさせていただきました。 レコチョクとクラブレコチョクについて スライドを参照いただければと思います。 Auroraを選択した理由 システム単体の課題を可決するために移行したというより、 会社全体としていくつか課題を抱えていたので、それを解決するために 全システムAWS移行を決めたというのが、まずはじめにあります。 Auroraを
ウィスキー、シガー、パイプをこよなく愛する大栗です。 Auroraへ移行するお話を頂くことが増えてきました。そこでAuroraへの移行時における冗長化のポイントを考えてみました。 RDSのSLA定義はMulti-AZが前提である旨を追記しました。 そもそもMulti-AZって? ここではMySQLの場合のMulti-AZについて述べます。 Single-AZでは、以下の問題があります。 耐久性: ストレージボリュームで障害が発生した時には、「最新の復元可能な時刻」以降のデータ更新が失われる。 可用性: ハードウェア障害が発生した時に、インスタンスを再作成するため再接続までの時間が必要になる Auroraを除くRDSではストレージボリュームにEBSと同等のものが使用されているようなので通常のディスクに比べて高い可用性と信頼性を備えています。 補足すると、EBSについての具体的な数字としては「
ども、大瀧です。 Amazon Linux 2015.09RC版のリリース告知に"Amazon Aurora JDBC driver"という項目があり、調べてみるとAuroraの可用性をアップさせるナイスな機能だったのでご紹介してみたいと思います。 RDS Multi-AZの"普通の"フェイルオーバー Amazon RDSで提供される可用性機能としてMulti-AZがあります。一般に言うActive-Standbyクラスタで、エンドポイントとなるDNSレコードのIPアドレスをアクティブノードに向ける、DNSベースの仕組みとなります。 以下のように、Masterノード障害を検知すると、エンドポイントのレコードをSlaveノードのIPアドレスに切り替える要領です。 AuroraでもCluster Endpointというエンドポイントが提供され、フェイルオーバーを実装することができます。しかし、
Photo via Visual hunt ヌーラボアカウントではつい先日、Amazon RDS for MySQL から Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 ヌーラボアカウントは Backlog や Cacoo、Typetalk といったヌーラボのサービスへの認証機能を提供しています。もし認証機能が使えないとすべてのサービスを利用できなくなってしまいます。そのため、ヌーラボアカウントには常に認証機能を提供し続けられるような、高いアベイラビリティが求められています。 ヌーラボアカウントではこれまで RDS for MySQL を利用していましたので、MySQL 互換を掲げる Amazon Aurora は、リリースされたときから移行の可能性を検討をしてきました。Aurora のメリットについては
ウィスキー、シガー、パイプをこよなく愛する大栗です。 本日、Amazon Auroraで読み込みエンドポイント(Reader Endpoint)が発表されました。今までは、インスタンスエンドポイント(Instance Endpoint)とクラスターエンドポイント(Cluster Endpoint)が利用できましたが、新しいエンドポイントについて試してみました。 読み込みエンドポイントとは 現在Auroraには、以下の3種類のエンドポイントがあります。クラスターエンドポイントはWriterを指すエンドポイントで、インスタンスエンドポイントは各インスタンスを指しエンドポイントです。今回追加された読み込みエンドポイントはReaderを指すエンドポイントです。 クラスターエンドポイント(Cluster endpoint) インスタンスエンドポイント(Instance endpoint) 読み込みエ
Amazon Auroraというクラウド上のRDBMSサービスがある。2015年の7月末にGAロウンチしたばかりのサービスだが、世界各国のユーザに非常に好評のようだ。 https://aws.amazon.com/rds/aurora/ Auroraをどう見るか、でクラウドの受け入れ度合いや現状の把握に使えると個人的には感じている。個人としてはAuroraほど画期的なサービスはDBでは今までなかったし、RDBMSの歴史の新しい1歩として認識している。ただあまりのシームレスさ、移行容易性、利用の簡便さに凄さに逆に気づきにくい状況がおきている。結果としてマーケティング的なムーブメントにはなりにくい状況で、個人としてはむしろそれが望ましいとも思っている。静かに深く世の中を変えていく、そんなサービスだ。ちなみにグローバルではOracleやSQL Serverからの移行が後を絶たない。理由の多くは、
Aurora を使いたいのだが、まだまだ MySQL にもお世話になっている。 ログについて確認したのでまとめ。 概要 RDS(MySQL)では以下のログを出力可能。 error.log general.log slowquery.log デフォルトでテーブルに記録されるが ParamaterGroup で設定すればログファイルに記録される。 また、1はデフォルトで出力されており、2,3については ParamaterGroup で設定が必要。 保管場所 テーブルでもファイルでもRDS のストレージ内 どちらでも勝手にローテートされる ファイルの場合 1時間ごとにファイルが切り替わる 24時間でローテートされる 容量がストレージの2%を超えている場合、ローテート時に2%以下に収まるように削除されるので注意 テーブルの場合 ストレージの使用容量によってローテートタイミングが決まる 使用容量 <
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の2つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
Amazon Auroraの運用について プレビュー版のAmazon Aurora使えるようになったので色々試しています。新しいDBエンジンということで、運用をどうするか気になっている方も多いのではないでしょうか。Amazon Auroraは、RDSの他のデータベースエンジンと同じように、CloudWatchで運用状況をモニタリングすることができます。これにより、正常稼働しているか、期待するパフォーマンスが出ているか確認することができますので、アラームを設定して運用に役立てることができます。 AuroraのDBクラスタ概念図 Aurora Metricsの種類 Auroraは、大きく分けて2種類の情報があります。Aurora System Monitoringと、Aurora SQL Monitoringです。前者は、ネットワーク/ディスク/CPUなどのシステムに関するモニタリングで、後者
どうも佐野です。トレタのインフラはEngineyardでワオワオやってたんですが、あの、なんていうのAurora?それを使いたかったわけです。 さて、私が書いた前々回の記事にて、「コア機能のAWS化」を今後のTODOとして挙げていましたが、5/9にEngineyardからAWSへの移設が完了していました。EngineyardはRailsやnodejsなどのWEB-DB環境を簡単に構築できるPaaSです。Herokuとの違いはサーバにsshしたり、chefを利用してFluentdなどのミドルウェアを入れたり、既存のコンフィグレーションをカスタマイズしたりすることができる点が挙げられます。比較的自由度の高いPaaSと言えるでしょう。トレタでは創業〜先月までお世話になりました。 今回は移設とAuroraの運用に関するTipsの紹介になります。なお、本記事に示す設計・運用方針はAWSのソリューショ
Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料 - RDS for MySQL から Aurora への移行に関する共有 事前に読んでおくべき資料 - Amazon re:Invent (DAT405) Amazon Aurora Deep Dive http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive - AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora - RDS for AuroraとRDS for MySQL5.6のPar
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照/更新クエリを実行しています デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く