Forums PostgreSQL.fr

litroma

Membre

PIT Restore

Bonjour a tous,

Je suis nouveau ici et également très jeune dans le monde de PostgreSQL.

Je vous explique mon problème.

Je cherche a valider le fonctionnement des PIT (Point In Time) Restore dans PostgreSQL version 12.
Voila ce que j'ai mis en place:

Je n'ai pas d'autre serveur avec réplication ou autre, uniquement mon serveur "on va dire de prod" (c'est plutôt un test pour l'instant)
J'ai un tablespace avec la base dvdrental dedans.
Ce tablespace est stocké sous /mnt/dvdrental qui correspond à une lun iSCSI

[root@postgresql12 ~]# psql -U postgres -d dvd
psql (12.1)
Type "help" for help.

dvd=# \db+
                                     List of tablespaces
    Name    |  Owner   |    Location    | Access privileges | Options |  Size  | Description
------------+----------+----------------+-------------------+---------+--------+-------------
 dvdrental  | postgres | /mnt/dvdrental |                   |         | 16 MB  |
 pg_default | postgres |                |                   |         | 24 MB  |
 pg_global  | postgres |                |                   |         | 623 kB |
(3 rows)


dvd=# \l+
                                                                    List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   |  Size   | Tablespace |                Description
-----------+----------+----------+-------------+-------------+-----------------------+---------+------------+--------------------------------------------
 dvd       | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                       | 16 MB   | dvdrental  |
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                       | 8193 kB | pg_default | default administrative connection database
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +| 8049 kB | pg_default | unmodifiable empty database
           |          |          |             |             | postgres=CTc/postgres |         |            |
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +| 8049 kB | pg_default | default template for new databases
           |          |          |             |             | postgres=CTc/postgres |         |            |
(4 rows)

Localement (sur mon serveur postgresql) j'ai un montage (lun iSCSI) sous /mnt/WAL dans laquelle j'archive tous les WAL à chaque sauvegarde.
Mon fichier postgresql.conf est configuré de la sorte:

wal_level = replica 
archive_mode = on               
archive_command = 'test ! -f /mnt/WAL/%f && cp %p /mnt/WAL/%f'
archive_timeout = 60
restore_command = 'cp /mnt/WAL/%f %p'
recovery_target_inclusive = off

Mon répertoire de WAL n'a pas changé et se trouve par défaut sous /var/lib/pgsql/12/data/pg_wal

J'effectue des sauvegardes de la sorte:
pg_start_backup
puis effectue une copie sur la baie de disque qui héberge les LUN iSCSI
puis termine avec un pg_stop_backup

Si je restore complètement mon tablespace, aucun souci, je retrouve bien ma DB dvdrental telle qu'elle était au moment de la sauvegarde.

Mais, je souhaiterai pouvoir utiliser mes archives WAL pour effectuer un recovery jusqu'à un instant T
Pour cela, j'imagine restorer mon tablespace à l'instant T-10 jours par exemple
Puis indiquer à postgresql de rejouer les transactions des archives présentes sous /mnt/WAL

Déjà, pouvez-vous me confirmer que j'ai bien compris le principe des PIT restore?

Seulement, je rencontre toujours le problème suivant et n'arrive jamais a rejouer mes transactions.

Voila ce que je fais:

j'arrête mon serveur postgresql via systemctl stop postgresql-12.service
je demonte la lun où se trouve mon tablespace
je restore mon tablespace à l'instant T-10 (par exemple)
je remonte ma lun où se trouve mon tablespace

A ce moment-là, j'ai dans mon répertoire /var/lib/pgsql/12/data/pg_wal les WAL résultant de l'activité de la DB et ceux des sauvegardes.
La plupart du temps j'en au toujours plus que dans mes archives sous /mnt/WAL

Exemple de WAL présent dans /var/lib/pgsql/12/data/pg_wal

[root@postgresql12 data]# ll pg_wal
total 65540
-rw------- 1 postgres postgres 16777216 Dec  6 09:30 00000001000000000000002E
-rw------- 1 postgres postgres      361 Dec  6 09:30 00000001000000000000002E.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 09:30 00000001000000000000002F
-rw------- 1 postgres postgres 16777216 Dec  6 09:30 000000010000000000000030
-rw------- 1 postgres postgres 16777216 Dec  6 08:35 000000010000000000000031
drwx------ 2 postgres postgres      133 Dec  6 09:30 archive_status

Puis les WAL présent au même moment dans les archives sous /mnt/WAL

[root@postgresql12 data]# ll /mnt/WAL
total 606276
-rw------- 1 postgres postgres 16777216 Dec  5 17:34 00000001000000000000000B
-rw------- 1 postgres postgres 16777216 Dec  5 17:34 00000001000000000000000C
-rw------- 1 postgres postgres      358 Dec  5 17:34 00000001000000000000000C.00000060.backup
-rw------- 1 postgres postgres 16777216 Dec  5 17:39 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 Dec  5 18:30 00000001000000000000000E
-rw------- 1 postgres postgres      358 Dec  5 18:30 00000001000000000000000E.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 18:35 00000001000000000000000F
-rw------- 1 postgres postgres 16777216 Dec  5 19:30 000000010000000000000010
-rw------- 1 postgres postgres      361 Dec  5 19:30 000000010000000000000010.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 19:35 000000010000000000000011
-rw------- 1 postgres postgres 16777216 Dec  5 20:30 000000010000000000000012
-rw------- 1 postgres postgres      361 Dec  5 20:30 000000010000000000000012.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 20:35 000000010000000000000013
-rw------- 1 postgres postgres 16777216 Dec  5 21:30 000000010000000000000014
-rw------- 1 postgres postgres      361 Dec  5 21:30 000000010000000000000014.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 21:35 000000010000000000000015
-rw------- 1 postgres postgres 16777216 Dec  5 22:30 000000010000000000000016
-rw------- 1 postgres postgres      361 Dec  5 22:30 000000010000000000000016.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 22:30 000000010000000000000017
-rw------- 1 postgres postgres 16777216 Dec  5 22:35 000000010000000000000018
-rw------- 1 postgres postgres 16777216 Dec  5 23:30 000000010000000000000019
-rw------- 1 postgres postgres      361 Dec  5 23:30 000000010000000000000019.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  5 23:35 00000001000000000000001A
-rw------- 1 postgres postgres 16777216 Dec  6 00:30 00000001000000000000001B
-rw------- 1 postgres postgres      361 Dec  6 00:30 00000001000000000000001B.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 00:30 00000001000000000000001C
-rw------- 1 postgres postgres 16777216 Dec  6 00:35 00000001000000000000001D
-rw------- 1 postgres postgres 16777216 Dec  6 01:30 00000001000000000000001E
-rw------- 1 postgres postgres      361 Dec  6 01:30 00000001000000000000001E.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 01:35 00000001000000000000001F
-rw------- 1 postgres postgres 16777216 Dec  6 02:30 000000010000000000000020
-rw------- 1 postgres postgres      361 Dec  6 02:30 000000010000000000000020.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 02:35 000000010000000000000021
-rw------- 1 postgres postgres 16777216 Dec  6 03:30 000000010000000000000022
-rw------- 1 postgres postgres      361 Dec  6 03:30 000000010000000000000022.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 03:35 000000010000000000000023
-rw------- 1 postgres postgres 16777216 Dec  6 04:30 000000010000000000000024
-rw------- 1 postgres postgres      361 Dec  6 04:30 000000010000000000000024.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 04:35 000000010000000000000025
-rw------- 1 postgres postgres 16777216 Dec  6 05:30 000000010000000000000026
-rw------- 1 postgres postgres      361 Dec  6 05:30 000000010000000000000026.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 05:35 000000010000000000000027
-rw------- 1 postgres postgres 16777216 Dec  6 06:30 000000010000000000000028
-rw------- 1 postgres postgres      361 Dec  6 06:30 000000010000000000000028.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 06:35 000000010000000000000029
-rw------- 1 postgres postgres 16777216 Dec  6 07:30 00000001000000000000002A
-rw------- 1 postgres postgres      361 Dec  6 07:30 00000001000000000000002A.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 07:35 00000001000000000000002B
-rw------- 1 postgres postgres 16777216 Dec  6 08:30 00000001000000000000002C
-rw------- 1 postgres postgres      361 Dec  6 08:30 00000001000000000000002C.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 08:35 00000001000000000000002D
-rw------- 1 postgres postgres 16777216 Dec  6 09:30 00000001000000000000002E
-rw------- 1 postgres postgres      361 Dec  6 09:30 00000001000000000000002E.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  6 09:30 00000001000000000000002F

Résultat, il y a toujours de WAL plus récent sous /var/lib/pgsql/12/data/pg_wal que sous /mnt/WAL
Mais, cela me semble normale, vu que le la commande archive_command n'est déclenchée que au moment du pg_stop_backup

Par contre, là où je ne comprends pas ce que je fais de mal, c'est si je veux déclencher un PIT restore.
Pour cela, je crée un fichier recovery.signal et positionne dans mon fichier postgresql.conf les champs suivants:

recovery_target_time = '2019-12-05 14:00:00 CET'

Puis je redémarre postgresql via systemctl start postgresql-12.service
Et voila ce que je constate dans les logs:

2019-12-06 09:53:07.084 CET [16660] LOG:  database system was shut down at 2019-12-06 09:49:08 CET
cp: cannot stat ‘/mnt/WAL/00000002.history’: No such file or directory
2019-12-06 09:53:07.090 CET [16660] LOG:  starting point-in-time recovery to 2019-12-06 04:00:00+01
cp: cannot stat ‘/mnt/WAL/000000010000000000000031’: No such file or directory
2019-12-06 09:53:07.100 CET [16660] LOG:  consistent recovery state reached at 0/310000A0
2019-12-06 09:53:07.100 CET [16660] LOG:  invalid record length at 0/310000A0: wanted 24, got 0
2019-12-06 09:53:07.100 CET [16660] LOG:  redo is not required
2019-12-06 09:53:07.101 CET [16656] LOG:  database system is ready to accept read only connections
cp: cannot stat ‘/mnt/WAL/000000010000000000000031’: No such file or directory
cp: cannot stat ‘/mnt/WAL/00000002.history’: No such file or directory
2019-12-06 09:53:07.116 CET [16660] LOG:  selected new timeline ID: 2
2019-12-06 09:53:07.186 CET [16660] LOG:  archive recovery complete
cp: cannot stat ‘/mnt/WAL/00000001.history’: No such file or directory
2019-12-06 09:53:07.207 CET [16656] LOG:  database system is ready to accept connections

Que dois-je faire pour que postgreSQL rejoue les logs jusqu'à l'instant T que je lui ai indiqué?
Est-ce que je dois vider le repertoire /var/lib/pgsql/12/data/pg_wal avant de redemarrer PostgreSQL?
Si c'est la cas je tombe toujours sur ce message d'erreur au moment de redemarrer PostgreSQL:

Job for postgresql-12.service failed because the control process exited with error code. See "systemctl status postgresql-12.service" and "journalctl -xe" for details.

Avec ceci dans les logs

2019-12-06 09:57:54.288 CET [16721] LOG:  database system was shut down at 2019-12-06 09:56:45 CET
cp: cannot stat ‘/mnt/WAL/00000003.history’: No such file or directory
2019-12-06 09:57:54.294 CET [16721] LOG:  starting point-in-time recovery to 2019-12-06 04:00:00+01
2019-12-06 09:57:54.299 CET [16721] LOG:  restored log file "00000002.history" from archive
cp: cannot stat ‘/mnt/WAL/000000020000000000000032’: No such file or directory
cp: cannot stat ‘/mnt/WAL/000000010000000000000032’: No such file or directory
2019-12-06 09:57:54.313 CET [16721] LOG:  invalid primary checkpoint record
2019-12-06 09:57:54.313 CET [16721] PANIC:  could not locate a valid checkpoint record
2019-12-06 09:57:54.313 CET [16718] LOG:  startup process (PID 16721) was terminated by signal 6: Aborted
2019-12-06 09:57:54.313 CET [16718] LOG:  aborting startup due to startup process failure
2019-12-06 09:57:54.316 CET [16718] LOG:  database system is shut down

Merci d'avance pour votre aide afin de m'expliquer ce que je fais mal ici?

gleu

Administrateur

Re : PIT Restore

Déjà, pouvez-vous me confirmer que j'ai bien compris le principe des PIT restore?

Ça semble être ça, oui.

Exemple de WAL présent dans /var/lib/pgsql/12/data/pg_wal

Pour éviter tout problème, ce répertoire devrait être vide.

Résultat, il y a toujours de WAL plus récent sous /var/lib/pgsql/12/data/pg_wal que sous /mnt/WAL

Normal à condition qu'il n'y ait pas une trop grosse différence.

Mais, cela me semble normale, vu que le la commande archive_command n'est déclenchée que au moment du pg_stop_backup

Absolument faux. L'archivage se fait toujours au fil de l'eau.

Que dois-je faire pour que postgreSQL rejoue les logs jusqu'à l'instant T que je lui ai indiqué?

Déjà, il faudrait que la sauvegarde restaurée ne date pas d'après le point de restauration. Dans votre exemple, la sauvegarde date de "2019-12-06 04:00:00+01" et vous voulez le restaurer au "2019-12-05 14:00:00 CET". Ça ne peut pas fonctionner. Le PITR fonctionne en marche avant, pas en marche arrière.

Ensuite, vous indiquez restaurer votre tablespace. On est d'accord qu'en fait, vous restaurez l'instance complète ? c'est-à-dire le répertoire des données principal et tous les tablespaces utilisateurs ?

Est-ce que je dois vider le repertoire /var/lib/pgsql/12/data/pg_wal avant de redemarrer PostgreSQL?

Ce n'est pas obligatoire mais ça permet d'éviter des problèmes.

---

Guillaume.

litroma

Membre

Re : PIT Restore

Merci Guillaume pour la réponse.

Mes captures d'écran ne sont pas bonnes en effet.
Je restaure bien la Lun contenant le répertoire ou se trouve le tablespace dvd:

dvd=# \db+
                                     List of tablespaces
    Name    |  Owner   |    Location    | Access privileges | Options |  Size  | Description
------------+----------+----------------+-------------------+---------+--------+-------------
 dvdrental  | postgres | /mnt/dvdrental |                   |         | 16 MB  |

Cette lun est bien monté sous /mnt/dvdrental
Et dans ce tablespace, il n'y a que la database dvdrental:

dvd=# \l+
                                                                    List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   |  Size   | Tablespace |                Description
-----------+----------+----------+-------------+-------------+-----------------------+---------+------------+--------------------------------------------
 dvd       | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                       | 16 MB   | dvdrental  |

Pour ce test, je n'ai pas d'autres databases sur mon serveur postgresql

Par contre, j'ai bien restauré la lun a une date antérieure à ma recovery_target_time (en l’occurrence la sauvegarde date du 5/12/2019 à 17h34)
Et ma recovery_target_time est bien dans le futur comme indiqué dans les logs:

019-12-06 09:53:07.090 CET [16660] LOG:  starting point-in-time recovery to 2019-12-06 04:00:00+01

Mais, pas comme je vous l'ai indiqué dans mon post et je m'excuse pour cette confusion.

Donc, je cherche bien à faire un PITR en marche avant, mais sans succès.

J'ai bien essayé de vider mon repertoire pg_wal avant de redemarrer en recovery PostgreSQL,
mais comme je vous l'ai indiqué, alors postgreSQL m'affiche systématiquement ce type de message d'erreur:

cp: cannot stat ‘/mnt/WAL/00000003.history’: No such file or directory
2019-12-06 09:57:54.294 CET [16721] LOG:  starting point-in-time recovery to 2019-12-06 04:00:00+01
2019-12-06 09:57:54.299 CET [16721] LOG:  restored log file "00000002.history" from archive
cp: cannot stat ‘/mnt/WAL/000000020000000000000032’: No such file or directory
cp: cannot stat ‘/mnt/WAL/000000010000000000000032’: No such file or directory
2019-12-06 09:57:54.313 CET [16721] LOG:  invalid primary checkpoint record
2019-12-06 09:57:54.313 CET [16721] PANIC:  could not locate a valid checkpoint record
2019-12-06 09:57:54.313 CET [16718] LOG:  startup process (PID 16721) was terminated by signal 6: Aborted
2019-12-06 09:57:54.313 CET [16718] LOG:  aborting startup due to startup process failure
2019-12-06 09:57:54.316 CET [16718] LOG:  database system is shut down

Soit principalement cette erreur PANIC:  could not locate a valid checkpoint record
Et une fois dans cette situation, ma seule façon de m'en sortir est d'executer un pg_resetwal sur mon datadir
Alors postgreSQL redemarre, mais sans aucune recovery et donc sans rejouer aucune transaction.

Vraiment, je ne comprends pas ce que fait de mal???

Merci d'avance pour votre aide.

gleu

Administrateur

Re : PIT Restore

Soit principalement cette erreur PANIC:  could not locate a valid checkpoint record

Cette erreur indique qu'il n'arrive pas à trouver le premier journal de transactions dont il a besoin pour commencer la restauration. Donc la première question est "est-ce que le fichier /mnt/WAL/0000000?0000000000000032 existe ?"

Et une fois dans cette situation, ma seule façon de m'en sortir est d'executer un pg_resetwal sur mon datadir

pg_resetwal supprime les journaux de transactions et modifie le fichier pg_control pour qu'il ne lance pas de restauration. Autrement dit, dans le cas en question, vous corrompez votre serveur. pg_resetwal ne doit être utilisé qu'en dernier recours, et encore...

Alors postgreSQL redemarre, mais sans aucune recovery et donc sans rejouer aucune transaction.

Logique, pg_resetwal est fait pour ça.

Vraiment, je ne comprends pas ce que fait de mal???

Difficile pour nous de vous aider sans avoir toutes les étapes de la restauration (et je dirais même de la sauvegarde).

---

Guillaume.

litroma

Membre

Re : PIT Restore

Bonjour,

Merci Guillaume pour les informations.
Voici ce que j'ai comme données concernant le backup.

Prenons le backup effectué ce matin à 8h30

Résultat du pg_start_backup:

(Mon Dec  9 08:30:37 2019) stdout: [ pg_start_backup
(Mon Dec  9 08:30:37 2019) -----------------
(Mon Dec  9 08:30:37 2019)  0/C1000028
(Mon Dec  9 08:30:37 2019) (1 row)]

Puis résultat du pg_stop_backup consécutif:

(Mon Dec  9 08:30:51 2019) stdout: [ pg_stop_backup
(Mon Dec  9 08:30:51 2019) ----------------
(Mon Dec  9 08:30:51 2019)  0/C2000088
(Mon Dec  9 08:30:51 2019) (1 row)]
(Mon Dec  9 08:30:51 2019) stderr: [psql: NOTICE:  all required WAL segments have been archived]

Donc, il semble que le pg_start_backup et pg_stop_backup ce sont bien passés et que les WAL correspondants ont bien été archivés

Maintenant à 12h19 je restore la lun contenant le tablespace dvd avec la database dvdrental avec la sauvegarde de 8h30
Je positionne une recovery_target_time à 10h00 aujourd'hui (donc bien dans le futur par rapport à ma sauvegarde)
Je vide mon pg_wal
Je ne touche pas à mon répertoire d'archive (/mnt/WAL)
Celui-ci contient alors les WAL suivants, entre autres:

-rw------- 1 postgres postgres 16777216 Dec  9 07:30 0000000200000000000000BF
-rw------- 1 postgres postgres      361 Dec  9 07:30 0000000200000000000000BF.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  9 07:35 0000000200000000000000C0
-rw------- 1 postgres postgres 16777216 Dec  9 08:30 0000000200000000000000C1
-rw------- 1 postgres postgres      361 Dec  9 08:30 0000000200000000000000C1.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  9 08:30 0000000200000000000000C2
-rw------- 1 postgres postgres 16777216 Dec  9 08:35 0000000200000000000000C3
-rw------- 1 postgres postgres 16777216 Dec  9 09:00 0000000200000000000000C4
-rw------- 1 postgres postgres 16777216 Dec  9 09:05 0000000200000000000000C5
-rw------- 1 postgres postgres 16777216 Dec  9 09:13 0000000200000000000000C6
-rw------- 1 postgres postgres 16777216 Dec  9 09:14 0000000200000000000000C7
-rw------- 1 postgres postgres 16777216 Dec  9 11:59 0000000300000000000000CF
-rw------- 1 postgres postgres 16777216 Dec  9 11:59 0000000300000000000000D0
-rw------- 1 postgres postgres      361 Dec  9 11:59 0000000300000000000000D0.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  9 12:03 0000000300000000000000D1
-rw------- 1 postgres postgres 16777216 Dec  9 12:04 0000000300000000000000D2
-rw------- 1 postgres postgres      328 Dec  9 12:04 0000000300000000000000D2.00000028.backup
-rw------- 1 postgres postgres 16777216 Dec  9 12:12 0000000300000000000000D3

Dès que je redemarre PostgreSQL j'obtien les messages suivants:

2019-12-09 12:19:35.866 CET [2244] LOG:  database system was shut down at 2019-12-09 12:12:01 CET
2019-12-09 12:19:35.867 CET [2244] LOG:  creating missing WAL directory "pg_wal/archive_status"
cp: cannot stat ‘/mnt/WAL/00000004.history’: No such file or directory
2019-12-09 12:19:35.873 CET [2244] LOG:  starting point-in-time recovery to 2019-12-09 10:00:00+01
cp: cannot stat ‘/mnt/WAL/00000003.history’: No such file or directory
cp: cannot stat ‘/mnt/WAL/0000000300000000000000D4’: No such file or directory
2019-12-09 12:19:35.884 CET [2244] LOG:  invalid primary checkpoint record
2019-12-09 12:19:35.884 CET [2244] PANIC:  could not locate a valid checkpoint record
2019-12-09 12:19:35.885 CET [2241] LOG:  startup process (PID 2244) was terminated by signal 6: Aborted
2019-12-09 12:19:35.885 CET [2241] LOG:  aborting startup due to startup process failure
2019-12-09 12:19:35.888 CET [2241] LOG:  database system is shut down
2019-12-09 12:21:08.859 CET [2303] LOG:  database system was shut down at 2019-12-09 12:21:01 CET
2019-12-09 12:21:08.871 CET [2300] LOG:  database system is ready to accept connections

Est-ce que les fichiers .history doivent se trouver également copiés dans mon répertoire d'archive (/mnt/WAL)?
Car ce n'est jamais le cas, pour moi.
Et pourquoi est-ce que PostgreSQL cherche le WAL référence ...D4 dans mes archives alors qu'il est postérieur à la recovery_target_time que je souhaite atteindre?
Pourquoi ne se content-il pas de d'utiliser les WAL jusqu'à la référence ...C7, qui correspond à la derniere archive avant ma recovery_target_time?

Vraiment je suis perdu

Merci d'avance pour votre aide

Dernière modification par litroma (09/12/2019 18:59:59)

rjuju

Administrateur

Re : PIT Restore

À priori il manque des fichiers.

Comment effectuez-vous la sauvegarde exactement ?  Comment appelez-vous pg_start_backup, et avec quel(s) arguments ?  Quel est le contenu du répertoire de donnée après restauration ?

Au passage, votre archive_command est problèmatique.  En cas d'interruption durant l'archivage, vous perdrez des données.  En cas d'arrêt brutal, vous pouvez également perdre des données.  En cas d'utilisation de ces archive pour de la réplication, vous aurez également des problèmes.

---

Julien.
https://rjuju.github.io/

litroma

Membre

Re : PIT Restore

Bonjour Julien,

Merci pour votre réponse.

La sauvegarde en tant que telle est effectuée entre le pg_start_backup et le pg_stop_backup par la prise d'un snapshot, sur la baie de disque contenant la Lun avec les fichiers données de mon tablespace.

Et le pg_start_backup est exécuté très simplement avec comme argument un label correspondant au snapshot créé dans la baie de disque, exemple:

select pg_start_backup('RG_cluster_dvd_12-10-2019_11.31.38.4279');
exit code: [0]
(Tue Dec 10 11:31:48 2019) stdout: [ pg_start_backup
(Tue Dec 10 11:31:48 2019) -----------------
(Tue Dec 10 11:31:48 2019)  1/6000028
(Tue Dec 10 11:31:48 2019) (1 row)]

J'ai modifié mon select archive_command avec ceci:

archive_command = 'cp %p /mnt/WAL/%f'           # command to use to archive a logfile segment

Est-ce que cette nouvelle archive_command est plus satisfaisante pour vous?

Le répertoire de donnée contient les fichiers de mon tablespace, à savoir quelque chose comme cela:

[root@postgresql12 data]# ls /mnt/dvdrental/PG_12_201909212/16714/
112        14022_vm   14039      1418       16781      16842      16896  16922  2336      2604_fsm  2610      2617_vm   2657  2675  2693      2832      3079      3381      3467      3599      3607      4149  4165  6110
113        14024      14041      16738      16781_fsm  16842_fsm  16898  16923  2337      2605      2610_fsm  2618      2658  2678  2696      2833      3079_fsm  3394      3468      3600      3608      4150  4166  6111
1247       14026      14042      16740      16790      16846      16900  16924  2579      2605_fsm  2610_vm   2618_fsm  2659  2679  2699      2834      3079_vm   3394_fsm  3501      3600_fsm  3609      4151  4167  6112
1247_fsm   14027      14042_fsm  16740_fsm  16792      16848      16902  16925  2600      2605_vm   2611      2618_vm   2660  2680  2701      2835      3080      3394_vm   3502      3600_vm   3712      4152  4168  6113
1247_vm    14027_fsm  14042_vm   16749      16792_fsm  16848_fsm  16904  16926  2600_fsm  2606      2612      2619      2661  2681  2702      2836      3081      3395      3503      3601      3764      4153  4169  6117
1249       14027_vm   14044      16751      16797      16858      16906  16927  2600_vm   2606_fsm  2612_fsm  2619_fsm  2662  2682  2703      2837      3085      3429      3534      3601_fsm  3764_fsm  4154  4170  826
1249_fsm   14029      14046      16751_fsm  16799      16860      16908  16928  2601      2606_vm   2612_vm   2619_vm   2663  2683  2704      2838      3118      3430      3541      3601_vm   3764_vm   4155  4171  827
1249_vm    14031      14047      16756      16799_fsm  16866      16910  16929  2601_fsm  2607      2613      2620      2664  2684  2753      2838_fsm  3119      3431      3541_fsm  3602      3766      4156  4172  828
1255       14032      14047_fsm  16758      16804      16868      16912  16930  2601_vm   2607_fsm  2615      2620_fsm  2665  2685  2753_fsm  2838_vm   3164      3433      3541_vm   3602_fsm  3767      4157  4173  pg_filenode.map
1255_fsm   14032_fsm  14047_vm   16763      16806      16869      16914  16931  2602      2607_vm   2615_fsm  2650      2666  2686  2753_vm   2839      3256      3439      3542      3602_vm   3997      4158  4174  pg_internal.init
1255_vm    14032_vm   14049      16765      16821      16871      16916  16932  2602_fsm  2608      2615_vm   2651      2667  2687  2754      2840      3257      3440      3574      3603      4143      4159  5002  PG_VERSION
1259       14034      14051      16765_fsm  16823      16886      16917  174    2602_vm   2608_fsm  2616      2652      2668  2688  2755      2840_fsm  3258      3455      3575      3603_fsm  4144      4160  548
1259_fsm   14036      14052      16774      16823_fsm  16888      16918  175    2603      2608_vm   2616_fsm  2653      2669  2689  2756      2840_vm   3350      3456      3576      3603_vm   4145      4161  549
1259_vm    14037      14054      16776      16828      16890      16919  2187   2603_fsm  2609      2616_vm   2654      2670  2690  2757      2841      3351      3456_fsm  3596      3604      4146      4162  6102
14022      14037_fsm  14056      16777      16830      16892      16920  2224   2603_vm   2609_fsm  2617      2655      2673  2691  2830      2995      3379      3456_vm   3597      3605      4147      4163  6104
14022_fsm  14037_vm   1417       16777_fsm  16840      16894      16921  2328   2604      2609_vm   2617_fsm  2656      2674  2692  2831      2996      3380      3466      3598      3606      4148      4164  6106

J'ai vu sur dalibo.org, dans l'exemple sur la fonctionnalité PITR, qu'au moment du redémarrage en mode recovery le fichier <transaction_ID>.<checkpoint ID>.backup était lu.
Dans mon cas, aucun fichier .backup n'est lu d'après les logs.

A chaque fois, il cherche une archive WAL qui n'existe pas (toujours celle juste derrière la dernière présente donc mon répertoire d'archive):

2019-12-10 12:25:24.379 CET [11048] LOG:  database system was shut down at 2019-12-10 12:20:16 CET
cp: cannot stat ‘/mnt/WAL/00000004.history’: No such file or directory
2019-12-10 12:25:24.385 CET [11048] LOG:  starting point-in-time recovery to 2019-12-10 12:00:00+01
cp: cannot stat ‘/mnt/WAL/00000003.history’: No such file or directory
cp: cannot stat ‘/mnt/WAL/000000030000000100000023’: No such file or directory
2019-12-10 12:25:24.399 CET [11048] LOG:  invalid primary checkpoint record
2019-12-10 12:25:24.399 CET [11048] PANIC:  could not locate a valid checkpoint record
2019-12-10 12:25:24.400 CET [11045] LOG:  startup process (PID 11048) was terminated by signal 6: Aborted
2019-12-10 12:25:24.400 CET [11045] LOG:  aborting startup due to startup process failure
2019-12-10 12:25:24.403 CET [11045] LOG:  database system is shut down

Ici la 23
Alors que dans mes archives, je m'arrête à la 22:

[root@postgresql12 data]# ls -latr /mnt/WAL | tail -30
-rw-------  1 postgres postgres      358 Dec 10 11:32 000000030000000100000006.00000028.backup
-rw-------  1 postgres postgres 16777216 Dec 10 11:58 000000030000000100000007
-rw-------  1 postgres postgres 16777216 Dec 10 12:02 000000030000000100000008
-rw-------  1 postgres postgres 16777216 Dec 10 12:10 000000030000000100000009
-rw-------  1 postgres postgres 16777216 Dec 10 12:10 00000003000000010000000A
-rw-------  1 postgres postgres 16777216 Dec 10 12:10 00000003000000010000000B
-rw-------  1 postgres postgres 16777216 Dec 10 12:11 00000003000000010000000C
-rw-------  1 postgres postgres 16777216 Dec 10 12:11 00000003000000010000000D
-rw-------  1 postgres postgres 16777216 Dec 10 12:11 00000003000000010000000E
-rw-------  1 postgres postgres 16777216 Dec 10 12:11 00000003000000010000000F
-rw-------  1 postgres postgres 16777216 Dec 10 12:11 000000030000000100000010
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000011
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000012
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000013
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000014
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000015
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000016
-rw-------  1 postgres postgres 16777216 Dec 10 12:14 000000030000000100000017
-rw-------  1 postgres postgres 16777216 Dec 10 12:15 000000030000000100000018
-rw-------  1 postgres postgres 16777216 Dec 10 12:16 000000030000000100000019
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001A
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001B
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001C
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001D
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001E
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 00000003000000010000001F
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 000000030000000100000020
-rw-------  1 postgres postgres 16777216 Dec 10 12:19 000000030000000100000021
drwxr-xr-x  2 postgres postgres    16384 Dec 10 12:20 .
-rw-------  1 postgres postgres 16777216 Dec 10 12:20 000000030000000100000022

Toujours dans l'exemple sur dalibo.org, on voit bien le process de recovery, qui part du dernier WAL de backup puis rejoue chaque archive WAL jusqu'à la recovery_target choisie:

guillaume@laptop:~$ pg_ctl start
pg_ctl: another server might be running; trying to start server anyway
LOG:  database system was interrupted; last known up at 2008-07-13 16:38:17 CEST
LOG:  starting archive recovery
LOG:  restore_command = 'cp /tmp/pg_xlog_archives/%f %p'
cp: cannot stat `/tmp/pg_xlog_archives/00000001.history': No such file or directory
LOG:  restored log file "000000010000000000000008.004C5654.backup" from archive
LOG:  restored log file "000000010000000000000008" from archive
LOG:  automatic recovery in progress
server starting
LOG:  redo starts at 0/84C5654
LOG:  restored log file "000000010000000000000009" from archive
LOG:  restored log file "00000001000000000000000A" from archive
LOG:  restored log file "00000001000000000000000B" from archive
LOG:  restored log file "00000001000000000000000C" from archive
LOG:  restored log file "00000001000000000000000D" from archive
LOG:  restored log file "00000001000000000000000E" from archive
LOG:  restored log file "00000001000000000000000F" from archive
cp: cannot stat `/tmp/pg_xlog_archives/000000010000000000000010': No such file or directory
LOG:  could not open file "pg_xlog/000000010000000000000010" (log file 0, segment 16): No such file or directory
LOG:  redo done at 0/FB20BD4
LOG:  last completed transaction was at log time 2008-07-13 16:40:30.632653+02
LOG:  restored log file "00000001000000000000000F" from archive
cp: cannot stat `/tmp/pg_xlog_archives/00000002.history': No such file or directory
LOG:  selected new timeline ID: 2
cp: cannot stat `/tmp/pg_xlog_archives/00000001.history': No such file or directory
LOG:  archive recovery complete
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections

Je ne vois vraiment pas ce que je fais de mal, mais pourquoi dans mon cas PostgreSQL n'a pas le même comportement?
Est-ce parce que je fais un shutdown propre de PostgreSQL avant mon test de redémarrage ou bien cela n'a rien à voir?

Merci d'avance.

rjuju

Administrateur

Re : PIT Restore

Le répertoire de donnée contient les fichiers de mon tablespace, à savoir quelque chose comme cela:

Il s'agit d'un tablespace, pas du répertoire de données principal.  Est-ce que vous sauvez également le répertoire principal de données ?

Est-ce que cette nouvelle archive_command est plus satisfaisante pour vous?

Non, la commande n'est pas atomique et ne garantit pas la durabilité du fichier archivé.

---

Julien.
https://rjuju.github.io/

gleu

Administrateur

Re : PIT Restore

La sauvegarde en tant que telle est effectuée entre le pg_start_backup et le pg_stop_backup par la prise d'un snapshot, sur la baie de disque contenant la Lun avec les fichiers données de mon tablespace.

S'il n'y a que ce tablespace, votre sauvegarde n'est pas bonne. La sauvegarde doit contenir tous les fichiers de PostgreSQL. Donc le répertoire /var/lib/pgsql/12/data et tous les tablespaces du serveur. J'ai bien l'impression que vous ne sauvegarder que le répertoire du tablespace de votre base.

---

Guillaume.

litroma

Membre

Re : PIT Restore

C'est effectivement le cas, la LUN sauvegardée et restaurée (sous /mnt/dvdrental) ne contient que mon tablespace dvdrental

postgres=# \db+
                                     List of tablespaces
    Name    |  Owner   |    Location    | Access privileges | Options |  Size  | Description
------------+----------+----------------+-------------------+---------+--------+-------------
 dvdrental  | postgres | /mnt/dvdrental |                   |         | 16 MB  |
 pg_default | postgres |                |                   |         | 170 MB |
 pg_global  | postgres |                |                   |         | 623 kB |
(3 rows)

Je ne sauvegarde pas les autres tablespaces contenu dans /var/lib/pgsql/12/data

Mais, je vais ajouter cela rapidement à mes sauvegardes et refaire un test.
Je vous tient au courant.

Pour la archive_command je ne vois pas quoi d'autre utiliser pour archiver proprement mes WAL.
Avez-vous une idée?

rjuju

Administrateur

Re : PIT Restore

Je vous conseille de consulter en priorité la documentation officielle concernant la sauvegarde.  Vous pouvez par exemple regarder https://www.postgresql.org/docs/current … iving.html.

Pour la archive_command je ne vois pas quoi d'autre utiliser pour archiver proprement mes WAL.

rsync permet de rendre la copie atomique.  Pour assurer la durabilité, malheureusement vous avez assez peu d'options.  À priori, à part utiliser un "sync" global il n'y a pas d'alternative.

---

Julien.
https://rjuju.github.io/