MongoDB读书笔记之复制集有关LOCAL数据库及成员状态

   一、 在复制集中，我们需要关注一下local数据库，该数据库包含多个与复制相关的集合，有利于我们排错与管理。每个mongodb实例都会有自己的local数据库，其对于复制集是不可见的，不会被复制，只是记录当前实例内部复制数据，相当于元数据，如果被复制，就发挥不了其作用，那就必要存在。local数据库包含了以下下集合：
    startup_log:每当实例启动时，会被插入关于实例本身及主机系统层面的信息以便诊断，例如
    

点击(此处)折叠或打开

1. shard1:PRIMARY> db.startup_log.find()
2. { "_id" : "mas-1449590300027", "hostname" : "mas", "startTime" : ISODate("2015-12-08T15:58:20Z"), "startTimeLocal" : "Tue Dec  8 23:58:20.027", "cmdLine" : { "config" : "/work/mongodb/shard11.conf", "net" : { "bindIp" : "192.168.1.218", "http" : { "enabled" : false }, "port" : 28017 }, "processManagement" : { "fork" : true }, "replication" : { "oplogSizeMB" : 2048, "replSet" : "shard1" }, "sharding" : { "clusterRole" : "shardsvr" }, "storage" : { "dbPath" : "/work/mongodb/shard11", "journal" : { "enabled" : true } }, "systemLog" : { "destination" : "file", "logAppend" : true, "path" : "/work/mongodb/shard11.log" } }, "pid" : NumberLong(3311), "buildinfo" : { "version" : "2.6.11", "gitVersion" : "d00c1735675c457f75a12d530bee85421f0c5548", "OpenSSLVersion" : "", "sysInfo" : "Linux build4.ny.cbi.10gen.cc 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49", "loaderFlags" : "-fPIC -pthread -Wl,-z,now -rdynamic", "compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -Wno-unused-function -Wno-deprecated-declarations -fno-builtin-memcmp", "allocator" : "tcmalloc", "versionArray" : [ 2, 6, 11, 0 ], "javascriptEngine" : "V8", "bits" : 64, "debug" : false, "maxBsonObjectSize" : 16777216 } }
   

    system.replset:记录复制集配置信息，rs.conf()读取的就是system.replset所存的信息

点击(此处)折叠或打开

1. shard1:PRIMARY> db.system.replset.find()
   
2. { "_id" : "shard1", "version" : 23, "members" : [ { "_id" : 1, "host" : "mas:28018", "priority" : 3, "tags" : { "dc" : "idc01" } }, { "_id" : 3, "host" : "mas:28017", "priority" : 3, "tags" : { "dc" : "idc01" } }, { "_id" : 4, "host" : "mas:28016" } ], "settings" : { "getLastErrorDefaults" : { "w" : "majority", "wtimeout" : 5000 } } }

    oplog.rs:包含其从主复制的相关操作日志信息
    replset.minvalid:内部使用用来追踪复制状态
    slaves:3.0版本已经被移除，用来监控复制状态，与rs.status()作用类似

二、在平时使用过程有必要关注下复制集各成员状态，有利于加强对MongoDB replication工作机制的理解。这里我们能从最开始的状态说起。
    startup : 当实例开始启动并加载复制配置文件时所呈现的状态，当加载动作完成后会进startup2状态，表明将会加入复制集中，成为活动成员，然后根据自身情况，决定下一步状态，如果重新从主库进行initial  sync,在过程会持续一定时间，如果过程存在着更新，则有必要应用oplog，类似recover,接下来会进入recovering状态，在这一阶段该成员仍不可读，当有选举权，但不会被选举为主，如果复制进度能满足一定要求，一定程度上保证数据库的一致性，会从recovering状态变化secondary状态，该成员会提供读功能，并不停应用发生在主上的写操作，并有机会被选举为主，从而进入primary状态。
    上面是我们经常可以碰见的状态，在有些特殊情况，可以看到一些其他不常见的状态：down,unknown,removed,rollback(旧主重新加入到复制集时）,fatal(依然活着，但已经不可能利用oplog追赶上主，需要重新同步数据，重新同步数据时会呈现recovering状态）。