Vous n'êtes pas identifié(e).
Pages : 1
bonjour,
je souhaite savoir s'il existe un logiciel permettant de lire un fichier archive de transaction : les fichiers dans le dossier pg_xlog.
Ma seconde question :
quand on refait jouer les fichiers de transactions, est il possible de dire de rejouer à partir d'une date ?
Dans le lien suivant, je n'ai que l'exemple d'une demande de jeu jusqu'à une date :
http://www.mkyong.com/database/postgres … al-backup/
Merci d'avance
Hors ligne
Bonjour,
il existe l'outil pg_xlogdump (http://www.postgresql.org/docs/devel/st … gdump.html).
Il n'est pas possible de rejouer les wal uniquement à partir d'une date donnée, sinon les données restaurées ne seraient pas cohérentes.
Julien.
https://rjuju.github.io/
Hors ligne
le probleme c'est que si dans les journaux , il y a une requete pirate du genre delete * from matable, cette requete sera rejouée !
Comment isoler , désactiver ces transactions pirates ?
Hors ligne
Les journaux applicatifs ne contiennent pas les requêtes effectuées mais les modifications physiques des blocs de données.
Pour le reste, il faut utiliser les autorisations, des vues ou des procédures stockées par exemple afin de restreindre l'accès aux données afin d'empêcher ce genre de chose.
Julien.
https://rjuju.github.io/
Hors ligne
supposons qu'on arrive pas à empêcher que le hacker fasse une injection sql de la mort;
Le seul recours sera de rejouer les transactions en séparant le grain de l'ivraie en supposant que cela soit possible.
Hors ligne
Non, dans ce cas il faut restaurer jusqu'à la transaction précédant l'injection sql.
Si des données ont été insérées entre temps, il faut restaurer sans supprimer les données existantes, et tenter de les récupérer manuellement en isolant les nouvelles lignes afin de les sauvegarder et les restaurer.
Julien.
https://rjuju.github.io/
Hors ligne
"et tenter de les récupérer manuellement en isolant les nouvelles lignes afin de les sauvegarder et les restaurer."
comment les isoler ? est-ce que pg_xlogdump permet de retrouver les requetes saines en question ?
Dernière modification par icadedt (21/08/2013 14:17:18)
Hors ligne
Non, les wal ne contiennent aucune information de requête. Pour isoler les lignes, il faut effectuer des requêtes sur les 2 serveurs afin de voir les enregistrements qui ne sont pas présents sur la base restaurée, tout ça en s'assurant de la cohérence des données.
Julien.
https://rjuju.github.io/
Hors ligne
les 2 serveurs ????
votre postulat est que j'utilise londiste pour fairre des replications ?
Hors ligne
Lorsque je disais « il faut restaurer sans supprimer les données existantes », je voulais parler de restauration dans une nouvelle instance (sur la même machine ou non) afin de disposer des données avant et après restauration, en même temps. C'est sans rapport avec une quelconque réplication.
Julien.
https://rjuju.github.io/
Hors ligne
une autre question :
comment faire pour savoir quels sont les fichiers de transactions qui precedent tout juste le fichier de backup fabriqué grace aux commandes
select pg_start_backup('monnombackup') puis pg_stop_backup()
Dernière modification par icadedt (21/08/2013 21:38:27)
Hors ligne
En lisant le fichier backup_label qui indique le journal en cours lors de l'exécution du pg_start_backup().
Guillaume.
Hors ligne
La fonction pg_start_backup va créer un fichier backup_label dans le répertoire pgdata qui contient le nom du wal concerné. La requête pg_stop_backup() va renommer ce fichier en pg_xlog/nom_du_wal.backup et y ajoutera le nom du dernier wal.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour
Mais comment PostgreSQL renseigne le fichier "backup_label" pour devenir <nom du WAL de début de backup>.<offset>.backup ?
mais aussi, comment bien déterminer le nom du fichier "backup_label" après son renommage à partir des informations présentes
dans le fichier backup_label renseignées par le pg_start_backup?
D'avence Merci
Hors ligne
Bonjour,
Est ce que quelqu'un pourra m'aiguiller SVP?
Merci
Hors ligne
Ça devrait être possible dès que la question sera compréhensible...
Guillaume.
Hors ligne
Merci Guillaume,
désolé de ne pas être claire, néanmoins je essayer de m'expliquer:
\! cat /var/lib/postgresql/9.4/main/backup_label
START WAL LOCATION: 9/CF000028 (file 0000000100000009000000CF)
CHECKPOINT LOCATION: 9/CF000028
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-06-10 12:14:04 CEST
LABEL: test-test
********
postgres=# \! ls -al /var/lib/postgresql/9.4/main/pg_xlog/
total 1033468
drwx------ 3 postgres postgres 4096 10 juin 12:18 .
drwx------ 18 postgres postgres 4096 10 juin 12:18 ..
-rw------- 1 postgres postgres 16777216 10 juin 12:10 0000000100000009000000CE
-rw------- 1 postgres postgres 16777216 10 juin 12:14 0000000100000009000000CF
-rw------- 1 postgres postgres 298 10 juin 12:18 0000000100000009000000CF.00000028.backup
...
*********
postgres=# \! cat /var/lib/postgresql/9.4/main/pg_xlog/0000000100000009000000CF.00000028.backup
START WAL LOCATION: 9/CF000028 (file 0000000100000009000000CF)
STOP WAL LOCATION: 9/D0000050 (file 0000000100000009000000D0)
CHECKPOINT LOCATION: 9/CF000028
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-06-10 12:14:04 CEST
LABEL: test-test
STOP TIME: 2015-06-10 12:18:29 CEST
==>
Visiblement Postgresql prend le dernier fichier Wal (start wal location) et il rajoute le checkpont ID (pg_current_xlog_location et un point backup comme suffix.
Autrement dit est ce qu'on peut modifier le nom fichier ".backup" et avoir un autre nom en sortie comme (date et heure sur le nom) tout en pensant à l'exploitabilité du fichier après lors de la restauration?
Hors ligne
Non, ce n'est pas possible. Le nom du fichier n'est pas modifiable.
Guillaume.
Hors ligne
Merci Guillaume,
La réponse est claire.
J'aurai bien aimer savoir (voir la question initiale) sur quel mécanisme s'appuie PostgreSQL pour faire comme il fait pour le nommage des fichier backup_label et "nom_fichier.backup"?
D'avance merci
Hors ligne
Je ne comprends vraiment pas la question. Toutes les informations pour passer de backup_label à 0000000100000009000000CF.00000028.backup dans votre exemple sont contenues dans le backup_label.
Julien.
https://rjuju.github.io/
Hors ligne
Ok Julien,
Je cherche comme indiqué à savoir comment fonctionne le mécanisme pour créer un fichier backup comme il le fait.
Peut être il faut que j'expose le problème que j'ai rencontré:
J'ai été confronté à un crach d'une base PostgreSQL 9.0. Lors de la restauration PosgeSQL me réclame un wal manquant . Après restauration il manque des données qui on été insérées.
La date des données insérées correspondent à la date de du WAl xxxxxxxxxxEC alors que le PITR demandé se trouve dans le WAL xxxxxxxxxxED. Chose que je n'arrive pas à comprendre. C'est pour cela j'ai demandé comment fonctionne le mécanisme (la logique des choses).
J'espère que j'ai été claire
Merci d'avance
Hors ligne
Comment savez-vous que les données se trouvent dans le journal ...EC ?
Pour informations, il y a les enregistrements avec les données (enregistrement Heap et/ou Heap2). Et il y a l'enregistrement de validation de la transaction. Il est tout à fait possible que des lignes insérées se trouvent dans les enregistrements du journal ...EC, mais que le COMMIT de cette transaction se trouve dans le journal ...ED. Dans ce cas, si le journal ...ED n'est pas disponible, les données du journal ...EC sont rejouées... mais ne sont pas visibles du fait du manque du COMMIT.
Guillaume.
Hors ligne
Bonjour,
Merci gleu pour ta réponse et désolé pour ce retard faute de disponibilité. Merci encore
Hors ligne
Pages : 1
