ttlsaチュートリアルシリーズのmongodb--(五)mongodbアーキテクチャ-レプリケーション原理&レプリケーションセット


mongodbクラスタ:レプリケーション、レプリケーションセット、スライス.本番環境でmongodbのレプリケーション機能を使用することを強くお勧めします.レプリケーションには、フェイルオーバー、読み取り拡張、ホットバックアップ、オフラインバッチ操作があります.デフォルトでは、プライマリノードはクライアントのすべての読み書き要求を担当し、ノードから読み書きできません.一.動作原理1.mongodbのレプリケーションには少なくとも2つのインスタンスが必要です.1つはプライマリノードであり、クライアント要求の処理を担当し、残りはセカンダリノードであり、プライマリノード上のデータのコピーを担当します.プライマリノードは、その上に記録されたすべての操作oplogを記録し、ノードから定期的にプライマリノードをポーリングしてこれらの操作を取得し、自分のデータのコピーに対してこれらの操作を実行し、ノードからのデータがプライマリノードと一致することを保証します.2.プライマリノードの操作レコードはoplog(operation log)と呼ばれ、localデータベースに格納される(localデータベースはコピーされず、コピー状態情報を格納するために使用される).oplogの各ドキュメントは、プライマリノードで実行される操作を表します.oplogは,ノードからプライマリノードとデータ同期を維持するメカニズムとしてのみ用いられる.3. oplog.rsは固定長のcapped collectionである.デフォルトでは、64ビットのインスタンスは、localデータベースに割り当てられ、サーバの起動時に予め割り当てられたoplog 5%の空き領域を使用します.4.ノードからプライマリノードに遅れている場合、oplogログがノードから実行されていないため、oplogがロールバックされている可能性があります.ノードからプライマリノードに追いつかず、レプリケーションが停止します.ノードから完全な同期を再実行する必要がある場合は、{resync:1}コマンドを使用して再同期を手動で実行するか、スレーブノードの起動時に--autoresyncオプションを指定して自動的に再同期させることができます.再同期のコストは高価で、できるだけ避けるべきで、避ける方法は十分なoplogを構成することです.oplog情報を表示するには、次の手順に従います.
> db.oplog.rs.stats()
{
        "ns" : "local.oplog.rs",
        "count" : 7276573,
        "size" : 1980730564,
        "avgObjSize" : 272.20651314842854,
        "storageSize" : 2097156096,
        "numExtents" : 1,
        "nindexes" : 0,
        "lastExtentSize" : 2097156096,
        "paddingFactor" : 1,
        "systemFlags" : 0,
        "userFlags" : 0,
        "totalIndexSize" : 0,
        "indexSizes" : {

        },
        "capped" : true,
        "max" : 2147483647,
        "ok" : 1
}
oplogを表示します.rs内容:
> db.oplog.rs.find().limit(1).toArray()
[
        {
                "ts" : Timestamp(1357529944000, 1),
                "h" : NumberLong("-3237467944396345731"),
                "v" : 2,
                "op" : "i",
                "ns" : "ttlsa_event.ttlsa_events",
                "o" : {
                        "_id" : ObjectId("50ea43599ca66a2d7e000000"),
                        "aid" : 110000,
                        "kid" : 10007,
                        "tag" : "Mobile",
                        "uid" : 368514901,
                        "stmp" : 1357529945,
                        "born" : 1357529945,
                        "total" : 1,
                        "val" : [
                                {
                                        "nickname" : "m44332148",
                                        "productid" : 109350,
                                        "product" : "    OL",
                                        "stmp" : 1357529945
                                }
                        ]
                }
        }
]
フィールドの説明:ts:操作のタイムスタンプ.操作の実行時間を追跡するために使用されます.op:操作タイプ、iは挿入、uは更新、dはdelete ns:実行操作の集合名o:ドキュメント内容2.レプリケーションmongodbは、従来のmaster-slaveアーキテクチャをサポートします.自動フェイルオーバ機能はありません.masterとslave端子を指定する必要があります.レプリケーション・セット・アーキテクチャの使用を強くお勧めします.レプリケーション・セット・アーキテクチャはレプリケーション・アーキテクチャよりもメンテナンスがよく、機能がより強いです.master-slaveアーキテクチャは、一般的に次の2つのケースで使用されます.1.slaveは11個を超える.単一のデータベースmaster-salveアーキテクチャ構成をコピーする必要があります://master serverはmasterを起動し、masterパラメータを指定するだけです
# mongod --master
//slave server slaveを起動するには、slaveパラメータとmasterのIPとポートを指定する必要があります
# mongod --slave --source master_server:27017
プライマリ・スレーブ・レプリケーションのオプションは次のとおりです.1.--onlyはslaveノードでコピーするデータベースのみを指定します.2.--slavedelay slaveノードの同期master 3の遅延数を指定します.--fastsyncは、masterノードのデータスナップショットに基づいてslaveノード4を起動します.--Autoresync slaveノードが同期していない場合は、アクティブに再同期します.oplogSize masterノードoplogサイズ3.複製セット複製セットには、少なくとも3台のサーバまたは2台のサーバ+仲裁1台が必要です.複製セットの構成については、次を参照してください.http://www.ttlsa.com/html/1093.htmlmasterのoplogメタデータ情報を表示するには、次の手順に従います.
> db.printReplicationInfo()
configured oplog size: 2000MB
log length start to end: 16685504secs (4634.86hrs)
oplog first event time: Mon Jan 07 2013 11:42:50 GMT+0800 (CST)
oplog last event time: Fri Jul 19 2013 14:34:34 GMT+0800 (CST)
now: Fri Jul 19 2013 14:34:38 GMT+0800 (CST)
フィールド説明:configured oplog size:oplogファイルサイズlog length start to end:oplogログの有効期間oplog first event time:最初のトランザクションログの生成時間oplog last event time:最後のトランザクションログの生成時間now:現在の時間間slaveの同期状態を表示する:
> db.printSlaveReplicationInfo()
source:   10.1.11.157:27017
         no replication info, yet.  State: ARBITER
source:   10.1.11.156:27017
         syncedTo: Fri Jul 19 2013 14:34:42 GMT+0800 (CST)
                 = 2 secs ago (0hrs)
フィールドの説明:source:ライブラリのIPおよびポートsyncedTo:現在の同期状況からノードを追加します.
ttlsa:PRIMARY> rs.add("10.1.11.111:27017")
ノードの削減:
ttlsa:PRIMARY> rs.remove("10.1.11.111:27017")
では、ライブラリからの読み込みを許可します.
ttlsa:SECONDARY> db.getMongo().setSlaveOK()
手動転送primary:
ttlsa:SECONDARY> rs.freeze([secs]) //make a node ineligible to become primary for the time specified 
ttlsa:PRIMARY> rs.stepDown([secs]) //step down as primary (momentarily) (disconnects)
複製セットのステータス:1.STARTUP:レプリケーションセットに追加されたばかりで、構成はまだロードされていません.STARTUP 2:構成がロード済み、初期化状態3.RECOVERING:復元中で、読みは適用されません.ARBITER:仲裁者5.DOWN:ノード到達不可6.UNKNOWN:他のノードの状態を取得していないが、どのような状態なのか分からないが、一般的には2人のメンバーしかいないアーキテクチャで発生し、脳裂7.REMOVED:複製セット8を除去する.ROLLBACK:データロールバック、ロールバック終了時にRECOVERINGまたはSECONDARY状態に移行する.FATAL:エラーです.ログgrep"replset FATAL"を確認してエラーの原因を探して、再び同期をします10.PRIMARY:マスターノード11.SECONDARY:バックアップノード4.レプリケーション認証認証が有効になっている場合は、プライマリノードとスレーブノードのlocalデータベースの下に、同じユーザー名とパスワードのユーザーを作成し、読み書き可能にする必要があります.ノードからプライマリノードを接続する際にlocalに格納する.system.users中のユーザが認証を行い、最初にreplユーザを用いることを試みるが、そうでなければlocalを用いる.system.usersの最初の使用可能なユーザー.
> use local
> db.addUser("repl","password")
.分割して次の節に話します.転載は出典を明記してください.http://www.ttlsa.com/html/1679.html