mysqldump n'exporte pas toutes les lignes ou mysql n'importe pas
J'ai une table qui contient près de 4 millions de lignes. Je l'ai exporté avec mysqldump et l'ai transféré via scp vers un autre serveur et l'ai importé avec la commande mysql mais il manque maintenant plusieurs centaines de milliers de lignes. J'ai répété ce processus plusieurs fois et à chaque fois, il manque une quantité différente de lignes.
J'ai essayé mysqldump --compatible=ansi car lors d'une exportation, il y a eu une erreur dans la syntaxe pour une raison quelconque. Cette décharge a fini par avoir le plus de lignes à l'importation, mais il en manque encore des centaines de milliers.
Edit: J'ai essayé l'option -f mais elle affiche toujours une erreur mysql avant de revenir à l'invite de commande:
ERROR 1064 (42000) at line 41458: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '286,'54.227.215.70','http://example.com/'),(81547367,'CbLc4lXH',1501560286,'54.7' at line 1
Je ne sais pas s'il s'est arrêté en raison de l'erreur ou non, mais je sais qu'il me manque environ un million d'enregistrements après l'importation. Le fichier a une taille de 40 Go et je n'ai plus accès au serveur mysql précédent pour effectuer une autre exportation. J'ai toutes les données dont j'ai besoin. Je ne peux tout simplement pas l'importer.
Parfois, cela peut se produire en raison d'une combinaison d'une certaine séquence de caractères et du jeu de caractères du client MySQL au moment de l'importation.
Vous auriez pu intercepter ces erreurs sans outils supplémentaires en procédant comme suit
mysql -u dbuser -p -f -D thedb < importfile.sql 2>errors_encountered.txt
Cela aurait enregistré vos problèmes dans errors_encountered.txt
Qu'est-ce qui aurait pu être fait avec mysqldump pour commencer ???
SIMPLIFIER LE CONTENU DE L'EXPORTATION
Vous auriez pu utiliser les options - - hex-blob pour convertir les caractères en une représentation hexadécimale. Cela aurait pu atténuer les interprétations erronées ou les malentendus du jeu de caractères de la part du programme client MySQL.
DUMP ONE ROW AT UNE FOIS
Même lorsque vous utilisez - force pour le client MySQL, cela peut toujours entraîner l'insertion de centaines ou de milliers de lignes. Pourquoi ?
Par défaut, mysqldump a - opt activé. Cela définit les éléments suivants
--opt Same as --add-drop-table, --add-locks, --create-options,
--quick, --extended-insert, --lock-tables, --set-charset,
and --disable-keys. Enabled by default, disable with
--skip-opt.
Notez que l'une des options est - extended-insert . Cela oblige mysqldump à mettre en place des insertions en morceaux de centaines ou de milliers de lignes à la fois.
Si une seule ligne d'un bloc de lignes a rencontré un problème lors de l'importation et que vous utilisez - force , le bloc de lignes entier n'est pas inséré.
Comment mettre la main sur toutes les bonnes parties d'un morceau. Pour un mysqldump créé avec - extended-insert , il n'y a pas de moyen simple. Que pouvez-vous faire lorsque cela se produit? J'ai de bonnes et de mauvaises nouvelles.
BONNES NOUVELLES : Vous devez lancer un nouveau mysqldump avec --skip-extended-insert. Cela force un mysqldump à créer un INSERT pour chaque ligne. De cette façon, lors de l'utilisation de - force lors de l'importation, un INSERT invalide dû à chaque fois que les circonstances n'affecteront pas les lignes environnantes.
MAUVAISES NOUVELLES # 1 : Cela rend le fichier mysqldump résultant beaucoup plus volumineux.
MAUVAISES NOUVELLES # 2 : L'importation du fichier mysqldump résultant prend beaucoup, beaucoup plus de temps.
C'est quelque chose que j'ai recommandé Aug 09, 2013 ( la sauvegarde/exportation des données de la table des pièces jointes MySQL 5.5 échoue! )
SUGGESTION
Pour annuler le problème de taille que cela crée, vous pouvez procéder comme suit
gzip le mysqldump en faisant mysqldump
Nohup mysqldump ... | gzip > importfile.sql.gz &
décompressez le mysqldump et redirigez-le vers mysql pour l'importation
gzip -d < importfile.sql.gz | mysql -u dbuser -p -f -D thedb
ESSAIE !!!
Je pense avoir rencontré ce problème aujourd'hui. Je vidais une table entière et la réimportais sur un autre serveur. La table sur le nouveau serveur avait moins de lignes que l'original et au moins 1 valeur entière est passée de 1 à 0.
Très curieux en effet!
En utilisant --skip-extended-insert comme suggéré dans l'autre réponse corrigé cela, mais rend l'importation extrêmement lente.
J'ai fini par utiliser --net_buffer_length=16384 ce qui raccourcit les inserts. J'ai choisi 16384 car il s'agit de la valeur par défaut pour MySQL et cela rend les insertions beaucoup plus courtes que je ne les avais à l'origine.
Donc un très gros avertissement à tous: NE PAS UTILISER --net_buffer_length=16384 PEUT BRISER VOS SAUVEGARDES ET DONNÉES CORROMPUES!
En fait, les sauvegardes elles-mêmes sont OK. Le problème est créé lors de la restauration du vidage, mais vous n'avez peut-être pas le choix lorsque votre serveur tombe en panne et vous ne pouvez restaurer qu'à partir d'un mauvais fichier, ou amusez-vous à diviser les instructions SQL d'insertion en petits morceaux à la main :(