Bonjour à tous,
J'ai pris un serveur SQL de 16 Go de capacité pour un gros projet (10-12 Go) et comme c'est plutot pas mal de faire des tests de sauvegarde / restauration au cas où, voici où j'en suis :
Via le manager :
- Sauvegarde => ok
- Restauration => ko (le support dit que le time out est à 3600 s et qu'il faut que je découpe)
J'ai essayé de réimporter avec le script php BigDump http://www.ozerov.de/bigdump/
Il faut paramétrer très peu de lignes à la fois car elle sont très longues => ok pour le début de l'import mais après ca m'a peté à la geule et j'ai laissé tomber.
Via le shell
- Sauvegarde table par table en découpant chacune en petits fichiers de 60 Mo => ok
- Restauration de chaque fichier via cat | mysql dans une boucle => ko au bout de 30 fichiers (ERROR 2006 (HY000) at line 37: MySQL server has gone away)
Il y a eu des redémarrages serveur sur la période, je ne comprend pas comment est gérée la RAM, elle ne redescend pas lorsque j'enchaine plusieurs opérations disctinctes.
C'est le même problème que j'ai eu pour charger initialement les données en base :
Si j'enchaine des requêtes LOAD DATA LOCAL INFILE sur des fichiers de 100 000 lignes chacuns avec fermeture de la connexion entre chaque => redémarrage du serveur tous les 7 / 8 fichiers.
Le support me dit que ce sera mieux en php via un cron mais je ne vois pas pourquoi ca changerait…
Bref, avez vous des idées ? Car une BDD de 16 Go sans pouvoir la sauvegarder / restaurer c'est un peu comme jouer à la roulette russe tous les jours…
Bonjour,
le problème dans ce genre de cas est que vous saturer la RAM et cela déclenche un reboot côté OVH avant de tomber en OOM complet.
Du coup dans votre cas il faut faire les imports par petit nombre et reboot l’instance manuellement pour vider la RAM de force puis recommencer.
C'est sûr c'est loin d'être la méthode optimal, mais il faut pas que regarder les 16Go de stockage, il y a aussi les 1Go de RAM a prendre en compte.
Cordialement, janus57
Le support me dit que ce sera mieux en php via un cron mais je ne vois pas pourquoi ca changerait...
Avec un script PHP --> **1https://wordetweb.com/word-et-web/OVH-Sauvegarder-Restaurer-une-base-de-donnees-via-un-script-FR.htmhttps://wordetweb.com/word-et-web/OVH-Sauvegarder-Restaurer-une-base-de-donnees-via-un-script-FR.htm OVH - Sauvegardes et Restaurations de Bases de Données via un script_**
Merci Janus57, c'est ce que je craignais.
Est ce que vous savez quels sont les mécanismes qui font que la RAM se vide naturellement ?
Bonjour,
De mémoire le temps et la non utilisation de la table.
Après éventuellement avant de passer par le rebooter peut être qu'un coup de "FLUSH TABLES;" avant qu'il reboot tout seule peu arranger les choses.
Cordialement, janus57
Merci pour la sugestion, voici le résultat du Flush tables :
ERROR 1227 (42000) at line 1: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation
Pour pouvoir le faire en automatique, il me reste comme solutions, le reboot via l'api ovh (je rêvais de m'y mettre…) ou la méthode bourrin de saturer le serveur avec des données qui ne servent qu'à ca et que j'efface ensuite.
Bonjour à tous,
J'ai donc mis en place un reboot du SQL privé après chaque morceau de sauvegarde restauré et ca a fonctionné quelques temps. Depuis hier la commande system(cat | mysql …) ne fonctionne plus et le reboot me renvoit l'erreur
> resulted in a `403 ActionImpossible` response:
> {"message":"You already have an action in progress"}
Et idem via le manager.
Vous avez une idée du problème ?
Bonjour,
Il y a visiblement une actio5en cours sur le SQLPrive du coup il faut attendre qu'elle soit marqué comme finit pour en relancer une.
Cordialement, janus57
Merci, ca j'avais compris 
et le manager marque toujours "redémarrage en cours".
Je vais attendre la réponse à mon ticket, les fois précédentes les opérations non terminées au bout de 12h avait du être débloquées par le support.
Bonjour,
Du coup pourquoi poster ici si vous connaissez la procédure car vous y avez déjà été confronté?
Cordialement, janus57
Bonjour Antoine,
Jai exactement le même problème.
Au final peux tu me dire si tu es parvenu à réaliser des restaurations par morceaux et si oui de quelle taille et comment ?
A chaque plantage, je dois appeler le support et l'attente est longue.
Merci d'avance
Bonjour,
C'est simple, j'ai mis de coté ce projet pour l'instant…
La taille des morceau n'avait pas d'impact car la ram n'est pas vidée entre chaque morceau donc ca saturait toujours au même endroit.
J'avais contourné en forcant un redémarrage serveur via l'api ovh entre chaque morceau.
Ca devenait trop du bricolage et surtout pas robuste dans le temps, je n'ai jamais réussi à faire une restauration entière via un script.