Bonsoir,
 
Je travaille actuellement sur une migration de base de données de type "uzine à gaz".
Migration de 74 tables vers une nouvelle base de données.
Le problème réside sur le fait qu'il y a une quantité assez importante à migrer et le script que je suis en train de concevoir ne peut pas supporter toute la charge que je lui est donné.
A titre d'exemple, une table qui contient 1800 enregistrement met environ 70 secondes à s'executer. Et les 73 autres tables contiennent plus ou moins la même quantité d'information.
 
PS : J'utilise 2 fichiers (un fichier php pour appeller chaques fonctions et afficher leur "etat" et un fichier pour les différentes fonctions. Chacune d'elle représente une table à migrer).
 
J'ai essayer par mal de chose :
- un "set_time_limit(300);"
- un "set_time_limit(300);" dans une boucle
...
 
Lors de l'execution de mon script, je suis obliger de limiter le nombre de table à migrer mais même cela, le navigateur ne recoit pas la page html pour dire que la migration s'est bien déroulé ou pas.
Je ne peux pas non plus faire table par table cela va à l'encontre de l'automatisation...
 
Que me conseillez-vous pour optimiser le code ?
Connaissez-vous des scripts qui ressemble plus ou moins à ce que je veux faire ?
Flush() est-il utile pour mon cas ?
Comment faire pour que le serveur m'envoie régulièrement "un état d'avancement" ?
 
Merci pour votre aide si bien sur vous souhaitez m'aider

Tes tables elles font quel poid? moi je trouve ça trés long 70s pour 1800 enregistrements s'ils ne sont pas énorme.
Pour le fait que le navigateur ne recoit pas la page, c'est normal : un navigateur n'attend une page que pendant un temps déterminé avant de considéré que le serveur est innaccéssible. A ma conaissance aucun navigateur récent n'attendra pendant 5 minutes d'affilé sans rien recevoir.
Le Flush poura servir à envoyer un etat d'avancement au navigateur. Celà dit, le navigateur attendra d'avoir reçu sufisament de texte (dans la limite d'un temps donnée) avant de t'afficher l'avancement.
 
Si ton systéme est vraiment trop trop long, alors tu devras faire table par table, mais tu n'es pas obligé de demander au client de cliquer à chaque fois dans son navigateur pour lancer l'exportation suivante : un navigateur est capable d'appeller une autre page quand le serveur lui dit d'aller voir ailleur. Utilise donc les redirections pour que le navigateur appelle succéssivement les pages servant à exporter toutes les tables.
 
Une autre solution mais qui ne marche que si tu as accés au serveur consiste à lancer des programmes de gestion de base de donnée tels que ceux fournis avec mysql et de leurs faire faire l'exportation comme il faut : ca ira surement plus vite qu'une page php contenant des boucles et tu n'auras plus de probléme de timeout. Sinon, essaye de voir si ton hébergeur ne propose pas ce genre de service : ca sert à rien de se prendre la tête si c'est déjà en place.

moi, je trouve ça aussi très long. Pour une table de 11000 enregistrements, ça me prend 10s environ sous mysql 3

+1 pour le très (trop) long!!!
tu pourrais montrer de script? Surtout les requetes d'alimentation en fait...

Oui c'est bien ce que je pensais (lol).
Heuresement que j'ai pas précisé que c'était en local ! (Pour l'instant, juste le temps du développement).
 
omega2 > "Si ton systéme est vraiment trop trop long, alors tu devras faire table par table, mais tu n'es pas obligé de demander au client de cliquer à chaque fois dans son navigateur pour lancer l'exportation suivante : un navigateur est capable d'appeller une autre page quand le serveur lui dit d'aller voir ailleur. Utilise donc les redirections pour que le navigateur appelle succéssivement les pages servant à exporter toutes les tables."
=> Oui, c'est ce que j'ai finalement fait mais encore ce problème de temps d'execution beaucoup trop long pour les tables qui on plus de 10 000 enregistrements.
 
Voici un exemple de ce que j'utilise pour réaliser l'exportation entre 2 bases MySQL :
 
transfere_db.php

 
maj_tables.php

 
PS : Pour un soucis de clareté, je n'est pas inclus les autres fonctions et j'ai présenté la migration d'une seule table. ^^

Plus fondamentalement : est-ce bien raisonable de faire ce genre de migration avec PHP server-side?
 
C'est pour un hébergement mutualisé?

non Intranet.
Je me suis posé la même question, mais on m'a imposé le langage :s
Je suis actuellement en train de voir pour migrer les plus grosses bases de données à l'aide de C#.
 
Donc d'après vous, il n'est pas possible de réaliser la migration avec PHP pour ce cas la ?

D'accord,

pas besoin de chercher plus loin, une requette par ligne à insérer avec mysql, c'est normal que ca rame. Fait plustôt des requettes d'insertion correspondant à un lot de 10, 20 ou 50 lignes à insérer. Tu véras que ca ira beaucoup plus vite.
 
EDIT : PS : Fait attention aux hébergeurs, de nombreux hébergeurs bloquent les accés distant à la base SQL ce qui empécherait ton script de bosser comme il faut.

+1 sur la cause mais pas d'accord sur la solution qui n'est pas beaucoup mieux.

Mysql te propose un truc assez pratique c'est SELECT ... INTO FILE et LOAD DATA FILE. Du coup pour dumper ta table tu fais:

et pour la upper

anapajari > Pour ça, il faut que le serveur mysql soit sur la même machine que le serveur php ce qui est rarement le cas en dehors des hébergements dédiés.
Certe en local ca marcherait mais une fois en production, il y a peu de chance qu'il puisse utiliser cette méthode.
 
Cette méthode à en plus un défaut méconu avec mysql : mysql remplis la table sans mettre à jour les index puis exécute les fonctions de réparation de table pour que les index soient à jour. Pour de trés grosses tables, (plusieurs disaines ou centaines de millions de lignes par exemple) ca peut se réveller plus lent que des insertions classiques. Je sais, on est trés loin de ce volume de données dans le cas présent.

Euh non      
tu fais

• un script de dump + sauvegarde des fichiers sur le serveur 1
• un script d'upload fichier + load data sur le serveur 2

not quite true.
La "non mise à jour" des index n'est effectué que si l'opération a lieu dans une table vide, d'ailleurs dans la doc te donne la procédure pour toujours émuler ce comportement à toi de choisir ou non quel cas te convient le mieux.
Mais juste pour quoter cette page:

Et pour moi, dans ce cas précis on est exactement dans le "usually" ( comme tu l'indique également dans ton message )

Merci beaucoup pour vos réponses, elle me sont précieuses !
Je vais tester toutes les solutions afin de trouver celle qui correspond au besoin de mon cas.