Discussion :

[69Pierre]

Bonjour.
Je travaille avec easy php 13.1 (oui c'est pas la dernière) le logiciel est lancé sur une clé USB.
MYSQL 5.6.11
Pendant que je modifiais ma BDD, l'ordinateur n'a plus reconnu la clé et le serveur de BDD a planté.
Si j'essaie de le redémarrer, j'ai le message suivant :
"Unespected end of Mysql...See log Files ?"
Le log file, c'est :

2017-10-09 16:54:11 13240 [Note] Plugin 'FEDERATED' is disabled.
2017-10-09 16:54:11 2c10 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2017-10-09 16:54:11 13240 [Note] InnoDB: The InnoDB memory heap is disabled
2017-10-09 16:54:11 13240 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2017-10-09 16:54:11 13240 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-10-09 16:54:11 13240 [Note] InnoDB: Not using CPU crc32 instructions
2017-10-09 16:54:11 13240 [Note] InnoDB: Initializing buffer pool, size = 16.0M
2017-10-09 16:54:11 13240 [Note] InnoDB: Completed initialization of buffer pool
2017-10-09 16:54:11 13240 [Note] InnoDB: Highest supported file format is Barracuda.
2017-10-09 16:54:11 13240 [Note] InnoDB: The log sequence numbers 10698783 and 10698783 in ibdata files do not match the log sequence number 10698793 in the ib_logfiles!
2017-10-09 16:54:11 13240 [Note] InnoDB: Database was not shutdown normally!
2017-10-09 16:54:11 13240 [Note] InnoDB: Starting crash recovery.
2017-10-09 16:54:11 13240 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-10-09 16:54:11 13240 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: .\mysql\innodb_table_stats.ibd. Cannot open tablespace touslesport/multisports which uses space ID: 1 at filepath: .\touslesport\multisports.ibd
InnoDB: Error: could not open single-table tablespace file .\touslesport\multisports.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

Il y là une foule d'info (en anglais, donc que traduis mal).
Je travaillais sur une BDD qui s'appelle touslesport.V2 et pas touslesport.
Je travaillais sur une autre table que multisports.

Comment puis-je récupérer ma structure et mes données ?

Merci de votre aide.

[69Pierre]

Bonjour.
Je joue à l'apprenti sorcier...
J'ai réinstallé easy php ailleurs sur ma clé USB.
Il fonctionne maintenant, le serveur de BDD se lance.
J'ai copier le répertoire qui a le nom de ma BDD (avec les .frm, ibd et .opt qu'il contient) dans le répertoire EasyPHP-DevServer-13.1VC9\binaries\mysql\data
J'ai lancé le serveur de BDD.
Puis le batch suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SET JOUR=%date:~-10,2%
SET ANNEE=%date:~-4%
SET MOIS=%date:~-7,2%
SET HEURE=%time:~0,2%
SET MINUTE=%time:~3,2%
SET SECOND=%time:~-5,2%
 
if "%time:~0,1%"==" " SET HEURE=0%HEURE:~1,1%
 
SET REPERTOIR=E:\Projet20171008\DUMP
 
SET FICHIER=%REPERTOIR%\Sauvegarde_du_%JOUR%_%MOIS%_%ANNEE%_A_%HEURE%_%MINUTE%.sql
 
if not exist "%REPERTOIR%" md "%REPERTOIR%"
 
E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\mysql\bin\mysqldump -u root --opt E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\mysql\data\touslesport.V2 -h localhost >  %FICHIER%

Le fichier est bien créé mais vide.

La fenêtre DOS affiche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
C:\Windows\system32>E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\mysql\b
in\mysqldump -u root --opt E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\
mysql\data\touslesport.V2 -h localhost  1>E:\Projet20171008\DUMP\Sauvegarde_du_1
0_10_2017_A_14_57.sql
mysqldump: Got error: 1059: Identifier name 'e:\projet20171008\easyphp-devserver
-13.1vc9\binaries\mysql\data\touslesport.v2' is too long when selecting the data
base

La batch est dans E:\Projet20171008\BAT et l'exe mysqldump.exe dans E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\mysql\bin

Merci de me m'indiquer les erreurs que j'ai fait et/ou de m'indiquer comment m'y prendre.

[69Pierre]

L'erreur évolue mais toujours rien d'interessant dans mon Dump :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
-- MySQL dump 10.13  Distrib 5.6.11, for Win32 (x86)
--
-- Host: localhost    Database: touslesport.v2
-- ------------------------------------------------------
-- Server version	5.6.11-log
 
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

fenêtre DOS :

C:\Windows\system32>E:\Projet20171008\EasyPHP-DevServer-13.1VC9\binaries\mysql\b
in\mysqldump -u root --opt touslesport.v2 -h localhost 1>E:\Projet20171008\DUMP
\Sauvegarde_du_10_10_2017_A_16_15.sql
mysqldump: Got error: 1146: Table 'touslesport.v2.2017resultats' doesn't exist w
hen using LOCK TABLES

Il ne trouve pas de table, cela veut dire que mysql a des infos sur cette BDD en dehors du répertoire qui a le nom de la bdd et qui est dans EasyPHP-DevServer-13.1VC9\binaries\mysql\data mais où ?

[69Pierre]

Le problème vient visiblement du fichier ibdata1.
J'ai remplacé celui du easy php nouvellement installé et hop même erreur : "Unespected end of Mysql...See log Files ?"
Est t-il possible de corriger-shrinker(78M) ce fichier et comment ?

Bonjour.
Je travaille avec easy php 13.1 (oui c'est pas la dernière) le logiciel est lancé sur une clé USB.
MYSQL 5.6.11
Pendant que je modifiais ma BDD, l'ordinateur n'a plus reconnu la clé et le serveur de BDD a planté.
Si j'essaie de le redémarrer, j'ai le message suivant :
"Unespected end of Mysql...See log Files ?"
Le log file, c'est :
Il y là une foule d'info (en anglais, donc que traduis mal).
Je travaillais sur une BDD qui s'appelle touslesport.V2 et pas touslesport.
Je travaillais sur une autre table que multisports.

Comment puis-je récupérer ma structure et mes données ?

Merci de votre aide.

[SQLpro]

Apprenez qu'une base de données, c'est pas des petits bouts de fichiers qu'on colle au gré du vent dans un répertoire. Si c'était cela, alors de simple fichier texte aurait suffit !
Apprenez aussi que bricoler une base, sensé contenir des données généralement sensible, sur une clef USB, c'est aussi stupide que de faire Paris Marseille en vélo sur autoroute.

Bref, avant d'utiliser un outil on se renseigne, on apprend...

Et vous verrez que lorsque l'on fait n'importe quoi avec un outil qui doit être utilisé à bon escient cela ne peut que se traduire mal.

En conclusion il n'existe pas d'outil magique pour réparer les conséquences de l'utilisation parfaitement stupide que vous avez eut de MySQL !

C'est pour cela que personne ne vous a répondu dans ce forum.

A +

[69Pierre]

Bonjour.
J'espère que ça vous a fait du bien.

Apprenez qu'une base de données, c'est pas des petits bouts de fichiers qu'on colle au gré du vent dans un répertoire. Si c'était cela, alors de simple fichier texte aurait suffit !

J'ai bien compris, j'espérai juste aller un peu plus loin.

Apprenez aussi que bricoler une base, sensé contenir des données généralement sensible, sur une clef USB, c'est aussi stupide que de faire Paris Marseille en vélo sur autoroute.

Il n'y a aucune données sensibles dans ma base.
Pour Paris Marseille à vélo, je suis preneur.
Rassurez vous je ne prends jamais l’autoroute à vélo.

Bref, avant d'utiliser un outil on se renseigne, on apprend...

C'est ce que je fais.

Et vous verrez que lorsque l'on fait n'importe quoi avec un outil qui doit être utilisé à bon escient cela ne peut que se traduire mal.

???Ca doit sûrement vouloir dire quelque chose.

En conclusion il n'existe pas d'outil magique pour réparer les conséquences de l'utilisation parfaitement stupide que vous avez eut de MySQL !

Ca faisait partie de ma question, j'ai maintenant la réponse.
Merci.

C'est pour cela que personne ne vous a répondu dans ce forum.

A +

Il n'y a là aucun problème.

[CinePhil]

Avez-vous fait des sauvegardes, au moins avec la commande mysqldump ou un outil qui fait l'équivalent (exporter depuis phpMyAdmin par exemple) ?

Si oui :
1) Réinstallez un MySQL tout neuf ;
2) Rechargez votre sauvegarde.
3) Vérifiez que ça fonctionne.

Si non :
1) Pleurez !

[69Pierre]

Bonjour.

Non, je n'ai pas fait de Dump, sinon...
Mais je n'ai aucune raison de pleurer, il n'y a pas de données de valeur dans ce que je fais.
Je me demandais si le ibdata1 est réparable.
Si ce problème de taille du ibdata1 est gérable et comment.
Si, à partir d'une version ultérieure de innodb (de mysql) ce problème a été réglé.

Voilà ce que je cherche à savoir maintenant.

PS : pourquoi "au moins avec mysqldump", ce n'est pas recommandé ?

[CinePhil]

Non, je n'ai pas fait de Dump, sinon...

Dommage !
À prévoir d'urgence : un petit script pour automatiser la sauvegarde.

Mais je n'ai aucune raison de pleurer, il n'y a pas de données de valeur dans ce que je fais.

Donc vous pouvez recommencer votre BDD à zéro sans problème ? Ouf !

Je me demandais si le ibdata1 est réparable.

Généralement non.

Si ce problème de taille du ibdata1 est gérable et comment.

ibdata1 et les ib_logfile sont dépendants.
Recharger un ibdata1 tout seul ne fonctionne pas.
Recharger l'ensemble peut peut-être fonctionner s'il n'y a pas eu de transactions qui rend l'ensemble incohérent.

Si, à partir d'une version ultérieure de innodb (de mysql) ce problème a été réglé.

Quel problème ?
ibdata1 est le fichier qui contient les données des tables InnoDB.

PS : pourquoi "au moins avec mysqldump", ce n'est pas recommandé ?

Si, mysqldump peut convenir. En principe et si je comprends bien la doc, il peut sauvegarder la BDD en préservant la cohérence des données, même si des modifications de données interviennent durant la sauvegarde.

[69Pierre]

Merci CinePhil.

[Artemus24]

Salut à tous.

Je me demandais si le ibdata1 est réparable.

Que vous ayez eu un plantage (je parle de votre premier message), cela est réparable en faisant un "repair" sur toutes vos tables.
Et je dirais même que ce n'est pas bien grave. Cela m'arrive assez souvent.
Mais après ce premier plantage, vous venez bidouiller en créant un second plantage et là, on ne peut plus rien faire pour vous.

Pour répondre à votre question, non, on ne peut pas réparer le fichier "ibdata1" !
Alors que faire ? Tout simplement réinstaller une sauvegarde comme le conseil si judicieusement CinePhil.
Mais voilà, si vous n'avez pas fait de sauvegarde, on ne peut pas vous aider.

@+

[69Pierre]

Merci.
Je note le "repair".