Before learning the concept of replication, the first part of the previous chapter is a little unfinished content to do a simple introduction, mainly automatic failover, asynchronous replication, and additional functions, these are only a brief introduction, in the relevant chapters will be specialized in-depth study.
1. Automatic fault transfer
When the primary service and other members of the schema interrupt communication for more than 10 seconds, Replica set will attempt to elect other members to become a new primary service, and the scondary of the number of votes will become primary.
The schema is as follows:
Description
In a replica set schema, if primary is unreachable, a scondary is automatically elected as a new primary in a member other than primary, making the replica set guaranteed to be available for automatic failover.
2. Asynchronous replication
Secondaries all operations are applied asynchronously from primary, when the primary operation is being applied asynchronously, the collection may continue to work, but the data is not copied to other members at this time, so when the client returns data through the secondary node it may not be the most recent data for the dataset.
3. Additional functions
The Replica set provides a number of options to support the needs of the application. For example, you can deploy a Replica set in a multi-datacenter, or control the election results by adjusting the member's priority, Replica Set can support member reports, disaster recovery, or backup functions.
4. The concept of reproduction (this chapter focuses)
This section mainly describes and provides examples of operation, configuration, and behavior of the replica set, an introduction to replica set, and a document management command, please learn the previous section.
4.1. Replica Set memebers (member)
MongoDB A replica set is a set of mongod processes that provide redundancy and high availability, and a member of a replica set includes the following :
- Primary:Primary Receive all write operations
- secondary: Copy all operations from primary to hold a copy of the same data set, secondary may add some special-purpose configurations, such as secondary without the right to vote and priority set to 0.
Of course you can add a arbiter (arbiter) in a replica set schema, arbiter cannot hold a copy of the data, and the arbiter plays a controlling role in the replica set architecture, when replica The primary is not available in set, and it is necessary to re-elect other members as new primary.
A replica set can have up to 12 members, and only 7 members can be voted on at the same time. a replica set minimal schema includes 1 primary, 1 secondary, 1 arbiter, and most deployments will hold three members to store the data: one primary and two secodary members.
4.2, Primaryin the previous chapters, we have already learned the basics of primary, and in this chapter we have learned that in a replica set architecture, when and only one primary service is used to receive all the writes, MongoDB applies the write operation to the primary. While recording the primary log of the primary write operation (Oplog), the secondary member replicates the log and copies the data collection according to the copy log. The following is a three-member replica set schema:
Description:
- Replica set all members can receive read operations, by default, read from primary, can be configured to change the read operation behavior.
By default, the client reads directly through primary, guaranteeing that the most recent version of a document is returned, but by assigning some read operations to secondary members, This can improve the read throughput of the system or reduce the unpredictable problem when an application does not need complete data. Note: When you specify that a member outside of a primary can receive read operations, you must be extra careful because the secondary member may not be synchronizing the most recent data collection from primary. the principle structure is as follows: If you choose a read mode that does not have primary, the app may not get real-time data, because secondary will have some delays, and the MongoDB driver provides five read modes: * Primary: Default mode, all reads are from the primary of the current replica set schema. * PRIMARYPREFERRD: In most cases, the read operation passes through the primary, but when the primary is unreachable, the read operation is performed through secondary* Secondary: All read operations are performed through secondary members. * secondarypreferred: In this mode, the read operation is performed through the secondary, but when the secondary is unreachable, the read operation is automatically performed via primary. * Nearset: The read operation is performed by the nearest member of the network delay in the replica set schema, regardless of the type of the member.
- Replica set has and has only one primary member. If the current primary member is unreachable, an additional member is automatically selected as the new primary to ensure that the entire schema is available.
4.3, secondariespreviously introduced secondary, it mainly through the primary log for data replication operations, there are some delays, if an application directly through the secondary to read the data, may not get the replica set schema the latest data, A replica set schema can have one or more secondary members, which are three members of the replica set schema, including two secondary members:
Although the client cannot write directly through secondary, the client can read the data through secondary, and a secondary can be converted to primary in the case of primary unreachable. At the same time can also be self-developed some configuration to give secondary special functions:
- If you prevent a secondary member from becoming a primary in an election, simply set the priority of the member to 0.
(1), Replica set member priority 0 Introduction
a secondary member with a priority of 0 cannot be converted to a new primary when primary is unreachable, a member with a priority of 0 cannot trigger an election event, but it can hold a copy of the data collection, read operations and elections, Configuring a member with a priority of 0 is primarily intended to prevent the member from becoming a primary, which is useful in multi-datacenter deployments. In the replica set schema of a three member, a primary member and a secondary member on the host of the first datacenter, a secondary with a priority of 0 on the host of the second datacenter cannot be primary.
(2), the role of priority 0 members a member with a priority of 0 is usually used as a data backup, in some replica set schemas, it may not be possible to add a new member at a suitable time, and an alternate member holding the current data backup can replace some unavailable members. in many cases, you do not need to set the priority to 0 to have members as backup members, and in different hardware and geographically distributed deployments, the standby of priority 0 ensures that only eligible members can become primary. This method can be implemented if 7 members in the schema already have a voting right, and other members are configured as non-election voting members. (3), priority is 0 member and fail-over by configuring a priority of 0 members, consider potential failure modes, including all possible network partitions, and always ensure that your primary data center contains rules-compliant election members and determined members. (4), Configuration Note: The Rs.resconfig () method allows the current primary service to step down, and when a primary is down (unreachable), Mongod shuts down all client connections, and the process takes 10-20 seconds. To successfully configure replica set, most members must be accessible, and if your replica set member is an even number, you can add a arbiter to make sure that the member that gets the majority of the votes becomes primary. (1), retrieving the current replica set configurationrs.conf () fee that send returns a replica set containing the current replica set configuration document. a MONGO client connects to a primary, and the run Rs.conf () method is assigned to a variable, as follows:
<span style= "White-space:pre" ></span> cfg = rs.conf ()
The method returns a replica set schema that contains all the member configuration documents.(2), assigning a priority value of 0 in order to assign a priority value to a member of the replica set, accessing the member's configuration document is useful for an array index, and in the following example, changing the number of members with an array angle of 2 to a priority of 0
<span style= "White-space:pre" ></span> cfg.members[2].priority = 0
This configuration will not take effect until the replica set is reconfigured.(3), reconfigure replica set Use the Rs.reconfig () method to reconfigure the replica set for updating the configuration document. Use the CFG variable in the Rs.reconfig () method.
<span style= "White-space:pre" ></span> rs.reconfig (CFG)
- If you prevent an app from reading through secondary, you only need to hide the member in the replica set schema.
Hide replica set members (1), a hidden member still maintains a primary data collection, but the client application is not visible to it, a hidden member must always have a total priority of 0, cannot become primary, and using the Db.ismaster () method cannot display hidden members. The following is a five-member replica set schema, with four members holding the primary data collection, but one member is a hidden member.
(2), read operation clients do not read through a hidden member, so these members cannot accept other member base copy operations, and use hidden member tasks like reports, backups, deferred members should be hidden. in a shard cluster, MONGOs routes cannot interact with hidden members. (3), electionIf you stop a hidden member, make sure that the collection has more active members or that the primary stops. because of the purpose of backup, you can avoid stopping hidden members by using Db.fsynclock () and Db.fsyncunlock () not that operation to flush all writes in the backup operation to yoke the Mongod instance.
- such as by running a historical snapshot to recover from a confirmed error, such as accidentally deleting a database.
Part V Architecture Chapter 13th MongoDB Replica Sets Architecture (member in-depth understanding)
