Re: upgrade to repmgr3

From: Pekka Rinne <tsierkkis(at)gmail(dot)com>
To: Ian Barwick <ian(at)2ndquadrant(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: upgrade to repmgr3
Date: 2016-08-16 05:34:50
Message-ID: CACAG2VULCpkJes3TyRqwfjY41P_s+FbogXr0QyzjU0YA5KPt=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

hi

2016-08-04 16:19 GMT+03:00 Ian Barwick <ian(at)2ndquadrant(dot)com>:

> Hi
>
> On 08/04/2016 05:57 PM, Pekka Rinne wrote:
>
>> hi!
>>
>> I have been using postgres 9.4 and repmgr2.0 combination and been doing
>> replication (hot standby). Now I'd like to start doing slot based
>> replication and have installed repmgr3 and exeuted the provided sql
>> scripts
>> and also added use_replication_slots=1 into repmgr.conf.
>>
>> The question is that what is the correct procedure to switch into using
>> slots (max_replication_slots) in this case as the system has been set up
>> already without them? Do I have to unregister and re-register all the
>> standbys? Hopefully re-clone could be avoided.
>>
>
> No reclone needed.
>
> What I tried was that I configured max_replication_hosts=5, restarted
>> master, created some slots using select * from
>> pg_create_physical_replication_slot(<name>), configured one created slot
>> into recovery.conf in the slave. What I noticed was that replication
>> seemed
>> to be still working after this but in repl_nodes table slot_name remained
>> empty. Then I did standby re-register with force and slot_name was filled
>> with repmgr_slot_2 value which is not the name I gave for the slot. I
>> think
>> repmgr invented this name but in the pg_replication_slots table
>> repmgr_slot_2 does not exist. There is only the slot I created myself
>> (active=t). So I guess this approach is not quite right.
>>
>> What if I just skip doing the re-register. Does is matter if slot_name
>> remains empty in repl_nodes?
>>
>
> This won't affect replication, however if you attempt any failover actions
> using repmgr (e.g. following a new master), it will probably cause
> problems when
> attempting to create a replication slot on the new master.
>
> As a workaround you can manually update the slot name in the repl_nodes
> table
> to match the one you've chosen. We'll update repmgr to better handle this
> kind of situation. I don't think we've had this particular use-case before,
> so I'll add some notes to the documentation on how best to handle it.
>
>
I tried this workaround. But what I noticed was that after promoting a
standby as a master my replication slots were renamed in repl_nodes to
repmgr_slot_2 and repmgr_slot_3. I did not use those names while creating
them.

Is the correct procedure to assume that nodes slot name should be
repmgr_slot_<ID>? This seems to be the case and slots can be created
following this rule.

Another thing is that is it mandatory to pre-create the slots by using
pg_create_physical_replication_slot()? Even if I do not do that replication
seems to sill be working but pg_replication_slots table remains empty. It
is only after promoting a standby as a master that one slot seems to get
created automatically.

br,
Pekka

In response to

Browse pgsql-general by date

  From Date Subject
Next Message dandl 2016-08-16 06:24:27 Re: C++ port of Postgres
Previous Message Sameer Kumar 2016-08-16 05:15:49 Re: Critical failure of standby