A new approach in the area of coordinating clusters of fail-stop storage devices, Chain Replication is a medium of supporting large-scale storage services that exhibit high throughput and availability and that too without sacrificing strong consistency guarantees. The simulation experiments involved in it explore the performance characteristics of a prototype implementation. Various object placement strategies that elegantly include schemes based on distributed hash table routing are seemingly discussed along with throughput and availability scenarios. This primary backup system is a major tool for linearly ordering servers to form a comfortable chain with the primary at the end. In classic primary backup systems, the topology of the network resembles a star with the primary at the center. The entire protocol considered in the profiling process is simple and unbiased. Every read request received in normal primary backup systems is sent to the tail (primary) of the chain and from here the updates are passed along with the chain which consists of the results of the write only in order to avoid unnecessary hassle. Since the requests are ordered at the primary at the tail of the chain, a natural scenario of strong consistency is thoroughly followed.
Setup Instructions
The process of chain replications occurs when a secondary member replicates from another secondary member and not from the primary one. This can happen in a situation when a secondary member selects its replication target based on ping time or on the probability that the closest member is also secondary. A large amount of load kept on the primary can be reduced because of chain replication and network topology.
In Replica Set Configuration, you can go for settings.chainingAllowed setting and disable chained replications in order to avoid situations where chained replications are causing lag.
One of the major features of MongoDB is enabling chained replications by default. We take a quick look at the procedure of disabling and re-enabling this chained protocol.
In order to disable chained replications, you are required to set the settings.chaining allowed field in Replica Settings Configuration to false.
The set of commands given below can help you in setting command configuration to false.
• Copy the configuration settings into the config object as:
cfg = rs.config( )
• You are required to take note of whether the current configuration settings contain the settings embedded document. If the settings embedded document is present, then skip this step.
If settings embedded document is not present in the current configuration, then you can create the embedded document by issuing the following command.
cfg.settings = { }
• The next step involves issuing the following sequence of commands to set settings.chaining Allowed to false:
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)
In case of Re-enabled chain replication set, you need to set settings.chaining Allowed to true. The following sequence of commands can be used:
cfg = rs.config( )
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)
Tips and Tricks
Properly configuring and using a particular mongoDB driver can effectively enhance the chances of completely marvelling the documentation for the PHP driver on the PHP community site. It's a common scenario of encountering incorrect configurations of the driver, particularly pertaining to timeouts and replica set connections. There are several tips and tricks which we need to take in consideration while handling MongoDB chain replication processes. We recommend the following settings to help you connect to MongoDB using the PHP driver.
// extension mongo.so 1 . 5 . x
$uri = " mongodb : // myuser :
mypassword@host1 : port 1, host2 : port 2 / mydb " ;
/*
(Refer to the tips and tricks given below here, specially the replica set name to avoid connection errors)
*/
$options = array( "
connectTimeoutMS" => 30000, "
replicaSet" => "replicaSetName") ;
$client = new MongoClient($uri, $options) ;
Several other tricks have been listed below.
• Connection timeoutMS: No explicit definition of connection Timeout is defined by the PHP driver. The major default value is determined mostly by the default socket Timeout setting in the php.ini file (default: 60 seconds )
This default option allows the driver to wait up 60 seconds while connecting before timing out. Explicitly setting the connection Timeout option via connection string URL MS is highly recommended.
• Another major trick in the settings is to be aware of is mongo.in_interval that is set in the php.ini file and has a default value of 5 seconds. An interval is set by this option regarding the time interval that the driver sends ping requests to each MongoDB server in order to find a down node. mongo.ping_interval is used in conjunction with the PHP driver's concept of a server blacklist which takes these notes down.
• In the series of tips and tricks we have been discussing, another important one is taking a look at how the PHP driver makes an attempt to connect and authenticate to each non-hidden node in the cluster while establishing a connection to a MongoDB replica set. The "down" nodes are usually passed over. In situations where the node is "up" but holding the write lock such that the 'authenticate' command can't execute, the driver will then hang. In such cases, an updated version is recommended to be taken into consideration for use.
• Connection and authentication to each hidden mode in the cluster of MongoDB replica set is a chain of indices. One connection per PHP process is recommended to be created in your database as the PHP driver does not use connection pooling. In case of building a web application, a number of PHP work processes are required which creates a scenario of multiple database connection creations. In such case, since the PHP driver can't share connections between processes, you need to customise the connection TimeoutMS option and be aware of mongo.ping_interval option in php.ini.
How Do You Measure Performance And Test It?
Measuring the performance of chain replication involves rigorously comparing the available protocol with ordinary primary backups. Since detecting a failed server takes much longer than fixing the failure once it is detected, a sincere discussion is made regarding the length and number of message round trips the recovery will take in targeted systems. A mix of reads versus writes is taken care of regarding the system that ultimately measures which system performs better because primary failure is easier to fix in chain replication and under a classic primary backup scheme, backup failure is easier to fix. Evaluation of performance of chain replication with different setups under multiple scenarios forms a bigger picture of the entire case which we would need to handle. Systems get to have an interesting take away regarding the chain replication where one can read stale data from any server in the chain and this can hamper the performance of the network, and the ratio of updates can possibly become one-tenth of the replication. The performance of the system where data is spread in volumes across multiple chains is also evaluated and read throughout to permanently lower the after effects of failures even when a new server is added to the system as the server becomes the tail of all the chains in which the failed server was involved. An interesting observation that can be made is that the work throughput increases temporarily after a failure. This particularly happens because of the shorter length of chains and it means that the work done has to be less for each write until the failed server is replaced.
A testing connection between all members is an important aspect of forming a credible database network. In order to support replication, each member of a replica set must be able to connect to every other member. Connections must be verified in both directions since replication can be blocked through networking topologies and firewall configuration. If any configuration in any direction fails, you need to check your networking and firewall configuration and reconfigure your environment to allow these connections.
In the scenarios which involve rebooting the members of a replica set, you need to make sure that the set is able to elect a primary during the maintenance. This basically involves ensuring that a majority of the set's active member's votes are available.
Another important aspect of performance testing is checking the size of the oplog. A higher tolerance for lag is provided by a large oplog which ultimately makes the set more resilient. To check the size of the of the oplog for a given replica set member, connect to the member in mongo shell and run the rs.printReplicationInfo( ) method. The oplog should be long enough to hold all transactions for the longest downtime you expect on a secondary. We usually recommend the oplog to be of the same size on all members. If you go on resizing the oplog, resize it to all members.