Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Il y a des choses fondamentales basiques que je n'arrive pas à comprendre et ça se traduit par mon incapacité à remettre mon serveur postgresql d'aplomb après une mise à jour de mon système. Donc...
J'ai une partition /var/www sur laquelle se trouve des bases de données dans /var/www/bdd/data
J'ai changé mon système linux, sans rien toucher à la partition. Du coup j'ai un nouveau postgres 9.4 au lieu du 9.3 d'avant.
Je crée un utilisateur postgres. Je lance configure le bazar pour que postgres se lance au démarrage de l'ordinateur. Là tout va bien. Sauf que :
- Il veut des bases de données dans /var/lib/pgsql/data
- que initdb refuse d'utiliser /var/www/bdd/data
- que si je lui demande de faire un upgrade de /var/www/bdd/data il me répond
su -c 'postgresql-setup --upgrade --datadir=/var/www/bdd/data'
WARNING: --datadir option is ignored, either use --new-systemd-unit
option, or configure the systemd unit manually.
ERROR: Cannot upgrade because the database in /var/lib/pgsql/data is of
version 9.4 but it should be 9.3Ce qui veut dire que mon option datadir il s'en fout.
- du coup je lance
bash-4.3$ PGDATA=/var/www/bdd/data
bash-4.3$ echo $PGDATA
/var/www/bdd/data
bash-4.3$ postgres -D $PGDATA
LOG: no se pudo enlazar al socket IPv4: La dirección ya se está usando
HINT: ¿Hay otro postmaster corriendo en el puerto 5432? Si no, aguarde unos segundos y reintente.
WARNING: no se pudo crear el socket de escucha para «localhost»
FATAL: no se pudo crear ningún socket TCP/IPDonc si je comprend tout, ça veut dire en clair :
Je suis lancé en pointant sur le cluster (?) ou groupe de basses (?) qui est sur /var/lib et je ne peux pas demarrer sur autre chose. Donc, on ne peut pas avoir plusieurs clusters et un même serveur ?
Si je veux que le serveur démarre avec mon nouveau PGDATA, il faut que je change postgres.conf dans /var/lib/pgsql/data/ et j'obtiens
su -c 'service postgresql start'
Contraseña:
Redirecting to /bin/systemctl start postgresql.service
Job for postgresql.service failed because the control process exited with error code. See "systemctl status postgresql.service" and "journalctl -xe" for details.Et là il refuse de se lancer! et "journalctl -xe" en m'aide pas beaucoup en m'envoyant voir les log du serveur. J'ai trouvé deux fichiers pg_clog et pg_log dans lesquels y a rien d'intéressant. Le fichier /var/www/bdd/data/PG_VERSION contient 9.4 mais je ne suis pas sûr que les bases du répertoire ne soient pas en fait de la version 9.3 et dans un cas comme dans l'autre ça refuse de démarrer.
Donc avant de continuer à m'enfoncer, j'ai besoin de votre aide :
1 - Est-ce que cluster = groupe de bases de données = un répertoire de bases de données.
1.bis - dans un cluster il y a les schémas et dans les schéams les bases de données ?
2 - comment fait-on que le système crash, qu'on installe tout pour retrouver un serveur postgres qui fonctionne avec les anciennes bases ?
3 - Si je veux que mon serveur démarre avec le système, et utiliser soit des bases sur un répertoire dont le propriétaire est postgres soit des bases sur un autres répertoire dont le propriétaire est Deun, je fais comment ?
Merci de m'aider à y voir un peu plus clair
Hors ligne
Bonjour,
Votre postgresql ne pourra pas démarrer car les fichiers de votre instance sont en version 9.3 et les binaires sont en version 9.4.
Il faut soit :
- remettre les binaires en version 9.3
- migrer vos données avec pg_upgrade (http://docs.postgresql.fr/9.4/pgupgrade.html)
Cordialement.
Cordialement,
Sébastien.
Hors ligne
En complément
1 et 1.bis : oui
2 : pas compris
3 : selon votre distribution, il faut regarder si les scripts permettent de spécifier un utilisateur autre que postgres. Pour debian/ubuntu par exemple, c'est posible. Il suffit de créer son cluster avec l'option -u : http://manpages.ubuntu.com/manpages/har … ter.8.html
Si vous voulez réinstaller une version 9.3 sur votre système, regarder du côté des dépôts communautaires (apt.postgresql.org et yum.postgresql.org).
Julien.
https://rjuju.github.io/
Hors ligne
Super merci.
Bon alors le 2 était pas clair, c'est clair. Donc je reformule la chose : si mon système plante, j'installe un autre Linux, comme là c'est Fedora, que la version de postgres n'est pas la même comment je me débrouille pour retrouver mes anciennes base de données.
Si j'ai ien compris ruizsebastien mon instance c'est les bases qui se trouvent dans /var/www/badd/data ? Je ne suis pas sûr de la version. De mémoire il me semble que c'était 9.3...
J'ai déjà regardé http://docs.postgresql.fr/9.4/pgupgrade.html mais ça n'avait pas marché. Ceci dis je n'ai sans doute pas fait ce qu'il faut pour. Voilà le résultat quand j'essaie aujourd'hui...
bash-4.3$ pg_upgrade -c /var/www/bdd/data
cannot write to log file pg_upgrade_internal.log
Failure, exitingde même
pg_upgrade -d /var/www/bdd/data -D /var/www/bdd/pg9.4 -u postgres
cannot write to log file pg_upgrade_internal.log
Failure, exitingrjuju : je cehrcher du côté de fedora si c'est possible, ou comment revenir à la version 9.3. Merci. Ceci étant revenir à une version antérieure ne me semble pas une bonne solution car il faudra bien un jour que je comprenne comment mettre à jour mon serveur.
Dernière modification par Deun (31/12/2015 13:21:56)
Hors ligne
Pour connaitre la version de vos fichiers de données, il suffit de voir le nom des répertoires qui accueille les fichiers de données.
Ces répertoires commence par le numéro de version.
Exemple : PG_9.4_201409291
Cordialement,
Sébastien.
Hors ligne
Je n'ai aucun répertoire comme ça, cependant dans data/base/1/PG_VARSION il y a 9.4 auquel cs je n'ai pas de soucis sur la version. Ça règle un problème parce que je suis sûr de n'avoir jamais touché ce fichier.
Hors ligne
L'idéal dans votre cas serait d'installer le moteur 9.3 en plus du 9.4 et de jouer avec les variables d'environnement. Pour voir quel moteur fonctionne avec vos données.
Cordialement,
Sébastien.
Hors ligne
J'avoue y avoir pensé mais cela me fait un peu peur, déjà que je ne m'en sors pas avec un seul serveur... en plus je ne sais pas si je peux installer deux versions via les paquetages, ou s'il va falloir que je le compile à la main.
Et je me dis qu'il y a forcément moyen de faire autrement. C'est juste que j'y comprend pas grand chose et du coup je dois faire des bourdes.
Il y a deux jours postgres démarrait. Depuis aujourd'hui, à force de bidouiller je n'arrive plus à m'identifier avec l'utilisateur postgres dans psql alors que je n'ai pas changé de mot de passe. Et maintenant plus rien de démarre. C'est bien la preuve que c'est moi qui me débrouille comme un manche.
Hors ligne
Il suffit d'ajouter les dépôt communautaire pour la ou les version majeures voulues, et chaque version pourra être installée en parallèle des autres. Par exemple pour la 9.3 http://yum.postgresql.org/repopackages.php#pg93
Vous pouvez aussi regarder du côté de http://yum.postgresql.org/files/Postgre … n-PGDG.pdf
Sinon, si votre système plante je ne suis pas certain que réinstaller un système différent soit la meilleure chose à faire. Mais dans ce cas c'est encore la même réponse : aller sur les dépôt communautaire et installer la version voulue plutôt que passer par la version supportée nativement pas la distribution.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre aide.
Finalement, j'ai reconfiguré le fichier postgres.config de /var/lib , mon serveur fonctionne.
J'ai décidé de résoudre mon problème de plusieurs clusters en créant un tablespace différent dans un endroit différent (je viens relire en quoi ça consiste ces "tablespace" et ça devrait répondre au besoin). Clairement ça donnerai :
- un tablespace sur /var/www/bdd/gestion avec postgres comme propriétaire et groupe et des droits 700
- un tablespace sur $HOME/../projets_SIG avec deun comme propriétaire et posgres en groupe avec des droits 776
J'utilise le conditionnel parce que pour l'instant, car je bute non pas sur un problème venant de posgres, mais venant des droits sur les répertoires en question... dans les deux cas.
Hors ligne
A propos de cette erreur-là avec pg_upgrade:
cannot write to log file pg_upgrade_internal.log
C'est une erreur toute bête.
Ca arrive quand on lance pg_upgrade alors qu'on n'a pas le droit d'écriture dans le répertoire courant.
C'est parce qu'il veut créer ce fichier dans le répertoire.
Il suffit de faire cd $HOME ou cd /tmp si on n'a pas l'intention de garder ce fichier de log et de relancer la commande.
Dernière modification par dverite (04/01/2016 19:08:11)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1