On Thu, Jul 14, 2011 at 5:50 AM, RNZ <[email protected]> wrote: > > > On Thu, Jul 14, 2011 at 3:28 PM, Florian Haas <[email protected]>wrote: > >> On 2011-07-14 12:55, RNZ wrote: >> > >> > >> > On Thu, Jul 14, 2011 at 2:02 PM, Florian Haas <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On 2011-07-14 08:46, RNZ wrote: >> > > No, I want and I need - multi-master scheme (more then two >> nodes)... >> > >> > There is nothing in Pacemaker's master/slave scheme that restricts >> you >> > to a single master. The ocf:linbit:drbd resource agent, for example, >> is >> > configurable in dual-Master mode. >> > >> > Once the resource agent properly implements the functionality (the >> hard >> > part), configuring a multi-master master/slave set is simply a >> question >> > of setting the master-max meta parameter to a value greater than 1 >> (the >> > easy part). >> > >> > I don't think so... Couchdb RESTful API very easy allow running >> > repliacate by next scheme: >> >> It's entirely possible that the couchdb native API may be more powerful >> in specific regards, but if you want to put it into a Pacemaker cluster >> you may have to occasionally accept some minor limitations. That's a >> tradeoff which is present for all Pacemaker managed applications. > > I understand that. But I don't understand why pacemaker not allow to change > resource location, based on other resource state? It's like a self-evident > functional... Did not it? >
Why it does you can use collocation or groups. If you can somehow separate one instance of you CouchDB from other (Andrew suggested a master role for example) you can tie up vIP to that instance with a collocation constraint. Other way if you uniquely identify all of your instances than again you can collocate you vIP with one of them. > > >> > primitive cdb0 >> > hostA: hostB:dbB > localhost:dbB >> > hostA: hostC:dbC > localhost:dbC >> > hostA: hostD:dbD > localhost:dbD >> > primitive cdb1 >> > hostB: hostA:dbB > localhost:dbB >> > primitive cdb2 >> > hostC: hostA:dbC > localhost:dbC >> > >> > In this scheme hostA used as master for hostB and hostC (master-master) >> > and as slave for hostD (slave-master). Both (master-master and >> > slave-master for different servers/databases) scheme per one instance. >> >> So you mean there would be a cascading replication, like so: >> >> hostD >> | >> hostA >> / \ >> hostB hostC >> >> Such a thing is not something Pacemaker caters for specifically, but I >> dare say it doesn't need to, either. You would simply create one >> master/slave set where D is master and A is slave, and another where A >> is master and B and C are slaves. >> > > Florian, no this example scheme not cascade, hostA usead as slave for hostD > and as master/slave from hostB and hostC > hostB <---> hostA <---> hostC > ^ > | > hostC----------- > > > By the way, is there any specific reason you are contributing under a >> > pseudonym? It's highly unusual in this community to do so. >> > >> > >> Pleased to meet you Alibek, welcome to the tribe. :) >> > > Thank you Florian, me too peased to meet you! 8) > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ > > -- Serge Dubrouski.
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
