とあるAuroraクラスタの、完全なデータコピーかつ最新データも元クラスタからレプリケーションで反映し続けるクラスタって作れるのかなーと調べてみると、公式のユーザーガイドにも一般情報にも見つからないしで、裏技臭がしたので書き留めておきます。 実はわりと常識レベルだったりしたらゴメンナサイって感じですが・・・おそらく仕様変更など入らず、ずっと使い続けられるテクニックだと推測できる内容であります。それでは、Auroraクラスタの完全コピーを作りたくなった理由も含めて、まとめていきたいと思います。 Auroraの基本的なレプリケーション Auroraの復習ですが、Writer(=Master) と Reader(≒Slave) は共通のディスクを利用することで、極小さな遅延（10-20ms）でのデータ共通化を実現しています。なので、Writer/Reader間は従来のbinlogを用いたMySQ
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の技術に関して多くの質問をいただいています。私は自分の意見を明らかにすることを決心しました。個人の実際に手を動かした経験に勝るものはありませんし、それを共有しようと思います。 私がこれから言及する資料
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Aurora - Looking Deeper
