03.07.2013, 06:43, "Takatoshi MATSUO" <matsuo....@gmail.com>: > Hi Stefano > > 2013/7/2 Stefano Sasso <stesa...@gmail.com>: > >> Hello folks, >> I have the following setup in mind, but I need some advice and one hint on >> how to realize a particular function. >> >> I have a N (>= 2) nodes cluster, with data storage on postgresql. >> I would like to manage postgres master-slave replication in this way: one >> node is the "master", one is the "slave", and the others are "standby" >> nodes. >> If the master fails, the slave becomes the master, and one of the standby >> becomes the slave. >> If the slave fails, one of the standby becomes the new slave. > > Does "standby" mean that PostgreSQL is stopped ? > If Master doesn't have WAL files which new slave needs, > new slave can't connect master. > > How do you solve it ? > copy data or wal-archive on start automatically ? > It may cause timed-out if PostgreSQL has large database. > >> If one of the "standby" fails, no problem :) >> I can correctly manage this configuration with ms and a custom script (using >> ocf:pacemaker:Stateful as example). If the cluster is already operational, >> the failover works fine. >> >> My problem is about cluster start-up: in fact, only the previous running >> master and slave own the most updated data; so I would like that the new >> master should be the "old master" (or, even, the old slave), and the new >> slave should be the "old slave" (but this one is not mandatory). The >> important thing is that the new master should have up-to-date data. >> This should happen even if the servers are booted up with some minutes of >> delay between them. (users are very stupid sometimes). > > Latest pgsql RA embraces these ideas to manage replication. > > 1. First boot > RA compares data and promotes PostgreSQL which has latest data. > The number of comparison can be changed using xlog_check_count parameter. > If monitor interval is 10 sec and xlog_check_count is 360, RA can wait > 1 hour to promote :) >
But in this case, when master dies, election a new master will continue one hour too. Is that right? > 2. Second boot > Master manages slave's data using attribute with "-l forever" option. > So RA can't start PostgreSQL, if the node has no latest data. > >> My idea is the following: >> the MS resource is not started when the cluster comes up, but on startup >> there will only be one "arbitrator" resource (started on only one node). >> This resource reads from somewhere which was the previous master and the >> previous slave, and it wait up to 5 minutes to see if one of them comes up. >> In positive case, it forces the MS master resource to be run on that node >> (and start it); in negative case, if the wait timer expired, it start the >> master resource on a random node. >> >> Is that possible? How can avoid a single resource to start on cluster boot? >> Or, could you advise another way to do this setup? >> >> I hope I was clear, my english is not so good :) >> thank you so much, >> stefano >> >> -- >> Stefano Sasso >> http://stefano.dscnet.org/ > > Regards, > Takatoshi MATSUO > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
