On Feb 13, 2008 6:41 AM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote: > Serge Dubrouski írta: > > > On Feb 13, 2008 4:29 AM, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote: > > > >> Andrew Beekhof írta: > >> > >>> On Feb 12, 2008, at 8:57 PM, Zoltan Boszormenyi wrote: > >>> > >>> > >>>> Andrew Beekhof írta: > >>>> > >>>>> On Feb 12, 2008, at 4:59 PM, Zoltan Boszormenyi wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Serge Dubrouski írta: > >>>>>> > >>>>>>> pgsql OCF RA doesn't support multistate configuration so I don't > >>>>>>> think > >>>>>>> that creating a clone would be a good idea. > >>>>>>> > >>>>>>> > >>>>>> Thanks for the information. > >>>>>> > >>>>>> Some other questions. > >>>>>> > >>>>>> According to http://linux-ha.org/v2/faq/resource_too_active > >>>>>> the monitor action should return 0 for running, 7 ($OCF_NOT_RUNNING) > >>>>>> for downed resources and anything else for failed ones. > >>>>>> Either this documentation is buggy, > >>>>>> > >>>>> no > >>>>> > >>>>> > >>>>>> or heartbeat doesn't conform to its own docs. > >>>>>> > >>>>> also no > >>>>> > >>>>> > >>>>>> Here's the scenario: londiste creates a pidfile and deletes it when > >>>>>> it quits correctly. > >>>>>> However, if I kill it manually then the pidfile stays. What should > >>>>>> my script return > >>>>>> when it detects that the process with the indicated PID is no > >>>>>> longer there? > >>>>>> It's not a "downed" resource, it's a failed one. So I returned > >>>>>> $OCF_ERR_GENERIC. > >>>>>> But after some time heartbeat says that my resource became > >>>>>> "unmanaged". > >>>>>> > >>>>> i'm guessing (because you've not included anything on which to > >>>>> comment properly) that the stop action failed > >>>>> > >>>> It shouldn't have failed, stop action always returns $OCF_SUCCESS. > >>>> > >>>> > >>>>>> In contrast to this, the pgsql OCF RA does it differently. It > >>>>>> always returns 7 > >>>>>> when it finds that there's no postmaster process. Which is the > >>>>>> right behaviour? > >>>>>> > >>>>> it depends what you want to happen. > >>>>> if you want a stop to be sent, use OCF_ERR_GENERIC. > >>>>> if the resource is stateless and doesnt need any cleaning up, use > >>>>> OCF_NOT_RUNNING > >>>>> > >>>> It's quite an important detail. Shouldn't this be documented at > >>>> http://linux-ha.org/OCFResourceAgent ? > >>>> > >>> yep. but its a wiki so anyone can do that :) > >>> > >> I see. It's an excuse because no one did it yet. :-) > >> > >> Yesterday another problem popped up and I don't understand why > >> didn't it happen before. I upgraded to heartbeat 2.1.3 using the > >> SuSe build service packages at > >> http://download.opensuse.org/repositories/server:/ha-clustering/ > >> but the problem seems persisting. I have two pgsql resources, > >> using the stock install on my Fedora 6, i.e. pgdata=/var/lib/pgsql/data. > >> Both are tied to their respective nodes, symmetric_cluster on, > >> the constraints' score is -INFINITY for running them on the wrong node. > >> The documentation of heartbeat said that for a symmetric cluster > >> it's the way to bind a resource to a node (or to a set of nodes). > >> The problem is that after the first pgsql resource is started successfully > >> on the first node then the second pgsql resource is checked whether > >> it's running on the first node - surprise, surprise, the system indicates > >> that it does. As a consequence, it's marked as startup failed and > >> heartbeat doesn't try to start it on the second node. Doing a cleanup > >> on the failed second pgsql resource makes it start but now the first > >> pgsql resource is marked failed. I guess because of the cleanup, > >> the second pgsql is thuoght to be running on node1 and is stopped. > >> The monitor action of the first resource notices that is's dead. > >> Catch 22? > >> > >> Turning the configuration upside down (symmetric_cluster off > >> and using +INFINITY rsc_location scores for binding to the correct > >> node) didn't help. > >> > >> How can I solve this besides using a different PGDATA directory > >> on the second node? The two machines is supposed to be configured > >> identically regarding PostgreSQL. > >> > > > > Attached is a patch for pgsql that supposedly fixes this issue. Please > > test it and let me know the results. > > > > Thanks, but why not simply use pg_ctl status? > > --- old_ocf/pgsql 2008-01-25 17:16:52.000000000 +0100 > +++ pgsql 2008-02-11 06:15:28.000000000 +0100 > @@ -267,7 +267,7 @@ > # > > pgsql_status() { > - pgrep -u $OCF_RESKEY_pgdba "postmaster|postgres" >/dev/null 2>&1 > + runasowner "$OCF_RESKEY_pgctl -D $OCF_RESKEY_pgdata status > >/dev/null 2>&1" > } > > # > > This one above solved the problem for me. > But it requires that I use different PGDATA on different nodes.
Why would you need to have the same PGDATA for different instances of PostgreSQL? Imagine what would happen at the failover time. You'll have 2 instances of PostgreSQL trying to start on the same PG_DATA which, I'm affraid isn't a good idea. > It seems your patch isn't different in this regard. Your mods: > 1. if $PIDFILE is readable, look at the PID it has > 2. if not, look at the processes The problem is that by default PG_DATA isn't readable by everybody, but OCF spec requires that "status" command should work for any user, also "stop" command should report service down for for stopped service for any user as well. That's why I have to use this double logic. > It still have problems with identical PGDATA directories. > Do you have an idea how to distinguish in that case? Still don't understand why do you need to have the same PG_DATA? Are you trying to build a cluster with 2 instances of PostgreSQL each of each is tied to particular node? > > > > >> And a question about 2.1.3. After the upgrade, haclient couldn't connect > >> because mgmtd wasn't started. I needed to add these two lines to ha.cf: > >> > >> apiauth mgmtd uid=root > >> respawn root /usr/lib64/heartbeat/mgmtd -v > >> > >> Is it really needed? It wasn't for 2.0.8 and the docs say that > >> it's not necessary since 2.0.5. Documentation got outdated again, > >> or something broke? > >> > >> -- > >> ---------------------------------- > >> Zoltán Böszörményi > >> Cybertec Schönig & Schönig GmbH > >> http://www.postgresql.at/ > >> > >> > >> _______________________________________________ > >> > >> Linux-HA mailing list > >> [email protected] > >> http://lists.linux-ha.org/mailman/listinfo/linux-ha > >> See also: http://linux-ha.org/ReportingProblems > >> > >> > > > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > -- > ---------------------------------- > Zoltán Böszörményi > Cybertec Schönig & Schönig GmbH > http://www.postgresql.at/ > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > -- Serge Dubrouski. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
