Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
j'ai cherché dans le forum général et celui de réplication mais je n'arrive pas à trouver ma réponse.
Voilà, dans le cadre de la mise en place d'un PRA on nous installe une solution de réplication ArcServe de chez CA qui permet de synchroniser par fichier ou par bloc. Le souci que je pose, est de savoir si on peut éspèrer une synchronisation des données en prenant le dossiers data de postgresql.
J'ai regardé sur la doc au chapitre 50 le détail du contenu PGDATA et je voudrais savoir si en synchronisant les répertoires base et global celà pourrait fonctionner.
Je ne suis pas vraiment optimiste mais pourriez-vous m'indiquer ce que vous en pensez.
Merci par avance pour vos réponses.
Gilles
Hors ligne
Bonjour.
Ce type de sauvegarde se fait très bien, il faut juste s'assurer d'ajouter dans votre job de sauvegarde en pré sauvegarde une requête pg_start_backup() sur la base et en fin de travail un pg_stop_backup(), et de sauvegarder aussi le répertorie pg_xlog. Vous pouvez également utiliser l'utilitaire pg_basebackup qui fera le tout.
Vous pouvez également sauvegarder les fichiers wal entre 2 sauvegardes arc serve pour pouvoir effectuer une restauration PITR qui permettra une perte de donnée minime en cas d'incident.
Pou plus d'information sur ce type de sauvegarde : http://docs.postgresqlfr.org/9.1/contin … iving.html
Dernière modification par rjuju (28/03/2012 16:13:18)
Julien.
https://rjuju.github.io/
Hors ligne
Il faut sauvegarder tout le répertoire PGDATA (celui qui contient base et global et plein d'autres répertoires et fichiers) ainsi que les répertoires des tablespaces. Vu le système, il me semble que vous ne pourrez faire ça qu'en arrêtant PostgreSQL. J'ai du mal à croire que vous allez mettre l'archivage en place, du coup pg_start_backup et pg_stop backup ne sont pas disponibles et il ne reste plus que la sauvegarde de fichiers avec base arrêtée.
Guillaume.
Hors ligne
Merci bien à tous les deux,
rjuju: je vais regarder le lien de plus près.
gleu: donc selon vous, je reste plus sur un système de sauvegarde - restauration et pas du tout sur une synchronisation ?
Pardon, je relisais et j'apporte une précision sur l'outil que l'on met en place de chez archserve. Ce n'est pas un outil de backup mais bien un outil de réplication qui travail avec un agent qui surveille toutes modifications intervenues. Je ne sais pas si celà change quelque chose mais çà me semble plus clair et complet quant à ma question.
Merci en tout cas.
Dernière modification par gilou974 (28/03/2012 17:03:30)
Hors ligne
Comme tous les SGBDR, PostGreSQL effectue des opérations d'écriture de fichier asynchrones entre data et transaction afin d'en optimiser l'écriture. La capture des IO d'une racine de stockage d'une base de données à des fins de reproduction vers un autre serveur ne peut en aucun cas garantir une bonne fin des opérations en cas de crash et vous pouvez vous retrouver in fine dans une situation ou la base est considérée comme corrompue par le serveur et donc définitivement inexploitable.
Même les outils professionnels et payant comme Double Take ne garantissent pas une telle reprise.
Voici ce que je dis dans le chapitre 11 "Administration" de mon ouvrage sur SQL à paraître dans 3 mois (4e edition) :
"
6.5 – Réplication des IO des fichiers des bases
Des solutions vendues dans le commerce permettent de répliquer les IO d’une base de données, voire de tout un serveur. C’est par exemple DoubleTake de Vision Solutions ou encore Left Hand de Hewlett-Packard. Le principe en est simple : chaque opération d’écriture sur un fichier, une arborescence, sur un disque ou même sur toute une baie est envoyée par réseau à un système homologue qui récrit les IO ainsi capturées.
Si l’offre est séduisante, elle n’est reste pas moins discutable :
• De par la nature des écritures dans les fichiers de données (pages, voir extensions), ce sont souvent des quantités importantes qui sont écrites, même si ce n’est que cycliquement (une seule donnée d’une seule ligne modifiée dans une table nécessite la récriture au minimum de la page complète) ;
• La vitesse d’écriture dans les journaux de transactions, même s’ils sont Write Ahead, peut conduire à des goulets d’étranglement sur une base de données fortement transactionnelle. Qu’en sera-t-il du réplica ?
• Comme nous l’avons déjà dit, le mode asynchrone des écritures entrecroisées entre données et transactions, propre aux SGBDR, peut conduire, en cas d’arrêt brutal, et avec un système supplémentaire lui-même asynchrone, à une situation irrécupérable de la base, malgré des fichiers intrinsèquement en bon état.
Il est en effet rarissime que ces mécanismes soient synchrones, sinon cela pénaliserait trop le système d’origine, tirant irrémédiablement les performances vers le bas.
Dès lors, aucune de ces solutions ne peut garantir une parfaite bonne fin en cas de crash !
"
Merci e na pas réproduire.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Ne connaissant pas ARCserve, je ne crois pas pouvoir en dire plus.
Guillaume.
Hors ligne
Bonjour et merci pour vos réponses.
Juste pour vous dire.
J'ai juste fait un test en copiant le répertoire PGDATA au complet via un scénario de réplication dans CA et quand je relance mon serveur sur l'hote de réplication je retrouve bien toutes les modifs effectuées.
Par contre effectivement je ne peux pas vraiment être sûr et doc ce n'est pas viable dans le cadre de la mise en place du PRA.
Je vais me tourner vers les outils de réplication de Postgres et je reviendrais probablement vers vous pour vos conseils.
Encore merci pour toutes vos réponses.
Gilles.
Hors ligne
Bonjour à tous,
je voulais avoir une précision sur la sauvegarde en attendant de mettre en place une réplication postgres.
Sur mon serveur de réplication je ne ferai qu'envoyer les sauvegardes effectuées à partir de mon serveur en prod.
Je laisse donc mon serveur Postgres OFF sur l'hote de réplication et je ne synchroniserai que les fichiers résultants du pg_dumpall de mon serveur d'origine.
Questions :
.Dans ce cas de figure est-ce que je suis assuré en faisant un restaure avec
psql -f fichier_d_entree postgres
de retrouver tout ce que j'avais sur le serveur origine.
.Lors du pg_dumpall y-a-t il un verrou qui se met en place ou faut-il couper l'accés à toutes les bases?
Merci pour vos réponses.
Hors ligne
Euh... pourquoi arrêter PostgreSQL si vous faites du pg_dumpall ? pg_dumpall ne s'utilise qu'avec un PostgreSQL démarré.
Toutes les méthodes de sauvegarde/restauration proposées par PostgreSQL sont cohérentes (donc pas de perte de données) et à chaud. Ça veut dire pg_dump/pg_dumpall et PITR. La sauvegarde des fichiers à froid est elle-aussi cohérente (forcément).
Guillaume.
Hors ligne
Ah oui, j'oubliais la dernière question. pg_dumpall (comme pg_dump) pose des verrous sur les tables. Le but de ces verrous est seulement d'empêcher la suppression des tables ou leur modification en terme de structure (autrement dit, pas de DROP TABLE, pas d'ALTER TABLE, pas de CLUSTER ou de VACUUM FULL sur les tables présentes en début de sauvegarde pendant la durée de la sauvegarde). Mais les utilisateurs peuvent toujours faire des INSERT, UPDATE, DELETE, COPY, SELECT, etc.
Guillaume.
Hors ligne
Merci pour vos réponses Guillaume.
Juste, je précise sur votre question concernant le Postgres arrêté :
j'ai du mal m'exprimé, je suis bien d'accord le pg_dumpall je le fais bien sur le serveur qui tourne.
C'est mon serveur de secours que je ne laisse pas tourner.
Si je dois basculer de l'un à l'autre je ne lancerai mon serveur de secours qu'à ce moment pour y faire le restore.
Merci encore.
Gilles
Hors ligne
Pages : 1
