Vous n'êtes pas identifié(e).
Pages : 1
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 = offMon 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_statusPuis 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 00000001000000000000002FRé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 connectionsQue 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 downMerci d'avance pour votre aide afin de m'expliquer ce que je fais mal ici?
Hors ligne
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.
Hors ligne
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+01Mais, 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 downSoit 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.
Hors ligne
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.
Hors ligne
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 0000000300000000000000D3Dè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 connectionsEst-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)
Hors ligne
À 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/
Hors ligne
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 segmentEst-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 6106J'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 downIci 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 000000030000000100000022Toujours 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 connectionsJe 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.
Hors ligne
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/
Hors ligne
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.
Hors ligne
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?
Hors ligne
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/
Hors ligne
Pages : 1