Re: PostgresSQL 9.5 and systemd autorestart but without replication.

From: Poul Kristensen <bcc5226(at)gmail(dot)com>
To: Scott Mead <scottm(at)openscg(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PostgresSQL 9.5 and systemd autorestart but without replication.
Date: 2016-10-17 18:35:29
Message-ID: CAAOuvVqm1m=n0OUfypxQBeKsTtvgg-0H3BbQFq3dQE=7VOm7sA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

RHEL 7.2, which made the postgresql-9.5.service restart on both virtual
servers because of some network problem I am almost sure.

The problem now is to make the replication server understand that he is not
the master now until next failover. If I can not do this by reestablishing
recovery.conf and then restarting the postgresql.-9.5.service then I am
running out of ideas. I have to make sure to be able to handle the
failover's and the reestablishment of the "replica" or standby server
again when going in production on the physical servers.

Thanks
Poul

2016-10-14 14:53 GMT+02:00 Scott Mead <scottm(at)openscg(dot)com>:

> On Fri, Oct 14, 2016 at 7:42 AM, Poul Kristensen <bcc5226(at)gmail(dot)com>
> wrote:
>
>> Hi !
>>
>> Hopefully this is a situation in virtuel environments and not on physical
>> servers with storage on SAN.as replication have to follow up in a
>> autorestart without a manual new basebackup.
>>
>
> What OS are you running? recovery.conf gets renamed to 'recovery.done'
> only when a promotion (failover) occurs. This can happen a number of ways (*pg_ctl
> promote, trigger_file, etc..). *Typically, these commands are not
> executed automatically for you, you would have had to either install a tool
> that does auto failover, *or* the startup scripts in your OS did
> something (highly doubtful).
>
> --Scott
>
>
>
>> Does anyone have experience with replication on physical servers(slaves)?
>>
>>
> Thanks
>>
>> Poul
>>
>>
>>
>>
>> 2016-10-13 17:45 GMT+02:00 Poul Kristensen <bcc5226(at)gmail(dot)com>:
>>
>>> Thank you for fast respons.
>>>
>>> No. The recovery.conf has now replace a recovery.done file on the slave.
>>> No errors in the pg_log. I have not earlier experienced this situation.
>>> The feature of autorestart is really nice.
>>> BTW: I do not quite understand why the recovery.conf are replaced with a
>>> recovery.done file.
>>>
>>> Thanks
>>>
>>> /Poul
>>>
>>>
>>> 2016-10-13 16:30 GMT+02:00 Hunley, Douglas <douglas(dot)hunley(at)openscg(dot)com>:
>>>
>>>>
>>>> On Thu, Oct 13, 2016 at 6:00 AM, Poul Kristensen <bcc5226(at)gmail(dot)com>
>>>> wrote:
>>>>
>>>>> This morning I noticed that my 2 PG virtual servers had made an
>>>>> automatic
>>>>> restart at exactly the same time 00:00. The 2 servers is running and
>>>>> accepting connections but no WALL sender and no WALL receicver is running.
>>>>> Why don't replication follow up!
>>>>> Do I have to make a new pg_basebackup from primarily to replica?
>>>>> OS: RHEL 7.2
>>>>>
>>>>
>>>> Is the recovery.conf file still present and valid in $PGDATA on the
>>>> slave? Any errors in the slave's pg_log directory concerning the
>>>> replication?
>>>>
>>>>
>>>> --
>>>> {
>>>> "name" : "douglas j hunley",
>>>> "email" : "douglas(dot)hunley(at)openscg(dot)com <doug(dot)hunley(at)gmail(dot)com>",
>>>> "title" : "database engineer",
>>>> "phone" : "+1 732 339 3419 x163"
>>>> }
>>>>
>>>
>>>
>>>
>>> --
>>> Med venlig hilsen / Best regards
>>> Poul Kristensen
>>> Linux-OS/Virtualizationexpert and Oracle DBA
>>>
>>
>>
>>
>> --
>> Med venlig hilsen / Best regards
>> Poul Kristensen
>> Linux-OS/Virtualizationexpert and Oracle DBA
>>
>
>
>
> --
> --
> Scott Mead
> Sr. Architect
> *OpenSCG <http://openscg.com>*
> http://openscg.com
>

--
Med venlig hilsen / Best regards
Poul Kristensen
Linux-OS/Virtualizationexpert and Oracle DBA

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Thomas Munro 2016-10-17 21:56:03 Re: [ADMIN] 9.5 new setting "cluster name" and logging
Previous Message Gilberto Castillo 2016-10-14 17:58:11 Re: [MASSMAIL]Re: Help with synchronous replication automation