Jut a small correction on the formula:
to connect to mongod on location N use localhost:${27019 + N}
The rest seems to be OK.
If the mongo replication process is robust then restarting stunnel when
adding a location should not be a problem.
(If you start at port 27020 for the master then slave 1 has port 27021,
slave 2 port 27022 etc etc, seems more intuitive/easier).
Paul.
Douglas Hubler <[email protected]> wrote on 18-04-2011 18:12:44:
> Goal
> =========
> Devise a mongo database replication topology where there is one
> primary location (master) and up to 50 secondary locations (slaves).
> Configuration information will flow from primary to secondary machines
> only. Local data like registrations will flow from any location to
> any, all or multiple other locations. Admins will want to bring
> locations on and off line w/minimal disruption to the services.
>
> Assertions
> ========
> - in 4.6, for security reasons each mongod service will be configured
> to disallow connections from remote machines. Instead connections to
> each mongod instance will go thru stunnel to authorize, authenticate,
> encrypt.
>
> Plan
> ========
> So i'm going to be creating an stunnel config that could potentially
> open a connection to the mongod service on any other location. The
> port to connect to the primary location will be 27019, The port range
> to connect to secondary locations will start at 27020 and increment by
> one until the last location is mapped.
>
> Example:
> to connect to mongod on primary location use localhost:27019
> to connect to mongod on location 1 use localhost:27020
> to connect to mongod on location 2 use localhost:27021
> ...
> to connect to mongod on location N use localhost:${27020 + N}
>
> So this means every time a new location is added or removed, a new
> stunnel config will need to be replicated and the stunnel service on
> each server will need to be restarted. Consequently all open
> replication connections will be interrupted. However, we will be
> introducing the concepts of locations that are enabled and disabled.
> This will be important to take servers out of rotation in case they
> are unavailable for whatever reason. When locations are enable or
> disabled, the stunnel configuration will not change, where to
> replicate based on enabled state will be handled in the application
> layer.
>
> Implementation Notes
> ==================
> * It will be up to the local replication modules like the registration
> replicator to honor enabled or disabled locations and act
> appropriately. This replicator will also have to be able to map a
> location with it's stunnel local port mapping. E.g. If location
> number 6 on host foo.example.com is disabled, then all other locations
> should not attempt to replicate to localhost:27025. This mapping
> could easily be written to a config file as part of stunnel config
> file replication to abstract out the mapping.
> _______________________________________________
> sipx-dev mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
