ある特定のテーブルに対するレプリケーションの遅延時間が、ここ数ヶ月間どんどん長くなり、場合によっては10分以上（！？）という状態になっていて困っていました。 データ量や更新頻度は、テーブルを作成した時とほぼ同じなのにどうして！と思って調べていました。 OPTIMIZE TABLEコマンドが使えそう 該当のこのテーブルは、他のテーブルと比較して、以下のような特徴があります。 データ量は多い INDEXデータサイズも大きい 更新頻度もかなり多い このあたりが、レプリケーション遅延に影響しているのだろうと思い、調べていると以下のような情報を見つけました。 optimize tableでテーブルを最適化するだけでMyISAMはパフォーマンスが格段にアップするらしい（特にデータ更新が頻繁なテーブルの場合）。 MySQLとオープンソースに捧げる毎日:MySQLの管理など - livedoor Blog

CTOの椎名アマド ( @ima_amataro) です。 前回の記事：「Pairy : チャットデータを Redis から Amazon DynamoDB に全移行した話（１）」 前回はRedisをチャットのプライマリのストレージとして使う上での問題点と、 Amazon DynamoDB の特徴などを紹介しました。 今回はDynamoDBの詳細説明と、実際の移行作業と、その際にハマった点をお話していきます。 DynamoDBのテーブル構成 まずは DynamoDB 上のテーブル構成を考えるところから。 Redisにおいてはシンプルな list にチャットを保存していて、 chat.room.{room_id} {timestamp}:{user_id}:{urlencode(message)} {timestamp}:{user_id}:{urlencode(message)} {tim

CTOの椎名アマドです。 今回は、Pairyのチャットデータを全てRedisからAmazon DynamoDBに移行した話をしたいと思います。 我々が 2012年6月に カップル専用アプリ Pairy をリリースした時には、 データベースは MySQL と Redis の両方を利用するところで始めました。 Redis の役割は： 1. MySQLレスポンスのキャッシュ 2. プッシュ通知等のキュー 3. チャットのデータを全保管 サービスローンチ直後はまだ Appサーバー(EC2)１台と、MySQL & Redisを両方走らせてる DBサーバー(EC2)１台で十分だという判断で、しばらくはそんな構成でやってました。（S3などは省略） しかし、いざサービスが成長してくるともちろん MySQL & Redis を１台でまかなうのはキツくなり、MySQL と Redis を別々のEC2インスタン

MySQLはとても気ぃつかい屋さんである。我々が投げる多少あいまいな指示も頑張って解釈し、なんとか文句を言わずに実行してみようと挑戦してみてくれる。 今日はそんなMySQLがケナゲに解釈してくれる自動変換について紹介しようと思う。この自動変換、ケナゲなMySQLの奥ゆかしさ故、出した指示と異なる動作をされたことに気がつかないことがある。ここで紹介する６つの自動変換をしっかり脳ミソにたたき込んでおけば、無用なトラブルにハマる時間も減るかもしれない。 １．[数値] 範囲外の数値は頭を押さえつけられる intやsmallint、bigintなどの数値型には、扱える範囲が決まっている。例えばint型なら最大21億ちょっとだ（unsignedの場合は43億弱）。これより大きい数字を登録するよう指示を出すとMySQLはどうするか。そう、頑張って入れられるところまで入れてくれるのである。「入れられるとこ

この記事は MySQL Casual Advent Calendar 2013 の18日目の記事です。こんな記事をAdvent Calendar初日に書いちゃったので今回は別のネタで。 メモ：ENUM型をフラグにするのどうなんだろうと思った件 - rkajiyamaの日記 みんな大好きEXPLAIN文。インデックス利用の有無やファイルソートしないかの確認など、MySQLでの実行計画の確認に使う、便利なあれです。MySQL 5.6.3からは、SELECT文だけではなく、UPDATE文、DELETE文、INSERT文とREPLACE文でも使えるようになっています。 EXPLAIN文の一般的な使い方やアウトプットの見方は漢の記事が役に立つのでそっちを見てください。 ここでは小ネタを2つほど。 SQLの実行計画の確認だけじゃないEXPLAIN文 EXPLAINに続けてテーブル名を付けると、 mys