Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Réplication » Réplication par système de fichier » 21/11/2013 15:17:51
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?
#2 Re : Réplication » Réplication par système de fichier » 20/11/2013 17:26:53
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
#3 Re : Réplication » Réplication par système de fichier » 19/11/2013 23:45:53
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.
#5 Réplication » Réplication par système de fichier » 18/11/2013 21:43:25
- MartinDrainville
- Réponses : 9
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?
#6 Général » Mettre une BD hors-ligne » 04/10/2013 20:05:59
- MartinDrainville
- Réponses : 3
Bonjour,
J'utilise PostgreSQL 9.0.5 ainsi que pgAdmin 3 et j'ai besoin d'une requête SQL (éventuellement incorporée dans un script afin d'automatiser une tâche) qui me permettrait de mettre une BD hors ligne.
La solution que je vois le plus souvent dans mes recherches internet ressemble à quelque chose comme ceci :
ALTER DATABASE <Nom_de_BD> SET OFFLINE WITH IMMEDIATE ROLLBACKToutefois, "l'ouput" que j'ai est qu'il y a une erreur dans la syntaxe.
Qu'est ce qu'il faut corriger?
Merci
#7 Re : Sécurité » La sécurié de PostgreSQL » 18/09/2013 16:27:53
Quant est-il du chiffrement de la base de données même? Par exemple, la table des utilisateurs et des mots de passe?
Tout ce que j'ai par rapport au chiffrement (http://docs.postgresql.fr/9.0/encryption-options.html) mentionne seulement md5.
Est-il possible d'utiliser une autre fonction de hachage cryptographique plus sécuritaire tel que SHA-256?
#8 Sécurité » La sécurié de PostgreSQL » 18/09/2013 14:18:09
- MartinDrainville
- Réponses : 10
Bonjour,
Je commence à utiliser PostgreSQL depuis peu et j'ai une question par rapport à la sécurité.
Comme je n'ai vu personne d'autre soulevé la question, il soit seulement avoir quelque chose que je ne saisi pas correctement.
Comment PostgreSQL peut-il être sécuritaire alors que la fonction de hachage est MD5 qui n'est plus sécuritaire depuis quelques années déjà?
Y a-t-il une autre de méthode de cryptage des données qui n'est pas mentionné dans la doc?
Merci
Pages : 1