Bonjour à toutes et à tous,
- Nom de domaine : tracesmusicales.fr
- Hébergement mutualisé OVHcloud
Je rencontre la problématique suivante :
Après plusieurs années d'hébergement sans problème, la restauration de ma BD WordPress du 23 août a déclenché l'erreur suivante :
"Suite au retour des administrateurs, voici l'erreur retournée lors de la restauration :
Call failed with: [Errno 1] b"ERROR 1118 (42000) at line 452 in file: '/var/lib/mysql/import-mysql137-tracesmuwxjazzy-202308302004/tracesmuwxjazzy-202308302004': Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline."
Afin de corriger cela, vous devez vérifier votre base de données et voir comment elle est gérée avec MySQL."
Comme j'ai trouvé que ce type de problème peut se manifester sur les versions de MySQL postérieures à 5.5, comme expliqué dans ce lien :
https://stackoverflow.com/questions/25163614/error-1118-42000-row-size-too-large
je me demande si MySQL v.5.7 ne serait pas à l'origine du problème.
Donc si quelqu'un pouvait m'aider à réparer cela, je lui en serais reconnaissant.
Pour moi, le plus simple serait de vider la BD et de la restaurer.
Merci d'avance,
Bonjour @GuyR
Restauration faite depuis le manager OVH avec les sauvegardes journalières de OVH de votre base de données ?
Bonjour Gaston_Phone,
Merci de votre réponse.
Oui, je fais référence à la restauration des sauvegardes journalières de OVH de ma BD. J'ai tenté aussi d'importer une sauvegarde du 10 août 2023 que j'avais conservée sur mon Mac : même comportement.
D'accord, votre site était un site créé à partir d'un CMS ou un site fait par vous-même ?
C'est un site que je construis depuis plusieurs années avec WordPress, hébergé chez OVH depuis février 2016.
Votre WordPress est-il à jour ?
Quelle version de PHP avez-vous exactement ?
C'est un site que je construis depuis plusieurs années avec WordPress, hébergé chez OVH depuis février 2016.
Bonjour,
Avez-vous une idée de la table qui vous pose tant de problème ?
Un fichier export est une succession d'ordres SQL, plus ou moins lisibles à l'oeil avec notepad++, donc également modifiable ou pouvant être découpé en plusieurs fichiers plus petits.
Localisez les instructions CREATE TABLE et INSERT INTO
Certaines tables contiennent du code HTML et sont peu lisibles par un humain, et je ne serais pas surpris que ce soit justement dans une de celles-là.
Autre chose: votre site a-t-il été infecté/piraté ?
Oui, la version WordPress est à jour, et je suis sous PHP 7.4
Bonjour,
Merci de votre réponse.
J'ai ouvert la BD avec TextEdit, et j'ai localisé CREATE TABLE et INSERT INTO.
J'ignore si mon site a été piraté ou infecté, mais j'ai un doute, car la page d'accueil a affiché brièvement entre-temps une entête "Hacked By MR.GREEN", avec la mise en page de mon thème WordPress.
Hacked By MR.GREEN
Et c'est à cause de cela que vous souhaitez revenir en arrière ?
Vous devriez probablement retrouver ce texte "GREEN" soit dans le fichier export, soit quelque part dans un des fichiers php de votre site.
Récupérez-le en entier sur votre PC, et passez-le à l'antivirus.
Non, cela s'est produit après le pb de formatage de la BD.
Je vois effectivement GREEN plusieurs fois dans la BD, avec des infos inconnues, et même des traces de sites indésirables…
Mon site était protégé par WordFence et AntiMalWare.
Puis-je passer ma BD à l'antivirus ? Quel antivirus me recommandez-vous sur Mac ?
Bonjour,
Je reviens sur le pb de base (erreur du restore dump).
Dans votre fichier SQL, au niveau de la création des tables avez vous ? :
ROW_FORMAT=COMPACT
Si c'est le cas, alors vous pouvez tenter un changement de format pour :
ROW_FORMAT=DYNAMIC
Plus d'infos : https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/
Je vois effectivement GREEN plusieurs fois dans la BD
Si votre BD contient du code hostile, je ne connais rien qui puisse la décontaminer.
Evidemment je suppose que vous ne savez pas depuis quand vous êtes infecté, et je présume que vous n'avez aucune copie (saine) en votre possession en-dehors de OVH.
Vous devrez peut-être envisager de repartir sur une installation nouvelle, et vous pourrez aller repêcher dans les cendres de l'ancien site (wp-content/uploads par exemple) vis décorations, identités visuelles, etc.
Dans INSERT INTO xx_posts vous allez retrouver tous vos articles, autant de fois qu'il y a de révisions, vous pouvez tenter de sauver un fragment (sélectionner / copier / coller dans un nouveau fichier / donnez lui un nom.html / ouvrez-le dans votre navigateur.)
C'est laborieux, je n'ai aucune idée de la quantité d'articles et d'images que contient votre site infecté.
Merci, je ne vois aucune occurrence de ROW_FORMAT dans mon fichier SQL, voici la 1ère création de table :
–
– Table structure for table `wp_FinalTiles_gallery`
–
DROP TABLE IF EXISTS `wp_FinalTiles_gallery`;
/*!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8 /;
CREATE TABLE `wp_FinalTiles_gallery` (
`Id` int(11) NOT NULL AUTO_INCREMENT,
`configuration` varchar(5000) DEFAULT NULL,
UNIQUE KEY `id` (`Id`)
) ENGINE=InnoDB AUTO_INCREMENT=34 DEFAULT CHARSET=utf8;
/!40101 SET character_set_client = @saved_cs_client */;
Où faudrait-il insérer ROW_FORMAT=DYNAMIC ?
A la fin de la commande de création.
Exemple :
CREATE TABLE `ps_access` (
`id_profile` int(10) unsigned NOT NULL,
`id_authorization_role` int(10) unsigned NOT NULL,
PRIMARY KEY (`id_profile`,`id_authorization_role`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC;
Vous connaissez la version du serveur MySQL sur lequel vous êtes ?
serveur MySQL
5.7 MySql sur les mutualisés
J'ai inséré ROW_FORMAT=DYNAMIC dans les 73 commandes CREATE TABLE de ma BD, et j'attends l'annulation par le support OVH de la dernière tâche en erreur (import du fichier SQL) pour relancer l'import de cette BD.
Version MySQL v.5.7
J'ai inséré ROW_FORMAT=DYNAMIC dans les 73 commandes CREATE TABLE de ma BD, et j'attends l'annulation par le support OVH de la dernière tâche en erreur (import du fichier SQL) pour relancer l'import de cette BD.
Bonjour @GuyR
Pour la prochaine fois, pensez à sauvegarder régulièrement votre Hébergement et votre Base de données sur votre PC.
Voir dans mon guide le paragraphe :
**U - Sauvegarde complète de votre site sur votre PC**
https://www.wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm#_U_%E2%80%93_Sauvegarde
**__________________________________________________________________________________**
Voici un petit guide que j'ai écrit et qui pourrait vous apporter des éclaircissements pour **une Installation complète et propre de votre Site**.
**************************************************************************************************
* **Guide - Comprendre la Relation Domaine > Zone DNS > Hébergement > Dossier du site** *
**************************************************************************************************
Voir --> **https://wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm CMS - WordPress - Guide Installation chez OVH**
Contrôler votre situation en suivant **attentivement** les paragraphes : **A** à **J**
_N'hésitez pas à me faire un retour : positif ou négatif._
_C'est comme cela que je peaufine mon Guide._
_Si ce guide vous a bien aidé, n'hésitez pas à cliquer sur le bouton « j'aime »_
Merci @Fritz2cat
Si il n'y a pas de format spécifié je suppose que cela doit être celui par défaut. v5.7 est très récent le format par défaut devrait être DYNAMIC… Enfin, je suppose.
Merci pour votre guide qui représente une synthèse utile pour les non-spécialistes de BD…
Je tiens maintenant à valider mon site en local avant de le retransférer chez OVH, et j'ai tenté d'importer les tables de ma BD sauvegardée : je retombe sur le même problème, bien que j'aie inséré ROW_FORMAT=DYNAMIC dans toutes les tables.
Il semble que la table wp_bwg_theme pose problème, comme mentionné dans le message d'erreur qui suit :
CREATE TABLE `wp_bwg_theme` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
`thumb_margin` int(4) NOT NULL,
`thumb_padding` int(4) NOT NULL,
`thumb_border_radius` varchar(32) NOT NULL,
`thumb_border_width` int(4) NOT NULL,
`thumb_border_style` varchar(16) NOT NULL,
`thumb_border_color` varchar(8) NOT NULL,
`thumb_bg_color` varchar(8) NOT NULL,
`thumbs_bg_color` varchar(8) NOT NULL,
`thumb_bg_transparent` int(4) NOT NULL,
`thumb_box_shadow` varchar(32) NOT NULL,
`thumb_transparent` int(4) NOT NULL,
`thumb_align` varchar(8) NOT NULL,
`thumb_hover_effect` varchar(128) NOT NULL,
`thumb_hover_effect_value` varchar(128) NOT NULL,
`thumb_transition` tinyint(1) NOT NULL,
`thumb_title_font_color` varchar(8) NOT NULL,
`thumb_title_font_style` varchar(16) NOT NULL,
`thumb_title_pos` varchar(8) NOT NULL,
`thumb_title_font_size` int(4) NOT NULL,
`thumb_title_font_weight` varchar(8) NOT NULL,
`thumb_title_margin` varchar(32) NOT […]
MySQL a répondu : Documentation
#1118 - Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.