ココまでできるの！？Amebaを支えるMySQLシステム構築
というお題目でのデータベースセッション。
＜アジェンダ＞
1.レプリケーション
データベースの運用でI/O負荷が問題でSELECTのレスが低下する。
解決としてI/O分散のためスケールアップすることで簡単に解決できるが
コストがかかる。
データベースの改善策として、SQLのチューニング、インデックスの見直し
レプリケーションを利用した分散。
MySQLの特徴として、レプリケーション機能で簡単に負荷分散できる。
1-1.レプリケーションを利用した分散について
スキーマ別やテーブル別でSlaveサーバを構築。
スキーマ別での分散は「アメばた会議」で利用。
テーブル別での分散は「ブログ」、「なう」など多くのサービスで利用。
1-2.用途に合わせたレプリケーション
導入からテーブル分割する必要はないが、設計段階からスケールアウト
できる設計すれば迅速対応できる。
データ量が多くなるテーブル同士でのJOINはさける。
1-3.レプリケーションを効果的に使うための設計
1-4.ストレージエンジンとレプリケーション
トランザクションを必要とする更新=>InnoDB
SELECT発行が多い場合は、Slaveサーバのストレージエンジンを
Memoryエンジンにすることで、パフォーマンスが出る。
Memoryエンジンは、データ、インデックスをメモリ上で管理するので
書き込み、読み込み共に、最もはやい。ただし、Memoryエンジンは
MySQLの再起動でデータが消えてしまうので再起動方法や障害時の
データ復旧など予め考えておくことが必要。
ピグでMemoryエンジンを使用。
Masterサーバには不要な履歴などのテーブルがある場合はBlackHoleエンジン
MasterサーバのI/O負荷を軽減できる。<=参照はSlaveでするから。
MasterのDisk容量を確保、I/Oを減らせる。
1-5.多階層のレプリケーション
ブログのデータをマイページ、プロフィールで使うなど。
データセンターが違うとき。
2.MySQLの運用
監視サーバからケータイにメール。
MySQLサーバでは、PING監視、PORT監視、レプリケーション監視、
RAID監視を行っている。ツールは「mon」。
「mon」はデフォルトでPING、PORT監視をするコマンドがある。
レプリケーション監視については、独自に作成。
レプリケーション監視にはMySQLコマンドと「SNMP」を使用。
SHOW SLAVE STATUS
2-1.バックアップ
mysqldumpでのバックアップは一般的だが、リストアに時間がかかるし、
使える保証がない。
LVM2 スナップショット機能でバックアップ。
2-2.障害監視
障害監視ツール「mon」以外に「Negios」を使用して
”Load Average”と”Diskの使用率”も監視しています。
2-3.性能監視
主にLoad Average、トラフィック量、Disk I/O、Memory使用量
Disk使用量、レプリケーション遅延、vmstat
3.今後の取り組み
新しいMySQLのバージョンの検証。ストレージエンジンのパフォーマンス
サードパーティー系のストレージエンジン。
KeyValue型の検証。
メモ：
Amebaでは年50台増えている。
DBサーバーは今は250台くらい。
ほぼすべてをmysqlで運用。
SQL発行回数2500回/secを超えたら詰まった。
監視を強化
3秒はスローログとする。
2500回/secを超えたら詰まったのは、
IBM/X336
4コアサーバでやっている。
DELL/R300
ではそれ以上だった。
XenでやったらI/Oがよろしくないから仮想やってない＝単体サーバ。
アメブロはオラクルとハイブリッド。
現在使っているMySQLのバージョンは4.1.21と5.0系
5.1はバグが多いと。