Shulou(Shulou.com)06/01 Report--

A more complex, but flexible method for routing report queries to a dedicated node to use tags and read preferences.

Because of the use of hidden members, set a member to priority: 0, but not set it to hidden. However, assign a tag use: reporting:

PRIMARY > conf = rs.config () {"_ id": "test", "version": 21, "members": [{"_ id": 0, "host": "xucy.local:27017",}, {"id": 1, "host": "xucy.local:28017",}, {"_ id": 2, "host": "xucy.local:29017" }]} / / we'll use members [1], the instance on port 28017 PRIMARY > conf.members [1] .priority = 0 PRIMARY > conf.members [1] .tags = {"use": "reporting"} PRIMARY > conf.version + = 1 PRIMARY > rs.reconfig (conf) [.]

As before, xucy.local:28017 will never be the master; however, in this case the other two machines become unreachable and your application will be able to handle reading to the report server. It will continue needless to say that your report should be suspended during such an event.

Your report code will look like this (using Python, this time):

From pymongo import MongoReplicaSetClient from pymongo.read_preferences import ReadPreference rep_set = MongoReplicaSetClient ('xucy.local:27017,xucy.local:28017,xucy.local:29017', replicaSet =' test', read_preference = ReadPreference.SECONDARY, tag_sets = [{'use':'reporting'}]) # check to ensure we're not running reporting against the sole remaining secondary if rep_set.primary is not None: rep_set.my_application.users.aggregate (...)

The above only sends the report query to the copy marked with use: reporting, and it avoids running at all if there is no master available. In practice, you will throw exceptions and handle them in your extension code if you find that there is no master! Even better, your monitor can set the values available at run time, and you can transfer, for example, reporting_system.ok ().

Benefits and considerations

Using tags and reading preferences allows some levels of flexibility, which is not possible in hidden members.

Report instances can be easily added

Because your connection code is definable instead of assigning to a dedicated host, add more nodes to report jobs, just add them and mark them, like this:

PRIMARY > rs.add ({_ id:3, host: "xucy.local:30017", priority:0, tags: {'use':'reporting'}})

Your existing code will take advantage of the new capacity, and the replication set will continue to run without triggering elections and disconnecting from the client.

Report instances can be skipped or deleted

Report tags can be moved or even removed if you need to provide read bandwidth to other jobs if necessary. A reconfiguration like this will trigger the election and reconnect all clients, but this will be no worse than the other options. Note: this is an anti-pattern to increase common capacity by publishing production read replica members. It's just an emergency.

Some drivers need to be synchronized manually

The Ruby driver (like 1.9.2), for example, does not refresh the view of the replica set unless the client initializes it explicitly like this, using refresh_mode:: sync. Check your driver documentation.

Conclusion

Simple replication configuration has become one of the reasons I like MongoDB, which makes MySQL replication look like it came from the Stone Age. It's a little rough, but it's already improving performance. Whether you use tag collections or hide members, build a report architecture based on MongoDB's replication attributes, simplifying operations and allowing you to focus on building a great application.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.