blogスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。blog2010-11-02MongoDBのレプリケーションとバックアップ機能の紹介MongoDB久々の更新です。MongoDBのドキュメントのReplicationの部分の訳が一応完了しましたので、それに合わせてこのブログでもReplication機能について書いていきたいと思います。解釈の甘い部分も残っていますので、今後もこの部分の勉強を続け修正を行っていきます。Zoneの訳を進めていくつもりです。setMongoDBのバックアップ機能についてファイルのバックアップmongodumpによるエクスポートMongoDBのReplication機能についてMongoDBのReplicationは細かく分けると3種類あります。Master/Slave典型的なMasterとSlaveの構成です。Masterが常に書き込み処理を行い、Masterに書き込まれたデータがSlaveに同期されていきます。1つのMasterのみが書き込みに対してアクティブなことにより、強い一貫性(consistency)を実現します。それ以外のSlaveに対してもオプションで読み込み権限を与えることができます。consistency)を採用しているためです。MongoDBでMaster/Slaveの構成を実現するのはとても簡単です。Masterサーバーは自身がMasterであることを起動時のオプションで明示してやります。27020でmasterサーバーを起動します。して起動する場合を考えます。/mongo/slaveまた、1つのslaveで、2つの別々のmasterからデータを持ってくるといった事も可能です。こちらにその例があります。setに置き換わるまで、フェイルオーバー機能を備えたもう1つのレプリケーションでした。Master/Slaveとの大きな違いは、フェイルオーバーと呼ばれる、現在書き込みがアクティブなサーバー(primary)がダウンしたときに自動的にその他のサーバー群(secondaries)から1台をprimaryに昇格させて処理を継続させる機能を持っていることです。setは3台以上のサーバーで構成できるより柔軟な仕様になっています。pairの採用は推奨されていませんが、こちらも非常に簡単に構成することができますので紹介しておきます。pairとしてMongoDBを起動する場合、必要なのはペアとなるサーバー情報(host、port)と、arbiterと呼ばれるペアのどちらをprimaryにするかの決定を支援する独立したサーバーの情報です。pairを構成してみます。これはあくまで例であって、本来はすべてのサーバーは違うマシンで稼働させるべきです。得にarbiterサーバーは独立したマシンで起動させないと意味がありません。/data/mongo/arbiterarbiterここでarbiterについて少し説明を加えておきます。pairのメンバーがネットワーク障害でお互いに通信できなくなった場合、どのデータベースをprimaryにするのかの決定を効果的に行う役目を持っています。オプションを省略することもでき、この設定では通信ができなくなった場合、両方のサーバがprimaryとして動作することになります。書き込みが双方のサーバーで継続して可能な場合、この状況ではデータの競合が起こってしまいます。arbiterサーバーが必要となる場合。通信障害の後もClientsからのリクエストは双方のサーバーへ届いてしまいます。これを防止するためにarbiterサーバーがただ1つのprimaryを決定します。pairに置き換わる機能としてバージョン1.6より追加されました。複数台以上のサーバーでのフェイルオーバーをサポートできるのが大きな特徴です。データはこのノード間で完全に同期され、この内のただ1台だけがprimaryとなりその他はSecondaryとして動作します。どのノードもprimaryになる可能性を持っています。passiveノードこのノードは完全なデータの複製を保持しますが、決してprimaryになることはありません。arbiterノードデータの複製も保持せず、primaryノードにもなり得ません。このノードは現primaryノードに障害があったときに次のprimaryをsecondariesから選択する際の補助役としてのみ動作します。オプションでsetメンバーに共通の名称を起動時に明示してやる必要があります。各サーバーを起動させた後、1つのサーバーでsetメンバーの登録設定を行います。setとして機能するようになります。今回も簡単な例として、localhostのポート27020(set1)、27021(set2)、27022(set3)、27023(arbiter)を使用した構成例を示します。状態の確認ができるフェイルオーバー時の動作それでは現primaryがダウンしてしまった場合、どのようにして時期primaryが選択されるのでしょうか?ここではオプションである優先度(priority)がすべてのsecondaryで等しいものとして話を進めていきます。現在のprimaryがダウンした際には最も直近で同期を完了したサーバーが優先的に次のprimaryとして選択されるようになっています。新しいprimaryとして選ばれたサーバーは他の健常なサーバーと同期を始めます。実は各サーバーにはデフォルトで1つの投票権(vote)を持っており、時期primaryの決定にはこのvoteによる投票が行われ、過半数のvoteを得たサーバーが晴れてprimaryとなります。各サーバーは現在通信可能なサーバーの中で最新のデータを保持しているサーバーへ投票します。過半数を得るためには少なくとも半数以上のサーバーが通信可能な状態でないといけません。ない場合は過半数票を得ることができませんのでprimaryが選ばれず、書き込み不可能な状態が継続します。setでも生じ、primaryがダウンした場合、voteは自身の持つ1つのみであるため過半数とみなされず、primaryを決定できません。setを構成しないといけません。※時期primaryの選ばれ方についてはまだ理解が浅く、もしかしたら上の記述は間違っているかもしれません(すいません)。その際はご指摘していただけると幸いです。primaryがダウン。この時secondary2が1分前に同期を終えたばかりで最新のデータを有している。この時secondary2がprimaryとして選択され、他のノードとの同期を再会する。MongoDBのバックアップ機能についてほとんどのデータベースにはデータのバックアップ機能を備えています。MongoDBにも大きく分けて2種類のバックアップ機能を備えています。ファイルのバックアップmongodumpによるエキスポートこの2つの違いは主に前者は書き込み処理を止めて実行しないといけない(すなわちダウンタイムが生じる)のに対して、後者はサーバーを停止させずにバックアップを行うことができる点です。それでは詳しく見ていきましょう。ファイルのバックアップファイルのバックアップとは、直接MongoDBのデータファイルをコピーすることです。設定されていますので、このディレクトリ以下のファイルをコピーすれば基本的にバックアップは完了します。プロセス)の起動の際にオプションとして指定することができます。/data/mongo/masterとします。このバックアップは非常に簡単ですが、いくつかの注意点があります:書き込みが行われている途中でのバックアップは安全ではないデータベースが稼働中で書き込み処理が行われている際中にmongodのデータを直接バックアップするのは安全ではありません。データベースを一度停止させてバックアップをし、その後再起動する方法もありますが、mongoDBではコマンドライン上でfsyncコマンドを利用することでデータベースを停止させることなく、一時的な書き込みのロックを行って、その間にバックアップを行います。コマンドを利用するfsyncコマンドは元々まだ書き込みが行われていない処理を全て強制的に行うコマンドですが、安全にデータベースのデータファイルのスナップショットを取るためのロックオプションをサポートしています。ロックオプションが指定されたfsyncコマンドが実行されている間はすべての書き込み操作がブロックされます。この間にバックアップを行い、完了後にunlockコマンドでロックを解除して書き込み処理を再開するようにします。バックアップ終了後は以下のロック解除コマンドを実行します。informationと表示されて起動に失敗することがあります。これは不意にmongodbがシャットダウンされた場合に、ロックされたままの状態になっているような際に起こります。ファイルを削除して起動してみてください。よるエクスポートmongodump上述の方法では、一時的にMongoDBの書き込み処理を停止させてしますことになります。このmongodumpによる方法はデータベースが稼働中でもデータベース全体をdumpすることができます。稼働しているMongodから--dbで指定したdbをバックアップしています。/data/mongo/dumpmongorestoremongodumpでダンプされたファイルは、mongorestoreコマンドによってリストアすることができます。dumpされたディレクトリ以下には[collection名].bsonというファイル名でデータが格納されています。今、以下のmongodサーバーでリストアを行うことにします。いうディレクトリ以下にリストアするとします。/data/mongo/restoreそしてコンソール上で以下のコマンドでデータベース:mydbのリストアが実行されます。--dropコマンドは既に同じコレクション名が存在している場合には先にコレクションのデータをを削除してからリストアするオプションです。/data/mongo/dump終わりにこれまでに紹介した機能はMongoDBの持つ多彩なレプリケーション機能のほんの一部でしかありません。細かな設定や他の機能は公式ドキュメント(日本語、英語)を参考にしてください。MongoDBのレプリケーション機能は万能ではありません。以前エントリーで紹介したFoursquareの事例のように、断片化の問題や、同期の遅さ、フェイルオーバーの失敗などが報告されています。そのような問題も、提供元の10genとコミュニティの方々の活発な活動によってどんどん解消されていくだろうと思います。僕もその活動に少しでも関わって行けたらと感じています。今後とも本ブログにおいてMongoDBに関するエントリーを続けていきますのでよろしくお願いします。blogのメイントピックをトレジャーデータ日本語公式ブログへ移設しました。Blog|ブログを報告する。