Shulou(Shulou.com)06/01 Report--

Background:

It turned out that a colleague asked me why there was a big data gap between the master and slave mongodb database. I asked him to take a look at the differences between the two sides and found out

The main local library has 13g slaves, but it is very small. After entering local, du found that the file with a collection prefix had 13g, indicating that a collection in the local database is too large. It is speculated that oplog is too large. Oplog is an archivelog similar to mysql's binlog oracle.

When Primary writes, these write records are written to the Oplog of Primary, and then Secondary copies the Oplog to the local machine and applies these operations, thus realizing the function of Replication.

At the same time, because it records write operations on the Primary, it can also be used for data recovery.

You can simply think of it as a binlog in Mysql.

For further confirmation, after entering the mongodb, pass the

Show dbs

Use local

Show collections

See existing collections

And then

Db.getReplicationInfo ()

Rs.printReplicationInfo ()

Learn about replication information and oplog size and usage

To further confirm whether the corresponding file is oplog

Db.printCollectionStats ()

According to the results shown, only two pieces of information are needed:

"ns": "local.oplog.$main"

"uri": "statistics:table:local/collection-2-1716662444632575459"

You can confirm the corresponding files of the oplog collection, and if the oplog is too large, you can clean up and modify the size.

MongoDB oplog is a capped collection, when creating capped collection, createCollection can set the parameters of size (maximum number of bytes) and max (maximum number of documents). When the "total size of this collection exceeds size" or "total number of documents exceeds max", the first documents inserted in the collection will be automatically deleted when newly inserted, which is equivalent to a circular storage space.

Oplog (local.oplog.rs collection) is configured to 5% of the available disk space by default. When the oplog is full, the first written oplog will be deleted. A normal insert operation includes the following steps:

Writes a document to the specified collection

Log write operations to oplog

If the oplog is full, delete the first written oplog

Optimization strategy

MongoDB 3.2 in order to improve write performance, the deletion strategy for the collection local.oplog.rs is optimized when using the wiredtiger engine, with major improvements:

Remove the delete action from the user's write path and leave it to the background thread to execute

Batch deletion is not triggered as soon as the oplog is full, but one batch at a time.

Implementation plan

When monogd starts, the entire collection is divided into 10-100 Stone according to the maximum number of bytes of oplog (it can be understood as a piece of data of oplog, which contains multiple documents, depending on the configuration of the specific number of Stone oplogSizeMB).

WiredTigerRecordStore::OplogStones::OplogStones (OperationContext* txn, WiredTigerRecordStore* rs): _ rs (rs) {/ /. Unsigned long long maxSize = rs- > cappedMaxSize (); const unsigned long long kMinStonesToKeep = 10UL; const unsigned long long kMaxStonesToKeep = 100UL; unsigned long long numStones = maxSize / BSONObjMaxInternalSize; _ numStonesToKeep = std::min (kMaxStonesToKeep, std::max (kMinStonesToKeep, numStones)); _ minBytesPerStone = maxSize / _ numStonesToKeep; / /.}

Where _ numStonesToKeep is the number of Stone that oplog should keep, and _ minBytesPerStone represents the minimum number of bytes per Stone.

Next, the approximate number of Stone contained in the current oplog is estimated based on the current size of oplog and _ minBytesPerStone, and the starting position of each Stone is obtained by sampling (the size of each Stone is not guaranteed to be exactly the same as expected), and then all the Stone are stored in a queue sequentially.

Mongod records the size of the newly generated oplog each time when the service writes the request. When the total amount of newly generated oplog exceeds _ minBytesPerStones, a new Stone will be added to the queue.

Void WiredTigerRecordStore::OplogStones::createNewStoneIfNeeded (RecordId lastRecord) {if (_ currentBytes.load ())

< _minBytesPerStone) { // Must have raced to create a new stone, someone else already triggered it. return; } // ... OplogStones::Stone stone = {_currentRecords.swap(0), _currentBytes.swap(0), lastRecord}; _stones.push_back(stone); _pokeReclaimThreadIfNeeded(); // 唤醒后台回收oplog空间的线程} 当队列中的Stone数量超过_numStonesToKeep，后台线程就会删除最老的Stone里的数据，来回收oplog的存储空间。 修改mongodb oplog sizeoplog简介： oplog：operations log的简写，存储在一个特殊的数据库中（local），oplog就存储在其中的oplog.$main集合里面，这个集合是一个固定集合，新操作会自动替换旧的操作，以保证oplog不会超过预设的大小，其中的每个文档都代表主节点上执行的一个操作，oplog会包含所有对数据有修改的的操作（查询操作不会记录），默认下，oplog大小会占用64位的实例5%的可用磁盘空间。 mongo复制的过程：主节点应用业务操作修改到数据库中，然后记录这些操作到oplog中，从节点复制这些oplog，然后应用这些修改。ps：这些操作是异步的。如果从节点的操作已经被主节点落下很远，oplog日志在从节点还没执行完，oplog可能已经轮滚一圈了，从节点跟不上同步，复制就会停下，从节点需要重新做完整的同步，为了避免此种情况，尽量保证主节点的oplog足够大，能够存放相当长时间的操作记录。 查询oplog的大小及保存的操作记录持续的时长 repltest:PRIMARY>

Db.printReplicationInfo ()

Configured oplog size: 1024MB

Log length start to end: 3705secs (1.03hrs)

Oplog first event time Thu Oct 10 2013 11:13:29 GMT+0800 (CST)

Oplog last event time Thu Oct 10 2013 12:15:14 GMT+0800 (CST)

Now Fri Oct 11 2013 16:33:42 GMT+0800 (CST)

Query the list of data sources of the slave node, in which the data lag time

Repltest:PRIMARY > db.printSlaveReplicationInfo ()

Source: 192.168.1.101:37017

SyncedTo Fri Oct 11 2013 16:38:16 GMT+0800 (CST)

= 1 secs ago (0hrs)

Source: 192.168.1.100:37017

No replication info, yet. State: ARBITER

So, modify the size of oplog: (two ways are described below)

Method 1:

The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations. Also: to resize the oplog, you need to perform maintenance mode on each node. (official recommendation)

Steps:

1: restart an instance in stand-alone mode

Usually before shutting down server again, use rs.stepDown () to force primary to become secondary

2: recreate a new size

It contains the oplog of the entry entry for the old oplgo

3: restart mongod as a member of replica set

Procedure:

1 >: Restart a Secondary in Standalone Mode on a Different Port

Close the mongod instance:

Repset:PRIMARY > use admin

Repset:PRIMARY > db.shutdownServer ()

Restart the mongod instance in stand-alone mode and modify the port without adding-- replSet parameter

# vim / etc/mongo.conf

Dbpath=/var/lib/mongodb

Logpath=/var/log/mongodb/mongo.log

Pidfilepath=/var/run/mongo.pid

Directoryperdb=true

Logappend=true

# replSet=repset

Bind_ip=192.168.1.100127.0.0.1

Port=37017

OplogSize=2000

Fork=true# mongod-f / etc/mongo.conf

Backup oplog# mongodump-- db local-- collection 'oplog.rs'-- port 37017

2 >: Recreate the Oplog with a New Size and a Seed Entry

Save the latest point in time of oplog

> use local

> db.temp.save (db.oplog.rs.find ({}, {ts: 1, h: 1}) .sort ({$natural:-1}) .limit (1) .next ()

> db.temp.find ()

Delete the old oplog

> db.oplog.rs.drop ()

3 >: Create a New Oplog

Create a new Oplog of 2G size

> db.runCommand ({create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024)})

Insert the previously saved record of the old oplog's point in time

> db.oplog.rs.save (db.temp.findOne ())

> db.oplog.rs.find ()

4 >: Restart the Member:

Shut down the stand-alone instance:

> use admin

> db.shutdownServer ()

Modify back to configuration # vim / etc/mongo.conf

Dbpath=/var/lib/mongodb

Logpath=/var/log/mongodb/mongo.log

Pidfilepath=/var/run/mongo.pid

Directoryperdb=true

Logappend=true

ReplSet=repset

Bind_ip=192.168.1.100127.0.0.1

Port=37017

OplogSize=2000

Fork=true

Start mongod

# mongod-f / etc/mongo.conf

Repeat the above steps to all nodes that need to be changed.

Method 2:

Steps:

1: stop all replca set nodes.

2: the master node deletes the files under the local library and deletes all files under the data directory from the node.

3: modify all node configuration files.

4: restart all nodes.

5: reconfigure replca set, the slave node will resynchronize all data (initial sync).

Ps: the advantage of this method is that it is simple, but the service needs to be stopped, and if the amount of data is large, the cost of initial synchronization is high.

1 >: close the mongod instance (all nodes)

> use admin

> db.shutdownServer ()

2 >: delete all files under the local database (PRIMARY node)

# rm-rf / var/lib/mongodb/local/*

Delete the mongo data directory (operations on other nodes, but do not delete errors. It is recommended that all rm operations be mv first and delete again when there is no problem) # rm-rf / var/lib/mongodb/*

3 > modify all node profiles (oplogsize)

# vim / etc/mongo.conf

Dbpath=/var/lib/mongodb

Logpath=/var/log/mongodb/mongo.log

Pidfilepath=/var/run/mongo.pid

Directoryperdb=true

Logappend=true

ReplSet=repset

Bind_ip=192.168.1.100127.0.0.1

Port=37017

OplogSize=2000

Fork=true

4 > restart all nodes mongod

> mongod-f / etc/mongo.conf

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.