Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host

Поиск
Список
Период
Сортировка
От Paul Förster
Тема Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host
Дата
Msg-id 4F8DF27C-E82A-4CBC-B06E-AD4FCD3E66FF@gmail.com
обсуждение исходный текст
Ответ на Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host  (Ian Barwick <ian.barwick@2ndquadrant.com>)
Ответы Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host  (Alexander Kukushkin <cyberdemn@gmail.com>)
Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host  (Ian Barwick <ian.barwick@2ndquadrant.com>)
Список pgsql-general
Hi Ian,

> On 26. Feb, 2020, at 01:38, Ian Barwick <ian.barwick@2ndquadrant.com> wrote:
>
> Assuming the standby/replica is created using pg_basebackup, you can use the
> -T/--tablespace-mapping option to remap the tablespace directories.

no, with Patroni, replicas are always initiated by Patroni. Patroni copies the whole PGDATA including everything
(postgresql.conf,etc.) in it to the replica site. When launching Patroni for the first time, all you need is its yaml
configurationfile and an empty PGDATA. It then will copy the whole master's PGDATA as is, launch the replica database
clusterand start replication. 

Even if Patroni uses pg_basebackup internally (which I assume it does), there is no way to pass parameters to it.

Then you can stop the Patroni process on the replica site which in turn takes the replica database cluster down, make
someconfiguration changes and launch it again. You can of course only make changes to things which don't get replicated
allover again or are managed by Patroni itself. This is, how I set up individual archive destinations for each
replicationmember because the initial archive destination of course is replicated, and thus identical, when Patroni
buildsthe replica database cluster. 

Tablespace mapping just creates the links to the directories in ${PGDATA}/pg_tblspc to a different location. And since
pg_basebackupisn't used, there is no way to do that. But I can do that by hand. That is not the problem. 

The problem is that PostgreSQL keeps the tablespace location inside the database and not in some config file. If the
latterwould be the case then I could just as well set it individually per node as I can with the archive destination. 

So, the tablespace location is always /data/pg01a/ts, even on the replica site where it should be /data/pg01b/ts.
Hence,on my local cluster, the replica site 'b' always uses the tablespace directory (and thus the files) of the master
'a'.

Cheers,
Paul


В списке pgsql-general по дате отправления:

Предыдущее
От: Thomas Kellerer
Дата:
Сообщение: Re: Backup & Restore
Следующее
От: Alexander Kukushkin
Дата:
Сообщение: Re: Highly academic: local etcd & Patroni Cluster for testing on asingle host