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

1. 1サーバで複数プロセス起動して対応している
2. MySQLはマスタを1つしか指定ができない
3. 仮想IPアドレスを割り当て、それのみ、LISTENするようにする(my.cnf)
4. ポートを変える方法は、ポート管理が大変
5. アプリケーション側で変更がなくなるので、仮想IPアドレスの方法を行なっている

Databackup

1. ただのスレーブ。サービスに入っていない
2. mysqldumpで行なっている
3. それを使って、slaveをいつでも作ることができる
4. slaveの追加が、サービスに影響を与えずできる

MHA

1. マスタが落ちた際に、自動で、マスタ昇格するスクリプト

Big Data

Purge

1. よくあるものは、古いデータを消す
2. 古いバージョンでは、DELETEで消していく方法しかなかった
3. DELETEは重い処理
4. 5.1以降では、パーティション機能でテーブルによっては、簡単に削除できるようになった
5. range partition を使えば簡単に削除できる
6. drop table と同じ感覚

High Traffic

1. Range Scan は気をつけるべき
2. Primary KeyでSELECTすることが多い
3. Handler socket plugin (made by higuchi)
4. Too many UPDATE
5. ロックの時間をできるだけ短くする
6. SINが落ちることはある
7. コネクションをはったあとでロックしていく
8. いろんなマスタに対し、1回で更新を行いたい
9. 1つのサーバで発生した場合は、検知ができるが、複数サーバで発生した場合は、設定ファイルで回避するしかない。→時間がかかる
10. まずは、デッドロックが起きないようにするチューニング
11. 楽観的ロック。バージョンカラムというものを用意する
12. 更新するときに、バージョンカラムを更新する
13. レプリケーション遅延が起きてしまう
14. その遅延をどのようにして計測するか
15. バックアップサーバは、スレーブよりスペックが低いことが多い
16. バックアップサーバで遅延が発生したら、スレーブでも発生するだろうという考え
17. バックアップサーバの状態を確認し、チューニングしていく
18. SSD は、レプリケーション遅延が発生しにくい
19. レプリケーションは、1スレッドで行うため、どうしても遅延しやすい
20. HDDでは遅延するが、SSDでは余裕というケースは多々ある
21. SATA-SSD is good
22. SAS-SSD は、現時点ではまだ使えるレベルではないと考えている