Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Le projet sur lequel je travaille comporte deux serveurs postgresql version 9.0.5 et pgpool version 3.3.1 roulant sur Red Hat enterprise 6.4.
Suite à des discussions, mon équipe de travail a choisi d'utiliser la réplication avec postgresql par système de fichier, pgpool n'est utilisé que pour le balancement des requêtes de connexions. La documentation concernant ce type de réplication est plutôt mince et mes tests sommaires ne fonctionnent pas entièrement.
Est-ce qu'un simple "cp /path/folder /path/newfolder" devrait fonctionner pour répliquer un serveur A à un serveur B? Qu'est-ce qu'il faut copier, les dossiers contenant les données? Les tablespaces?
J'imagine que les deux serveurs postgres doivent avoir la même structure et les mêmes schémas pour que la réplication fonctionne.
Bref, quels sont les aspects à prendre en considération pour faire fonctionner ce type de réplication?
Hors ligne
Vous pourriez préciser ce que vous entendez par "la réplication avec postgresql par système de fichier" ? vous parlez de la réplication interne ou de DRBD ?
Guillaume.
Hors ligne
DRBD
Hors ligne
OK. Dans ce cas, pgpool ne sert à rien. En effet, avec de la réplication DRBD, les esclaves ne sont pas disponibles, en écriture comme en lecture.
Et pour répondre aux questions du premier post :
* "Est-ce qu'un simple "cp /path/folder /path/newfolder" devrait fonctionner pour répliquer un serveur A à un serveur B?" Non, ce n'est pas ainsi que DRBD fonctionne.
* "Qu'est-ce qu'il faut copier, les dossiers contenant les données? Les tablespaces? " Tout le répertoire des données, ainsi que les tablespaces. Mais DRBD le fait automatiquement une fois qu'il est installé.
* "J'imagine que les deux serveurs postgres doivent avoir la même structure et les mêmes schémas pour que la réplication fonctionne." Bien sûr, c'est de la réplication physique.
Avez-vous lu cet article http://www.dalibo.org/hs45_drbd_la_repl … cs_disques ? j'y explique comment mettre en place DRBD avec PostgreSQL.
Guillaume.
Hors ligne
Merci pour le lien, est-ce que DRBD propose une réplication seulement synchrone? De plus, y a-t-il un lien vers la "documentation excellente" mentionnée dans les avantages?
Car en fait, la réplication que mon équipe de travail privilégie est asynchrone, le fait d'avoir le contrôle sur le moment de la réplication du serveur B par rapport au serveur A est très important. La réplication doit se faire sous certaines conditions et prédispositions.
En fait, dans le meilleur des cas, la commande de déclenchement de la réplication serait inséré dans un script. C'est d'ailleurs pourquoi je posais la question si un simple "cp /path/folder /path/newfolder" fonctionnerait car en fait, c'est ce qui serait optimal dans notre contexte. Comme postgresql est dans un univers Linux et que tout est contenu dans un système de fichiers, est-ce que c'est une solution plausible?
Je sais que c'est plutôt une réplication "custom", pas vraiment standard mais c'est ce qui répond à nos besoins.
Hors ligne
La documentation est sur le site officiel : http://www.drbd.org/docs/about/ , et notamment http://www.drbd.org/users-guide/
DRBD peut faire de la réplication asynchrone, mais elle sera faite en continue. Que cherchez-vous à faire exactement ? De ce que je comprends, vous avez plutôt besoin de mettre en pause la réplication, je suppose en cas de problème lors d'exécution de scripts ? Où alors construire un esclave à intervalle régulier ? Bref, sans plus de détail difficile de vous aider.
Julien.
https://rjuju.github.io/
Hors ligne
Le système à bâtir ressemble à ceci: deux serveurs postgres et pgpool (sur un des serveurs postgres ou sur un autre serveur, ce n'est pas décidé encore). Pgpool n'est utilisé que pour le balancement des connexions aux serveurs postgres et ces connexions, venant de l'extérieur, ne seront que des requêtes de type "SELECT", aucune écriture.
Les seules écritures se feront à partir de l'interne suite à divers processus de conditionnement des données à une fréquence d'une fois par mois. Le vœu est d'avoir les données accessibles pour les clients en tout temps même lors de la mise à jour des bases de données.
La stratégie est d'utiliser le balancement de pgpool pour mettre à jour les serveurs. Voici les étapes:
1 - Le balancement est 50-50 entre les serveurs A et B.
2 - Le balancement est 0-100 sur le serveur B, toute les nouvelles connexions sont dirigées vers le serveur B. Lorsqu'il n'y a plus de connexion sur le serveur A, celui-ci est mis à jour via des scripts.
3 - Le balancement change à 100-0 sur le serveur A, toute les nouvelles connexions sont dirigées vers le serveur A. Lorsqu'il n'y a plus de connexion sur le serveur B, celui-ci est répliqué depuis le serveur A.
4 - Le balancement redevient 50-50 entre les serveurs A et B.
Bref, la réplication doit se faire seulement à un moment précis dans le processus, c'est pourquoi je mentionnais que le contrôle du moment de la réplication était important. La possibilité de simplement ré-exécuté les scripts de mise à jour des données sur le serveur B a été étudié mais le processus est plutôt long et couteux, ce n'est pas la solution idéale.
Est-ce que mes explications clarifient la situation? Quelle type de réplication conviendrait le mieux à cette situation?
Merci
Hors ligne
Dans ce cas, ne faites pas de réplication. Sauvegardez la base ou l'instance du serveur A, et restaurez la sur le serveur B. Beaucoup plus simple, beaucoup plus rapide.
Guillaume.
Hors ligne
En gros, c'est d'utiliser pg_dump et pg_restore plutôt que quelconque mécanisme de réplication?
C'est plus rapide même si l'on veut seulement mettre à jour quelques tables et non tout l'ensemble de la base de données?
Dernière modification par MartinDrainville (21/11/2013 15:23:21)
Hors ligne
Pas forcément plus rapide, mais beaucoup plus simple et donc moins de problèmes à venir. Maintenant, ça ne veut pas dire forcément pg_dump. Ça peut être une sauvegarde PITR, qui sera plus rapide à restaurer.
Vous pouvez aussi utilisé Slony mais dans ce cas, la modification sera automatiquement transféré sur le deuxième serveur ce qui ralentira l'étape 2.
En fait, tout dépend de la taille de la base. Si vous avez une base d'au moins 500 Go, il vaut mieux penser à Slony. Sinon, une sauvegarde pg_dump ou une sauvegarde PITR me semble le meilleur choix.
Guillaume.
Hors ligne
Pages : 1
