Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je viens de déployer pgBackRest sur une instance de test.
Mon paramétrage:
pgBackRest version: 2.26
PostgreSQL version: 9.3.25
Operating system/version: Debian 8.11
Did you install pgBackRest from source or from a package? Package
pgbackrest.conf file(s):
[global]
repo1-path=/media/backup/pgbackrest
repo1-retention-full=2
process-max=1
log-level-console=info
log-level-file=detail
start-fast=y
[global:archive-push]
compress-level=1
[main]
pg1-path=/axihome/base2/postgresdata
postgresql.conf file :
data_directory = '/axihome/base2/postgresdata'
hba_file = '/etc/postgresql/9.3/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.3/main/pg_ident.conf'
wal_level = archive
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 600
/var/log/pgbackrest/main_backup.log
2020-06-02 23:41:54.948 P00 INFO: backup command begin 2.26: --log-level-console=info --log-level-file=detail --pg1-path=/axihome/base2/postgresdata --process-max=1 --repo1-path=/media/backup/pgbackrest --repo1-retention-full=2 --stanza=main --start-fast --type=full
2020-06-02 23:41:55.560 P00 INFO: execute exclusive pg_start_backup(): backup begins after the requested immediate checkpoint completes
2020-06-02 23:41:56.061 P00 INFO: backup start archive = 000000020000025D0000004D, lsn = 25D/4D000028
2020-06-02 23:41:56.313 P00 ERROR: [070]: link 'pg_tblspc/16432' destination '/axihome/base2/postgresdata/axidata' is in PGDATA
2020-06-02 23:41:56.313 P00 INFO: backup command end: aborted with exception [070]
L'archivage des WAL fonctionne sans soucis
Au lancement manuel du backup :
postgres@DPICHCDBTST:~$ pgbackrest --stanza=main --type=full backup
2020-06-02 23:41:54.948 P00 INFO: backup command begin 2.26: --log-level-console=info --log-level-file=detail --pg1-path=/axihome/base2/postgresdata --process-max=1 --repo1-path=/media/backup/pgbackrest --repo1-retention-full=2 --stanza=main --start-fast --type=full
2020-06-02 23:41:55.560 P00 INFO: execute exclusive pg_start_backup(): backup begins after the requested immediate checkpoint completes
2020-06-02 23:41:56.061 P00 INFO: backup start archive = 000000020000025D0000004D, lsn = 25D/4D000028
ERROR: [070]: link 'pg_tblspc/16432' destination '/axihome/base2/postgresdata/axidata' is in PGDATA
2020-06-02 23:41:56.313 P00 INFO: backup command end: aborted with exception [070]
Une idée du pourquoi le backup ne s'exécute pas à cause du lien 'pg_tblspc/16432' (présent dans '/axihome/base2/postgresdata/pg_tblspc') qui pointe sur '/axihome/base2/postgresdata/axidata' ???
Hors ligne
Le répertoire cible d'un tablespace ne devrait pas être dans le PGDATA. Sinon vous courrez le risque de le backuper deux fois, d'avoir le système de backup qui écrase les mauvais fichiers, etc… c'est pour ça que pgbackrest refuse de backuper. Mieux vaut vous alerter maintenant.
À moins que axidata soit un point de montage vers un autre filesystem, ce tablespace n'a aucun intérêt pour postgres de toutes façons, le but d'un tablespace sous postgres, c'est juste de pouvoir utiliser un système de fichiers différent (sur un type de stockage différent par exemple) pour certains objets. Donc deux possibilités pour résoudre votre problème:
- soit axidata est un point de montage. Dans ce cas là, arrêtez l'instance, remontez le ailleurs, qui ne soit pas un sous répertoire de /axihome/base2/postgresdata/, et mettez à jour le lien symbolique (techniquement le tablespace n'est qu'un lien symbolique) de 'pg_tblspc/16432 pour pointer vers la nouvelle destination
- soit c'est juste un répertoire. dans ce cas, il ne sert vraiment à rien, vous allez plus vous compliquer la vie qu'autre chose. ramenez les objets dans le tablespace par défaut, supprimez le tablespace. ça a un sens sous oracle par exemple, parce qu'il gère des datafiles, sous postgres ça ne sert à rien.
Marc.
Hors ligne
Notre prestataire est allé mettre des Databases, des Tables, des Séquences et des Index dans les tablespaces 
Mais ils sont bien dans le même filesystem...
/axihome/base2/postgresdata/pg_tblspc
|
--16432 ==> /axihome/base2/postgresdata/axidata
|
---16433 ==> /axihome/base2/postgresdata/axiindex
|
----16434 ==> /axihome/base2/postgresdata/connectdata
|
-----16435 ==> /axihome/base2/postgresdata/connectindex
|
------16436 ==> /axihome/base2/postgresdata/axiccam
Or les 2 databases de l'instances sont:
CREATE DATABASE "AXIBASE"
WITH
OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'fr_FR.UTF-8'
LC_CTYPE = 'fr_FR.UTF-8'
TABLESPACE = axidata
CONNECTION LIMIT = -1;
CREATE DATABASE "CONNECT"
WITH
OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'fr_FR.UTF-8'
LC_CTYPE = 'fr_FR.UTF-8'
TABLESPACE = connectdata
CONNECTION LIMIT = -1;
Je vais voir avec le prestataire l'intérêt de ces tablespaces et éventuellement s'ils sont OK pour les supprimer.
Hors ligne
ça sent le portage 1:1 d'Oracle, c'est une pratique habituelle, séparer les data et les index dans des schémas différents
Marc.
Hors ligne
Bien vu Monsieur est un connaisseur 
J'ai posté (bien avant ici) sur le Github de pgBackRest, et la réponse est similaire:
A tablespace may not be located inside PGDATA (data_directory setting). PostgreSQL will warn in this case:
/* Warn if the tablespace is in the data directory. */
if (path_is_prefix_of_path(DataDir, location))
ereport(WARNING,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
errmsg("tablespace location should not be inside the data directory")));
but we treat it as an error. Resolving and remapping these types of links during a restore can be very confusing for the user and therefore error prone.
In short -- move the tablespace link destination outside of PGDATA.
Hors ligne
Pages : 1
