Bonjour à tous,
Ce message est pour aider d’autres personnes qui pourront rencontrer des problèmes identiques ou similaires de corruption de table. Je ne sais pas si c’est une « bonne méthode », mais dans mon cas, cela a fonctionné pour la table concernée.
Avertissement : cette méthode est risquée (à vos risques et périls), essayez de sauvegarder Jeedom, si cela ne fonctionne pas, d’exporter la base.
Il y a une perte de données, mais je pense que j’aurais quand même eu.
Pour l’historique :
Depuis le 30 décembre/1er janvier, j’avais régulièrement des erreurs de calcul de téléinfo.
Dans le log « téléinfo » :
Erreur sur teleinfo::calculateTodayStats() : [MySQL] Error code : 42S02 (1932). Table 'jeedom.historyArch' doesn't exist in engine : SELECT AVG(CAST(value AS DECIMAL(12,2))) as avg, MIN(CAST(value AS DECIMAL(12,2))) as min, MAX(CAST(value AS DECIMAL(12,2))) as max, SUM(CAST(value AS DECIMAL(12,2))) as sum, COUNT(CAST(value AS DECIMAL(12,2))) as count, STD(CAST(value AS DECIMAL(12,2))) as std, VARIANCE(CAST(value AS DECIMAL(12,2))) as variance FROM ( SELECT * FROM history WHERE cmd_id=:cmd_id AND `datetime`>=:startTime AND `datetime`=:startTime AND `datetime`
De plus, la sauvegarde de Jeedom ne se faisait plus.
Après investigation, la table « historyArch » était endommagée et mes tentatives de récupération n’ont pas fonctionné.
Depuis que j’avais installé ma clé zigbee (début décembre), j’avais régulièrement des problèmes avec mon RPI (le plugin Livebox m’indiquait que la communication ne fonctionnait pas vers elle, impossibilité d’accéder d’accéder à la page web de jeedom ou en ssh, ping KO). Je n’ai pas trouvé de relation entre l’ajout de périphérique et le comportement erratique de mon RaspberryPi et Jeedom.
Bref, le bazar total. Donc le seul moyen de récupérer l’accès = débrancher/rebrancher !
Entre-temps j’ai lancé des scans d’intégrité du SSD, tout à l’air bon.
Je ne souhaitais pas réinstaller Jeedom, car j’avais entre temps réalisé de petites modifications que je voulais garder.
Après ma petite histoire, voici comment j’ai procédé :
- j’ai récupéré sur mon ordinateur la base de données depuis une des archives de Jeedom (celle du 30 décembre, la dernière disponible)
- j’ai ouvert le fichier « DB_backup.sql » pour ne garder que ce qui concerne la création de la table « historyArch », ainsi que les données
- j’ai sauvegardé le fichier en « DB_backup_historyarch.sql »
- via une WinSCP, j’ai déposé le fichier « DB_backup_historyarch.sql » dans le répertoire « /home/jeedom/ »
- en SSH, j’ai tappé les commandes suivantes :
-
mysql -u jeedom -p (pour se connecter au serveur mysql, « jeedom » étant le nom d’utilisateur la base de donnée présente dans « Réglages → Système → Configuration → OS/DB »)
- <tappé le mot de passe de la base de donnée>
- use jeedom; (sélectionné la base « jeedom »)
- drop table historyArch; (pour supprimer la table)
- CTRL + C (sortir du serveur mysql en utilisant les raccourcis clavier)
-
mysql -u jeedom -p jeedom < /home/jeedom/DB_backup_historyarch.sql (pour recréer la table et restaurer les données)
-
<tappé le mot de passe de la base de donnée>
La restauration se fait alors, cela peut être très long en fonction de la quantité de données -
mysqlcheck -u jeedom -p --all-databases (pour vérifier toutes les bases de données)
-
<tappé le mot de passe de la base de donnée>
-
Restauration terminée.
J’aurais pu exporter la table « historyArch » avant la restauration, mais les précédentes tentatives se soldait par (fichier « /var/log/mysql/error.log ») : "
2022-01-05 22:24:48 10 [Note] InnoDB: Uncompressed page, stored checksum in field1 2979677095, calculated checksums for field1: crc32 3551396420, innodb 1418179208, page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 3551396420, innodb 2421700207, none 3735928559, page LSN 37 2584389858, low 4 bytes of LSN at page end 0, page number (if stored to page already) 23277, space id (if created with >= MySQL-4.1.1 and stored already) 747
2022-01-05 22:24:48 10 [Note] InnoDB: Page may be an index page where index id is 1243
2022-01-05 22:24:48 10 [Note] InnoDB: Index 1243 is `unique` in table `jeedom`.`historyArch`
2022-01-05 22:24:48 10 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2022-01-05 22:24:48 10 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace jeedom/historyArch page [page id: space=747, page number=23277]. You may have to recover from a backup.
2022-01-05 22:24:48 10 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex b19a43a700005aed00005aec00005aee000000259a0aa8e245bf0000000000000000000002eb00793af581e5000000003add0002000001e30000000000000000000000000000000004db0000000000000000000000000000000000000000010002001c696e66696d756d0008000b000073757072656d756d0200000010001f800001be99ab12fb700000000000008000000000000034350200000018001f800001be99ab12fbb30000000000008000000000000034350200000020001f800001be99ab12fbf50000000000008000000000000034350200040028001f800001be99ab12fc38000000000000800000000000003435020000 45 % 45 %V 45 % 45 % 45 & 45 &` 45 & 45 & 45 '( 45 'k 45 ' 45 ' 45 (2 45 (u 45 ( 45 ( ( 45 0 )A 45 8 ) 45 @ ) 45 H * 45 P *L 45 X * 45 ` * 45 h + 45 p +V 45 x + 45 + 45 , 45 ,a 45 , 45 , 45 -) 45 -k 45 - 45 - 45 .3 45 .v 45 . 45 . 45 0B 45 0 45 0 45 1 45 1L 45 1 45 1 45 2 45 ( 2W 45 0 2 45 8 2 45 @ 3 45 H 3a 45 P 3 45 X 3 45 ` ;
InnoDB: End of page dump
2022-01-05 22:24:49 10 [Note] InnoDB: Uncompressed page, stored checksum in field1 2979677095, calculated checksums for field1: crc32 3551396420, innodb 1418179208, page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 3551396420, innodb 2421700207, none 3735928559, page LSN 37 2584389858, low 4 bytes of LSN at page end 0, page number (if stored to page already) 23277, space id (if created with >= MySQL-4.1.1 and stored already) 747
2022-01-05 22:24:49 10 [Note] InnoDB: Page may be an index page where index id is 1243
2022-01-05 22:24:49 10 [Note] InnoDB: Index 1243 is `unique` in table `jeedom`.`historyArch`
2022-01-05 22:24:49 10 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
220105 22:24:49 [ERROR] mysqld got signal 11 ;"
J’avais également ces informations (fichier « /var/log/mysql/error.log ») :
2022-01-05 6:30:13 1731 [ERROR] InnoDB: Table `jeedom`.`historyArch` is corrupted. Please drop the table and recreate.
2022-01-05 6:30:13 1731 [ERROR] Got error 128 when reading table './jeedom/historyArch'
La restauration m’a permis de récupérer mon serveur Jeedom fonctionnel, avec une perte de données (car avant restauration, il semble que la table contenait plus de ligne, mais je les considérais comme perdus d’avance). Et je perdais mon temps (et soirées) pour tenter une réparation, au détriment de l’archivage de l’historique et la sauvegarde de Jeedom.
Bonne journée 
Ressources complémentaires :
- Message d'erreur jeedom history sur MAJ Jeedom - #10 par bobaxx
- Plantage jeedom a 1h31
- Besoin d'aide, problème backup de Jeedom après mauvaise manipulation
- MariaDB Basics
- How to import and export MySQL or MariaDB databases [Tutorial]
- How To Import and Export Databases in MySQL or MariaDB | DigitalOcean