大規模ゲーム運営のポイント：データベースのチューニング
データベースのチューニングについて、正延氏は次の7つのポイントを挙げました。
1：net_slave_timeoutは短くする
スレーブサーバでは、しばしばレプリケーションが行われなくなっていることがあります。これは何らかの原因でマスターとスレーブ間のコネクションが失われたためですが、MySQLはこのことを認識しません。しかも、レプリケーション通信が行われない場合のコネクション再接続時間が、標準で3,600秒と非常に長く実質的ではありません。net_slave_timeoutの時間を短くすることで、レプリケーションが止まってもすぐに再開できるようになります。
2：max_binlog_sizeは小さくする
max_binlog_sizeはバイナリログがローテーションされるサイズのしきい値を指定しますが、標準で1GBが設定されています。しかし、これではI/O負荷が高くなり、処理の滞留が発生することがあります。この値を200～300MB程度に減らすことで1回あたりのログ削除負荷を軽減し、処理滞留を防止できます。
3：innodb_log_file_sizeは最大に
MySQL5.1＋InnoDB Plugin、あるいはMySQL5.5を使う前提では、innodb_log_file_sizeとinnodb_log_files_in_groupでInnoDBログのファイルサイズが常に最大の約4GBになっています。コナミでは、この値を標準でinnodb_log_file_size = 2047MB、innodb_log_files_in_group = 2とギリギリまで拡大しています。実際のところ、シャットダウン時のクラッシュリカバリ時間には、あまり影響しません。
4：MySQLの通信は圧縮する
MySQLサーバとの通信はプロトコルがほぼテキスト形式であるため、zlibによる圧縮が有効です。非圧縮時に比べ40％程度まで帯域を節約できます。同様に、マスターとスレーブの両方でslave_compressed_protocolを有効にすることで、レプリケーション通信も圧縮可能です。CPU負荷の上昇は影響を与えるレベルではないため、帯域が従量課金制の場合や、通信が安定しづらいクラウドサービスで非常に有効です（PHPでPDO+mysqlndの組み合わせで接続している場合、圧縮機能が実装されていません）。
5. パーティションは有効に
MySQL5.1系からパーティショニング機能が使えるようになりました。このパーティショニング機能はテーブルをIDや日次ごとなどに分割する機能ですが、この機能はバトルログなどが溜まりがちなソーシャルゲームでは非常に有効で、古いログを削除するために大量のDELETEを行う必要がありません。ただし、バグの少ない最新版を使うようにします。
6：my-innodb-heavy-4G.cnfは使わない
ソースディレクトリのsupport-filesディレクトリ内のmy.cnfテンプレートにあるものですが、OLTP系のサーバにはまったく不適です。そもそもMySQLには今となってはあまりよい設定テンプレートがついていないのですが、ベースにするのであればmy-huge.cnfがおすすめです。
7：slow_query_log_file, log-errorは必ず指定する
この2つの設定はそれぞれスロークエリログのファイル名、エラーログのファイル名を指定します。指定しないとログ名にホスト名が入ってしまうため、ログのローテーションやログ監視が煩雑になります。システムを使うにつれて響いてくるポイントです。
最後に、監視とインフラ運用のポイントを紹介します。
