Vous n'êtes pas identifié(e).
Salut,
Depuis quelques temps, je travaille sous postgreSQL et j'utilise, en guise de backup, un système de PITR. Toutes les 24heures, je place mon serveur en mode backup pour recopier le répertoire pg_data sur un drive réseau et toutes les 15 minutes, je force la génération d'un WAL copié sur ce même disque (archive_command et archive_timeout). Récemment, j'ai eu un crash hardware et j'ai du restaurer mon backup sur un autre serveur. J'ai déjà réalisé cette opération sans problème par le passé mais cette fois, lorsque j'ai redémarré postgres, mes séquences sont toutes tombées. J'ai tenté de restaurer une seconde fois et le problème s'est reproduit. Habituellement, j'utilise 2 serveurs strictement identiques (pour la production et le backup) et tout se passe sans problème. Mais ici, mon serveur de production est un Xeon et le serveur de secours est un Opteron (je ne sais pas si ça joue beaucoup...) Les 2 machines sont sous Red Hat entreprise 4.4 et postgres 8.2.6.
Quelqu'un voit où se situe le problème?
Merci.
Hors ligne
Si l'architecture est différente, la restauration ne peut pas fonctionner. À priori, les deux sont 64 bits, donc je me demande si c'est vraiment le problème. Avez-vous essayé sur un Xeon ?
Guillaume.
Hors ligne
J'ai effectivement tenter la même opération avec les mêmes fichiers sur un autre serveur Intel et ça a fonctionné.
Je ne comprend pas où se situe le problème, j'ai cherché sur le site de PostgreSQL mais je n'ai trouvé aucune contre indication pour ce type de backup.
Hors ligne
Entre AMD et Intel, je ne pense pas que les différences soient visibles pour PostgreSQL : pas d'utilisation de SSE, des extensions VT ou d'autres petites choses de ce genre qui font la différence entre un Xeon et un Opteron. Ces deux processeurs ont le même jeu d'instruction, vu de Postgres. D'ailleurs les distributions et packages tagguées comme AMD64 ou x86_64 s'installent indifféremment sur les deux architectures.
Marc.
Hors ligne
Je ne sais pas si ça a ou non son importance mais je n'installe jamais postreSQL via package (rpm ou autre) je le compile toujours sur la machine.
Hors ligne
A part le possible temps perdu, ça n'a pas d'importance 
Par contre êtes vous sûr d'avoir compilé les deux moteurs exactement de la même façon ?
Marc.
Hors ligne
J'ai utilisé gcc dans les 2 cas et compilé comme suit :
tar –xjvf postgresql-8.2.12.tar.bz2
cd /root/install/postgresql-8.2.12
./configure
make
make install
Dernière modification par etpaf (05/11/2009 09:31:16)
Hors ligne
- Je croyais que c'était une 8.2.6.
- As tu le config.log de chaque ? Tu peux toujours en faire un diff pour voir ce qui a été fait différemment entre les 2 serveurs, si quelque chose a été fait différemment.
- Autre méthode : faire les checksums de tous les fichiers postgres des 2 côtés (exécutables, librairies…)
Pas que je sois sûr que de toutes façons une différence de compilation entre les deux noeuds puisse entraîner ce problème. Mais autant s'en assurer.
Marc.
Hors ligne
Effectivement, c'est une 8.2.6 mais depuis l'installation de ce client (3ans) nous sommes passé à la 8.2.12 (les lignes de commande viennent de ma dernière installation.)
Je n'avais pas pensé aux fichiers de log de l'installation, merci du conseil.
Hors ligne
Je viens de comparer les 2 fichiers de log et ils sont identiques, au nom des machines près...
Ce qui me semble plus étrange, c'est que j'ai pu restaurer ce data sur un autre serveur intel, avec postgres 8.2.14 et je n'ai pas le moindre soucis de séquence.
Je suis assez perplexe, les machines sont fort semblables (sauf cpu). Les partitions sont en ext3 sur les 3 machines, c'est assez inattendu...
Hors ligne
C'est effectivement très étrange. Peut-être avez vous fait une erreur dans la procédure de restauration ?
Marc.
Hors ligne
C'est ce que j'ai pensé au début mais je restaure mes bases via un script et c'est ce même script qui m'a permis d'avoir une copie fonctionnelle sur l'autre serveur Intel.
Hors ligne
Rien dans la log Postgres? Pas d'erreur ? Avez vous réessayé depuis sur l'opteron (erreur temporaire ?) ?
Marc.
Hors ligne
2 tentatives sur l'opteron et 2 fois le même résultat...
Vous parlez d'erreur temporaire, s'agit-il d'une heure légèrement différentes sur les 2 serveurs?
Hors ligne
Non, je parlais d'une fois ça rate une fois ça marche
Je ne vois pas pourquoi ça marcherait sur un Xeon et ça échouerait sur un Opteron. C'est bien exactement les mêmes données que vous essayez de restaurer ?
Marc.
Hors ligne
J'utilise la même archive sur les 2 serveurs, c'est assez étrange et plutôt difficile à justifier auprès d'un client.
Surtout que mon employeur a du pas mal batailler pour faire accepter PostgreSQL...
Hors ligne
Ça me semble surtout hautement improbable : il y a une différence entre les deux, mais ça ne vient pas du processeur. Sinon ça risque de devenir compliqué pour AMD et Intel…
Donc merci de contrôler les checksums.
Autre question : êtes vous sûr d'être en 64 bits des 2 côtés (je présume que oui, mais vérifiez quand même). Et que postgres est bien en 64 bits des 2 côtés.
Marc.
Hors ligne
Les 2 OS sont en 32 bits (les CPU permettent le 64 mais le client avait déjà des licences pour du 32).
Je re-essaierai dès que possible l'intégralité de la procédure (de l'archivage du data à sa restauration dès que possible mais le client dispose d'une DB de 35 giga et c'est coton à copier...)
En tout cas, merci pour les avis...
Dernière modification par etpaf (05/11/2009 16:26:32)
Hors ligne
