Vous n'êtes pas identifié(e).
Pages : 1
Merci pour vos conseils. La solution de basculé l'esclave en maître n'est pas idéale car cela va engendrer une coupure de service.
De plus, de lancer une procédure de faileover pour des besoins de maintenance est risqué dans un environnement de prod.
Je préfère encore couper tous mes clients pendant X minutes le temps de l'intervention.
Pour pgpool II le problème c'est qu'on utilise des fonctions comme now(). J'ai vu que dans ce cas, il n'était pas certain que les données soient identiques entre les nœuds.
Si je comprends bien, il n'y pas de solution l'heure actuelle pour répondre à mon besoin ?
Bonjour,
J'ai actuellement une architecture de ce type :
- Base de donnée mutualisé postgreSQL 8.4 (sur un même serveur, je peux avoir X bases de données)
- Un serveur maître postgreSQL 8.4
- Un serveur esclave postgreSQL 8.4 (Warm standby)
Tout fonctionne bien, j'ai testé la bascule sous un environnement de production et je n'ai rien perdu.
Mon problème est le suivant, si je dois pour des raisons de maintenance arrêter mon serveur maître (augmentation de la ram, cpu, disque, maj système), je suis coincé.
Mes serveurs Web qui attaquent mon sgbd ne peuvent plus se connectés le temps de la maintenance.
Est-ce qu'il existe une autre type de réplication/configuration/architecture pour gérer ce type d'intervention ?
J'ai déjà lu qu'il n'était pas trop conseillé de faire du master/master synchrone car cela n'est pas géré en natif sur PostgreSQL.
La version 8.4 est utilisé pour des pré-requis des bases mais un changement vers la version 9 est envisageable.
Merci d'avance pour vos conseils.
Bonjour,
Une évolution vers une version > à la 8.4 est en cours. Mais je n'ai pas encore de retour sur sa sortie.
Je comprends bien que je ne donne pas beaucoup d'info. Je vais donc rester en l'état et adapterai mes besoins au fil de l'eau comme indiqué.
En tout cas merci d'avoir pris du temps pour me répondre.
Bonjour,
Je suis nouveau sur ce forum, j'espère donc que je poste sur le bon topic.
Je débute dans l'administration d'un serveur PostgreSQL et je me pose des questions sur comment dimensionner correctement mon serveur postgres.
Le but de ce serveur est de mutualisé plusieurs petites bases de données (< à 1Go) pour héberger des petites boutiques de vente en ligne (type boulangerie).
Je vais tabler sur un maximum de 10 bases et une moyenne réaliste de 5.
Configuration actuelle :
- Postgres 8.4 avec log shipping comme système de réplication
- CentOS release 6.5
- 4 Go de RAM
- 2 Vcpu
Pour info, notre base n'est actuellement pas comptaible avec postgres 9 donc la contrainte est de rester en 8.4.
Mon serveur est virtuelle donc je peux lui allouer plus de CPU ou RAM si besoin.
En fait j'ai du mal à savoir comment le dimensionner correctement pour avoir des bonnes perfs mais sans non plus trop le sur-gonfler.
Je suis parti sur un nombre max de connexion à 150 sur mon cluster mais ici encore c'est assez approximatif.
Est-ce que vous avez des bonnes pratiques/conseils pour m'aider ?
Merci
Pages : 1
