Retour à la liste
From:
Ludovic Pénet
Subject:
Re: [TECH] Replication de Postgres
Date:
11/08/2003 15:19
Mailing-list:
Message-ID:
<1060607941.647.11.camel@chomsky>
Attachements
Le lun 11/08/2003 à 14:35, Tony Bassette a écrit :
> Bonjour à tous.
>
> Pour des besoins professionnels, j'aurais besoin de mettre en
> place un postgres en mode HA (High-Availability), le seul hic
> c'est que je n'ai rien trouvé de particulièrement bien fait ou
> bien documenté.
>
> J'ai essayé Distributed Postgresql, dbbalancer, Replicated
> Postgresql, et dernièrement il me reste à tester usogres (qui
> compile seulement avec gcc-2.95). Bref le premier n'a aucune
> doc sur sont mode de mise en place, le second rien qu'avec les
> script de tests effondre une machine en un rien de temps, le
> troisième si j'arrive à le compiler un jour je vous ferais signe
> le dernier ben pas encore tester.
>
> J'aimerai savoir si l'un d'entre vous aurais déjà jouer avec ce
> genre de chose et si oui ce qu'il a utilisé pour se faire.
>
> merci à vous
Je n'ai pas encore joué avec mais j'ai fait une petite étude
préliminaire pour voir ce que je pourrais bien implémenter pour faire
uniquement de la haute dispo, sans répartition de charge.
La première solution que j'ai vue est d'utiliser `rserv' pour faire une
mise à jour régulière (toutes les minutes?) de la base maîtresse vers
l'esclave. Ainsi, on conserve l'essentiel des données lors du
basculement (suite à la détection d'une défaillance par heartbeat par
exemple) d'une base à l'autre.
La seconde solution est d'utiliser un système de fichier distribué,
comme coda par exemple, pour définir l'espace de stockage de la base
pour les deux machines capables de la faire tourner. Sachant qu'une
seule tourne à la fois, l'esclave étant démarrée par heartbeat lorsque
la maîtresse défaille, je ne vois pas de raison que cela ne fonctionne
pas. En ce cas, on ne perd a priori que les transactions non "comitées".
J'attends d'avoir les machines pour tester la seconde solution. :-)
@+!
Ludovic
> Bonjour à tous.
>
> Pour des besoins professionnels, j'aurais besoin de mettre en
> place un postgres en mode HA (High-Availability), le seul hic
> c'est que je n'ai rien trouvé de particulièrement bien fait ou
> bien documenté.
>
> J'ai essayé Distributed Postgresql, dbbalancer, Replicated
> Postgresql, et dernièrement il me reste à tester usogres (qui
> compile seulement avec gcc-2.95). Bref le premier n'a aucune
> doc sur sont mode de mise en place, le second rien qu'avec les
> script de tests effondre une machine en un rien de temps, le
> troisième si j'arrive à le compiler un jour je vous ferais signe
> le dernier ben pas encore tester.
>
> J'aimerai savoir si l'un d'entre vous aurais déjà jouer avec ce
> genre de chose et si oui ce qu'il a utilisé pour se faire.
>
> merci à vous
Je n'ai pas encore joué avec mais j'ai fait une petite étude
préliminaire pour voir ce que je pourrais bien implémenter pour faire
uniquement de la haute dispo, sans répartition de charge.
La première solution que j'ai vue est d'utiliser `rserv' pour faire une
mise à jour régulière (toutes les minutes?) de la base maîtresse vers
l'esclave. Ainsi, on conserve l'essentiel des données lors du
basculement (suite à la détection d'une défaillance par heartbeat par
exemple) d'une base à l'autre.
La seconde solution est d'utiliser un système de fichier distribué,
comme coda par exemple, pour définir l'espace de stockage de la base
pour les deux machines capables de la faire tourner. Sachant qu'une
seule tourne à la fois, l'esclave étant démarrée par heartbeat lorsque
la maîtresse défaille, je ne vois pas de raison que cela ne fonctionne
pas. En ce cas, on ne perd a priori que les transactions non "comitées".
J'attends d'avoir les machines pour tester la seconde solution. :-)
@+!
Ludovic