Bonjour,
Voilà, j'ai une appli web sur un serveur avec un BD et j'ai une instance secours de cette appli web sur un autre serveur (bien loin). Je voudrais que chaque soir, la BD du serveur main soit sauvegardée et transmise puis importée sur le serveur backup (chez 1&1)
Pour ça, j'ai développé un script php exécuté chaque soir sur le serveur main via le cron qui fait la sauvegarde (contenu sql zippé) puis appel l'url du script n°2 situé sur le serveur backup, lui aussi écrit en PHP. Ce 2ème script se connecte en FTP sur le serveur main, télécharge le fichier zip de la sauvegarde du jour, décompresse le fichier zip puis exécuter via system() la ligne de commande permettant d'importer dans Mysql le fichier.
 
Si le script 1, ça va, le n°2, j'ai 2 pb depuis quelques temps :
1) bizarrement, il n'arrive pas toujours à télécharger le fichier comme s'il ne le trouvait pas alors qu'il existe bien, à l'endroit indiqué En lançant 2-3 fois le script à la suite, ça finit par passer.
 
2) le temps d'import est trop long et je me prends un timeout de PHP Pourtant, le fichier sql, dézippé, fait 50 à 60 Mo, environ 170000 lignes.
Le même fichier, importé via l'IHM phpMyAdmin de 1&1 prend 7 min
 
Auriez-vous une solution, svp ?
 
Merci.
 

Découper ta base de donnée pour faire plusieurs petit fichier, je ne vois pas comment faire autrement car tu n'auras pas la main pour augmenter l’exécution time chez 1&1...
 
Mais ça va sacrément compliquer ta moulinette de transfert car in faudra vérifier que chaque étape ce fait sans erreur et sinon tout recommencer...
En écrivant des fichiers txt de chaque coté et en vérifiant leur état, plus un cron tous les  5 minutes pendant toute la nuit ça devrait le faire. ^^

Oserais-je faire part de ma déception face à cette proposition ?
J'avais effectivement pensé à ça, mais c'est pas du tout ce que j'espérais...
 
Bon, pour mon pb n°1, j'ai trouvé une solution : transfert en https. Actuellement, en compressé, ma BD fait 1 Mo et ça marche à chaque coup. Je pense pouvoir encore gagner en remplaçant le INSERT INTO fait pour chaque enregistrement de table et utiliser l'écriture raccourcie qui permet de faire un seul INSERT INTO pour pleins d'enregistrements. Au passage, y'a une limite du nb d'enregistrements qu'on peut mettre en un seul INSERT INTO ?
Je crois que phpMyAdmin fait des paquets de 50000 enregistrements max. Je pense que je vais faire ça aussi.
 
Pour le pb n° 2, je pensais découper mon dump SQL en autant de fichiers que j'ai de tables que je supprime quand l'import s'est bien fait. J'ai terminé l'import quand j'ai plus de fichiers SQL. Pour "prolonger le timeout" de PHP, si je fais un appel à l'url de mon script, est-ce que si le timeout du premier appel de mon script expire, l'exécution du 2ème appel se poursuit (bref, faire un chaînage du même script appelé en https) ?
 
Merci.

Un timeout c'est un process php (enfin je crois ^^), avec pour chacun sa mémoire, ses variables, etc.  
Donc non je ne penses pas que tu puisses chainer différent process sur un même job, par contre avoir une moulinette qui process table par table c'est bien (quand tes data sont homogène, sur un un forum phpbb j'avais la table post 10 fois plus grosses que toute les autre réunis donc juste celle sauver a part et je serais les fesses pour qu'elle continuer à bien vouloir dumper).
Suffit que ton process décompresse table.sql.zip, fasse une requete d'import et mette un flag à "c'est bon", et quand le process est relancé il importe toujours la première table qui a pas un flag positif (faut que y'ai des truncate ou create table bien sur ^^)...
 
C'est de la bricole mais vu les limitation de l’hébergement mutualisé impose, je ne vois pas vraiment d'autres solution...

J'ai voulu tester un autre truc : des exemples proposées sur la fonction exec avec une exécution en background: https://www.php.net/manual/fr/function.exec
Mais ça ne marche pas
Dans ma ligne de commande, j'ai fait :
$CmdLine = PHP_BINDIR."/php -q ".dirname(__FILE__)."/toto.php";
 
Mais toto.php n'est pas exécuté. Vu que j'ai pas forcément la sortie standard affichée, je fais créer un fichier à toto.php pour voir si ça marche. Je mets tous les chemins en absolu. mais non, ça marche pas et je ne comprends pas pourquoi
 
Là, je tente avec cURL avec un timeout à 1000s vu que je sais que via phpmyAdmin, le fichier se traite en 7 min. On va voir...
 
Edit : bon ben ça change rien, ce qui est logique vu que je vais dépendre du timeout de 1&1 Bizarrement, un phpinfo sur 1&1 montre un max_executoin_time de 50000   Mais c'est manifestement pas cette valeur qui est appliquée puisqu'elle doit tourner aux alentours de 60s.

Bon, ben, j'ai fait le découpage du fichier en plusieurs petits.
Vu que j'ai la main sur le serveur qui fait la sauvegarde, je pense mettre un max_execution_time assez long et lancer l'exécution x fois du script qui importe successivement les x fichiers sql.
 
Mais c'est pas propre et ça fait chier

J'ai essayé avec 2>&1 mais manifestement, y'a quand même un timeout car toute la BD n'est pas importée.
La sauvegarde et le transfert ne posent pas de souci, du coup, pas besoin de rsync.
 
Je voulais éviter de faire des scripts enregistrés dans le cron du serveur 1&1 car plus compliqué d'accès en ssh que par FTP... Mais bon, si ça peut simplifier, je vais voir.

C'est de la curiosité et j'imagine que si tu ne procèdes pas comme ça tu as de bonnes raison, mais pourquoi ne pas passer par les mécanismes de réplication classiques de ton SGBD ?

Je ne suis pas expert de ce genre de chose mais je doute que je puisse synchroniser via ce genre de mécanisme ma BD Mysql sur mon NAS avec celle située chez 1&1 en mutualisé
 
En cherchant sur le web, j'ai toujours trouvé la procédure classique de mysqldump d'un côté et mysql < dump.sql de l'autre. Rien vu d'autre. Ce qui variait après, c'était la façon d'envoyer le dump du serveur A au serveur B.
 
Je m'en suis finalement sorti avec 3 scripts PHP :
- sur le NAS, un script exécuté en ligne de commande via le cron (donc pas de pb de timeout d'exécution) qui appelle à la fin un script PHP situé sur le serveur 1&1 pour faire le transfert du dump en HTTPS
- sur 1&1, un script exécuté en ligne de commande via le cron un peu plus tard pour importer le fichier transféré.
 
Ca marche bien

J'imaginais que les deux pouvaient se parler, un VPN, quelque chose.
Parce que là ça marche mais il y a potentiellement un paquet de trucs qui peuvent mal se passer et pour lesquels une replication te sauverait la mise : crash X heures après le dernier backup (et donc X heures de data perdues), fail sur ton job ou pendant le transfert...
Sans parler de l'efficience du procédé où tu traites l'intégralité des données chaque jour, et pas le delta. Sur une faible volumétrie ça n'a pas beaucoup d'importance, je ne sais pas si c'est voué à changer dans ton cas.
 

La BD fait quelques Mo donc, c'est pas un souci. C'est une appli métier mais pour une asso, donc ça va.
Et je doute fort de pouvoir mettre en place un VPN sur un serveur 1&1 mutualisé
Mais merci pour la proposition.