Transférer une base MySQL entre 2 serveurs chez OVH

[WebRankInfo]

je vais devoir bientôt changer de serveur chez OVH (encore...) et j'aimerais savoir si quelqu'un a déjà réussi facilement à transférer sa base de données ?
le pire étant bien entendu ce forum, qui représente (le fichier .sql de requêtes de création de tables et d'insertion de champs) pas moins de 50 Mo !
la dernière fois j'ai passé des heures à exécuter ces scripts par petits bouts dans phpMyAdmin, mais j'espère qu'il y a une autre solution ?

[melmoth]

je vais devoir bientôt changer de serveur chez OVH (encore...) et j'aimerais savoir si quelqu'un a déjà réussi facilement à transférer sa base de données ?
le pire étant bien entendu ce forum, qui représente (le fichier .sql de requêtes de création de tables et d'insertion de champs) pas moins de 50 Mo !
la dernière fois j'ai passé des heures à exécuter ces scripts par petits bouts dans phpMyAdmin, mais j'espère qu'il y a une autre solution ?

si tu as un shell sur la machine, mysqldump apres avoir fermé le forum pour etre sur que ca ne bouge pas le temps du dump.

Si tu es sur que ca sera la meme version de mysql de l'autre coté, un bete tarball du repertoire ou est stocké la base devrait aussi faire l'affaire (forum fermé pendant le tarball). Enfin, en théorie, je 'n'ai jamais dumpé de base comme ca par ce que...c'est mal (tm)

Si tu n'as pas de shell, je crois que le plus simple est de demander à ovh de te faire un petit backup, par ce que phpmyadmin c'est joli certes, mais c est pas pratique pour un sous pour des grosses requetes qui prennent du temps ou des mettent beaucoup de données en jeu.

Bref, bash+screen rulez

[Mitirapa]

lol je viens de faire ca justement ya meme pas une heure avec un .sql de 20mo...
et comme tu l'as dit, tu devras faire bout par bout.. à cause d'un tps d'envoit trop long vers le serveur puis un temps trop long interne au serveur sql je crois en plus...

bonne chance !

[WebRankInfo]

50 Mo j'en ai facile pour 3 heures !!!
c'est l'horreur !!!

[BDGest]

Moi j'avais eu le pb sur sivit avec un dump de 200Mo
J'avais en fait uploadé le fichier sur mon site et c'est eux qui avait fait le chargement dans la base (impossible via PhpMyAdmin). Peut être qu'ovh peut te faire la même chose ?

[WebRankInfo]

oui j'essaierai un truc comme ça. d'ailleurs en allant plus loin je ne vois pas pourquoi il faudrait que je download un dump pour l'uploader ensuite sur mon compte pour qu'ils le récupèrent !!! ils peuvent le faire directement sans doute ?
bonne nuit à tous

[Eservice]

Si tu n'as pas d'outil à disposition, pour gagner du temps tu crées tes tables sans index, tu les charges et tu ajoutes les index ensuite. Sur des gros volumes de données, ça vaut la peine.

[BDGest]

Tout a fait exact. Les index sont indispensable pour les requetes en SELECT par contre ils sont trés consommateurs de ressource pour les INSERT (recalcul de l'index a chaque fois). Vous imaginez que sur une table de plusieurs millions d'enregistrement ca peut trés vite rendre le chargement trés trés long.

Pour la copie, c'est clair que c'est bcq plus simple que ovh la fasse eux mêmes

[eric]

Bonsoir,

Voici ce que j'ai trouvé dans la FAQ d'OVH.
Pour ma part, je n'ai jamais eu de si grosses bases à transférer dans ces conditions...

Q: Comment puis je faire une sauvegarde de ma base de données ?
--------------------------------------------------------------------------------
R: Pour cela, exécuter la commande du type :

mysqldump --host=serveur_sql --user=nom_utilisateur_sql --password=mot_de_passe nom_de_la_base > mabase.sql (remplacez les parties en vert)

Cette commande génèrera un ficher mabase.sql dans le répertoire courant dans lequel vous trouverez toutes les instructions SQL pour recréer la base telle qu'elle est, avec ses données.
Vous pouvez ensuite compresser ce fichier pour mieux le télécharger sur votre ordinateur (par FTP ou par le web). Pour compresser le fichier, exécutez par exemple gzip mabase.sql (qui créera le fichier mabase.sql.gz).

Vous pouvez effectuer ces commandes en les incluant dans un script, par exemple, en PHP :
<?
exec("mysqldump -hsql -ulogin -pmot_de_passe nom_de_la_base > mabase.sql");
exec("gzip mabase.sql");
?>

ou, en perl :
system("mysqldump -hsql -ulogin -pmot_de_passe nom_de_la_base > mabase.sql");
system("gzip mabase.sql");


Plans concernés : mediaplan, 720plan, 240plan, 90plan, 240gp, 60gp, mailplan
Catégories : Bases de données MySQL

Q: Comment faire pour importer mes tables dans ma base ?
--------------------------------------------------------------------------------
R: Avant tout de chose il faut rajoute la ligne suivante en debut du fichier mabase.sql :

use nomdelabase;

Ensuite il faut créer le script PHP dont le code est ci-dessous :

<?php
system("cat mabase.sql | mysql --host=serveur_sql --user=nom_utilisateur_sql --password=mot_de_passe nom_de_la_base");
?>

Vous devez remplacer les écritures en vert par les codes d'accès à votre base de données.

Adresse de la FAQ :
http://www.ovh.com/fr/support/faq/speci ... categorie#

@ +

[Kmacleod]

Je vais surement dire une grosse bétise, mais bon en local ca marche :
pourquoi ne pas utiliser le ftp pour recuperer les fichiers physiques,et recréer les tables (sans les données) sur la machine cible, relivrer les fichiers ensuite par ftp.

[eric]

C'est impossible sur un hébergement mutualisé, on a pas d'accès FTP au serveur de la base de données.

@ +

[ortolojf]

Bon
Moi, pour faire des backups de ma Base de Données sur OVH, qui contient facile un certain nombre de méga-octets, j'ai fait des scripts de lecture des tables-transfert dans un fichier, avec l'instruction SQL suivante, que j'inclus dans un script PHP:

"SELECT * FROM nom_table INTO LOCAL OUTFILE 'pathname_file' ORDER BY 'critère-de-tri';"

Celà donne le fichier de nom-chemin 'pathname_file', contenant les enregistrements de la table 'nom_table'.

Evidemment, tu t'arranges pour que le fichier généré soit dans un directory accessible de ton serveur.

Ensuite, je découpe ce fichier généré en morceaux contenant un certain nombre de lignes pour chaques morceaux, de manière à ce que chaque fichier-morceau, soit de l'ordre de 2 méga-octets. Je nomme ces morceaux, dans l'ordre séquentiel:
fichier_1.txt, fichier_2.txt, fichier_3.txt, etc.... jusqu'à être arrivé au bout de tout le fichier généré. Ce traitement de découpage en local sur mon ordintaeur après avoir téléchargé le fichier généré, évidemment.

Ensuite, tu télécharge tous ces fichiers 'fichier_1.txt', 'fichier_2.txt', etc... sur ton serveur.

Et puis, j'ai écrit de plus un script en PHP, qui va donner successivement à la variable $filename, les noms 'fichier_1.txt', 'fichier_2.txt', etc... en lançant à chaque itération, la commande SQL suivante:

"INSERT * FROM LOCAL INFILE '$filename' INTO 'nom_table';"

( Je crois que c'est la bonne instruction, il faudrait que tu vétifies dans le manuel de MySQL ).

A la fin de chaque itération, tu incrémente ton compteur de fichier, tu vérifie si le nouveau fichier existe, s'il existe, tu relance le même script avec une instruction PHP de rédirection genre 'Header', s'il n'existe pas le traitement est terminé.

Tu fais tout celà pour chacune des tables de ta Base de Données, et tu termine par l'installation de ton site sur le nouveau serveur, car évidemment il ne faudrait pas que des visiteurs aient accès à des résultats incohérents avant que la BDD ne soit entièrement chargée.

Bien à toi.

Jean Francois Ortolo

[annuat]

salut à tous ,

au risque de dire une bétise :

WRI>>ca marche pas avec PHPMYADMIN ??
pour moi oui mais avec des bases <150 Ko pour une base de plusieurs MO je sais pas. Qui a deja fait le test ?

car c vite fait de faire une sauvegarde avec ce produit (- 30 secondes)

a+nico

[WebRankInfo]

mon pb n'est pas la sauvegarde mais la restauration sur un nouveau compte.
et là ça prend des heures dans phpMyAdmin, je l'ai testé !

[annuat]

wri>>j'avais compris ton pb

là ça prend des heures dans phpMyAdmin, je l'ai testé !

c quoi qui prend des heures??

j'ai testé la migration d'une base, ca ma pris 5 minutes...(sur une base de 150Ko)

a+nico