nicknaychov opened a new issue #2382: CouchDB backup instance - zones vs replicas? URL: https://github.com/apache/couchdb/issues/2382 Hi I just got a nontraditional Christmas thought popping up in my mind :). I would like to setup backup of the main CouchDB install in second datacenter. Note that second setup will work only in case the first setup in the main datacenter is down. In the main datacenter I currently have 3 Couchdb's. In the second datacenter I would like to have 1 CouchDB. I do not want to mirror first setup of setting 3 VMs due to overhead related with that of managing&supporting another 3 VMs, plus cost is also consideration. Initially I was thinking of setting second zone for CouchDB back up site with settings: q=3 r=1 w=1 n=1 z=2 but not sure how adding new zone to existing setup works or if I need to do some re-balancing (I've never done CouchDB zoning). Plus I think this might be "over-engineering" of what I am trying to do. So I would like to find simpler/more effective approach, just like I do for each thing :) What about If I just move one of the three CouchDB nodes to the backup site? I known the read/writes should not happens over WAN and only replication should so what would be the best approach? Current setup is: ``` q=3 r=2 w=2 n=3 ``` so I am thinking of changing to : ``` q=3 r=1 w=1 n=3 ``` Thus I will guarantee that read and writes will not leave the site and happens over WAN. This is important due to security concerns and prevent slow downs due to DB quorum requirements, while optimizing server setup at the same time? Or this is stupid and I should just use 2 zones? Any feedback or thoughts how you would backup your site instance and if above would work well will be much appreciated. Thanks [NOTE]: # ( ^^ Provide a general summary of the RFC in the title above. ^^ ) # Introduction ## Abstract [NOTE]: # ( Provide a 1-to-3 paragraph overview of the requested change. ) [NOTE]: # ( Describe what problem you are solving, and the general approach. ) ## Requirements Language [NOTE]: # ( Do not alter the section below. Follow its instructions. ) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt). ## Terminology [TIP]: # ( Provide a list of any unique terms or acronyms, and their definitions here.) --- # Detailed Description [NOTE]: # ( Describe the solution being proposed in greater detail. ) [NOTE]: # ( Assume your audience has knowledge of, but not necessarily familiarity ) [NOTE]: # ( with, the CouchDB internals. Provide enough context so that the reader ) [NOTE]: # ( can make an informed decision about the proposal. ) [TIP]: # ( Artwork may be attached to the submission and linked as necessary. ) [TIP]: # ( ASCII artwork can also be included in code blocks, if desired. ) # Advantages and Disadvantages [NOTE]: # ( Briefly, list the benefits and drawbacks that would be realized should ) [NOTE]: # ( the proposal be accepted for inclusion into Apache CouchDB. ) # Key Changes [TIP]: # ( If the changes will affect how a user interacts with CouchDB, explain. ) ## Applications and Modules affected [NOTE]: # ( List the OTP applications or functional modules in CouchDB affected by the proposal. ) ## HTTP API additions [NOTE]: # ( Provide *exact* detail on each new API endpoint, including: ) [NOTE]: # ( HTTP methods [HEAD, GET, PUT, POST, DELETE, etc.] ) [NOTE]: # ( Synopsis of functionality ) [NOTE]: # ( Headers and parameters accepted ) [NOTE]: # ( JSON in [if a PUT or POST type] ) [NOTE]: # ( JSON out ) [NOTE]: # ( Valid status codes and their defintions ) [NOTE]: # ( A proposed Request and Response block ) ## HTTP API deprecations [NOTE]: # ( Provide *exact* detail on the API endpoints to be deprecated. ) [NOTE]: # ( If these endpoints are replaced by new endpoints, list those as well. ) [NOTE]: # ( State the proposed version in which the deprecation and removal will occur. ) # Security Considerations [NOTE]: # ( Include any impact to the security of CouchDB here. ) # References [TIP]: # ( Include any references to CouchDB documentation, mailing list discussion, ) [TIP]: # ( external standards or other links here. ) # Acknowledgements [TIP]: # ( Who helped you write this RFC? )
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
