<html><body><div style="color:#000; background-color:#fff; font-family:Courier New, courier, monaco, monospace, sans-serif;font-size:10pt"><div><span><br></span></div><div><span>Comme tu n es pas en contact avec les admins de la base OSM et que tu juges leurs decisions/actions sans savoir ce qu ils font voici leurs adresses mails : Tom Hughes <tom@compton.nu>; et openstreetmap@firefishy.com <openstreetmap@firefishy.com>;</span></div><div><span>Tu as plein de choses interessantes a leur expliquer et a leur apprendre, pense a garder au moins la liste osm-fr-dev en copie afin que nous puissions apprecier pleinements tes contributions<br></span></div><div><span><br></span></div><div>Julien</div><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-family: Courier New, courier, monaco, monospace, sans-serif; font-size: 10pt;"> <div style="font-family:
times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Philippe Verdy <verdy_p@wanadoo.fr><br> <b><span style="font-weight: bold;">À :</span></b> f.dos.santos@free.fr <br><b><span style="font-weight: bold;">Cc :</span></b> Discussions sur OSM en français <talk-fr@openstreetmap.org> <br> <b><span style="font-weight: bold;">Envoyé le :</span></b> Dimanche 1 avril 2012 23h24<br> <b><span style="font-weight: bold;">Objet :</span></b> Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)<br> </font> </div> <br>Le 1 avril 2012 21:54, <<a ymailto="mailto:f.dos.santos@free.fr" href="mailto:f.dos.santos@free.fr">f.dos.santos@free.fr</a>> a écrit :<br>> Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne<br>> vois pas ce que l'on sacrifie en faisant un pgdump +
pgrestore !<br><br>Un administrateur qui fait son travail son communiquer sur ce qu'il<br>veut faire, ou a fait, n'est pas un bon administrateur.<br><br>> "Toute bonne migration se fait par petites étapes qui passent<br>> presque inaperçues"<br>> Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu<br>> quand la base sera de nouveau en ligne.<br><br>C'est un apriori. Non décrit dans le plan de migration en court.<br><br>> "la base sera beaucoup plus « nettoyée » que ce qui a été annoncé"<br>> Pas de soucis à se faire vu qu'il n'y a aucun nettoyage.<br><br>Etant donné le plan d'urgence des 4 jours donnés pour faire le<br>travail, ils n'auront guère d'autre choix que de sacrifier une partie<br>des données en cas de problèmes, sinon ils ne redémarrent pas !<br><br>> "car justement ces administrateurs n'ont pas le temps de communiquer"<br>> Un admin ça administre c'est pas fait pour
faire de la comm.<br><br>Un administrateur qui fait son travail son communiquer sur ce qu'il<br>veut faire, ou a fait, n'est pas un bon administrateur, en tout cas<br>pas pour ce type de projet collaboratif. D'une façon ou d'une autre,<br>s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui<br>pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.)<br>permettant de tracer toutes ses actions.<br><br>> "On ne sait pas si les décisions prises sur une partie seront<br>> réversibles et si on aura même la possibilité de repérer ce qui<br>> manque"<br>> Tu radotes<br><br>Non. Le rique est réel.<br><br>> "Car le processus de migration n'a de serveur pas été documenté"<br>> Si là : <a href="http://lists.openstreetmap.org/pipermail/announce/2012-March/000061.html" target="_blank">http://lists.openstreetmap.org/pipermail/announce/2012-March/000061.html</a><br>> Technical: pg_dump (smaug) to pg_restore
-j x (ramoth). Upgrading from<br>> PostgreSQL 8.4 to PostgreSQL 9.1<br><br>On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des<br>migrtions de bases de données dans le passé, on a toujours rencontré<br>des problèmes de compatibilité sur des bases de données très<br>volumineuses. Pour passer le problème, on sacrifie une partie des<br>données non convertibles (ou mal converties et rejetées dans le<br>nouveaux schéma).<br><br>Après reste à résoudre le problème de ces données manquantes (à<br>condition de les avoir identifiées, conservées à part, afin de trouver<br>une solution ultérieure pour elles, et analyser proprement pourquoi<br>elles n'ont pas été acceptées et ce qu'on peut faire pour les<br>corriger. Sur des données aussi volumineuses, ces données en conflit<br>peuvent elles aussi être très volumineuses et demander plus que 4<br>jours pour les convertir proprement, au moins en partie, tout
en<br>sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin<br>de pouvoir vérifier aussi l'intégrité des données qui sont passées.<br><br>> "Alors je croise les doigts pour que les historiques complets (au moins<br>> la dernière modification par un utilisateur avant celle d'un<br>> utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent<br>> accessibles même sur la nouvelle base."<br>> Oui l'historique est préservé.<br>><br>> Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour<br>> ça.<br><br>Et il n'est pas inintéressant de lire les notes de compatibilité entre<br>PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne<br>seulement une idée sommaire (le détail est plus compliqué si on tient<br>compte de la plateforme matérielle ou OS) :<br><br><a href="http://www.postgresql.org/docs/9.1/static/release-9-1-3.html"
target="_blank">http://www.postgresql.org/docs/9.1/static/release-9-1-3.html</a><br><br>Ainsi que les notes de bogues existants pour ces migrations. Car il y en a !<br><br><a href="http://www.postgresql.org/docs/9.1/static/release-9-1.html" target="_blank">http://www.postgresql.org/docs/9.1/static/release-9-1.html</a><br><br>Certains outils ont des bogues jugés « non critiques » comme des<br>fuites mémoire, qui pourtant commenceront à tout planter au milieu<br>passé un certain volume de données traitées. D'autres choses concerne<br>la stabilité des tris et index. La compatibilité des critères<br>d'unicité pour les collations (changement de version des bases CLDR ou<br>Unicode par exemple).<br><br>Aussi, la compatibilité des systèmes I/O (en cas de changement de<br>version de l'OS hôte ou de son architecture matérielle). Des<br>contraintes liées aux processeurs pour la synchronisation multithread<br>(certaines procédures SQL qui
n'avaient à priori pas besoin de<br>synchronisation vont en avoir besoin, ou bien il y a de nouveaux<br>deadlocks entre sections critiques, générant des erreurs SQL et des<br>rollbacks implicites de transactions qui passaient sans problèmes<br>avant).<br><br>Des différences aussi dans la syntaxe SQL ou le support des plugins<br>GIS, ou dans la version du noyau de VM si le moteur supporte les<br>traitements dans une VM intégrée au moteur, tel que Java, ou des<br>différences de comportement et de compatibilité avec d'autres plugins<br>en code natif (certains intégrant des mots-clés, fonctions, types SQL<br>supplémentaires, ou de nouvelles méthodes d'indexation et de recherche<br>et jointure), ou de nouvelles restrictions de sécurité. Espérons que<br>le logiciel a déjà été testé sur le nouveau serveur, avec un jeu de<br>données de test significatif qui sera effacé, avant de commencer la<br>migration des données réelles
elles-mêmes.<br><br>Et que les interfaces disque/réseau n'ont pas de soucis matériel en<br>cas de montée en charge (les tests sur un jeu de données réduit ne<br>suffisant pas, il faut aussi normalement les compléter en important<br>massivement des données quasi-aléatoires générées par un petit script<br>répliquant tous les cas, y compris avec des index déséquilibrés). Mais<br>il est notoirement très difficile de simuler l'activité réelle des<br>requêtes venant du réseau, ainsi que celles générées par les diverses<br>API développées (y compris celle des dumps destinés à être<br>redistribués publiquement, qui doivent pouvoir tourner aussi sans<br>planter ou bloquer tout le reste).<br><br>Encore plus difficile à prévoir : des différences notables de<br>performance (pas toujours meilleure dans tous les cas !) dont l'effet<br>peut être inattendu voire même s'avérer très bloquant pour certaines<br>requêtes (les index sont
sensibles aux changements d'algorithmes<br>internes, qui souvent ne sont faits et optimisés que pour répondre à<br>certaines heuristiques "classiques"), à cause de nouvelles<br>vérifications de contraintes référentielles (l'algo optimisé passe<br>alors dans un mode de compatibilité bien plus lent que l'ancien algo<br>seul). On note aussi des différences de volumétrie notables de<br>certains index paginés (liés parfois à des contraintes matérielles<br>d'alignement de données, soit pour le processeur lui-même soit pour<br>les systèmes d'I/O).<br><br>Plus jamais je ne recommanderai une migration de type Big Bang qu'on<br>ne sait pas mener en quelques minutes d'installation. plusieurs jours<br>c'est beaucoup trop, surtout s'il y a de nombreux utilisateurs qui en<br>dépendent (que ces utilisateurs payent ou soient payés ou non pour les<br>utiliser, et surtout si ces utilisateurs sont externes et hors de<br>contrôle direct de celui qui
commande la migration de l'application).<br>Car je sais que de telles migration peuvent prendre jusqueà 10 fois<br>plus de temps que prévu.: une migration prévue de quelques minutes qui<br>prendrait la nuit, ça passe encore, après ça, on y risque sa santé ou<br>son job à la roulette russe, et la survie de l'organisation qui l'a<br>demandée, même si elle a pris certaines assurances !<br><br>Et même quand on commence une telle migration Big Bang (supposée durer<br>quelques minutes), il doit toujours être possible de l'annuler en<br>cours et continuer en s'en passant (pour la reprendre plus tard quand<br>on pourra si jamais on la recommence après avoir identifié la source<br>des problèmes et les moyens de le contourner), car on a toujours des<br>surprises inattendues (pas toujours positives) sur les performances<br>réelles du processus. Ce qui veut dire que d'autres prejets ne<br>devraient pas en dépendre directement ou devraient prévoir
une<br>alternative possible en cas de défaut. De tels plans de repli immédiat<br>doivent être prêts avant même de commencer la migration.<br><br>4 jours de travail prévus (même seulement pour surveiller comment ça<br>se passe) c'est beaucoup, et les administrateurs rentrent aussi chez<br>eux et ont besoin de dormir s'il veulent éviter des erreurs de<br>manipulation (ils ne seront pas toujours là dans les 4 jours, ils<br>peuvent se relayer mais oublier de se transmettre des infos sur ce qui<br>a déjà été fait ou reste à faire, même avec le meilleur plan préparé,<br>d'une façon ou d'une autre ils faut qu'ils se débrouillent avec leurs<br>propres moyens et prennent seuls des décisions immédiates et pas<br>toujours notées).<br><br>_______________________________________________<br>Talk-fr mailing list<br><a ymailto="mailto:Talk-fr@openstreetmap.org" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br><a
href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br><br><br> </div> </div> </blockquote></div> </div></body></html>