Comment configurer MySQL 5.6 LONGBLOB pour les grandes données binaires

Avant de poser ma question un peu d'arrière-plan: je fais L'Exportation/Importation de données en utilisant le Workbench MySQL 6.1 D'une base de données MySQL 5.5 d'une machine à une 5.6 sur une autre. les deux machines sont ubuntu un 32 bits l'autre 64 bits.

Je vide les données sans problème, mais quand j'essaie de les charger, j'obtiens le:

Erreur 1118 (42000) à la ligne 1807: Taille de ligne trop grande (>8126). Changer certaines colonnes en texte ou BLOB ou utiliser ROW_FORMAT = DYNAMIC ou ROW_FORMAT = COMPRESSED peut aider. Dans format de ligne actuel, préfixe BLOB de 768 octets est stocké en ligne.

Voici le tableau de créer:

CREATE TABLE `file_content` (
  `fileid` bigint(20) NOT NULL,
  `content` LONGBLOB NOT NULL,
  PRIMARY KEY (`fileid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

J'ai les éléments suivants pertinents mon.paramètres cnf ...

Max_allowed_packet=1G
innodb_file_per_table=1
innodb_file_format = Barracuda

Je passe beaucoup de temps à googler pour essayer de comprendre quel est le problème. BTW si je supprime la clé primaire (pas de problème ici, mais une autre table qui a une clé étrangère dans cette table plaindre.

Par chance, j'ai l'accès ssh à la boîte afin que je puisse voir mysqldb réel.journal. pourquoi je trouve qu'il est vraiment intéressant ...

2014-08-12 20:42:12 25246 [erreur] InnoDB: la longueur totale des données blob (14179167) est supérieure à 10% de la taille du fichier journal redo (3072). Veuillez augmenter innodb_log_file_size.

Donc, augmenter la taille du fichier journal de refaire à la taille 10X LONGBLOB a résolu mon problème. Cependant, cela signifie-t-il que pour insérer un LONGBLOB 1G (c'est le maximum réel en raison de la taille du paquet) j'aurai besoin d'un innodb_log_file_size 10G.

Quelqu'un Peut-il expliquer comment "refaire la taille du journal d'erreur" se transforme en "ligne de la taille est trop grande (>8126)" erreur.

BTW Je n'ai aucun contrôle sur la structure de cette base de données donc pas "pourquoi stockez-vous de gros blobs dans la base de données".

TIA

33
demandé sur nstCactus 2014-08-13 07:13:38

1 réponses

La raison de ce problème est un changement dans MySQL 5.6.20, comme on pouvait lire dans le journal des modifications:

À la suite de la limite d'écriture du BLOB redo log introduite pour MySQL 5.6, le paramètre innodb_log_file_size devrait être 10 fois plus grand que la plus grande taille de données BLOB trouvée dans les lignes de vos tables plus la longueur des autres champs de longueur variable (VARCHAR, VARBINARY et champs de type texte). Aucune action n'est requise si votre paramètre innodb_log_file_size est déjà suffisamment grand ou vos tables ne contiennent pas de données BLOB.

Pour résoudre votre problème, vous devez augmenter la valeur de l'optioninnodb_log_file_size dans votre my.ini sous la section [mysqld]. Sa valeur par défaut est 48M. Réglage sur

[mysqld]
innodb_log_file_size=256M

Aidé dans mon cas.

, Être prudent lors de la modification de la valeur de innodb_log_file_size vous ce faire en toute sécurité:

  1. vous devez fermer le serveur proprement et normalement.
  2. éloignez-vous (ne pas supprimer) les fichiers journaux, qui sont nommés ib_logfile0, ib_logfile1, et ainsi de suite.
  3. vérifiez le journal des erreurs pour vous assurer qu'il n'y avait pas problème la fermeture.
  4. redémarrez ensuite le serveur et regardez le journal des erreurs sortie soigneusement. Vous devriez voir InnoDB imprimer des messages disant que le les fichiers journaux n'existent pas. Il va créer de nouveaux et ensuite commencer.
  5. à cette point vous pouvez vérifier que InnoDB fonctionne, puis vous pouvez supprimer le les anciens fichiers journaux.
64
répondu naitsirch 2016-09-05 07:38:21