On a eu récemment une anomalie détectée sur le flux de téléchargement des diffs sur les serveurs tiers à cause de pannes sur le serveur principal qui ont fait que certains fichiers diffs ont été régénérés en écrasant un certain nombre d'anciens fichiers (pourtant valides) par une nouvelle version contenant une vue plus récente des objets voire plus d'objets ou moins.
Les dates indiquées dans les différentes instance d'Overpass indiquaient pourtant toutes que ces données étaient "à jour" mais il y avait des "oublis". Cela a causé des désynchronisations sur les serveurs tiers. Cela peut exister depuis en fait longtemps et à chaque arrêt redémarrage du serveur principal générant les fichiers diffs, il ya a pu y avoir des fichiers diffs écrasés. On ne s'en aperçoit plus tard que sur les serveurs tiers qui ont téléchargé les anciennes versions de ces fichiers diffs mais qui ne s'aperçoivent pas que sur le serveur principal leur contenu a changé: les autres fichiers diffs qui suivent peuvent contenir alors à des objets qui ne sont QUE dans les nouvelles versions mais pas dans les anciennes versions écrasées. ---- Il manque un système pour sécuriser cela et notamment il faudrait que le serveur où sont récupérés les diffs maintienne un fichier index avec les empreintes numériques (SHA1 ou MD5) des fichiers diffs afin que les serveurs tiers puissent savoir lesquels ont été écrasés et régénérés avec un contenu différent. Les robots qui consultent les fichiers diffs pour charger une autre base sauraient alors précisément quels fichiers sont à charger et au moins remonter à la source de la désynchronisation quand des diffs suivants ne sont pas chargeables car ils mentionnent des objets avec des ID inexistants qui n'existent que dans les nouvelles versions de fichiers diffs précédents). Sinon l'autre solution c'est pour ces robots de faire des requêtes HTTP "STAT" sur un grand nombre de fichiers diffs précédent pour voir ceux qui ont pu changer (en comparant les dates ou tailles). Mais il serait plus simple de limiter ces requêtes en ne faisant un HTTP "STAT" que sur un seul fichier index principal (qui peut lister des sous-fichiers index secondaires, par exemple un fichier index secondaire par heure, le fichier index principal par jour ne contient alors que 24 empreintes numériques pour chacun des 24 fichiers index par heure dont chacun liste les empreinte des diffs générés pendant cette heure). Le but au final c'est d'avoir une identification précise de tous les fichiers diffs qui ne sont pas encore chargés ou pas chargés dans leur dernière version connue par le serveur principal. ==> Ce qui reste ensuite à faire c'est savoir comment un serveur tiers va agir s'il y a des nouvelles versions de fichiers diff précédents, alors qu'il les a déjà traités et a pu en traiter un certain nombre d'autres (qui eux sont bien synchronisés et souvent ne dépendent pas non plus du contenu des diffs précédents). ==> Aucun protocole n'est défini pour automatiser ces resynchronisations, ces corrections se font pour l'instant manuellement dans chaque base tierce. Ou bien l'administrateur de la base tierce décide de ne rien faire manuellement et prévoit de recharger plus tard la totalité de la base depuis un dump global (ce qui nécessite tout de même plusieurs jours de traitement, puis de rejouer un certain nombre de diffs à partir de ce dump, et nécessite donc de pouvoir disposer d'une seconde base pour ensuite faire facilement la bascule de la base utilisée en ligne une fois ces rechargements terminés). ==> C'est pourtant un problème classique de réplication de bases de données entre un serveur maître et des serveurs esclaves (cela existe pourtant dans certains moteurs de bases de données, et tous les serveurs SQL commerciaux qui savent répliquer en utilisant les "commit logs", ce système de réplication devrait exister nativement aussi en PostgreSQL; certains moteurs savent aussi synchroniser deux bases dans les deux directions, pour les bases compatibles avec le "two-phase commit" et synchronisées par un moniteur transactionnel chargé de coordonner et arbitrer les priorités, selon les types d'objets et les types de transaction ou les utilisateurs: certains clients recevront des notifications de "rollback" d'autres verront leurs commits acceptés; mais cela nécessite que les applications clientes des serveurs esclaves soient préparées à traiter les rollbacks possibles et gérer des files d'attente de transactions non finalisées). Le 21 mai 2015 18:27, Éric Gillet <gill3t.3ric+...@gmail.com> a écrit : > Ne serait-ce pas juste un retard sur l'age des données ? > > Dans la réponse du serveur normalement il y a la dernière mise-à-jour des > données Overpass : > > <meta osm_base="2015-05-21T16:25:02Z"/> > ou > "timestamp_osm_base": "2015-05-21T16:26:02Z", > > Le 21 mai 2015 16:59, mga_geo <mga_...@yahoo.fr> a écrit : > >> Bonjour, >> >> J'utilise souvent le serveur http://overpass.osm.rambler.ru. Hors sur une >> requête de comparaison des arrêts de bus sur Rennes, je trouvais toujours >> des différences même après modification dans OSM (par exemple >> https://www.openstreetmap.org/node/3266582540/history ). >> Le serveur http://overpass-api.de donne par contre la bonne version. >> >> Comment est-il possible de savoir qu'un serveur a des différences par >> rapport à OSM ? >> >> A+ >> Marc >> >> >> >> >> -- >> View this message in context: >> http://gis.19327.n5.nabble.com/Overpass-difference-de-reponses-en-fonction-du-serveur-tp5845428.html >> Sent from the France mailing list archive at Nabble.com. >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
