Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
aspcitrix:update_version_medialog [2018/11/08 10:23] didier [Base] |
aspcitrix:update_version_medialog [2021/02/18 22:48] (Version actuelle) |
||
|---|---|---|---|
| Ligne 4: | Ligne 4: | ||
| ===== __Chronologie theorique :__ ===== | ===== __Chronologie theorique :__ ===== | ||
| + | en cas de maj 100% **manuelle**, passer directement à l'étape USERS et ACCES (1). | ||
| + | On peut également profiter d'une partie automatique, dans ce cas il faudra uniquement faire manuellement les points mis en gras dans les étapes ci dessous. | ||
| + | |||
| + | pour pour pouvoir lancer la partie **automatique**, on peut le faire en 'live' ou procedé par planification en tache schedulé (cfr daily update et ses commentaire). \\ | ||
| + | pour cela il faut se connecter en bureau a distance sur la machine TLCONV15 en tant qu'utilisateur 'tldomain\migrateur'. | ||
| + | Sur le bureau il y a un raccourci vers le dossier e:\update352. | ||
| + | |||
| + | En **live**, on pourra y lancer le fichier script update352.cmd, le script demandera l'alias du client que l'on va migrer, en cas de multifiliale, le script va regarder dans customer_addon et fera toutes les filiales répertoriées dans cette table. (le script d'upgrade de la base sera repris a un endroit équivalent a \\tlconv15\DiskE\Update360\scripts_sql\tout 3a6 pour bin+00.sql, donc il est bon de s'assurer que celui correspond au script officiel sur le tlserv2) | ||
| + | |||
| + | En cas d'utilisation de la tache **scheduler** il faudra créer un fichier texte au format "update_list[Date au formatYYYYMMDD].txt qui contiendra les alias client à migrer. | ||
| + | |||
| + | plus d'information sur le script sur le drive : https://drive.google.com/open?id=1PDX9rHugKs0rE_pTMUlSQTRMVYaI82XNy69ZqHjns7s | ||
| ==== Users et accès (1) ==== | ==== Users et accès (1) ==== | ||
| - | * prévenir le service IT que l'on va travailler sur un client précis, car des avertissements d'erreurs sur la NON accessibilité de la base du client vont apparaitre sur Nagios. | + | * **prévenir le service IT que l'on va travailler sur un client précis, car des avertissements d'erreurs sur la NON accessibilité de la base du client vont apparaitre sur Nagios.** |
| * désactivation (disable) des users dans l'active directory (tladfs1), pour éviter des reconnexions des users durant la phase d'upgrade | * désactivation (disable) des users dans l'active directory (tladfs1), pour éviter des reconnexions des users durant la phase d'upgrade | ||
| * faire un logoff des users recalcitrants encore connectés sur le farm (prog TLMC sur tlxadmin) | * faire un logoff des users recalcitrants encore connectés sur le farm (prog TLMC sur tlxadmin) | ||
| Ligne 11: | Ligne 23: | ||
| ==== Base ==== | ==== Base ==== | ||
| - | * on peut vérifier qu'il reste assez de place sur le serveur BD qui héberge le client. pour garder l'ancienne version, faire des backup/restore .... | + | * on peut vérifier qu'il reste assez de place sur le serveur BD qui héberge le client. pour garder l'ancienne version, faire des backup/restore .... (df -h sur serveur linux) |
| * se connecter (ibexpert) sur la base du client (sur tldbsx) que l'on va mettre a jour. | * se connecter (ibexpert) sur la base du client (sur tldbsx) que l'on va mettre a jour. | ||
| * renommer la base mlv2.fdb en mlv2_yyyyy.fdb | * renommer la base mlv2.fdb en mlv2_yyyyy.fdb | ||
| * regarder avec ibexpert dans la table MON$ATTACHMENT s'il existe des connexions autre que la notre, les tuer s'il en existe => DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION | * regarder avec ibexpert dans la table MON$ATTACHMENT s'il existe des connexions autre que la notre, les tuer s'il en existe => DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION | ||
| * par securité sauvegarder la base mlv2_yyyyy.fdb en prenant une copie mlv2_yyyyy_save.fdb | * par securité sauvegarder la base mlv2_yyyyy.fdb en prenant une copie mlv2_yyyyy_save.fdb | ||
| - | * récupérer le ou les scripts (si on upgrade de plusieurs version) de mise a jour de bases de donnée sur le tlfsint (exemple dans \\tlfsint\TLSERV2\Versions\Interne\version_2_3A5\upd\Script prendre le script tout 3a5 pour bin+02.sql pour passer de la version 3.5.1 a 3.5.2) et le mettre a coté du programme pmajbase.exe (voir point suivant). | + | * **récupérer le ou les scripts (si on upgrade de plusieurs version) de mise a jour de bases de donnée sur le tlfsint (exemple dans \\tlfsint\TLSERV2\Versions\Interne\version_2_3A5\upd\Script prendre le script tout 3a5 pour bin+02.sql pour passer de la version 3.5.1 a 3.5.2) et le mettre a coté du programme pmajbase.exe (voir point suivant).** |
| * exécuter le programme pmajbase.exe sur la base que l'on a renommer mlv2_yyyyy.fdb avec le ou les scripts d'update. (le programme pmajbase.exe peut être trouvé sur le tlxadmin (C:\Tools\Medialog\pmajbase), le fichier pmajbase.ini peut contenir le chemin et le nom de la base a updater. ATTENTION bien cocher dialect 3 et préciser encodage client. | * exécuter le programme pmajbase.exe sur la base que l'on a renommer mlv2_yyyyy.fdb avec le ou les scripts d'update. (le programme pmajbase.exe peut être trouvé sur le tlxadmin (C:\Tools\Medialog\pmajbase), le fichier pmajbase.ini peut contenir le chemin et le nom de la base a updater. ATTENTION bien cocher dialect 3 et préciser encodage client. | ||
| - | * contrôler en fin d'exécution que l'on a pas d'erreur qui pourrait contrecarrer notre mise a jour. (err_upgrade.log) | + | * **contrôler en fin d'exécution que l'on a pas d'erreur qui pourrait contrecarrer notre mise a jour. (err_upgrade.log)** |
| * faire un backup de la base (en désactivant le garbage). (par exemple via un iboconsole - pour ma part en me connectant sur le tldbs5). | * faire un backup de la base (en désactivant le garbage). (par exemple via un iboconsole - pour ma part en me connectant sur le tldbs5). | ||
| * faire un restore de la base que l'on vient de backuper (en mlv2_yyyyy_new.fdb) et ensuite la renommer en mlv2.fdb | * faire un restore de la base que l'on vient de backuper (en mlv2_yyyyy_new.fdb) et ensuite la renommer en mlv2.fdb | ||
| Ligne 25: | Ligne 37: | ||
| ==== Bin ==== | ==== Bin ==== | ||
| * Sur le tladfs1 prendre les bin des nouvelles versions \\tladfs1\e$\Share1\Media_update\Bin_23a5+02 par exemple) et les mettre dans la directory du client (dans l'ordre croissant des versions si on upgrade de plusieurs versions) (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin par exemple) | * Sur le tladfs1 prendre les bin des nouvelles versions \\tladfs1\e$\Share1\Media_update\Bin_23a5+02 par exemple) et les mettre dans la directory du client (dans l'ordre croissant des versions si on upgrade de plusieurs versions) (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin par exemple) | ||
| - | * contrôler avec beyond compare que tout les fichiers du tladfs1 sont plus récents que ceux du tladfs2 pour notre client (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin <--> \\tladfs2\e$\Share2\MediaLog\ML_TLLIB\Fil_version\Bin). Attention aussi il ne peut pas y avoir de dossier schemacache (a supprimer s'il existe)). S'il y a des fichiers plus récent sur le tladfs2, alors les écraser avec ceux du tladfs1, sinon durant la nuit le tladfs2 écrasera les bons fichier du tladfs1 ...). | + | * **contrôler avec beyond compare que tout les fichiers du tladfs1 sont plus récents que ceux du tladfs2 pour notre client (\\tladfs1\e$\Share1\MediaLog\ML_TLLIB\Fil_version\Bin <--> \\tladfs2\e$\Share2\MediaLog\ML_TLLIB\Fil_version\Bin). Attention aussi il ne peut pas y avoir de dossier schemacache (a supprimer s'il existe)). S'il y a des fichiers plus récent sur le tladfs2, alors les écraser avec ceux du tladfs1, sinon durant la nuit le tladfs2 écrasera les bons fichier du tladfs1 ...).** |
| * Si le client va travailler le même jour après notre upgrade \\ | * Si le client va travailler le même jour après notre upgrade \\ | ||
| - il faut mettre à jour toutes les machines virtuelles du farm, via le programme TLMC sur le tlxadmin, menu TOOLS - Maj bin Man. | - il faut mettre à jour toutes les machines virtuelles du farm, via le programme TLMC sur le tlxadmin, menu TOOLS - Maj bin Man. | ||
| Ligne 35: | Ligne 47: | ||
| ==== Doc et programmes externes ==== | ==== Doc et programmes externes ==== | ||
| - | * Vérifier si il n'y a pas de taches bloquées sur le tlworks1 suite à l'indisponibilité temporaire de la base du client (les tuer si nécessaire) | + | * **Vérifier si il n'y a pas de taches bloquées sur le tlworks1 suite à l'indisponibilité temporaire de la base du client (les tuer si nécessaire)** |
| - | * modifier le fichier version.info du client pour y renseigner la date de l'upgrade (copier/coller dans le fichier) (\\tlfsint\TLSERV2\Versions\EcrivainPublic par exemple) | + | * **modifier le fichier version.info du client pour y renseigner la date de l'upgrade (copier/coller dans le fichier) (\\tlfsint\TLSERV2\Versions\EcrivainPublic par exemple)** |
| - | * adapter la colonne version dans le fichier clients.xls (\\tlfsint\TLSERV2\Versions\interne\doc\) | + | * **adapter la colonne version dans le fichier clients.xls (\\tlfsint\TLSERV2\Versions\interne\doc\)** |
| * modifier le champ CUS_MLVERSI dans le record avec le cus_id du client dans la table CUSTOMERS( base e:\databases\tlcustomers\tlcustomers.fdb sur tldbs7) | * modifier le champ CUS_MLVERSI dans le record avec le cus_id du client dans la table CUSTOMERS( base e:\databases\tlcustomers\tlcustomers.fdb sur tldbs7) | ||
| - | * Activer certains programme externes qui peuvent être nouveaux avec la version pour notre client (exemple la mise à jour de la date de publication lors du passage de la 3.5.1 a la 3.5.2) | + | * **Activer certains programme externes qui peuvent être nouveaux avec la version pour notre client (exemple la mise à jour de la date de publication lors du passage de la 3.5.1 a la 3.5.2)** |
| * Lors du passage en 3.5.2 , ne pas oublier d'ajouter le client pour la mise à jour de la date de publication sur le tlworks1 qui se situe sur e:\tools\all\updatedatepub , il suffit de lancer l'application, sélectionner l'alias de base de données, définir le type de client ( BEFR, BENL ou NL ) et d'ajouter le client. On peut manuellement faire une initialisation du client si nécessaire sinon elle se fera automatiquement au prochain démarrage. | * Lors du passage en 3.5.2 , ne pas oublier d'ajouter le client pour la mise à jour de la date de publication sur le tlworks1 qui se situe sur e:\tools\all\updatedatepub , il suffit de lancer l'application, sélectionner l'alias de base de données, définir le type de client ( BEFR, BENL ou NL ) et d'ajouter le client. On peut manuellement faire une initialisation du client si nécessaire sinon elle se fera automatiquement au prochain démarrage. | ||