debiancdn

AWS, Content Delivery Network and Debian

カテゴリーアーカイブ: mysql

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

いろんな人に言われることではあるが、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運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。

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

このセッションでは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パーサをはぶけるので速くなる解説。

 

ScalebaseによるMySQLのホワイトペーパ

http://www.scalebase.com/downloads/MySQL%20Scaling%20Strategies.pdf

MySQLのシャーディングやHA化とは人類の夢。あわせて低価格化も。それでいてサポートをほしいとなれば選択肢は多くない。

MySQLのシャーディングといえば、http://spiderformysql.com/ がすぐに浮かぶ日本人でも、それ以外を網羅的に書いているのでぜひ一読をおすすめする。

mysql5.1にupgradeしたらmysql5.0でつかえてたテーブルが使えなくなったので,結局dumpしなおした.

結論を言うと

mysql5.1にupgradeしたらmysql5.0でつかえてたテーブルが使えなくなったので,結局dumpしなおした.

ということなのでした.

なんかmysqlがうごかんので,show databasesをしてみたら"#mysql50"という表示が出る.

mysql> show databases
    -> ;
+-------------------------------------+
| Database                            |
+-------------------------------------+
| information_schema                  |
| #mysql50#donrails-trunk_development |
| #mysql50#donrails-trunk_production  |
| #mysql50#donrails-trunk_test        |
| mlabcms                             |
| mysql                               |
| snf_development                     |
| test                                |
+-------------------------------------+

どうやら,"#mysql50#"という表示は,

http://dev.mysql.com/doc/refman/5.1/ja/identifiers.html

MySQL 5.1.6より、データベース名とテーブル名内の特殊文字は項8.2.3. 「ファイル名への識別子のマッピング」で記述されているとおり、対応するファイルシステム名にコード化されています。旧バージョンのMySQLを使用していて、で特殊文字を含むデータベース名やテーブル名が新しいエンコーディングに対応するようアップデートされていない場合、#mysql50#が接頭に表示されます。そういった名称を検索、もしくはそれらを新しいエンコーディングに変換するには、そのセクションを参照してください。

ということで

特殊な接頭辞を使用する必要を無くすため、旧名をアップデートするには、mysqlcheckで再エンコードしてください。次のコマンドは全ての名前を新エンコーディングにアップデートします。

 shell> mysqlcheck --check-upgrade --all-databases

をかませばいいらしい.

出力

#mysql50#donrails-trunk_development.authors
error    : Table upgrade required. Please do "REPAIR TABLE `authors`" or dump/reload to fix it!

こんなのが出た.

–auto-repair

チェックされたテーブルが破壊されていた場合、自動的に修復します。必要な修復は全てのテーブルがチェックされた後に実行されます。

なるものがあるので試してみた.

Repairing tables
#mysql50#donrails-trunk_development.authors
note     : The storage engine for the table doesn't support repair

あれれ,

 show create table テーブル名;

で,ストレージエンジン確認.

 ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8

とでてるな.InnoDBは対応してないのか?

AUTO_INCREMENTが悪さをしてるんだろうか.まあdumpして復帰.

DB2祭り開始

というかやっと! 仕事でミーティング地獄と付随する資料つくり地獄がおわった,,というかやっとロードが下がったので,やらなければならないDB2まわりに手をつけはじめる.
DB2は過去になぜかLinux ConfでIBMからいただいたフルライセンスがあるので何の問題もないのだが,DB2-expressで.とっと実装おえたい.が,きっとものすごく時間がかかるよてい.とっととおわらせて7.1までにpaperかかんと..

そして移行のためにrake db:migrate

donrailsではながいことmigrate機能をつかってこなかった。これは

  • donrailsをはじめたころにはそんなもんなかった
  • migrateは当初sqlite、sqlite3に未対応
  • donrailsというか私はそれをつかっていた

という理由だったのだがすべて解決し、今やOracleでもMSSQLでもmigrateできてしまうのでこれを使うことにした。

最初からmigrateをつかっていればはまらなかったのだが、不幸にも私ははまるケースで、

 rake db:migrate

をすると、なんと使っていたテーブル(とその内容)が消えてしまう現象が。

いろいろ疑ったり試したりした結果、production -> developmentにcopyしてdevelopmentでmigrateしたあとでdatabase.ymlをかきかえという方法で対応することにした。

 $ mysqldump -t donrails_production > donrails-0712a.sql
 $ vi database.yml

して、developmentにdonrails_production2を追加

 $ mysqladmin create donrails_production2 

で、db作成

 $ rake db:migrate VERSION=1

テーブルがいろいろできる

 $ mysql donrails_production2 < /tmp/donrails-0712a.sql

元のデータをかきもどし。

ここまででokなのだが今回はついでにtableを一部変更してversion2にしないといかんので

 $ rake db:migrate VERSION=2

としてChangeHabtmToHmtを適用。

 $ vi database.yml

prodcutionにdonrails_production2をみるように書きかえる。

メモ:mysqldumpによるバックアップ

  • テーブルを作成させない形式でのバックアップ: mysqldump -t donrails_development

  • 通常のバックアップ: mysqldump donrails_development

というわけで終了

donrailsからhabtmを一掃。

rails2.0ではhas_and_belongs_to_many(habtm)がなくなってしまうので、そのための対応をやった。

具体的にはコードをみるのが速いけど、has_many:throughにするというだけでもけっこう大変で、はじめてみたらかなりの作業量になった。まあ作業のかいあって、r269からはrails2.0でも動くはず。