月別アーカイブ: 2013年9月

DBのレプリケーションの話

こんにちは^^;しょうたんです。
今回はDBのレプリケーションの概要と注意点を手短にお話したいと思います。
何かと1から説明する事が多いので、DBを触るエンジニアでなければイメージしにくい世界なんだと思います。

まず、レプリケーションで何をしたいかですが、要は負荷分散したいわけです。
masterのDBの複製としてslaveのDBを作る事で負荷分散します。
2つのDBで分担する事で負荷を軽減できます、これはイメージしやすいと思います。

大事なのは検索クエリ(select)は単純に分散できるけど、更新クエリ(update,insert,delete)はどうすればいいの?という事です。更新クエリまで分散してしまったら、2つのDBでデータにズレが出てしまいます。
その為、DBのレプリケーションでは更新をmasterのDBに限定して、masterのDBに変更があれば後でslaveのDBへ書き込みます。結果的にレプリケーションのデータ書き込みは非同期となります。

このレプリケーションでDB運用は完璧かと思いきや、運用しているといずれ2つの問題が発生します。

①一つのmasterのDBへの書き込みでディスクI/Oの負荷が上がる。
よくとられる対処として、ディスクI/Oの対策となるハードに交換する等のスケールアップか、
masterのDB自体を分割し複数master構成にするスケールアウトが対処として考えられます。

②slaveのDBへ書き込みが出来なかった場合にデータがズレる
DB不整合と呼ばれるもので、DBアクセスを止めた後にレプリケーション再開する処置が必要になります。
構成によっては、DBアクセスを止める為にWEBサーバをメンテナンス表示しなければなりません。

データ完全同期の技術としては、レプリケーションとは別の構造で「クラスタリング」がありますが、
レプリケーションと同じく有用な冗長化技術なのでいずれ投稿したいと思います。

今回は以上です ~ お疲れさまでした★