Re: [ADMIN] Tablespace symlinks

Hi,

 

File content:

-bash-4.2$ more tablespace_map

16408 /pgdata/tablespaces/db1_lob

16409 /pgdata/tablespaces/db1_data

16410 /pgdata/tablespaces/db1_index

 

The problem is that I get errors in step 2: “tar Cannot open: No such file or directory…”

 

So, at which step symbolic links should be created by the server?

 

Regards,

Slavcho

--
We innovate. You win. http://netcetera.com

Slavcho Trnkovski | slavcho.trnkovski@netcetera.com | T +389 2 306 45 32 |
Netcetera DOOEL | 1000 Skopje | Macedonia | http://netcetera.com |

From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Achilleas Mantzios
Sent: Monday, January 30, 2017 3:58 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Tablespace symlinks

 

tar != "the server" . The doc tells you the server will consult tablespace_map. What does this file look like in your base.tar.gz ?

On 30/01/2017 16:24, Slavcho Trnkovski wrote:

Hi,

I'm using PostgreSQL 9.5.

As backup I use pg_basebackup with options --format=t -v -z -P .

These are the steps I do for restore:
1. 

tar -xzf base.tar.gz -C $PGDATA

2. 

for f in `ls | grep -v base.tar.gz `; do

echo "tar  -xf $f -C $PGDATA/pg_tblspc/`echo $f|cut -d'.' -f 1`" 
tar -xf $f -C $PGDATA/pg_tblspc/`echo $f|cut -d'.' -f 1`
done

 

I​ ha

​ v​

e​

​ problem because ​symlinks for my tablespaces are not being created in step 1.

 

​ According to https://www.postgresql.org/docs/9.5/static/app-pgbasebackup.html :

"When tar format mode is used, it is the user's responsibility to unpack each tar file before starting the PostgreSQL server. If there are additional tablespaces, the tar files for them need to be unpacked in the correct locations. In this case the symbolic links for those tablespaces will be created by the server according to the contents of the tablespace_map file that is included in the base.tar file."

my understanding is that these symbolic links should be created with the first step.

 

I was using same approach with PostgreSQL 9.4, and it was OK.

 

So, is this new behavior in 9.5 (so I shall handle it manually), or I am missing something?

 

Regards,

Slavcho

 

 

-- 

Achilleas Mantzios

IT DEV Lead

IT DEPT

Dynacom Tankers Mgmt

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt