Changement d'hébergeur et indisponibilité du site
10 messages
• Page 1 sur 1
Consultez la formation à Google Analytics de WebRankInfo / Ranking Metrics
-

Dr DLP - WRInaute impliqué

- Messages: 673
- Inscription: 28 Juin 2003
Changement d'hébergeur et indisponibilité du site
Bonjour
Je suis en train de migrer certains sites d'infomaniak vers OVH et je voudrais vos conseils sur la meilleure manière de le faire, afin de minimiser le temps durant lequel les sites seront indisponibles.
Je pensais faire ceci:
Dans cette idée, durant le transfert de domaine il y aura redirection vers site 2 et tout sera Ok un e fois celui-ci terminé.
Qu'en pensez-vous?
Merci
Je suis en train de migrer certains sites d'infomaniak vers OVH et je voudrais vos conseils sur la meilleure manière de le faire, afin de minimiser le temps durant lequel les sites seront indisponibles.
Je pensais faire ceci:
- Upload du FTP sur le nouveau serveur
- Interruption du site 1 durant le transfert de la base de données (ou alors le laisser tourner, mais ce qui se sera passé durant ce temps ne sera pas conservé, ce qui risque d'amener pas mal de questions)
- Faire une redirection temporaire du site 1 avec nom de domaine vers site 2 sans nom de domaine avec un htaccess
- Transférer nom domaine de site 1 vers site 2
Dans cette idée, durant le transfert de domaine il y aura redirection vers site 2 et tout sera Ok un e fois celui-ci terminé.
Qu'en pensez-vous?
Merci
- shrom
- WRInaute impliqué

- Messages: 865
- Inscription: 5 Juil 2004
C'est à peu près la méthode que j'utilise quand je dois transférer des sites.
Sauf que je ne fais pas de redirection entre le site 1 et le site 2 et j''empêche les modif de la bdd sur site 1.
Comme ça, tout est transparent surtout pour Google.
Sauf que je ne fais pas de redirection entre le site 1 et le site 2 et j''empêche les modif de la bdd sur site 1.
Comme ça, tout est transparent surtout pour Google.
-

Digit - WRInaute impliqué

- Messages: 613
- Inscription: 18 Avr 2003
Je viens de migrer un site, voici comment j'ai procédé :
- prétests techniques (bascule à blanc) afin de s'assurer de la compatibilité du code
- prévenir les utilisateurs qu'une opération sera menée et que le site restera actif en lecture seule.
- choix de la date la moins fréquentée, début des opération sà minuit (période de quelques heures les moins fréquentées)
- copie des éléments statiques vers le nouvel hébergeur (plusieurs centaines de Mo d'images, pages php etc.)
- restauration base de données sur nouvel hébergeur et inactivation des modifs sur l'ancien hébergeur (message d'info)
- synchronisation du delta entre les deux sites
- configuration du domaine : nouveaux DNS. A partir de ce moment les visiteurs peuvent venir
- maintien de l'ancien hébergement pendant une semaine car même si sous 24/48h les utilisateurs ne visitent plus l'ancien, de nombreux bots (dont google) continuent.
- drop de l'ancien hébergeur
=> Pas d'impact moteurs de recherche et impact très faible sur les visiteurs.
- prétests techniques (bascule à blanc) afin de s'assurer de la compatibilité du code
- prévenir les utilisateurs qu'une opération sera menée et que le site restera actif en lecture seule.
- choix de la date la moins fréquentée, début des opération sà minuit (période de quelques heures les moins fréquentées)
- copie des éléments statiques vers le nouvel hébergeur (plusieurs centaines de Mo d'images, pages php etc.)
- restauration base de données sur nouvel hébergeur et inactivation des modifs sur l'ancien hébergeur (message d'info)
- synchronisation du delta entre les deux sites
- configuration du domaine : nouveaux DNS. A partir de ce moment les visiteurs peuvent venir
- maintien de l'ancien hébergement pendant une semaine car même si sous 24/48h les utilisateurs ne visitent plus l'ancien, de nombreux bots (dont google) continuent.
- drop de l'ancien hébergeur
=> Pas d'impact moteurs de recherche et impact très faible sur les visiteurs.
-

Dr DLP - WRInaute impliqué

- Messages: 673
- Inscription: 28 Juin 2003
Audrey : je trouve aussi ^^
Digit: ça me semble une solution intéressante, mais les 24/48h de coupure, ça me parait beaucoup... Le côté intéressant c'est que tout ce qui se passera sur le site durant cette période ne sera pas répercuté sur le nouveau, peut être l'occasion de pourrir davantage le forums ^^^
Euh... Je pense à un truc, pourquoi pas une connexion mysql distante durant la propagation des DNS?
Il faut que je teste ça!
Digit: ça me semble une solution intéressante, mais les 24/48h de coupure, ça me parait beaucoup... Le côté intéressant c'est que tout ce qui se passera sur le site durant cette période ne sera pas répercuté sur le nouveau, peut être l'occasion de pourrir davantage le forums ^^^
Euh... Je pense à un truc, pourquoi pas une connexion mysql distante durant la propagation des DNS?
Il faut que je teste ça!
- [--Eric--]
- WRInaute occasionnel

- Messages: 415
- Inscription: 6 Jan 2004
Hello,
Moi aussi justement je vais transferer un site d'infomaniak vers un dédié chez Sivit et je m'appretais à poser la question...
L'idée de la connexion mysql distante me parait pas mal du tout, je n'y avais pas pensé !
Migrant sur un dédié je dois pouvoir l'autoriser et là ça ne demande une fermeture des pages dynamiques que le temps du dump mysql.
Au départ je pensais fermer carrément le site 1 avec une redirection sur une page unique indiquant que le site est en cours de migration. J'imagine que pour les bots c'est très mauvais non ?
@+
Moi aussi justement je vais transferer un site d'infomaniak vers un dédié chez Sivit et je m'appretais à poser la question...
L'idée de la connexion mysql distante me parait pas mal du tout, je n'y avais pas pensé !
Migrant sur un dédié je dois pouvoir l'autoriser et là ça ne demande une fermeture des pages dynamiques que le temps du dump mysql.
Au départ je pensais fermer carrément le site 1 avec une redirection sur une page unique indiquant que le site est en cours de migration. J'imagine que pour les bots c'est très mauvais non ?
@+
-

Dr DLP - WRInaute impliqué

- Messages: 673
- Inscription: 28 Juin 2003
J'ai testé pour le site de mon profil, le passage a été fait de manière complètement invisible
J'ai mis une différence sur l'index pour savoir sur quel hébergeur j'étais, et je viens de me rendre compte qu'il était passé sur OVH.
Génial ces connexions distantes! Il faut juste éviter de se faire piquer ses identifiants....
J'ai mis une différence sur l'index pour savoir sur quel hébergeur j'étais, et je viens de me rendre compte qu'il était passé sur OVH.
Génial ces connexions distantes! Il faut juste éviter de se faire piquer ses identifiants....
-

e-kiwi - Modérateur

- Messages: 15617
- Inscription: 23 Déc 2003
il suffit tout simplement de bloquer le smodifications de BDD entre la demande de changement de DNS et la fin de la propatagion
tu achete ton nouvel hebergement. qd t as les codes FTP et BDD, tu envoit le site en ligne avec la BDD, tu bloque les modifications de BDD, tu changes les DNS, et qd elles sont propagées, tu re-autorise la modification de données BDD. ton site sera indisponible 0 seconde. apres tout un site peut rester 2 jours sans modification BDD, les données seront consultables de toute facon
tu achete ton nouvel hebergement. qd t as les codes FTP et BDD, tu envoit le site en ligne avec la BDD, tu bloque les modifications de BDD, tu changes les DNS, et qd elles sont propagées, tu re-autorise la modification de données BDD. ton site sera indisponible 0 seconde. apres tout un site peut rester 2 jours sans modification BDD, les données seront consultables de toute facon
- [--Eric--]
- WRInaute occasionnel

- Messages: 415
- Inscription: 6 Jan 2004
Que veux-tu dire par modifications de BDD ? Si tu entends bloquer l'écriture sur les tables ça va être gênant pour un forum
Non je vais simplement créer un utilisateur mysql qui n'aura la droit de se connecter que depuis l'IP du serveur actuel et el locahlhost. Même si quelqu'un pique les identifiants il ne pourra pas se connecter.
En tout cas merci Dr DLP, ton idée est super
Non je vais simplement créer un utilisateur mysql qui n'aura la droit de se connecter que depuis l'IP du serveur actuel et el locahlhost. Même si quelqu'un pique les identifiants il ne pourra pas se connecter.
En tout cas merci Dr DLP, ton idée est super
10 messages
• Page 1 sur 1
Formation recommandée sur ce thème :
Formation Google Analytics : en 2 jours, apprenez comment exploiter l'essentiel des possibilités de l'outil de mesure d'audience de Google. Formation animée par les experts Google Analytics de Ranking Metrics.
Tous les détails sur le site Ranking Metrics : programme, prix, dates et lieux, inscription en ligne.
Lectures recommandées sur ce thème :
- Changement hebergeur
- [Changement]hébergeur
- changement site et hébergeur
- Changement de domaine et hebergeur
- changement hebergeur et dns
- changement hebergeur serveur perso
- Changement d' hebergeur, pièges à éviter ?
- Changement de serveur de mon hébergeur
- changement hebergeur et nom de domaine
- Changement hébergeur site e-commerce : méthodologie ?
Consultez la description détaillée des produits ou services de Google suivants : JotSpot
- Analyse de la classe C (adresse IP)
Cet outil vous permet de vérifier si plusieurs sites sont hébergés sur la même classe C (adresse IP du serveur).
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 2 invités

