1, Replication Introduction
MongoDB replication is the replication of data in multiple servers, the purpose of data replication is to provide redundancy and improve the availability of data, the operation of data replication on different database servers to save multiple copies of the data set, so as to avoid single-machine failure and thus loss of data, The replication mechanism also allows you to recover hardware failures and service outages, which in turn can serve as a disaster and backup for your data.
In MongoDB, a replica set is a set of Mongod instances, a Mongod instance as primary is the so-called master service, receiving all the write operations, other Mongod instances as secondaries is called the slave service, Their business comes from primary in order to get the same data set as primary.
1.1. Primary (Master)
The primary service receives all the operations from the client, and only one primary service can be in a replica set schema, because only a member of a replica set is allowed to receive writes, and the replica set schema provides strict rules that all reads must come from primary, MongoDB supports data changes through the Oplog log.
The following is a primary-based replica set infrastructure diagram:
1.2, secondaries (slave)
The secondaries service replicates primary's primary log (Oplog) to manipulate their datasets, and secondaries datasets reflect primary datasets If primary services are unreachable, Replica The set schema automatically selects a secondaries as the primary, and by default the client reads from primary, but the client can send a read directly to a secondaries service to fetch the data. The data that the client reads from the secondaries service does not necessarily reflect the primary data.
The following is a secondaries-based replica set schema:
1.3. Arbiter (arbitrator)based on the two architectures above, you can add an additional Mongod instance to the arbiter of the replica set schema (arbiter), Arbiter will not hold a dataset, arbiter only when primary is unreachable. To choose a secondary to vote for as a primary election, if your replica set structure has many members, adding a arbiter will get more votes in Primary's primary election, Arbiter does not need specialized hardware to support it. The following is the replica set schema for adding arbiter:
Note: A arbiter will always be a arbiter, meaning that in a replica set schema an arbitrator will always be an arbitrator, and a primary can become a secondary, A secondary can also be a primary in a re-election. However, the arbitrator cannot change in the architecture regardless of the occurrence.
1.3.1, Replica set arbiter (replica set arbiter)in front of us we've talked about a arbiter (arbiter) does not hold a backup of the dataset, nor can it be a primary service to receive client writes, Replica set may choose primary have arbiter (arbiter) to increase the votes, Aribter (arbiter) allows a replica set to have an uneven number of members, but it does not have the overhead of copying data as a member. Note: Do not run a arbiter (arbiter) on the same host as the primary service and the secondary service member, just add a arbiter (arbiter) as a fixed member of the replica set, If you add a arbiter (arbiter) as a temporary member of a replica set, this replica set may cause an unfair vote in the election. So how do you add a arbiter (arbiter) to a replica set schema? arbiters (arbiter) is an Mongod instance, as part of the replica set schema, but it does not hold data sets, arbiter (arbitrators) participate in primary elections in order to break the electoral kidnapping relationship if a replica Set has a uniform member, adding a arbiter (arbiter) requires some very few prerequisites, it does not require hardware support, you can deploy a arbiter (arbiter) service on an application service or monitoring host. Precautions :
- Do not deploy a arbiter (arbiter) service on a machine that is a member of a replica set schema.
- Arbiter (arbiter) does not store data, but when a arbiter (arbiter) Mongod process is added to a replica set schema, arbiter (arbiter) Starts a collection of data files with a full capacity of journal like any other mongod process.
- Arbiter allows you to set a base for voting in a replica set. As shown in the schema:
1.3.2, adding a arbiter (arbitrator)
- Create a data directory for the arbiter (such as DBPath), the Mongod instance uses this directory to hold the configuration data, which does not hold a collection of data from the primary primary log copy. As shown below:
Mkdir/data/arb
- To open a arbiter service, you need to specify the data directory and the replica set name as follows:
Mongod--port 30000--dbpath/data/arb--replset RS
- Use the Rs.addarb () method to add the Arbiter service to a replica Set, while connecting to the primary service .
Rs.addarb ("m1.example.net:30000")
At this point, a port at 30000 Arbiter (arbiter) service is running on the M1.example.net host.
1.3.3, (security) Safety
authentication (Certified)when Arbiter runs in a schema that requires authentication for the replica set, the Arbiter (arbiter) exchanges credentials to authenticate the group's members, and through MongoDB's cryptographic authentication process, the MONGODB authentication switches the encrypted security certificate, At this point the Arbiter service requires a key file to validate the replica set schema.
Communication (communication)In a replica set schema that is deployed with arbiter (arbitrators), only arbiter and other members of the communication, such as election polling, heartbeat, and configuration data are not encrypted in this data. Note: Of course, if your MONGODB uses SSL deployment, MONGODB will encrypt the communication of all members in the replica set schema, and the application in MongoDB on SSL will be listed in the following chapters. -------------------------------------------------------------MongoDB Series Blog Update--------------------------------------------------------------------------------------------
The first part of the basic chapter into MongoDB
The first part of the basic chapter II install MongoDB
Part I basic chapter III MONGODB architecture
The first part of the basic chapter fourth MongoDB Quick Start
The first part of the basic chapter Fourth MongoDB query
Part Two application chapter Fifth MongoDB advanced query
Part Two application chapter sixth MongoDB Gridfs
Part Two application chapter seventh MongoDB MapReduce
Part III Management chapter eighth MONGODB service Management
Part III Management Chapter Nineth the MongoDB Shell system command, user command
Part III Management Chapter Nineth of the MongoDB shell eval, process
Part IV Performance Chapter Tenth MongoDB index
Part IV Performance Chapter 11th MongoDB performance Monitoring
Part V Architecture Chapter 12th MongoDB Replica Sets Architecture (Introduction)
