Vous n'êtes pas identifié(e).
Pages : 1
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
Hors ligne
Non, les WALs ne sont utilisables qu'entre instances de même version majeure, et qu'entre copies physiques de la même base (pas entre une base, et le résultat de l'import de cette base).
Vous n'avez pas vraiment de solution simple pour résoudre votre problème, étant donné que vous avez en plus cette conversion de l'encoding à effectuer. Sinon, il y aurait eu des solutions pour gagner du temps (réplication slony par exemple, ou restauration en parallèle du dump).
Marc.
Hors ligne
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.
Hors ligne
La réplication Slony n'est vraiment pas utilisable ici à cause du problème d'encodage. À moins que ThuGaim soit sûr que les données enregistrées sont toutes en UTF-8, je prévois un max de problème (quelque soit la solution d'ailleurs). Il ne faut JAMAIS utiliser SQL_ASCII.
Guillaume.
Hors ligne
Non. Vous pouvez le faire avec des triggers. C'est ce que fait slony par exemple.
De toutes façons, tracer les requêtes n'est pas suffisant pour répliquer les modifications entre deux bases: le résultat des requêtes est dépendant du contexte (session) dans lequel il s'exécute. L'ordre de ces sessions est très important.
Avant de partir sur des solutions très complexes, de combien de temps disposez-vous pour migrer votre base ? Combien de temps prend le dump actuellement ? Et la restauration ?
Marc.
Hors ligne
Et pour répondre à la dernière question possible, PostgreSQL sait tracer les requêtes. Cependant, ce n'est pas suffisant. Il vous manquera de pouvoir les exécuter exactement de la même façon, avec le même parallélisme. Bref, c'est injouable.
Votre seule solution raisonnable est un dump suivi d'un restore. Et faites des tests avant car vous risquez d'avoir des soucis à cause de l'encodage.
Guillaume.
Hors ligne
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
Dernière modification par ThuGaim (20/04/2011 14:04:42)
Hors ligne
Ok. Vous devriez donc pouvoir faire tenir tout ça en 18 minutes environ, en ne passant pas par le disque, avec des pipes (au moins si vous utilisez un système unix).
Vous pouvez effectuer le dump, la conversion en la restauration en même temps.
Vous n'arriverez à mon avis pas à faire mieux, vu que vous devez convertir vos donnez en même temps.
Dernière modification par Marc Cousin (20/04/2011 14:19:43)
Marc.
Hors ligne
Pages : 1
