Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je souhaiterais mettre en place une architecture de ce type.
- 2 sites A et B
- 8 bases PgSQL (BDD1 à BDD8), 4 sur chaque site, avec la streaming replication active. la base maître sur le site A
- 1 pgpool sur chaque site (pgpoolA et pgpoolB), tous deux actifs, chacun dispatchant les requêtes sur les bases de son site, sauf la maitre
- deux serveurs d'application sur chaque site, utilisant chacun le pgpool local
- 1 service "hors PGPool" sur le site A pour alimenter la base maitre en modification (insert, update, delete)
- si possible, une surveillance mutuelle entre les 2 pgpool, celui restant actif relançant (ou reprenant les bases). Sinon, tant pis : je fais avec Nagios.
Est-ce possible ou qu'est-ce qui ne va pas. Notamment :
- est-il possible de répartir les bases entre plusieurs pgpool ? (ce qui me permet d'une part d'éviter les requêtes inter-site et leur latence, et d'autre part de ne pas trop surcharger un pgpool)
- est-il possible de ne pas donner accès à la base maître ? (ce qui me permet de ne pas permettre aux utilisateurs "en consultation" d'avoir physiquement accès à la base de mise à jour)
- jusqu'où puis-je utiliser les watchdog pgpool dans un tel contexte ?
- si ma base maître tombe, puis-je simplement (automatiquement ?) reconfigurer tout ça ?
Et si je propose un truc complètement absurde, quel type d'alternative proposez-vous ?
J'avoue que je suis un peu perplexe ...
Merci d'avance !
Hors ligne
Ça m'a l'air très compliqué, tout ça. Surtout que le vocabulaire approximatif n'aide pas. Pour commencer, vos 8 bases sont sur une même instance ou sur des instances différentes ?
Guillaume.
Hors ligne
Désolé pour le vocabulaire : je débarque sur PostgreSQL et ne suis pas un pro des bases de données.
Mes bases sont sur des serveurs physiques différents. Donc il s'agit d'instances différentes.
Je ne sais pas s'il y a d'autres termes "approximatifs", n'hésitez pas à les relever, je clarifierai au mieux
De même, pour mieux préciser le contexte, mes objectifs sont :
- supporter et privilégier énormément d'accès en consultation. J'ai mis 8 pour l'exemple, ca reste à tuner. C'est peut être 6, voire 4 ... ou plus de 8
- d'utiliser tous mes serveurs. L d'abord pour ne pas s'en priver mais aussi parce que es modes actif-passif ont on gros défaut : il faut les vérifier régulièrement et on n'est pas toujours sûr que le relai se fera en cas de panne
- de résister assez facilement à une panne de site (j'ai un "lot" 1 pgpool + 4 postgreSQL déjà actif sur chaque site)
- d'avoir une "afffinité de site" sur mes accès BDD (le serveur d'appli accède à un pgpool du même site qui accède à une base du même site pour éviter d'ajouter de la latence et ne pas dégrader les perfs en consultation)
J'ai "sorti" les services de mise à jour, mais je peux revenir là-dessus. C'est du détail. De même je peux revenir sur mon "affinité de site", la latence n'étant pas trop mauvaise, s'il s'avère que ca complique.
J'ai aussi mis 2 pgpool :
- parce que j'ai lu quelque part, de l'auteur lui-même, que 3 à 4 bases était l'idéal pour 1 pgpool. Et si je peux encore rester sur un unique pgpool, j'aimerais bien être rassuré sur la possibilité de scaler "horizontalement" (admettons, je n'ai plus 8 bases, mais 20 ... )
- parce que je veux éviter toute interruption de service
Mais je suis tout neuf sur ces technos, et moyennant le respect des contraintes exprimées ici, j'accepte volontiers les bons conseils et les contre-propositions.
Merci ,
Hors ligne
Pages : 1
