Blog ブログ
Archive
OLDER
2018.05(1)
2018.04(1)
2018.03(2)
2017.11(2)
2017.10(1)
2017.08(1)
2017.07(4)
2017.06(3)
2017.05(2)
2017.04(3)
2017.03(2)
2017.02(2)
2017.01(2)
2016.12(3)
2016.11(3)
2016.10(3)
2016.09(3)
2016.06(2)
2016.03(1)
2016.02(1)
2016.01(2)
2015.12(4)
2015.11(1)
2015.10(3)
2015.09(3)
2015.08(3)
2015.07(2)
2015.06(6)
2015.05(2)
2015.04(2)
2015.03(5)
2015.02(8)
2015.01(2)
2014.12(4)
2014.11(2)
2014.10(1)
2014.09(1)
サーバ冗長化で実現する快適安眠ライフ! ~DBのレプリケーション~
皆様、こんにちわ。
CCSでプログラマをやっている武藤と申します。
今回も引き続き、サーバの冗長化について書いていきたいと思います。
今回のテーマは『DBのレプリケーション』です。
◆『レプリケーション』とは?
そもそもレプリケーションという単語は「複製」という意味です。
単語から察することが出来ると思いますが、データの一貫性を保った「複製」を
作成することをレプリケーションと言います。
作成することをレプリケーションと言います。
DBの観点から考えたときに、バックアップとの違いは下記のようになります。
・複製元から複製先へ、全ての更新記録を送信します。
例えば複製元で、あるテーブルが作成された場合、もしくはテーブルにレコードを
1件挿入した場合はそれらの更新が全て複製先に通知され、実行・反映されます。
1件挿入した場合はそれらの更新が全て複製先に通知され、実行・反映されます。
・複製元で障害が発生した場合でも、複製先をダウンタイムなしで利用することが
出来ます。
出来ます。
冗長なDBシステムの構成に役立つのはもちろんのこと、データ取得に利用することで
負荷分散を図ることも可能です。
◆『レプリケーション』の方式と注意点
レプリケーションには前述の「マスタスレーブ方式」と「マルチマスタ方式」の2つの方式があります。
★マスタスレーブ方式
ー 複製元をマスタ、複製先をスレーブとし、マスタからスレーブへ更新記録を
送信します。
送信します。
ー 更新命令は全てマスタが受け取るため、更新頻度が高いほどマスタへの負荷が
集中します。
集中します。
ー マスタから送信された更新命令がスレーブで処理されるまでの間
マスタ・スレーブ間でDBの内容が異なる可能性があります。
(レプリケーション遅延)
マスタ・スレーブ間でDBの内容が異なる可能性があります。
(レプリケーション遅延)
ー スレーブからマスタへは更新が同期されないため、スレーブへの命令は
検索処理のみに限定されます。
検索処理のみに限定されます。
★マルチマスタ方式
ー 全てのDBがマスタ及びスレーブとなる方式です。
更新命令をどのDBに送ってもよく、全てのDBで同期がなされます。
ー その性質上、全てのDBが遅延することなく同期している必要があるため
更新性能が劣化する可能性があります。
メンテナンスやリカバリの際にも、マルチマスタ方式は扱いが難しいため
一般的にはマスタスレーブ方式が採用される場合が多いようです。
ソーシャルゲームのサーバ等、速度が最重要となる場合は
マスタスレーブ方式を使用しましょう。
一般的にはマスタスレーブ方式が採用される場合が多いようです。
ソーシャルゲームのサーバ等、速度が最重要となる場合は
マスタスレーブ方式を使用しましょう。
◆というわけで
今回はDBシステムの観点から、
・DBのレプリケーション
・レプリケーション方式と注意点
について簡単に書かせて頂きました。
構成自体は難しいものではないですが、どのような動作をするか
イメージし易くするためには実際に触ってみることをオススメします。
イメージし易くするためには実際に触ってみることをオススメします。
世界的に有名なOSSのMySQLでもサポートしていますので、比較的簡単に用意出来ます。
是非、レプリケーションをマスターして堅牢なシステム作りに役立てて下さい。