On 05/21/2016 05:56 PM, Tory M Blue wrote: > This maybe an odd request and let me preface this by saying, we have > used Slony for over 10 years, it works great, we have had no real > major issues. > > However my data sets, index creation times are starting to mean that a > drop/add of my master or a full replicated slave, takes about 15 hours > to come back on line (only takes about 2 hours to copy the data, but > some indexes take 7 hours on their own).. So any maintenance that > requires a drop/add (upgrades), requires a herculean effort, even with > dropping indexes and adding them at the end manually and concurrently > (as much as possible) > > So I was thinking with a master-master setup that Postgres provides, > could I run Postgres replication between the master servers > (master/slave), and run Slony to create our read only db's (these take > a bit less than 30 minutes to create)?
I am not sure what you mean by 'master-master'. Postgresql core doesn't currently contain any 'master-master' solutions, there are numerous extensions or third party projects that claim some form of 'master-master' solution each with a definition of 'master-master' and different limitations. It is really hard to say if slony is compatible with one without understanding which one you are talking about. Postgresql core does have built in master / standby replication (streaming replication). You can do a streaming replica for failover purposes and a slony replica for your reporting server. If your streaming replica is an asynchronous replica then there is a risk that following a failover it is possible that the slony replica saw transactions that never made it to the streaming replica. The solution to this is to rebuild your slony replica following a failover (as a matter of procedure/practice) OR use a synchronous replica > > I've been unsuccessful in determining why the index creation takes so > long (and right, it's not Slony, it's Postgresql!!) > > I would love to keep Slony for the read only query DB's and like I > said considering moving to Postrgresql replication for the > master/master. My query DB's only need about 5% of the data that is in > the insert master/slave, so using Postgresql replication and forcing > the same huge size db on each smaller query node, doesn't sound very > appetizing. > > The other issue is any heavy process causes Slony to backup, major > deletes back up, and it's just getting worse. > > Is this silly, is it either/or and I should now this? > > Thanks > Tory > _______________________________________________ > Slony1-general mailing list > Slony1-general@lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general > _______________________________________________ Slony1-general mailing list Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general
