MongoDB replica set database split and version upgrade combat

MongoDB replica set database split and version upgrade combat

Problem description

The replica set rs_1 all of the database services, and adding memory is no longer sufficient for application stress.

Solution Solutions

Consider splitting the replica set rs_1 part of the database to Rs_2, and upgrade the database version to 2.6 at the same time.

Architecture diagram

650) this.width=650; "title=" image "style=" border-top:0px;border-right:0px;background-image:none;border-bottom:0 px;padding-top:0px;padding-left:0px;margin:0px;border-left:0px;padding-right:0px; "alt=" image "src=" http:// S3.51cto.com/wyfs02/m00/6f/e2/wkiom1wsad-qs8biaakifw3wef4371.jpg "border=" 0 "height=" 505 "/>

Get ready

Evaluate upgrade possibilities

1. Connect the 2.6 MONGO shell to the 2.4 replica set secondary member and execute Db.upgradecheckalldbs () in the admin library.
2. Evaluate application compatibility issues for upgrade to 2.6, refer to: http://docs.mongodb.org/manual/release-notes/2.6-compatibility/

Database partitioning

1. Partition the split to replicate the set of database members.
2. Clear the corresponding application and prepare the link string to be updated.

Driver upgrade

1. The c#/.net driver version needs to be upgraded to more than 1.9 in advance.

Operation Steps

Add a 2.6 version of the secondary member to the replica set Rs_1

1. In Replset 1, add the 2.6 version of the secondary member (or upgrade the existing 2.4 version secondary to the 2.6 version), specifically

Level method, see "Upgrading MongoDB to 2.6".

2. According to the actual situation, see if it is necessary to add arbiter to ensure that Replset 1 has a base number of members.
Rs.addarb ("aaaaaa:30000")

Splitting some of the databases in the replica set Rs_1 to Rs_2

1. Configure a new replica set name for the secondary member of version 2.6
Modify configuration file/etc/mongod.conf configuration parameters replset=rs_2
2. Cessation of service of the secondary member
Service Mongod Stop
3. Delete the oplog of the secondary member
Cd/data/var/lib/mongodb/local
RM-RF local.*
4. Start the service
Service Mongod Start
5. Initializing a new replica set rs_2
Rs.initiate ()
Rs.conf ()
Rs.status ()
6. Upgrading the Licensing architecture
Db.getsiblingdb ("admin"). RunCommand ({authschemaupgrade:1});
7. Remove the member from the replica set rs_1
Rs.conf ()
Rs.remove (' xxxxxx:27017 ')
8. Keep the database members in the replica set rs_2 and delete the other libraries.
Use [database name]
Db.dropdatabase ();

Application modifications

1. Modify the link string for the application that corresponds to the members in the replica set rs_2.

To add two members of the 2.6 version to a replica set rs_2

1. Rs_1 two secondary members in the Mongod services  
   service Mongod stop    
2. Database version upgrade to 2.6   & nbsp
3. Delete the data files in the database directory    
4. Modify/etc/mongod.conf configuration Parameters replset=rs_2    
5. Start Mongod Services    
   service mongod start    
6. Primary shell that connects the MONGO of the new replica set rs_2 add two new members    
   rs.add (' yyyyyy:27017 ')    
   rs.add (' zzzzzz:27017 ')    
7. Remove the replica set Rs_ 1 yyyyyy and ZZZZZZ members   &NBSP,
   rs.conf ()    
   rs.remove (' yyyyyy:27017 ')    
   rs.remove (' zzzzzz:27017 ')    
8. Check the data synchronization status of the new replica set rs_2    
    Rs.status ()    
9. In order to avoid, when the data synchronization process, the application side a large number of query connection requests, resulting in synchronization can not be completed, you can hide the

The

Secondary member. (optional)  
   cfg = rs.conf ()    
   cfg.members[1].priority = 0    
&N bsp;  Cfg.members[1].hidden = True    ,
   rs.reconfig (CFG)    
   Note: The members array index starts at 0.    
10. When the data synchronization is complete, then unhide. (optional)    
   cfg = rs.conf ()    
   Cfg.members[1].hidden = False   &nbs P
   cfg.members[1].priority = 1    
   rs.reconfig (CFG)    
11. If Rs_ 2 Primary hardware configuration is better, can modify the priority of primary. (optional)    
   cfg = rs.conf ()    
   cfg.members[0].priority = 23°c   &NBSP ;
   rs.reconfig (CFG)    
12. In the case of ignoring 9 to 12 steps, if the hardware configuration of a secondary member is better, it is hoped that after the synchronization data is completed, it will be automatically elected as

Primary, the priority of the member can be modified during the synchronization of the data. After the data is synchronized, it will automatically switch. (optional)
CFG = rs.conf ()
Cfg.members[2].priority = 23
Rs.reconfig (CFG)

Source Replica set Rs_1 upgrade to version 2.6

1. Removal of election members.
Rs.remove (' aaaaaa:30000 ')
2. Delete the database member from the source replica set rs_1 that is split to rs_2.
3. To upgrade the replica set rs_1, see "Upgrading MongoDB to 2.6" and "MongoDB upgrade user authorization data to 2.6 format".

This article is from the SQL Server deep dives blog, so be sure to keep this source http://ultrasql.blog.51cto.com/9591438/1676286

MongoDB replica set database split and version upgrade combat