<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">le serveur utilisé actuellement dépend de la position géographique <br>
principalement mais peux aussi changer en cas de surcharge,<br>
info vérifiable en temps réel avec<br>
<a href="https://tile.openstreetmap.org/cgi-bin/debug" rel="noreferrer" target="_blank">https://tile.openstreetmap.org/cgi-bin/debug</a><br>
les 2 serveurs ok : Yevaud et Vial<br>
les 2 serveurs affectés : Scorch et Rhaegal<br></blockquote><div><br></div><div>Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et "orm" (et non pas "rhaegal" ou c'est un ancien alias).</div><div>- "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue<br></div><div>- "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue</div><div>- "Scorch" est en France (à Roubais chez OVH): il est affecté par le bogue, Ubuntu été mis à jour de 16.04 vers 18.04</div><div><div>- "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à jour de 16.04 vers 18.04</div><br></div><div>La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la persistence de ways parasites (marqués comme supprimés dans les "diffs" mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il semble que l'impact de cette mise à jour serait que les fichiers "diffs" seraient traités alors qu'ils ne sont pas complètement téléchargés : le traitement se fait sur une partie seulement des changesets qui sont alors tronqués.</div><div><br></div><div>Ce n'est apparemment pas un problème de base de données (sur la base de données esclave), mais des outils de téléchargement et synchronisation de répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script shell avec "wget", mais cet outil ne semble pas correctement synchronisé avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour les charger sur la base esclave, une ancienen opération qui était bloquante semble être devenue asynchrone et il manque une étape de validation des téléchargements de diffs effectivement terminés avant de placer ces fichiers dans la file d'attente à traiter pour l'import).</div><div><br></div><div><br></div></div></div>