Pour faire ce que tu décris on ne part pas d'un dump fait par pg_dump, car c'est une simple photo de la base (pg_dump a plusieurs formats de sortie, dont 1 en insertions SQL, mais ils sont tous équivalents).
Pour rejouer des WAL, il faut partir d'une copie des fichiers de la base de données (l'état binaire), et seuls les WAL émis après peuvent être pris en compte. Jusqu'à présent pour avoir une copie de la base il fallait:
* émettre une requête "pg_start_backup": le serveur commence à accumuler les WAL sans toucher aux fichiers de la base
* copier tous les fichiers
* émettre pg_stop_backup
Depuis la version 9 il y a un outil qui s'appelle pg_basebackup qui simplifie la procédure en faisant toutes ces opérations uniquement avec le protocol de postgres, et éventuellement depuis un serveur distant (donc pas besoin de paramétrer en plus un accès ssh pour la copies des fichiers).
Il n'y a pas 36 solutions si on veut un backup avec PITR: il faut faire un pg_basebackup régulier (1/semaine? 1/jour? ça dépend des cas) et archiver les WAL à côté, mais il faudra toujours de la place disponible. En case de restauration à l'instant t, il faut créer une base à partir du backup précédent t, et rejouer les WALs jusqu'à cet instant. Plus les backup sont réguliers, moins il y a de WAL à rejouer.
Sinon, c'est forcément un dump, avec l'avantage de pouvoir choisir quelle "database" voire quelles tables sont à restaurer. On peut combiner les 2 approches pour se créer un dump d'une database particulière à un instant "t". Ça nécessite quand même d'avoir la capacité monter la base de production: gros serveur, ou autre serveur.
Pour faire plus finement et moins "lourd", il faut connaître et comprendre les données stockées, et donc que ce soit l'application (donc le développeur) gère ça.
Enfin la "streaming réplication" depuis 9.1 ça marche bien et à part le cas 1 maître pour écrire et des esclaves pour lire cela permet de maintenir un serveur prêt à l'emploi pour devenir maître en moins d'1s. Depuis la 9.2 un esclave peut se répliquer à partir d'un autre esclave.
[^] # Re: .
Posté par Bertrand Mathieu . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 0.
Pour faire ce que tu décris on ne part pas d'un dump fait par pg_dump, car c'est une simple photo de la base (pg_dump a plusieurs formats de sortie, dont 1 en insertions SQL, mais ils sont tous équivalents).
Pour rejouer des WAL, il faut partir d'une copie des fichiers de la base de données (l'état binaire), et seuls les WAL émis après peuvent être pris en compte. Jusqu'à présent pour avoir une copie de la base il fallait:
* émettre une requête "pg_start_backup": le serveur commence à accumuler les WAL sans toucher aux fichiers de la base
* copier tous les fichiers
* émettre pg_stop_backup
Depuis la version 9 il y a un outil qui s'appelle pg_basebackup qui simplifie la procédure en faisant toutes ces opérations uniquement avec le protocol de postgres, et éventuellement depuis un serveur distant (donc pas besoin de paramétrer en plus un accès ssh pour la copies des fichiers).
Il n'y a pas 36 solutions si on veut un backup avec PITR: il faut faire un pg_basebackup régulier (1/semaine? 1/jour? ça dépend des cas) et archiver les WAL à côté, mais il faudra toujours de la place disponible. En case de restauration à l'instant t, il faut créer une base à partir du backup précédent t, et rejouer les WALs jusqu'à cet instant. Plus les backup sont réguliers, moins il y a de WAL à rejouer.
Sinon, c'est forcément un dump, avec l'avantage de pouvoir choisir quelle "database" voire quelles tables sont à restaurer. On peut combiner les 2 approches pour se créer un dump d'une database particulière à un instant "t". Ça nécessite quand même d'avoir la capacité monter la base de production: gros serveur, ou autre serveur.
Pour faire plus finement et moins "lourd", il faut connaître et comprendre les données stockées, et donc que ce soit l'application (donc le développeur) gère ça.
Enfin la "streaming réplication" depuis 9.1 ça marche bien et à part le cas 1 maître pour écrire et des esclaves pour lire cela permet de maintenir un serveur prêt à l'emploi pour devenir maître en moins d'1s. Depuis la 9.2 un esclave peut se répliquer à partir d'un autre esclave.