Vous n'êtes pas identifié(e).
Pages : 1
Merci pour les réponses. Je vais voir les informations que je peux récupérer.
Bref, tout dépend de l'importance et du but de cette haute disponibilité
Bonjour,
Je ne vois pas les différents buts à part que cela soit disponible ?
L'application qui va dépendre de la base de données devra fonctionner 24/24 7/7 (99.99% ou mieux) et devrait faire quasi en permanence des requêtes sur celle ci (persistance d'un fournisseur de service JMS).
Merci pour les réponses
Merci pour les réponses.
C'est difficilement une solution de haute-disponibilité si vous n'avez qu'un répertoire de données. Que se passe-t-il en cas de panne du SAN ?
Il me semblait qu'un SAN était conçu pour avoir une très haute disponibilité.
Toutefois si des solutions plus pertinentes qui permettent :
d’éviter la perte de données
de conserver les performances
et qui sont compatibles windows/linux existent, je suis preneur.
Bonjour,
Je tente une migration vers postgreSQL 8.4 depuis un autre SGDB et il se pose la question de la haute disponibilité.
L'idée suivie pour le moment est :
- d'utiliser un disque partagé où nous stockerions le groupe de base de données.
- l’utilisation de Windows Server avec l'utilisation de Microsoft Cluster Service pour gérer le failover (et l'ip virtuelle).
PostgreSQL offrant des services windows, ceux-ci sont ils fait de manière à ce que deux instance ne puisse tourner en même temps ?
Remarque qui a amené la question : Nous avons constaté qu'avec certains services l’arrêt est détecté par Windows avant que le service soit bien totalement arrêté, et "l'esclave" peut redémarrer avant que le "maitre" s’arrête.
Pour le dossier partagé il sera probablement sur un SAN (ce qui d’après la documentation ne doit pas poser des problèmes) , mais pour les premiers tests nous utiliserons un répertoire partagé (CIFS/SMB).
J'ai vu également une remarque concernant les montages NFS :
Beaucoup d'installations créent les clusters de bases de données sur des systèmes de fichiers réseau. Parfois, cela utilise directement par NFS. Cela peut aussi passer par un NAS (acronyme de Network Attached Storage), périphérique qui utilise NFS en interne. PostgreSQL™ ne fait rien de particulier avec les systèmes de fichiers NFS, ceci signifiant que PostgreSQL™ suppose que NFS se comporte exactement comme les lecteurs connectés en local (DAS, acronyme de Direct Attached Storage). Si les implémentations du client et du serveur NFS ont une sémantique non standard, cela peut poser des problèmes de fiabilité (voir http://www.time-travellers.org/shane/pa … mful.html). En particulier, des écritures asynchrones (décalées dans le temps) sur le serveur NFS peuvent poser des soucis de fiabilité. Si possible, montez les systèmes de fichiers NFS en synchrone (autrement dit sans cache) pour éviter cela. De même, le montage NFS n'est pas recommandé. Les SAN utilisent un protocole de communication bas-niveau plutôt que NFS.
J'ai quelques difficultés à comprendre ceci (la version anglaise ne m’éclaire pas plus) : Si possible, montez les systèmes de fichiers NFS en synchrone (autrement dit sans cache) pour éviter cela. De même, le montage NFS n'est pas recommandé.
Peut on utiliser NFS en synchrone ? pour CIFS/SMB y'a t il la même problématique ?
La solution semble t elle cohérente ou y a-t-il quelque chose de plus adapté à la haute disponibilité ?
Merci d'avance pour les réponses
Pages : 1
