RDSは1秒未満のスロークエリを記録できない。そこでmin_examined_row_limit

1以上のintegerですね。RT @hiroohi: あれ？RDS(mysql)のParameterGroupって、long_query_timeは1秒以上しか設定できない？ #jawsug

— ARAKI Yasuhiroさん (@ar1) 6月 13, 2012

いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。

そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。

漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ

min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全体の性能を劣化させる危険性があるので、long_query_timeを少し大きめにしておいて、このオプションを併用しておくといいだろう。例えばmin_examined_row_limit=10000など。いずれの変数もアプリケーションの特性に合わせて調節して欲しい。

これをRDSで一発でやるなら

$ rds-modify-db-parameter-group sweet-parameter-group --parameters "name=slow_query_log, value=ON, method=immediate" --parameters "name=long_query_time, value=1, method=immediate" --parameters "name=min_examined_row_limit, value=10000, method=immediate"

といった具合になる。

マイクロDBインスタンスのRDSのアレな活用

【AWS発表】Amazon RDS MySQL を月26ドルで! マイクロDBインスタンスが利用可能に! 

ということで、安くRDSを使うことができる。ただし、マイクロインスタンスなのでどうしようもなく遅い。耐えられないくらい正直遅い。

が、それを逆手にとった活用法がある。

それはスロークエリの検出。

MySQL Enterprise EditionとRDS

散々Amazon RDS for MySQLなるMySQLサービスを売っているのだが、それでもMySQL Enterprise Editionはすばらしい製品に見える。

違いをメモってみるか。ちなみにRDSはMySQL community edition.

• MySQL Enterprise Backup: これはRDSはバックアップの仕組み(snapshot)もあるしポイントインタイムリカバリもあるからいいか
• MySQL Enterprise Monitor: MySQL Query Analyzerいいなあ。RDSにないし。
• MySQL Workbench: 管理ツールはまあRDSにはいらないのかもしれない。
• MySQL Enterprise Security: LDAPやAD連携なんかはいいよね。RDSにもあっていいね。
• MySQL Enterprise Scalability: スレッドプールは圧倒的だよね。。
• MySQL Premier Support: @nippondanjiのサポートうけてみたいよね。。(#やっているかは知りません)

そんなわけで、欲しいものはまだまだあるのであった。

NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較 など。

NHNテクノロジーカンファレンスにいってきた。

DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。

"Mobage DBA Fight against Big Data" - NHN TE [slideshare id=12990643&w=425&h=355]

View more presentations from riywo

実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。

このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。

サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。

RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなインスタンスに設定を変更する。詳細はFAQの#20を参照。

「バックアップ」サーバ。マスタおちたときのレプリ昇格用。デイリーのバックアップ用。サービスからは参照されていないただのスレーブ。デイリーバックアップは人のすくない朝3時とかにmysqldump

RDSの場合は、http://aws.amazon.com/jp/rds/faqs/#23 にあるように、デイリーの自動化バックアップと、任意のタイミングでのデータベース スナップショットを提供している。

MHAでは、データの整合性をたもち、スプリットブレインがおこらないように、マスタ切り替え。IPのきりかえまでもやってくれる。夜中におちても切り替え時間だけの停止。計画的に使うこともできる。

RDSであれば、可用性向上のためにさらにMulti-AZオプションが使える。http://aws.amazon.com/jp/rds/faqs/#36 にあるように、Amazon RDS は別の Availability Zone において同期する、「スタンバイ」レプリカを自動的に設定して管理します。DBインスタンスに対する更新は、複数の Availability Zone 全体において、スタンバイに対して同時にレプリケーションされます。

フェイルオーバー時、Amazon RDS は単純に DB インスタンスの正規名レコード（CNAME）を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。DBサイズにもよりますが、3分以内で復旧します。

ここまでいいことを書いたけど、RDSでは絶対にできないことは、お客様側のアプリで対応しないといけないこと。そしてInnodb以外を使うこと。というわけで、次の2つはさすがのDeNAの総合力といったところだろうか。

UPDATEの最近の命題。ロックをどれだけ短かくするか。ソシャゲは綺麗なもんばかりじゃないのでデッドロックはおこる。そこでロックの順番をアプリで管理させる(理想) or バージョンをつかって楽観ロック 

プライマリキーでのSELECTの機会は多い。そこでHandler socketの登場。SQLパーサをはぶけるので速くなる解説。