[pgpool-general: 7482] Re: Promote specific backend to primary in streaming replication

[Tatsuo Ishii]

Hi,

> Thanks for your time on this so far!
> 
> Would it be possible to allow these to be changed at runtime without a config change + reload? Perhaps a more generic pcp command, to allow any “reloadable” configuration item to be changed? I’m not sure how many of these there are, and if any of them require deeper changes. Maybe we need a 3rd “class” of configuration item, to allow it to be changed without changing config.

Not sure. PostgreSQL does not have such a 3rd"class".

> We (and I am sure many others) use config management tools to keep our config in sync. In particular, we use Puppet. I have a module which I’m hoping to be able to publish soon, in fact.
> 
> Usually, environments which use config management like this have policies to not modify configuration which is managed.
> 
> Switching to a different backend would mean we have to manually update that managed configuration (on the pgpool primary, presumably) and reload, and then run pcp_detach_node against the primary backend. In the time between updating the configuration, and detaching the node, our automation might run and undo our changes which would mean we may get an outcome we don’t expect.
> An alternative would be to update the configuration in our management system and deploy it - but in many environments making these changes can be quite involved. I don’t think it’s good to require operational changes (i.e. “move the primary function to this backend”) to require configuration updates.
> 
> A work-around to this would be to have an include directive in the configuration and include a local, non-managed file for these sorts of temporary changes, but pgpool doesn’t have this at the moment I believe?

No, pgpool does not have. However I think it would be a good idea to
have "include" feature like PostgreSQL.

>> As of implementation details, I think we need to have new member in
>> POOL_REQUEST_INFO structure.  Currently we have main_node_id and
>> primary_node_id on it. I think we should leave them as they are and
>> have new member something like
>> "new_primary_candidate". get_next_main_node() will calculate the value
>> for new_primary_candidate depending on pgpool.conf. Finally we pass
>> the new_primary_candidate info to trigger_failover_command's
>> new_main_node parameter to handle failover.
>> 
>> Also those priority info should be added to BackendInfo structure.
> 
> That sounds great - as it would allow the %m and %H and so on to be used to convey the new_primary_candidate.

Yes.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp