osm-fr
résidus après maj pg
après maj pg, il reste des résidus de l'ancienne version, faudrait automatiser la migration dans la mesure du possible. actuellement sur:
- [x] osm104 (bano)
- [x] osm105 (layers)
- [x] osm108
- [x] osm143 (mastodon)
- [x] osm155
- [ ] osm202 (bzh)
Ménage fait sur osm143 (mastodon) Après le pg_upgradecluster de postgres, un petit pg_dropcluster de l'ancien permet de supprimer ces résidus
osm105: je ne vois pas résidus, il y a une base monde pour layers, mais plus de mise à jour à cause d'osmosis. J'ouvre un ticket à son sujet pour voir ce qu'on fait d'osm105... merge avec osm165 ?
osm108: le PG 9.4 n'est pas utilisé, aucune base dedans, elles sont toujours en 9.1 (bases osmose et polygons)... j'ai donc supprimé le PG 9.4 vide, mais un gros upgrade général est nécessaire si ces services sont encore actifs.
osm155 (peertube): un PG11 installé, mais sans base, toujours en 9.6... j'ai supprimé le PG11, un upgrade en PG12 serait à faire.
Si vous êtes passé en buster en utilisant pg_upgrade il faut reconstruire tous les index. La raison du pourquoi : https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html
Sur osm108, il ne devrait plus y avoir de base osmose utilisé. Par contre, polygons est effectivement à migrer sur une nouvelle VM.
C'est plutôt pg_upgradecluster qui est utilisé.
C'est pareil, enfin pg_upgradecluster c'est un wrapper debian autour de pg_upgrade.
sur osm202, on a PG10 (actif), PG11 et PG12 installés mais pas utilisés (pas d'upgrade de fait), du ménage pour Mael
@MaelREBOUX: tu pourrais regarder pour les bases de données à nettoyer sur bzh202 ?
Peut-être un résidu : http://polygons.openstreetmap.fr/?id=5936703 indique une relation cassée mais le premier lien c'est un 404 (https://analyser.openstreetmap.fr/cgi-bin/index.py?relation=5936703) et le second n'aboutit pas (https://analyser.openstreetmap.fr/cgi-bin/index.py?relation=5936703). Il est possible que l'analyse soit "simplement" trop complexe pour le second service par contre le premier semble un résidu de migration. Indirectement dû à la migration pg ?
@Bibi56 : ce n'est pas lié à ces bases pgsql. En fait, ces deux services n'ont pas été réinstallé depuis la migration de download.openstreemap.fr sur une nouvelle machine. Pour le cas dont tu parles, est-ce que la liste des ways reportés après "Message from postgresql server:" n'est pas suffisant pour avancer ?
@jocelynj merci de ta réponse. Peut-être que brancher vers http://ra.osmsurround.org/analyzeRelation?relationId=5936703&_noCache=on serait utile, je trouve ça plus clair que le brut de pg. N .B : clique sur le lien et tu verras que sur JOSM c'est problématique. Mais une telle relation est dans tous les cas problématique !
Alors oups total : je découvre cette issue à l'instant.
MySQL et PostgreSQL ne servent plus à rien sur ce serveur. Je viens de désinstaller MySQL et le PostgreSQL 10.
Il reste donc un serveur (éteint) et un client PostgreSQL 13.2 qui doit correspondre à votre déploiement.
Je propose de fermer ce ticket.
