It's always good to keep somewhere another node that will act as backup for master one. The backup process could be set via persistent continuous replications by using replicator db.
But for common case, a bit better to follow "rule of three" in production : one active master instance, one slave that will become master when previous one fall and one backup instance that will restore fallen master without causing additional load on active instances. Customize scheme to fit your environment, loads and needs. In my production experience for 2 years of uptime there was never need in backup/restore process - CouchDB just worked and well, but still but it's better to be prepared for the worst cases since everything could happened (hardware problems, bad sectors, etc.). -- ,,,^..^,,, On Wed, Jul 17, 2013 at 10:41 PM, Dan Santner <[email protected]> wrote: > I'm about to put together my production environment using couchdb as the > backend. I've been running my test environment on a single linux node > (couchdb ver 1.2) for about a year without even restarting it once! That > activity has actually been more than I can imagine in our production > environment, however, I'm nervous about going into production running a > single node. > > So...my question to you guys is this? Do I look into running big couch, and > does that even handle redundancy or just sharding? Do I simply setup two > nodes and let them cross replicate? Cross replication just seems ripe for > problems, but I've never tried it so I'm asking you all what you'd do. > > My production traffic will not be high by any measure. There will be bursts > of activity but as mentioned, nothing a single node hasn't been able to > handle so far. > > Any experiences you guys have to share is appreciated. > > Dan.
