You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2020/01/02 10:15:11 UTC

[GitHub] [couchdb] nicknaychov opened a new issue #2386: CouchDB Zones: How to verify if zones are setup correctly?

nicknaychov opened a new issue #2386: CouchDB Zones: How to verify if zones are setup correctly?
URL: https://github.com/apache/couchdb/issues/2386
 
 
   
   Hello & Happy New Year to all!
   
   I recently split my cluster into 2 zones. The question now is how to find out if that was successful?
   Could not find anything in your docs or with google.
   After all information related to setting, experimenting and use cases with CouchDB zoning seems very shy :)
   I can verify replication is working, since creating/deleting of DBs reflect to all nodes.
   I just want to ensure that R/W requests done in zone 1 are not send to zone 2. How this can be verified? 
   I enabled debug, but it looks this type of internal information is not logged.
   
   Any ideas would be welcome
   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:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [couchdb] kocolosk closed issue #2386: CouchDB Zones: How to verify if zones are setup correctly?

Posted by GitBox <gi...@apache.org>.

kocolosk closed issue #2386: CouchDB Zones: How to verify if zones are setup correctly?
URL: https://github.com/apache/couchdb/issues/2386
 
 
   

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [couchdb] nicknaychov commented on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?

Posted by GitBox <gi...@apache.org>.

nicknaychov commented on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?
URL: https://github.com/apache/couchdb/issues/2386#issuecomment-574241520
 
 
   Yes it helps, thanks @wohali .
   
   My point was, in order to keep in sync the third node rather than sending R/W, ( quorum can be satisfied by the local 2 nodes), thus maybe binary replication protocol could be used or something more efficient. Just an idea, I am sure it is not easy and might need drastic changes on the backend.
   
   CouchDB 4.0 That would be awesome! Thanks for the link.
   
   What would be you recommendations then for people which have mirrored deployments on two DCs, both running live traffic and need to share same consistent data across both DCs. Each need to be aware of each other data with minimal delay.
   Would you still recommend master-master replication?  I heard for issues there as well - with increased latency and decreased throughput due to the serialization of data into the JSON format.
   
   Does this approach scale well if you have let's say 3 DCs?
   
   Thanks

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

[GitHub] [couchdb] nicknaychov edited a comment on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?

Posted by GitBox <gi...@apache.org>.

nicknaychov edited a comment on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?
URL: https://github.com/apache/couchdb/issues/2386#issuecomment-572687087

@kocolosk wow this is big. You just saved me a lot of time and I believe to many other people as well!

I think that should be put somewhere in important place of the documentation:

**r,w and z parameters are not supported anymore.**
(Even better if couchdb display error if sees them, would be awesome. )

**n parameter will be overridden by "placement" if present** - I saw this already in the docs.

I think CouchDB is great project but there is a lot of pitfalls and lack of good docs, which makes a lot of people to give up and move on with other solutions.

I think replication, n (replicas) and placement are maybe overlapping and confusing concepts for some, thus clarification when and what should be used will help many people I am sure.

Example, in my case I have a lot of DBs which get added and removed on the fly by the upper layer logic, so I think I need special script for detecting that and start/stop DB replications.
So replication is not suitable in my case.

If I use the approach with n=3 replicas, 2 nodes on local site and one on remote site, that means unnecessary WAN load and delayed performance.

Thus I think optimal solution would be using DB placement with two replicas hosted on local site and 1 on remote. This way I think will achieve that R/W will occur only on the local site(if both nodes are up) to avoid unnecessary WAN delays, while in case of emergency I will have backup.

If @kocolosk or somebody else can confirm my statements will be much appreciated.
I think that would be good example and candidate for the best practices section - deployments.
Thank you.

----------------------------------------------------------------
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:
users@infra.apache.org

With regards,
Apache Git Services

[GitHub] [couchdb] nicknaychov commented on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?

Posted by GitBox <gi...@apache.org>.

nicknaychov commented on issue #2386: CouchDB Zones: How to verify if zones are setup correctly?
URL: https://github.com/apache/couchdb/issues/2386#issuecomment-572457662

thank you for answer @kocolosk .

That makes things little bit clearer. Just to add, I do not use placement but just z=2. I rely on "automatic" placement, since I need second cluster to be used as backup in case main site is down. I use couchdb prior to introducing the placement option, so I am not sure if I should use it and how exactly will fit in my case.

Would you actually recommend using of placement param in favor of z parameter?

Is there any link describing when we should use placement vs the z param? Maybe one of them should be deprecated in future releases if they overlap functionality in order to avoid confusion.

In my case with 4 nodes, 2 zones(z=2) and n=3 without using DB placement, if request comes to zone 1 then R/W will be done only to the 2 nodes from that zone and there will be no WAN crossing, correct?
My purpose is to avoid WAN crossing and thus slowing down the cluster.

BTW Shard map looks ok:
`"shards": {
"00000000-55555554": [
"couchdb@pbx1-z1.domain.ca",
"couchdb@pbx1-z2.domain.ca",
"couchdb@pbx2-z2.domain.ca"
],
"55555555-aaaaaaa9": [
"couchdb@pbx1-z1.domain.ca",
"couchdb@pbx1-z2.domain.ca",
"couchdb@pbx2-z1.domain.ca"
],
"aaaaaaaa-ffffffff": [
"couchdb@pbx1-z2.domain.ca",
"couchdb@pbx2-z1.domain.ca",
"couchdb@pbx2-z2.domain.ca"
]
}`

Many thanks to anybody who can shed some light on this.