Tory M Blue tmblue at gmail.com
Fri Aug 14 14:16:52 PDT 2015
On Thu, Aug 13, 2015 at 3:51 PM, Tory M Blue <tmblue at gmail.com> wrote:

>
> Been a bit, but I'm back with a question.
>
> I'm looking at doing a migration from one site to another and eventually
> have a hot warm site.
>
> Right now I have a 5 box slony cluster at site A
>
> Site A: Node 1 and 2 can switch/fail, nodes 3-5 are partial and can't
> become master.
>
> Node 1: MASTER
> Node 2: SLAVE
> Node 3: QUERYSLAVE1
> Node 4: QUERYSLAVE2
> Node 5: QUERYSLAVE3
>
> I have a new 5 node cluster in Site B.
>
> Site B:  This is our default turn up, so they have the same NODE ID as
> Site A..
>
> Node 1: MASTER
> Node 2: SLAVE
> Node 3: QUERYSLAVE1
> Node 4: QUERYSLAVE2
> Node 5: QUERYSLAVE3
>
> I was really interested in Node 2 of Site A replicating to Node 1 of Site
> B, and then just let the other boxen in site B take their information from
> Node 1 of the same site.
>
>  I think there is going to be some confusion with NODE ID's. I believe I
> can tell Site A that the Master of Site B is actually node 10 <whatever>
> and get it replicating and be able to drop NODE 10 if I needed from site A.
> However if I end up switching to the Master in Site B,  It won't know how
> to tell SITE A to kiss off,  as the NODE's in it's config will be
> 1,2,3,4,5, which are the same as Site A, so there would be no real way for
> me to clean up and or remove SITE A devices, drop node using NODE ID would
> be no beuno.
>
> So I guess basically, do I have to have unique NODE ID's (think I do, but
> if not??). It will just require some rework for every site I bring up,
>  this means I have a few different configurations and or scripts to use
> depending on what site the cluster is in.
>
> Is this sort of clear, murky yet you have the general idea, or holy carp
> Tory what are you asking?
>
> Thanks
> Tory
>


Okay so someone pinged me off list and stated yes NODE ID's have to be
unique, okay figured but that's good to know.

Now I'm wondering how to best setup the replication.

If Site A has

(Nodes 1-5)
MASTER - Replicates to the 4 servers below
SLAVE
QUERYSLAVE1,2,3

Site B has similar

(Nodes 11-15)
DRMASTER - Replicates to the 4 servers below.
DRSLAVE
DRQUERYSLAVE1,2,3

I was just thinking I would add DRMASTER as a slave off of SLAVE. Since
SLAVE has forward = yes, it could easily forward the data on to DRMASTER
and DRMASTER could in turn send all that DATA down it's pipe to
DRSLAVE/DRQUERYS*

I've run into a couple of issues and that is that it seems that all nodes
in site A become aware of DRMASTER from site B, and not sure I want that
and/or if it's possible to get around that.

The paths should be in site A

Master <-> Slave (set 1-3)
Master <-> Queryslave* (set 1)
Slave <-> Queryslave* (set 1) (due to switchover possibility).

paths in site B

DrMaster <-> DRSlave (set 1-3)
DrMaster <-> DRQueryslave* (set 1)
DrSlave <-> DRQueryslave* (set 1) (due to switchover possibility).


Then I would add a new path

Slave <-> DrMaster (set 1-3)

I'm wondering if I'm looking at this right. These are 2 separate clusters
but the data has to be in sync and I'm looking to use this as a site
migration tool.

BTW we have been using slony for over 9 years ,so I'm not totally new to
it, but it's always been isolated into it's own cluster (prod, staging, Qa,
Dev etc), now I'm looking to use it as a migration mechanism between 2
clusters at differing locations.

Thanks and sorry for being dense
Tory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20150814/79f9d8ae/attachment.htm 


More information about the Slony1-general mailing list