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.
Hori Blogフリーランスでバックエンドエンジニアとして活動している Ryota Hori のブログです。 最近はテック系記事より雑記ブログ気味。 Amazon Aurora 事例祭り に行ってきたので、メモを公開します。 社内共有で Slack に貼ろうと思っていたメモなのですが、長くなったのでブログに公開します。 概要 Amazon Aurora 事例祭り (2017 年 3 月 7 日開催) | AWS セッション内容 Amazon Aurora を使いこなすためのベストプラクティスと最新アップデート @con_mame さん データベースソリューションアーキテクト 登壇資料: [Aurora 事例祭り]Amazon Aurora を使いこなすためのベストプラクティス 開発サイドからの知見と今後の展望 PostgreSQL For Aurora でるよ! 9.6.4 と互換 My
概要 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というエンドポイントが提供され、フェイルオーバーを実装することができます。しかし、
MariaDB Connector/J has evolved a lot during the year. In this post I will talk about the failover capabilities in the connector and give some guidance on how to use them in some certain cases. One other important new feature that I’ll cover in a later article is the fact that MariaDB Connector/J can do load balancing over several servers now as well. To start off with we’ll need the connector its
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つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
Google、MySQL互換の第二世代「Cloud SQL」正式リリース。ベンチマークを公開し、Amazon Auroraより高速だとアピール Googleは、Google Cloud Platformで提供しているマネージドサービスのMySQL互換データベースである「Cloud SQL」を正式版としてリリースしました。 Cloud SQLは2011年に発表され、2015年12月には性能を強化した第二世代が登場、最大10テラバイトのデータ容量とインスタンスあたり最大104GBメモリを提供し、最大2万IOPSの性能に達すると説明されていました。 正式版リリースにあたり、同社はブログ「Google Cloud Platform Blog: Cloud SQL Second Generation performance and feature deep dive」で競合となるAmazonクラウド
Amazon Auroraの運用について プレビュー版のAmazon Aurora使えるようになったので色々試しています。新しいDBエンジンということで、運用をどうするか気になっている方も多いのではないでしょうか。Amazon Auroraは、RDSの他のデータベースエンジンと同じように、CloudWatchで運用状況をモニタリングすることができます。これにより、正常稼働しているか、期待するパフォーマンスが出ているか確認することができますので、アラームを設定して運用に役立てることができます。 AuroraのDBクラスタ概念図 Aurora Metricsの種類 Auroraは、大きく分けて2種類の情報があります。Aurora System Monitoringと、Aurora SQL Monitoringです。前者は、ネットワーク/ディスク/CPUなどのシステムに関するモニタリングで、後者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く