今日のお題「運用時のデータが壊れた場合の対策」
壊れるとは
- ディスクが壊れるなどで物理的に壊れる
- 書き込んでいた際に途中でサーバクラッシュなどで文字列が途中までしか保存できないなど論理的に壊れる
の2種類がある
RDBMSの対策
- レプリケーションなどでデータを複数台に保持する事で同時に壊れる確率を下げている。
→サーバ費用などのコストがかかったり、帯域を消費するため多ければ良いというものではない。ちょうど良いところに調整が必要。
→物理的に壊れない対策 - トランザクションなどで中途半端なものは登録しない。
→論理的には壊れない対策
全文検索エンジンの対策
トランザクションに対応していないものが多いので論理的に壊れる可能性がある。
対応方法
- バックアップとっておいて問題が発生したら戻す
→バックアップを取得してから障害が発生した際のデータが消失する可能性がある。 - マスターデータを別に用意しておいて0から復旧する
→時間がかかるがデータは全て復旧可能
Groongaの対策
同様にトランザクションが無いので論理的に壊れる可能性がある。
Groonga単体対応方法
マスターデータを用意する。
- 順次作るよりも0から作る際に早くなるモードがある
- 他のサービスよりも書き込みが早いのでこの方法をとる事が多い。
GroongaはRDBMSのライブラリとして利用できるのでRDBMSを利用する際はRDBMSの仕組みを利用できる
- MySQLの場合
- InnoDBをマスター、MroongaをSlaveとすることでマスターからの復旧が行える。
- Groongaではデータ+インデックスの両方を管理している
- PostgresSQLの場合
- Postgresのレプリケーションは物理的な更新位置を渡すような仕組みのためGroongaでデータが更新されたことを検知できないためGroongaにはインデックスだけを保持している。スレーブからREINDEXすることでデータを反映させる。
その他メモ
-
バックアップとしてスレーブを増やすと全台を運用で使いたくなるが
スレーブが落ちた際にサービスに影響が出る可能性があるので
全体だ動いている前提の設計はしない事。 -
Groongaのポリシーは新しい情報程重要(書き込んでいても検索時にはロックをかけないので検索性能が落ちない)
-
Mroongaを使うと参照性能を上げられる
-
Mroongaが死ぬとMySQLが落ちることがあるのでインスタンスを分けた方が良い
-
Mroongaのスレーブは、マスターからもスレーブのMroongaからのどちらからも作成できる。
-
Groongaのレプリケーション機能があるDroongaというプロダクトがある