AWS Aurora MySQLには、高性能を期待できる Parallel Query という機能があります。 実際、良いモノっぽいのですが、非常に情報が少ないので私めがいつものように掘り下げて、お役に立てればという徳を積む行為であります。 目次 Parallel Query とは リンク集 速度比較 費用の仕組み 設定による有効・無効 有効にできない条件 Parallel判定されるクエリ 結合クエリ innodb_buffer_pool_size との関係 その他 実践では Parallel Query とは 詳しくは下記リンクを見たほうがいいのですが、頑張って要約してみます。 通常のDB処理は、データを可能な限りメモリ上に置いておいて処理しようとしますが、オンメモリじゃないデータはストレージから取得する必要があり、データ取得後はDB本体における１スレッドがクエリ処理を行います。 Aur

RDS Auroraを使っているところで、OSの空きメモリが少なくなったアラートが出たので、それについて細かく考察したら、それなりの量になったのでまとめた感じです。 別にAuroraじゃなくRDS MySQLでも、MySQL Serverでも同じ話なのですが、クラウドならではの側面もあるなということでタイトルはRDSにしております。 RDSのメトリクス監視 RDSはブラックボックスとはいえ、必要なメトリクスはだいたい揃っているので、CloudWatch を見たり……APIで取得してどっかに送りつけたりして利用します。 なので、まずは接続数とメモリについて復習です。 SHOW STATUS 的には Threads_connected です。 CloudWatch Metrics 的には、DBInstanceIdentifier → DatabaseConnections です。 見た感じ、ど

久々にAuroraについて、小ネタ系で書いてみるテスト。 主にストレージIOPSにまつわるTipsで、光り輝くモノは別にないですけど、基本が大事ということで。 ストレージIOPSのグラフ生成 データベースの運用において、監視データであるメトリクスを色々収集するのは基本ですが、その中でも最重要に位置する項目である ストレージのIOPS についてです。 まず、Auroraのストレージ構成は共有型であり、IOPSメトリクスはホスト毎ではなくクラスタ毎のデータとして記録されています。 参考ページ Aurora ストレージエンジンのご紹介 Amazon Aurora DB クラスターメトリクスのモニタリング RDS Aurora の管理画面でモニタリングを見ると、グラフ名が [請求済み] ボリューム読み取り IOPS (カウント) [請求済み] ボリューム書き込み IOPS (カウント) となってい

年明けからAuroraに粘着し続けて４記事目、残りカスのような数値を記録しておきます。 RDS/Auroraは起動時間がそんなに早くないですが、スナップショットからの復元は特に遅いと感じたので、データ容量との関係を調べておきました。 スナップショットからの復元時間 いざという時・・・のためでもありますが、より機会が多いであろうテスト用に起動する時のためにも、何GBならだいたい何分で起動するのかを知っておくと、運用上健康的ですよね、ということで。Auroraの管理画面で、進行％を出してくれると最高なんですが、まぁそこまで要求するのもアレなんで、、（ﾁﾗｯ）ただデータを増やして起動するという、不毛気味な検証というかデータ採取をしてみました。 sysbench と INSERT ～ SELECT でデータ容量を倍増させてはスナップショットを取得。そして１つずつ起動時間を計測していきました。 起動

よく、Auroraを採用しました、安定しています、移行してよかったです！とか見かけますけど、 なんで快適なのかをちゃんとわかって使ってんのかこの野郎ッp(｀･ω･´ﾒ)q 俺も全然わかってねぇッ( ･`ω･´) ということで、今回もいい感じに飽きてきたAuroraです。Aurora。少々気になっていた、ALTER TABLE周りについて興味深い数値が取れたので、その共有で御座います候。 MySQL5.6互換 AuroraはMySQL5.6互換というけれど・・・ Q:「MySQL と互換性がある」とはどういう意味ですか? これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB スト

前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは３種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ

とあるAuroraクラスタの、完全なデータコピーかつ最新データも元クラスタからレプリケーションで反映し続けるクラスタって作れるのかなーと調べてみると、公式のユーザーガイドにも一般情報にも見つからないしで、裏技臭がしたので書き留めておきます。 実はわりと常識レベルだったりしたらゴメンナサイって感じですが・・・おそらく仕様変更など入らず、ずっと使い続けられるテクニックだと推測できる内容であります。それでは、Auroraクラスタの完全コピーを作りたくなった理由も含めて、まとめていきたいと思います。 Auroraの基本的なレプリケーション Auroraの復習ですが、Writer(=Master) と Reader(≒Slave) は共通のディスクを利用することで、極小さな遅延（10-20ms）でのデータ共通化を実現しています。なので、Writer/Reader間は従来のbinlogを用いたMySQ

Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ

前回、無様にも記事公開直前にRDSのMultiAZ分の検証が足りないことに気づいたものの、その時点では飽きてゲッソリしていたので、追試験する気力もなくゴメンナサイしてポチッてしまいました。が、やはり思い直しまして、というか自分でも気になるところなので、恥を忍んでRDSのMultiAZ版のデータも取得して比較考察してみることにしましたウェーイ（ごまかし）。 すぐに取り掛からなかったのは、息子の専用部屋を増やすために同マンション内での引っ越しをしていたからです（近況報告）。それでは、参りましょう。 RDS MultiAZのデータと考察 同期構成についての考察なので、前回データから一部非同期系を削除し、RDS MultiAZのデータを追加（赤枠）しました。 また、結果が思ったよりアレだったので、再びSingleAZでも実行してみましたが、結果はほぼ前回と同じだったのでそのままにしてあります。 R

CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し