I'm interesting in using replica set feature on Mongo as a method for smoothly migrating between machines. My Mongo database is currently a standalone instance. I realize the recommended practice is to have three independent instances running as a replica set. But our availability requirements are not currently high enough to justify the cost of running three independent instances. That being said I want to avoid downtime as much as possible.
When making a big change to a server what I would ideally like to do is boot up a new server with the changes needed (perhaps cloned from the original or perhaps built from scratch with the desired changes made). This server is hosting the mongo database.
While testing this new server I want it to be a hidden secondary. This way it has the data but doesn't actually answer client requests. Once I feel comfortable with the new server I want to switch things so the new server is the primary and the old server is a hidden secondary. This way the old server continues to get data but isn't handling client requests. If a problem is detected I can flip the primary and secondary again to send the clients back to the old server. Assuming no problems after several days I can shut down the old server.
My questions are:
- What problems might I encounter with this method?
- Will it achieve my goal of moving the data from one server to another (and the clients from one server to another) with hopefully zero downtime?
- Since I may want to do this for future changes I would probably leave the new server as a replica set with 0 members. I realize this doesn't offer the high availability that at least three members offers. But will it hurt anything to leave it this way? Or would be be best to switch it back to a standalone instance?