Re: WAL replication question

From: Keith Ouellette <Keith(dot)Ouellette(at)Airgas(dot)com>
To: Michael Wood <esiotrot(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)mail(dot)com>, "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org>
Subject: Re: WAL replication question
Date: 2013-01-24 19:54:59
Message-ID: 417C5AF7C228B94490192951394BEFE7AD4954@AIPHLEXDAG01B.airgas.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

Michael,

Good points. Instead of automating the recovery, I am now forcing someone to look at the failed unit, by automatically putting that node in standby. At this point, it makes things more stable and predictable.

Thanks,
Keith

________________________________________
From: Michael Wood [esiotrot(at)gmail(dot)com]
Sent: Tuesday, January 22, 2013 8:49 AM
To: Keith Ouellette
Cc: Kevin Grittner; pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] WAL replication question

Hi

On 22 January 2013 15:22, Keith Ouellette <Keith(dot)Ouellette(at)airgas(dot)com> wrote:
> Kevin,
>
> I understand the confusion. What I am being asked to do is the following:
>
> 1. Use pacemaker to determine who should be the Master node so it can assign a virtual IP to it.
>
> 2. Use the lsb:postgresql RA as a master resource to monitor the postgresql process on each node
>
> 3. Failover to the slave node when the master fails. Pacemaker moves over the virtual IP. I detect that in a process I run (script that checks the location of the virtual IP) and promote the slave to master using the trigger file.
>
> 4. When the failed server comes back up, I detect that it should no longer be master using the process and sync it to the new master, create the recovery.conf file and restart the postgres process.

How about at step 4:

When the failed server comes back up, do not automatically start
postgres, or in some other way prevent Pacemaker from thinking the
node is ready. Then, when you've done whatever you need to to get it
ready as a slave, start it up and Pacemaker can see that it is now
ready.

> The issue is when we restart the postgresql, Pacemaker takes that node "down" in alarm. The team lead does not want that. I am just wondering if it was possible to bring up the recovered server without restarting the postgresql process?

I think the main thing is that until you've finished reconfiguring
postgres it is not "recovered", so you need to make sure Pacemaker
doesn't think it is recovered before it's actually ready.

Unless I've missed something :) (I have no experience with Pacemaker
or postgres replication.)

--
Michael Wood <esiotrot(at)gmail(dot)com>

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Darryl Pye 2013-01-27 11:02:26 Schemas and views
Previous Message Jack Kaufman 2013-01-24 16:42:29 Prevent pgAdmin disconnect