Comment: Migration ou pas ?
| << Previous | Next >> |
Comment inspired from nuxwin
Nuxwin : Ok, alors on va commencer par le début.
Tu ne devrais pas brancher ta nouvelle instance sur la base actuellement en production : comme tu as pu le constater, il y a des nouveautés (il devrait y avoir, dans la nouvelle version...) mais ta base n'est pas mise à jour, donc elles n'y sont pas encore et cela génère les messages d'erreur sql.
Pour mettre fin à ces messages, il faut optimiser la base de donnée. Or si tu fais cela sur la base en production, c'est l'ancienne version de Yacs - celle qui est en production - qui va avoir des problèmes.
Deux portes de sortie :
Donc on récapitule : pour une migration sur un clone, il faut copier l'arborescence actuelle avec tous ces fichiers, et mettre cela dans un sous-domaine par exemple. Créer bien entendu une base de donnée correspondante, et y copier l'ensemble de la base actuellement en production.
Faire ce "clone" nécessitera de modifier (à la main) le fichier de paramètres systèmes pour lui donner les nouveaux éléments relatifs à cette nouvelle instance (en particulier, le chemin, la base de donnée...).
Si tu es à l'aise jusque là, alors vas-y. Sinon, préfère fermer le serveur à la navigation et fait la mise à jour en direct sur le serveur en production. Ça fera des manipulations en moins et on est là si besoin.
Pour info :
Bon, vois déjà ce qui est le plus simple pour toi : le clone ou la migration directe.
-----
Agnès
Il n'y a pas de problèmes, que des solutions.
Tu ne devrais pas brancher ta nouvelle instance sur la base actuellement en production : comme tu as pu le constater, il y a des nouveautés (il devrait y avoir, dans la nouvelle version...) mais ta base n'est pas mise à jour, donc elles n'y sont pas encore et cela génère les messages d'erreur sql.
Pour mettre fin à ces messages, il faut optimiser la base de donnée. Or si tu fais cela sur la base en production, c'est l'ancienne version de Yacs - celle qui est en production - qui va avoir des problèmes.
Deux portes de sortie :
- tu fais la migration sur le site de production.
- tu fais la migration sur un clone, mais un clone "complet" : il te faut aussi copier la base de données.
Donc on récapitule : pour une migration sur un clone, il faut copier l'arborescence actuelle avec tous ces fichiers, et mettre cela dans un sous-domaine par exemple. Créer bien entendu une base de donnée correspondante, et y copier l'ensemble de la base actuellement en production.
Faire ce "clone" nécessitera de modifier (à la main) le fichier de paramètres systèmes pour lui donner les nouveaux éléments relatifs à cette nouvelle instance (en particulier, le chemin, la base de donnée...).
Si tu es à l'aise jusque là, alors vas-y. Sinon, préfère fermer le serveur à la navigation et fait la mise à jour en direct sur le serveur en production. Ça fera des manipulations en moins et on est là si besoin.
Pour info :
- script a exécution unique (run_once) : il y en a lors de mises à jour. Ils sont fournis dans l'archive, et réalisent des opérations uniques (forcer la gestion des droits en cascade par exemple), juste pour cette mise à jour là. La procédure de mise à jour t'invite à passer par cette étape, il suffit de suivre le guide.
- scan : désolée, c'est un raccourci. En fait, il y a plusieurs étapes dans une migration, et là il s'agit de la recherche d'extensions - je crois.
Bon, vois déjà ce qui est le plus simple pour toi : le clone ou la migration directe.
-----
Agnès
Il n'y a pas de problèmes, que des solutions.
by Agnès on Nov. 5 2007
