In the event of a schema change we will be taking down the master node and one slave node, rebuilding replication on them then doing the other slave nodes one at a time.
Ex we have 3 slave nodes. This is how I envision it going. - Update schema on master & slave 1 - Create replication set on master & slave 1 - Update schema on slave 2 - Add slave 2 to replication set - Update schema on slave 3 - Add slave 3 to replication set >From what I'm reading, I would not have to add the paths for slave 2 & 3 until >I am ready to add them to the set, is this correct? Shaun McCloud, MCDST | Associate Software Developer Geo-Comm Inc. | www.geo-comm.com -----Original Message----- From: Christopher Browne [mailto:[email protected]] Sent: Tuesday, May 22, 2012 12:53 To: Shaun McCloud Cc: [email protected] Subject: Re: [Slony1-general] Run pgAdmin II Slony-I Creation scripts outside of pgAdmin III? On Tue, May 22, 2012 at 1:40 PM, Shaun McCloud <[email protected]> wrote: > Ok, > > I will do more research using that method. I was planning on allowing a user > to run the app on the Master node and each slave node to allow then to add > one slave at a time (due to the fact that we must maintain 100% uptime in the > event of a schema change). That shouldn't be an issue when using Slonik > directly, correct? Everything that can be configured can certainly be configured using Slonik; its use shouldn't restrict you in any additional ways. I don't imagine you can actually get "100% uptime," but that's a broader issue not particularly relevant to this. There are some actions that are likely to lead to some locking of database objects (see the Slony documentation; each Slonik command has a section describing locking implications) that would effectively lower uptime from 100%. _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
