Details
-
Bug
-
Resolution: Won't Fix
-
Major - P3
-
None
-
*Location*: https://docs.mongodb.org/v3.0/tutorial/deploy-geographically-distributed-replica-set/
*User-Agent*: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.3.0
*Screen Resolution*: 1080 x 675
*repo*: docs
*source*: tutorial/deploy-geographically-distributed-replica-set
*Location*: https://docs.mongodb.org/v3.0/tutorial/deploy-geographically-distributed-replica-set/ *User-Agent*: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.3.0 *Screen Resolution*: 1080 x 675 *repo*: docs *source*: tutorial/deploy-geographically-distributed-replica-set
-
0.25
Description
A user on IRC suggested that this document (considering the 3 nodes example) includes reasoning as to why having a single node in site B actually provides a geographically redundant set. The node in site B can for example never become a primary node - and hence not being fully redundant.
It could also benefit from updates (or a link to) as to how to really make a data centre geographic set-up work - and the only way (As far as I know) to do that, is by using at least one node in a tertiary data centre.
Reporter: Derick