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