On 02/08/11 01:05, Jaime Casanova wrote:
> On Wed, Jul 27, 2011 at 7:24 PM, Toby Corkindale
> <toby.corkindale@strategicdata.com.au> wrote:
>> On 28/07/11 03:47, Jaime Casanova wrote:
>>>
>>> On Wed, Jul 27, 2011 at 4:36 AM, Toby Corkindale
>>> <toby.corkindale@strategicdata.com.au> wrote:
>>>>
>>>> So that looks good, but then I try this on the slave:
>>>> # repmgr -f /etc/repmgr/validator/repmgr.conf \
>>>> --verbose standby register
>>>>
>>> can you show the content of /etc/repmgr/validator/repmgr.conf?
>>
>> cluster=validator
>> node=mel-db06
>> conninfo='host=10.133.54.1 port=5432 user=repmgr dbname=repmgr'
>>
>
> sorry for the delay on this... do you still have this problem?
We did, yes..
> the node parameter should be an integer value, i don't think that
> string should work for you
Ah! Right, yes, changing that to integer values on all the nodes
concerned has indeed solved the problem - once I manually deleted the
repgmr schema from the database. (It wouldn't replace the master, even
with --force)
>>>> I can query the database like so though, and it seems like it's all good:
>>>> repmgr=# select * from repmgr_validator.repl_nodes;
>>>> id | cluster | conninfo
>>>> ----+-----------+------------------------------------------------------
>>>> 0 | validator | host=10.133.54.2 port=5432 user=repmgr dbname=repmgr
>>>> (1 row)
>>>
>
> if in the standby that string you're using as node value ends up as a
> 0 then it never asks for the node 0 (it couldn't be the master because
> you're just registering as a standby)
>
> so i bet that's the problem, use numbers in the node parameter and
> everything will be ok
>
> i will have to add a check against this case in repmgr, though
Is there some documentation detailing the format of the repmgr.conf
file? Both I and another guy here have looked at it, and neither of us
spotted that node was only supposed to contain integers.
For that matter - is there a reason it has to be an integer? Allowing
hostnames there would be more friendly. Using integers means someone has
to maintain a mapping on node IDs to hostnames in a separate place, and
then that leads to mistakes, like someone thinking the standby node (2)
is the master hostname :/
Thanks for your help tracking this down!
Cheers,
Toby