3. Mobage運用技術DB編
Mobage MySQL運用
登壇者：DeNA岩永様
Many Servers
Master - Slave
critical SELECT -> master
non critical SELECT -> slave
レプリケーションは、非同期となっている。最新版は、対応できている部分もある。
Sharding
+ divide per tables ( no join )
+ record sharding (difficult range scan)
レコードで分けるのは、クライアントサイドのロジックで分ける方法と、マッピング情報を別テーブルを用意する方法がある。
hash or mapping
ScaleOut
1. auto increment
- same schema - different database
2. MyISAM sequence table
アプリケーション側で対処
Scale back
Reduce scale-outed servers
Databackup
- ただのスレーブ。サービスに入っていない
- mysqldumpで行なっている
- それを使って、slaveをいつでも作ることができる
- slaveの追加が、サービスに影響を与えずできる
MHA
- マスタが落ちた際に、自動で、マスタ昇格するスクリプト
Big Data
Purge
- よくあるものは、古いデータを消す
- 古いバージョンでは、DELETEで消していく方法しかなかった
- DELETEは重い処理
- 5.1以降では、パーティション機能でテーブルによっては、簡単に削除できるようになった
- range partition を使えば簡単に削除できる
- drop table と同じ感覚
High Traffic
- Range Scan は気をつけるべき
- Primary KeyでSELECTすることが多い
- Handler socket plugin (made by higuchi)
- Too many UPDATE
- ロックの時間をできるだけ短くする
- SINが落ちることはある
- コネクションをはったあとでロックしていく
- いろんなマスタに対し、1回で更新を行いたい
- 1つのサーバで発生した場合は、検知ができるが、複数サーバで発生した場合は、設定ファイルで回避するしかない。→時間がかかる
- まずは、デッドロックが起きないようにするチューニング
- 楽観的ロック。バージョンカラムというものを用意する
- 更新するときに、バージョンカラムを更新する
- レプリケーション遅延が起きてしまう
- その遅延をどのようにして計測するか
- バックアップサーバは、スレーブよりスペックが低いことが多い
- バックアップサーバで遅延が発生したら、スレーブでも発生するだろうという考え
- バックアップサーバの状態を確認し、チューニングしていく
- SSD は、レプリケーション遅延が発生しにくい
- レプリケーションは、1スレッドで行うため、どうしても遅延しやすい
- HDDでは遅延するが、SSDでは余裕というケースは多々ある
- SATA-SSD is good
- SAS-SSD は、現時点ではまだ使えるレベルではないと考えている
