Initial Experience of MongoDB3.6 Replica Set

Initial Experience of MongoDB3.6 Replica Set

Replica Set is called a Replica Set in China. Simply put, a copy of data is stored in multiple places.

1. Why should I use a replica set and when?

Some people say that the storage of a piece of data occupies a large amount of extra space in multiple places, which is a waste.

This statement cannot be correct or incorrect. It should be considered from different perspectives. If the company's business volume is small and there is not much data, one server can handle it, it does not need to store one copy of data in multiple places. As the company grows, the business volume increases and the data volume increases, we need to consider using distributed clusters to distribute data on different servers. At this time, you can still avoid using copies. By distributing data to different servers, the pressure on each server can also keep up with the company's current business volume. If the company scales up and the number of users increases, many customers may want to access the same resource. In this case, the pressure on servers that store this resource may be high. The necessity of copying is apparent.

2. What are the benefits of using a replica set?

Replica sets provide fault tolerance and high availability. Of course, replica is also used for disaster recovery backup and read/write splitting.

3. MongoDB Replica Set cluster Introduction

First, let's look at a typical Replica Set graph:

Rs cluster for easy introduction

(1). the rs cluster is composed of multiple Mongod instance nodes. Only one node is primary, other nodes are secondary, and the other nodes are dispensable arbitration nodes. When the cluster has an even number of nodes, an arbitration node will be added. If the cluster has an odd number of nodes, you do not need to use the arbitration node. The arbitration node does not store data. It is only used to vote for the primary node, and the arbitration node does not require a dedicated server, but cannot run on the server where the primary or secondary node is already installed, it can run on an application or monitoring server. (someone said that the arbitration node can elect another primary in the secondary node after the primary node becomes invalid. This is not true, the role of an arbitration node is to have the right to vote ).

(2) primary is used to receive read and write requests from the client and record operation logs. secondary is used to asynchronously synchronize operation logs of primary from the primary and update its own dataset. In general, secondary cannot respond to the client's read operations to avoid reading dirty data. However, when the rs cluster has multiple data centers, the client can request to read secondary data. When primay is on a server in Beijing, one of the Secondary's users is reading data in Chongqing and Chongqing, considering the relationship between the geographical location and the network speed, you can select read-only primary, primary first, read-only secondary, secondary first and read data from the nearest (nearest) node.

(3) When primary cannot be accessed, another primary node will be selected from the remaining secondary nodes.

4. RS cluster deployment example

(1) There are three servers. Because they are odd-number servers, no arbitration node is selected.

(2 ). download the MongodDB manual installation version (I downloaded the 64-bit Linux version), decompress it to a directory, change the name of the decompressed folder to mongoDB, enter the mongoDB directory, and create a new configuration file mongod. conf

# Mongod. conf
# Data storage path
Dbpath = mongodb/data/mongod

# Log storage path
Logpath = mongodb/log/mongod. log
Logappend = true

# Pid of the stored process running in the background
Pidfilepath =/home/yanggy/mongodb/mongod. pid
# One directory for each database
Directoryperdb = true

# Replica set Name
ReplSet = testrs

# Binding IP addresses and hosts
Bind_ip = server1
Port = 27001

# Log File Size
OplogSize = 100

# Running in the background
Fork = true

# Do not load data to the memory in advance
Noprealloc = true

Copy the configuration file to another server, modify the bound IP address, and manually create the corresponding data and log directory on each server.

(3). Start the mongod instance on each server

Mongod-f mongodb/mongod. conf

(4). Use mongo to connect to one of the servers

Mongo -- host server1 -- port 27001

(5) initialize the rs Cluster

> Cfg = {_ id: "testrs", members: [{_ id: 0, host: "server1: 27001", priority: 3 },
{_ Id: 1, host: "Server 2: 27001", priority: 2 },
{_ Id: 2, host: "Server 3: 27001", priority: 1}]}
Output:
{
"_ Id": "testrs ",
"Members ":[
{
"_ Id": 0,
"Host": "server1: 27001 ",
"Priority": 3
},
{
"_ Id": 1,
"Host": "server2: 27001 ",
"Priority": 2
},
{
"_ Id": 2,
"Host": "server3: 27001 ",
"Priority": 1
}
]
}

> Rs. initiate (cfg)
Output:
{
"OK": 1,
"OperationTime": Timestamp (1521190572, 1 ),
"$ ClusterTime ":{
"ClusterTime": Timestamp (1521190572, 1 ),
"Signature ":{
"Hash": BinData (0, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa = "),
"KeyId": NumberLong (0)
}
}
}

> Rs. status ()

Output:
{
"Set": "testrs ",
"Date": ISODate ("2018-03-16T08: 56: 23.948Z "),
"MyState": 1,
"Term": NumberLong (1 ),
"HeartbeatIntervalMillis": NumberLong (2000 ),
"Optimes ":{
"LastCommittedOpTime ":{
"Ts": Timestamp (0, 0 ),
"T": NumberLong (-1)
},
"AppliedOpTime ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"DurableOpTime ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
}
},
"Members ":[
{
"_ Id": 0,
"Name": "server1: 27001 ",
"Health": 1,
"State": 1,
"StateStr": "PRIMARY ",
"Uptime": 220,
"Optime ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"OptimeDate": ISODate ("2018-03-16T08: 56: 12Z "),
"InfoMessage": "cocould not find member to sync from ",
"ElectionTime": Timestamp (1521190582, 1 ),
"ElectionDate": ISODate ("2018-03-16T08: 56: 22Z "),
"ConfigVersion": 1,
"Self": true
},
{
"_ Id": 1,
"Name": "server2: 27001 ",
"Health": 1,
"State": 2,
"StateStr": "SECONDARY ",
"Uptime": 11,
"Optime ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"OptimeDurable ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"OptimeDate": ISODate ("2018-03-16T08: 56: 12Z "),
"OptimeDurableDate": ISODate ("2018-03-16T08: 56: 12Z "),
"LastHeartbeat": ISODate ("2018-03-16T08: 56: 22.733Z "),
"LastHeartbeatRecv": ISODate ("2018-03-16T08: 56: 19.659Z "),
"PingMs": NumberLong (0 ),
"ConfigVersion": 1
},
{
"_ Id": 2,
"Name": "server3: 27001 ",
"Health": 1,
"State": 2,
"StateStr": "SECONDARY ",
"Uptime": 11,
"Optime ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"OptimeDurable ":{
"Ts": Timestamp (1521190572, 1 ),
"T": NumberLong (-1)
},
"OptimeDate": ISODate ("2018-03-16T08: 56: 12Z "),
"OptimeDurableDate": ISODate ("2018-03-16T08: 56: 12Z "),
"LastHeartbeat": ISODate ("2018-03-16T08: 56: 22.733Z "),
"LastHeartbeatRecv": ISODate ("2018-03-16T08: 56: 19.641Z "),
"PingMs": NumberLong (0 ),
"ConfigVersion": 1
}
],
"OK": 1,
"OperationTime": Timestamp (1521190572, 1 ),
"$ ClusterTime ":{
"ClusterTime": Timestamp (1521190582, 1 ),
"Signature ":{
"Hash": BinData (0, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa = "),
"KeyId": NumberLong (0)
}
}
}

It can be seen that a node with a larger priority value may become primary.

Well, I believe you have a preliminary experience and understanding of the Replica Set. If there is anything that is not prepared or wrong in the above section, we would like to point out that we will discuss progress together.

This article permanently updates link: https://www.bkjia.com/Linux/2018-03/151492.htm