Re: what to do after a failover

--0000000000008a42b3059bb3b307
Content-Type: text/plain; charset="UTF-8"

Thanks for the response.
I am using Postgresql 11.
I want something simple and I have a strong preference toward using stock
tools. After the promotion and the original master comes online, I was
thinking of doing a pg_basebackup to sync. Any thoughts about that? I had a
very hard time with pg_rewind and I didn't like its complexity.



On Wed, Jan 8, 2020 at 11:31 PM Michael Paquier <[email protected]> wrote:

> On Wed, Jan 08, 2020 at 11:06:28PM -0500, Rita wrote:
> > I run a master and standby setup with Postgresql 11. The systems are
> > identical from a hardware and software setup.  If the master goes down I
> > can do a pg_ctl promote on the standby and point my applications to use
> the
> > standby (new master).
> >
> > Once the original master is online, when is an appropriate time to fail
> > back over? And are there any other things besides promote after the
> > failover is done?
>
> Make sure that you still have an HA configuration able to handle
> multiple degrees of failures with always standbys available after a
> promotion.
>
> The options available to rebuild your HA configuration after a
> failover depend on the version of PostgreSQL you are using.  After a
> failover the most simple solution would be to always recreate a new
> standby from a base backup taken from the freshly-promoted primary,
> though it can be costly depending on your instance.  You could also
> use pg_rewind (available in core since 9.5) to recycle the previous
> primary and reuse it as a standby of the new promoted custer.  Note
> that there are community-based solutions for such things, like
> pg_auto_failover or pacemaker-based stuff just to name two.  These
> rely on more complex architectures, where a third node is present to
> monitor the others (any sane HA infra ought to do at least that to be
> honest).
> --
> Michael
>


-- 
--- Get your facts first, then you can distort them as you please.--

--0000000000008a42b3059bb3b307
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the response.=C2=A0<div>I am using Postgresql 1=
1.<br><div>I want something simple and I have a strong preference toward us=
ing stock tools. After the promotion and the original master comes online, =
I was thinking of doing a pg_basebackup to sync. Any thoughts about that? I=
 had a very hard time with pg_rewind and I didn&#39;t like its complexity.=
=C2=A0</div><div><br></div><div><br></div></div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 8, 2020 at 11:3=
1 PM Michael Paquier &lt;<a href=3D"mailto:[email protected]">michael@paq=
uier.xyz</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">On Wed, Jan 08, 2020 at 11:06:28PM -0500, Rita wrote:<br>
&gt; I run a master and standby setup with Postgresql 11. The systems are<b=
r>
&gt; identical from a hardware and software setup.=C2=A0 If the master goes=
 down I<br>
&gt; can do a pg_ctl promote on the standby and point my applications to us=
e the<br>
&gt; standby (new master).<br>
&gt;<br>
&gt; Once the original master is online, when is an appropriate time to fai=
l<br>
&gt; back over? And are there any other things besides promote after the<br=
>
&gt; failover is done?<br>
<br>
Make sure that you still have an HA configuration able to handle<br>
multiple degrees of failures with always standbys available after a<br>
promotion.<br>
<br>
The options available to rebuild your HA configuration after a<br>
failover depend on the version of PostgreSQL you are using.=C2=A0 After a<b=
r>
failover the most simple solution would be to always recreate a new<br>
standby from a base backup taken from the freshly-promoted primary,<br>
though it can be costly depending on your instance.=C2=A0 You could also<br=
>
use pg_rewind (available in core since 9.5) to recycle the previous<br>
primary and reuse it as a standby of the new promoted custer.=C2=A0 Note<br=
>
that there are community-based solutions for such things, like<br>
pg_auto_failover or pacemaker-based stuff just to name two.=C2=A0 These<br>
rely on more complex architectures, where a third node is present to<br>
monitor the others (any sane HA infra ought to do at least that to be<br>
honest).<br>
--<br>
Michael<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">--- <span>Get your facts first, then you can dis=
tort them as you please.</span>--</div>

--0000000000008a42b3059bb3b307--