Re: BUG #16003: pg_basebackup failed with error : directory "xxxxxxx"exists but is not empty
От | Magnus Hagander |
---|---|
Тема | Re: BUG #16003: pg_basebackup failed with error : directory "xxxxxxx"exists but is not empty |
Дата | |
Msg-id | CABUevExO_OwbCA2pMjL3Kecz9y22XNwthcPELrD_2ZcdAivfWA@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #16003: pg_basebackup failed with error : directory "xxxxxxx" exists but is not empty (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16003: pg_basebackup failed with error : directory"xxxxxxx" exists but is not empty
RE: BUG #16003: pg_basebackup failed with error : directory "xxxxxxx" exists but is not empty |
Список | pgsql-bugs |
On Thu, Sep 12, 2019 at 4:41 AM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 16003
Logged by: sebastien ruiz
Email address: sebastien.ruiz@harmonie-mutuelle.fr
PostgreSQL version: 11.4
Operating system: Red Hat Enterprise Linux Server release 7.6
Description:
hello,
(sorry i'm french)
We have a problem when using pg_basebackup.
We tried to rebuild a slave (master/slave with streaming replication) using
pg_basebackup like this :
(executed on the slave server of course)
pg_basebackup -D /pgbd/IPMUTB6/admin -P -h PGSMUTB61 -p 5432 -U postgres
-X stream -v --waldir=/pgxlog/IPMUTB6/wal
But it failed :
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/17000028 on timeline 5
pg_basebackup: directory "/pgbd/IPMUTB6/data/dpaafb1_data" exists but is not
empty
pg_basebackup: removing data directory "/pgbd/IPMUTB6/admin"
pg_basebackup: removing WAL directory "/pgxlog/IPMUTB6/wal"
pg_basebackup: changes to tablespace directories will not be undone
in fact it failed because we have an architecture of tablespace who is not
compatible with the pg_basebackup tests/controls.
This is how our tablespace architecture looks like :
postgres=# \db
List of tablespaces
Name | Owner | Location
-----------------------+----------+-----------------------------------------------
aafb1_dpaafb1_data | aafb1 |
/pgbd/IPMUTB6/data/dpaafb1_data/aafb1_data
aafb1_dpaafb1_idx | aafb1 |
/pgbd/IPMUTB6/idx/dpaafb1_idx/aafb1_idx
dpaafb1_data | postgres | /pgbd/IPMUTB6/data/dpaafb1_data
dpaafb1_idx | postgres | /pgbd/IPMUTB6/idx/dpaafb1_idx
dpccmb1_data | postgres | /pgbd/IPMUTB6/data/dpccmb1_data
dpccmb1_idx | postgres | /pgbd/IPMUTB6/idx/dpccmb1_idx
dptemb1_data | postgres | /pgbd/IPMUTB6/data/dptemb1_data
dptemb1_idx | postgres | /pgbd/IPMUTB6/idx/dptemb1_idx
pg_default | postgres |
pg_global | postgres |
tech_dpaafb1_data | tech |
/pgbd/IPMUTB6/data/dpaafb1_data/tech_data
tech_dpaafb1_idx | tech | /pgbd/IPMUTB6/idx/dpaafb1_idx/tech_idx
tech_dpccmb1_data | tech |
/pgbd/IPMUTB6/data/dpccmb1_data/tech_data
tech_dpccmb1_idx | tech | /pgbd/IPMUTB6/idx/dpccmb1_idx/tech_idx
tech_dptemb1_data | tech |
/pgbd/IPMUTB6/data/dptemb1_data/tech_data
tech_dptemb1_idx | tech | /pgbd/IPMUTB6/idx/dptemb1_idx/tech_idx
temp | postgres | /pgtemp/IPMUTB6/tmp
tempob1_dptemb1_data | tempob1 |
/pgbd/IPMUTB6/data/dptemb1_data/tempob1_data
tempob1_dptemb1_idx | tempob1 |
/pgbd/IPMUTB6/idx/dptemb1_idx/tempob1_idx
webccmb1_dpccmb1_data | webccmb1 |
/pgbd/IPMUTB6/data/dpccmb1_data/webccmb1_data
webccmb1_dpccmb1_idx | webccmb1 |
/pgbd/IPMUTB6/idx/dpccmb1_idx/webccmb1_idx
In summary, we have tablespace directories into tablespace directories.
exemple :
/pgbd/IPMUTB6/data/dpaafb1_data/aafb1_data is inside the directory
/pgbd/IPMUTB6/data/dpaafb1_data
And this point is not compatible with pg_basebackup usage.
My question :
is it possible to make pg_basebackup compatible with this situation ?
I'm sure that many entreprise have this kind of architecture.
We can't use pg_basebackup and it's really too bad for us.
Why do you have multiple tablespaces if they are in the same place? The appropriate fix for that is to not do that.
And actually putting new tablespace directories inside other tablespaces is *definitely* not the way it's supposed to be done.
As a workaround, you might be able to use pg_basebackup with -T to relocate the tablespaces into a directory that is not in conflict.
//Magnus
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Alvaro HerreraДата:
Сообщение: Re: BUG #16005: cannot use \d to get description of table
Следующее
От: Thomas KellererДата:
Сообщение: Re: Unexpected behavior of jsonb_set() with a `null` value