Vous n'êtes pas identifié(e).
Pages : 1
Il ne faut JAMAIS utiliser SQL_ASCII.
Oui d'où le passage en UTF-8.
Concernant les tests, la procédure de dump et d'intégration avec le nouvel encoding se déroule correctement.
La durée d'interruption doit être inférieure à 10 minutes.
Le dump prend 18 minutes
La conversion 5 minutes 30
la restauration 12 minutes
Merci pour cette réponse rapide,
vu que l'utilisation des WALS est impossible, postgres fournit-il un mode de log des requêtes (dans un format sql standard) engendrant une modification de la base de données ?
L'idée serait d'activer ce mode puis de rejouer les requêtes sql sur le nouveau serveur.
Bonjour,
mon objectif est d'effectuer une migration de postgresql avec le contexte suivant :
Base de données initiale, Serveur N°1 :
- OS : Debian 5
- Archi : 64 bits
- Version postgres : 8.3
- Encoding des bases : (aucun) SLQ-ASCII
Base de données cible, Serveur N°2 :
- OS : Debian 6
- Archi : 64 bits
- Version postgres : 9.0
- Encoding des bases : UTF-8
Initialement, je pensais effectuer la procédure suivante pour effectuer cette migration :
1/ Arrêt des services pointant sur les bases de données concernés
2/ Dump des bases
3/ Encodage des dumps en UTF-8
4/ Intégration des dumps sur la nouvelle base
5/ Reprise
Néanmoins ce procédé demande une longue interruption de service (l'ensemble de la procédure prenant environ 1 heure).
Du coup, je me pose la question suivante : est -il possible d'utiliser dans cette configuration, les WAL du serveur n°1 sur le serveur n°2 pour intégrer seulement le delta d'une heure lié à la génération et à l'intégration des dumps ?
Cela ne pose-t-il pas de soucis de compatibilité lié aux différentes version de postgres et à l'encoding distinct des deux bases ?
Merci
Merci pour cette première réponse,
Si je récapitule, le processus complet serait le suivant ? :
- Lors d’une panne, s’assurer manuellement que le Maître n’as plus d’instance de postgresql active.
- Créer un trigger sur l’esclave afin de le promouvoir en Maître.
- Faire pointer les ressources sur le nouveau Maître
- Passage du maitre initial en Esclave (recovery.conf)
- Création d’un backup du nouveau Maître, envoi vers le Maître initial.
- Arrêt du Maître actuel, passage de ce Maître en Esclave (Recovery.conf), redémarrage
- Créer un trigger sur l’esclave (Maître initial) afin de le promouvoir en Maître.
- Faire pointer les ressources sur le nouveau Maître
Autre question, quel est le risque lorsque deux maîtres sont simultanément actif ? Leurs envois de WAL sont intégrés par les maîtres distants ?
Merci
Bonjour,
Nouveau sur ce forum, je suis à la recherche d'informations concernant la mise en place d'un système de réplication entre deux équipements Master - Slave avec la version 8.3 de postgresql.
Il m'a semblé voir que la mise en place d'une réplication warm standby pouvait répondre à ce besoin.
J'ai pu trouver des informations sur la mise en place de cette réplication, ainsi que sur le déroulement d'un scénario de panne du Master.
Ce scenario est le suivant :
Lorsque le master tombe, déclanchement (manuel ?) du passage de Status Esclave --> Maitre de la part du Serveur Esclave.
Redirection des ressources utilisant la Bdd initiale vers le nouveau Maitre.
Si ce processus est correct,
ma question concerne le rétablissement du Maitre initial :
-- Le Maitre initial doit être passé en Esclave ?
-- Quelle procédure doit être utilisée pour effectuer une bascule planifié vers le Maitre initial, qu’est-ce que cela engendre au niveau des interruption de service ?
Question supplémentaire, est-il possible d’assurer une certaine automatisation de ces processus de basculement : Echec Maitre --> Base de secours --> Retour Maitre
(si non, quels sont les points à vérifier lors de ces bascules manuelles ?)
Merci d’avance.
Pages : 1
