In The Works – Amazon Aurora Serverless | Amazon Web Services
Amazon Web Services ブログ In The Works – Amazon Aurora Serverless 既にご存知の通り、Amazon AuroraはMySQL互換とPostgreSQL互換があり、マネージドサービスで自動的に64TBまでスケールアップするデータベースストレージ’を備えています。Auroraデータベースインスタンスを作成する際に必要なインスタンスサイズの選択や、リードスループットを向上させるためにリードレプリカを作成するかどうかのオプションを選択します。処理の需要やクエリ数の増減に応じて、インスタンスサイズやリードレプリカの数を必要に応じて変更可能です。このモデルはリクエスト数や負荷などのワークロードが予測し易い場合はうまくいきます。 しかし、場合によっては1日や1週間の間に数時間、もしくは数分間だけリクエストがスパイクするようなワークロードの割り込
Aurora のスロークエリログを Fluentd 経由で Amazon Elasticsearch Service に転送する - kakakakakku blog
Aurora でスロークエリログを出力して，Fluentd 経由で Amazon Elasticsearch Service に転送する構成を作った．MySQL on EC2 のときは，サーバ内で直接スロークエリログを確認していて非常に面倒だったので（単なる運用上の考慮不足），運用面で大きく改善できるし，アプリケーションエンジニアも自由に Kibana で確認できるため，パフォーマンス改善が捗ると思う．非常に良い． アーキテクチャ図 Aurora インスタンスパラメータ デフォルトのインスタンスパラメータではスロークエリログは有効になっていないため，パラメータを変更する必要がある．今回はスロークエリログを有効にするだけではなく，デフォルトで10秒になっている閾値を5秒に変更した． パラメータ名 Before After slow_query_log <engine-default> 1 l
Aurora のパラメータグループで max_connections の値が計算値と合わない - kakakakakku blog
最近 Aurora の検証をしているので，今後は Aurora 関連の記事を書く機会が増えそう． 前提 RDS (Aurora MySQL) インスタンスタイプ : db.t2.medium DBInstanceClassMemory とは RDS のパラメータグループでは，特定の変数と演算子を使った動的な値設定ができる．今回は変数 DBInstanceClassMemory に関して調べたことと，計算が合わずに困ったことを書いておこうと思う． DBInstanceClassMemory は，名前だけを見るとインスタンスタイプごとに搭載されたメモリサイズのように思えるけど，実際には違っていて，RDS プロセスに割り当てられたメモリサイズのことを意味する．よって，搭載されたメモリサイズよりは確実に小さい値となる．その点はドキュメントにも書いてある． DBInstanceClassMemory
AuroraのALTER TABLE性能検証とRDS比較 | 外道父の匠
よく、Auroraを採用しました、安定しています、移行してよかったです！とか見かけますけど、 なんで快適なのかをちゃんとわかって使ってんのかこの野郎ッp(｀･ω･´ﾒ)q 俺も全然わかってねぇッ( ･`ω･´) ということで、今回もいい感じに飽きてきたAuroraです。Aurora。少々気になっていた、ALTER TABLE周りについて興味深い数値が取れたので、その共有で御座います候。 MySQL5.6互換 AuroraはMySQL5.6互換というけれど・・・ Q:「MySQL と互換性がある」とはどういう意味ですか? これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB スト
Auroraの各種エンドポイントとダウンタイムの検証 | 外道父の匠
前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは３種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ
48時間後… - DELiGHTWORKS Developers Blog
こちらは48時間後に突然サービスが瞬断される状況が頻発し、生きた心地がしなかった、という備忘録です。 AWS Summitでお話しさせて戴いたAWSへの移行ですが、その中にAuroraは出てきませんでした。しかし、実際にはFate/Grand Orderは一度Auroraへ移行をしていました。そして、再度RDSに切り戻しています。 こちらに関して既に問題は解決してはいるのですが、こんなこともあったということで知見を共有させていただきます。 4月末、私たちはRDS(MySQL)をAuroraへ移行しておりました。これはDBの分割前に行った対策になり、暫くは問題無く稼働していました。 しかし、稼働から48時間後突然のスパイク（アクセス障害）が訪れました。これに関してはまさに「この瞬間には何もしていない」のに発生したスパイクで、アクセス数が急増した訳でもなかったため、解決には非常に困難を極めまし
AWS Auroraよもやま話
12. まちかまえている（？）こと • パラメータ • Query Cache • CPU • Replicaとmigration • ReplicaのReboot • Replica lag spike
最強のDBを求めて、AWSのAuroraとMySQL5.7とGCPのGQLのv1,v2を比較し直してみた - Qiita
もう一度最強のDBを求めて 前回まで MySQL5.7 > Aurora 遅いと噂のGQL > RDS と、上のような結果が出てみたもののどうにも自分で調べておいて検証結果が信用できない。 データ容量と同時接続数を増やしてみてもう一度チャレンジしてみた。 検証方法 sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 prepare sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 --num-threads=XXX --oltp-read-only=off run 取りあえず手軽に試してみたかったので、sysbenchで実行してみる。 登録データ件数は1億件。容量にして約20GB。 同時接続数を4→8→16→32→64と増やし
AuroraとRDS MySQL 5.7のsysbench - Qiita
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
Amazon Aurora : パラメーターから見るその詳細(Percona Data Performance Blogより) | Yakst
Amazon Aurora : パラメーターから見るその詳細(Percona Data Performance Blogより) 出典について この記事はPercona Data Performance Blog内のVadim Tkachenko氏によるAmazon Aurora – Looking Deeper(2015/11/16)を翻訳したものです。 最近、私のPerconaの同僚であるYves Trudeauと業界の仲間であるMarco TusaがAmazon Auroraに関する記事を発表しました。実際のところ、Amazon Auroraは最近のホットな話題で、お客様からもAuroraの技術に関して多くの質問をいただいています。私は自分の意見を明らかにすることを決心しました。個人の実際に手を動かした経験に勝るものはありませんし、それを共有しようと思います。 私がこれから言及する資料
Nice to meet you Aurora!!
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
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
Amazon Aurora/MariaDB/MySQLの違いを整理してみる #reinvent | DevelopersIO
日本にいます西澤です。ついに東京リージョンにやってきたAuroraに加えて、MariaDBもRDSで利用が可能となりました！ちょっと選択肢が増えすぎて違いがわからなくなってきたので、情報を整理してみたいと思います。 ついに！Amazon Auroraが東京リージョンに来ました！ #reinvent 【速報】Amazon RDSが新たに「MariaDB」に対応しました！ #reinvent MariaDB on Amazon RDSを触ってみた #reinvent RDS for MariaDBへのレプリケーション #reinvent Specify DB Details Launch時に指定する項目から、違いがあるところだけ整理していきます。Aurora、MariaDBもt2インスタンス等で検証ができるようになると良いですね。特筆すべきは、Auroraの可用性(自動復旧するし、ディスクは自
ベンチマークシリーズ Aurora vs MySQL 結果まとめ
* ベンチマークシリーズ Aurora vs MySQL 結果まとめ ** 結果比較 - Connection数別トランザクション/分 Conn Aurora MySQL 20 6279.833 TpmC 6829.467 TpmC 30 8390.400 TpmC 1374.767 TpmC 50 11216.900 TpmC 1913.100 TpmC 70 14481.650 TpmC 2498.600 TpmC 100 14155.450 TpmC 2253.400 TpmC (詳細結果紛失 200 14932.350 TpmC ------- TpmC - 所感 データ投入や20Connくらいの接続数の場合、MySQLの方に分があったけれど、Conn数を増やしていくと、 Auroraがリニアにスコアを伸ばし、限界値が高いようです ※両方パラメータは吊るしの状態なためチューニング
IDCFクラウドRDBとAWS RDS, Auroraのベンチマーク | 稲葉サーバーデザイン
※RDS for AuroraのDB月額料金は、ストレージ100GB使用を想定、I/O料金は含まない。 sysbenchの実行条件 sysbench OLTPテストを行う。 sysbenchのバージョンは0.4.12.7。 スレッド数4, 16, 64, 128, 256のそれぞれについて、読み込みのみ(Read Only)と読み書き(Read-Write)の2パターンのテストを行う。 テストパターンごとに、データレコードの作成→キャッシュに載せるため、プレウォームでスレッド数16 Read Onlyのテストを実行→テストパターンの実行→データレコードの削除を行う。 テスト用レコード数は100万、最大実行時間は2分。 テスト実行コマンド例は次のとおりです（スレッド数4、Read-Writeテストの場合）。 $ sysbench --test=oltp \ --oltp-test-mode=
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn-ak-scissors.b.st-hatena.com/image/square/621590b3c7ee9e3370b81c3dfc99d0d34c4e6c55/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Famazonauroratips-170307140000-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Zaim 500万ユーザに向けて〜Aurora 編〜
https://qiita.com/winebarrel/items/fe0d844f4eaec5c93b73
日本のお客様におけるAmazon Auroraへの移行・検証事例と技術ポイント
AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora