mon souci depuis le début de semaine,
tous les jours j’ai des coupures dans mes enregistrements de capteurs,
par exemple, ce matin me me levant, j’ai vu que tous les graphiques étaient ‹ plats › depuis 5h25
un redémarrage de HA et c’est reparti !
j’ai ce problème depuis le passage a la 10.x
je voulais restaurer la sauvegarde de ma dernière core 9.7 mais quand je clique sur restaure, rien ne se passe
je ne peut pas plus passer a la 10.3 vu mon problème système non sure … le post d’hier
a savoir que je n’ai aucune erreur particulière dans les logs a l’heure de l’arrêt de l’enregistrement
et j’avais mis le module complémentaire MariaDB il y a plus d’un an mais sans jamais avoir eu d’erreur,
j’ai supprimé le module portainer qui semblait poser problème, redémarré l’hôte plusieurs fois …
bref, je ne sait pas trop quoi faire et ou regarder !
Sans log ça va être compliqué de chercher une piste, il y a forcement un truc (pas forcement au moment de l’arrêt).
Personnellement je soupçonnerai le backup …
le backup …?
pourquoi, tu a déjà eu des soucis avec ça ?
moi j’utilise le module ‹ Home Assistant Google Drive Backup ›
qui me crée les backups automatiques et les copie dans google drive
j’ai déjà eu il y a quelques mois une image core a restaurer et cela a bien fonctionné
mon dernier backup est d’hier à 10h49 et semble avoir une taille correcte mis a part le fait que si j’essaye de restaurer il ne se passe rien !
et pas non plus d’erreur dans le log …
Des soucis, je n’en ai pas (j’ai la même mécanique, mais je ne joue pas avec portainer…)… Pour moi ça ressemble à une tache planifiée, donc ma première idée c’est que le backup est coincé (plus de place en local, sur google…)
Il faut que tu cherches un peu partout sinon ça reste des idées en l’air et ça ne va pas beaucoup avancer
Montre les réglages du module backup comme @Pulpy-Luke je soupconne quelque chose en relation et je verrais bien que quand il essaye de faire le backup en local il a plus de place ce qui bloque l’enregistrement des capteurs ! Le fait que tes backups soient pas restaurables indiquent aussi un soucis à ce niveau la ! Tu as essayé de récupérer un des backups sur ton ordi et voir si tu arrives à l’ouvrir et s’il a l’air complet ?
sinon,
j’ai enfin réussi a supprimer et même ‹ détruire › portainer
sur le système hote, avec les commandes docker rm et docker rmi
un redémarrage complet et du coup j’ai pu restaurer ma dernière image 9.6
pour le moment, c’est stable et quasiment plus d’erreurs dans le journal !!
ça fais du bien !
on verra demain pour l’arrêt des enregistrements … je croise les doigts
en tout cas, si çà fonctionne, j’attendrais fin novembre pour la prochaine mise à jour !
ce matin à 4h11, idem
plus d’enregistrements
redémarrage simple de HA et c’est reparti …
je vais continuer de chercher dans mes logs … et arreter le backup au cas où !
… ajout a mon post
en fait, j’avais tous les graphiques plats à partir de 4h11
mais en regardant dans la partie ‹ historique ›, j’ai toutes les données !
malgré tout les données de mon bug d’hier et des jours précédents sont bien manquantes, même dans le graphique historique !
c’est a y rien comprendre
voilà les nouvelles depuis les 2 dernières matinées,
c’est difficile de comprendre ce qu’il se passe, je désespère
en fait, le matin en me levant, je regarde mes graphiques et tout est plat depuis 4h10 environ
je ne trouve rien de spécial dans les logs a part mariadb qui me met des erreurs de connexion à l’heure ou j’ai regardé comme si il n’arrivait pas a lire le fichier de data …
en redémarrant simplement le module mariadb, toutes mes données sont présentes
même le ‹ trou › entre 4h et 6h !!
pour demain matin,
j’ai supprimé le log de rflink qui pollue pas mal les logs
stoppé google backup et samba share >> pourquoi j’ai encore des logs de samba share alors qu’il n’est même pas démarré …?
redémarré mon hôte et dernier démarrage sans aucune erreur ni warning dans le log
et je ne vois plus trop quoi faire maintenant,
mon système raid fonctionne correctement et sans erreurs particulières
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun mariadb (no readiness notification)
services-up: info: copying legacy longrun mariadb-lock (no readiness notification)
[06:06:58] INFO: Using existing mariadb initial system
[06:06:58] INFO: Starting MariaDB
221015 06:06:59 mysqld_safe Logging to '/data/databases/mariadb.err'.
221015 06:06:59 mysqld_safe Starting mariadbd daemon with databases from /data/databases
221015 06:06:59 mysqld_safe Starting mariadbd daemon with databases from /data/databases
2022-10-15 6:07:00 0 [Note] /usr/bin/mariadbd (server 10.6.8-MariaDB) starting as process 244 ...
2022-10-15 6:07:00 0 [Note] mariadbd: Aria engine: starting recovery
recovered pages: 0% 32% 52% 80% 100% (0.1 seconds); tables to flush: 2 1 0
(0.1 seconds);
2022-10-15 6:07:01 0 [Note] mariadbd: Aria engine: recovery done
2022-10-15 6:07:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2022-10-15 6:07:01 0 [Note] InnoDB: Number of pools: 1
2022-10-15 6:07:01 0 [Note] InnoDB: Using generic crc32 instructions
2022-10-15 6:07:01 0 [Note] mariadbd: O_TMPFILE is not supported on /var/tmp (disabling future attempts)
2022-10-15 6:07:01 0 [Note] InnoDB: Using Linux native AIO
2022-10-15 6:07:01 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2022-10-15 6:07:01 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-15 6:07:01 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=136809255866,136812642149
2022-10-15 6:07:03 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 39909 row operations to undo
2022-10-15 6:07:03 0 [Note] InnoDB: Trx id counter is 24107976
2022-10-15 6:07:03 0 [Note] InnoDB: Starting final batch to recover 487 pages from redo log.
2022-10-15 6:07:04 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-15 6:07:04 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2022-10-15 6:07:04 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-10-15 6:07:04 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-10-15 6:07:04 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-10-15 6:07:04 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-10-15 6:07:04 0 [Note] InnoDB: 10.6.8 started; log sequence number 136813593996; transaction id 24107977
2022-10-15 6:07:04 0 [Note] InnoDB: Loading buffer pool(s) from /data/databases/ib_buffer_pool
2022-10-15 6:07:04 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-10-15 6:07:04 0 [Note] InnoDB: Buffer pool(s) load completed at 221015 6:07:04
2022-10-15 6:07:04 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-15 6:07:04 0 [Note] Server socket created on IP: '::'.
2022-10-15 6:07:05 0 [Note] /usr/bin/mariadbd: ready for connections.
Version: '10.6.8-MariaDB' socket: '/run/mysqld/mysqld.sock' port: 3306 MariaDB Server
[06:07:05] INFO: Check data integrity and fix corruptions
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.global_priv OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.index_stats OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.roles_mapping OK
mysql.servers OK
mysql.table_stats OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.transaction_registry OK
homeassistant.event_data OK
homeassistant.events OK
homeassistant.recorder_runs OK
homeassistant.schema_changes OK
homeassistant.state_attributes OK
homeassistant.states OK
homeassistant.statistics OK
homeassistant.statistics_meta OK
homeassistant.statistics_runs OK
homeassistant.statistics_short_term OK
sys.sys_config OK
[06:07:07] INFO: Ensuring internal database upgrades are performed
[06:07:08] INFO: Ensure databases exists
[06:07:09] INFO: Create database homeassistant
[06:07:09] INFO: Ensure users exists and are updated
[06:07:10] INFO: Update user homeassistant
[06:07:10] INFO: Init/Update rights
[06:07:11] INFO: Granting all privileges to homeassistant on homeassistant
[06:07:12] ERROR: Got unexpected response from the API: There is already a MySQL service in use from core_mariadb
[06:07:12] INFO: Successfully send service information to Home Assistant.
2022-10-15 6:07:15 0 [Note] InnoDB: Rolled back recovered transaction 24107975
2022-10-15 6:07:15 0 [Note] InnoDB: Rollback of non-prepared transactions completed
s6-rc: info: service legacy-services successfully started
[18:45:31] INFO: Lock tables using mariadb client...
[18:45:31] INFO: MariaDB tables locked.
[19:49:31] INFO: MariaDB tables unlocked.
au cas où cela inspirerait une idée …
peut être faut il supprimer mariadb ?
mais je ne suis pas certain que ce soit lui le fautif !
La vraie question c’est pourquoi mariadb ? C’est pas utile de base…
Quant aux horaires 4h11, 4h10 c’est quand même une grosse coïncidence…
Tu noteras au passage que même si tout va bien, mariadb fait un rejeu de plus de 400 actions pour se remettre à fonctionner
mariadb ?
j’étais resté sur un tuto expliquant que c’était mieux et plus rapide ?
tu ne l’utilise visiblement pas ?
mais maintenant est ce que je peut l’enlever ?
en fait je ne sais pas exactement où sont mes données, c’est le problème
c’est le fichier home-assistant_v2.db qui l’on peut voir dans le file editor ?
oui, c’est toujours a la même heure, très étrange
et si c’était une panne disque ou matériel ce serait n’importe quand !
Mouais théoriquement c’est vrai (mariadb c’est une vraie base) mais dans les faits et pour un usage domotique c’est vraiment pas certain.
Non… Le mécanisme de base fonctionne très bien donc pas besoin de le remplacer.
Oui mais avec disparition des histoires antérieurs… Il faut désactiver le recorder. C’est pas pire qu’un plantage journalier à mon avis
Ça c’est le fichier d’origine… Quant à l’éditer c’est faisable mais c’est pas une bonne idée de corriger à la main le contenu d’une base quelque soit son format. Ça impose de savoir très exactement ce que l’on fait sinon ça casse tout
oui,
c’est bien ce qui m’embête de tout perdre mon historique
en particulier la partie ‹ énergie › qui j’ai mis en place fin juillet
mais sinon si c’est pas mieux je tenterai une sauvegarde le soir avant de supprimer mariadb et comme cela si c’est pas mieux sans je pourrais toujours restaurer
4h10 et 4h11 c’est tout de même étrangement proche de 4h12 qui est l’heure de la purge automatique de la DB.
Le fait que tu voies les graphs avec une ligne plate ça indique je pense que ce n’est pas un souci de connexion, car qd la DB n’est pas connectée, il n’y a pas de graph du tout mais une animation d’attente.
L’historique depuis juillet, ce n’est pas non plus si grave que ça. Si ça avait été depuis plusieurs années, ok, mais 2 ou 3 mois, ce n’est pas si grave.
Le soucis ressemble à un problème de ressources sur le système, ou sur le container de MariaDB.
Les 54Go de ton système, c’est uniquement HA? Ou autre chose?
As tu aussi moyen de voir la taille de ta DB?
ah voilà une bonne avance !
on sait ce qu’il se passe a 4h12 !
maintenant pour info,
j’ai un PC avec processeur un peu ancien mais qui tourne pas mal tout de même
Atom N2800, 4G de RAM, 2 disques en RAID miroir
tout cela avec un ubuntu serveur 22.04.1 >> oui je sais c’est pas supporté, je le ferais plus !!
effectivement j’ai bien mis un ‹ purge ›
mais il n’a pas changé depuis plus d’un an !
je reste tout de même dans l’idée que c’est depuis le passage en 2022.10 que j’ai ce souci et cela n’a pas été réglé en revenant a 9.6
pour ce qui est de l’espace occupé, je vais essayer de chercher mais je n’ai rien d’autre de particulier qui tourne sur le système
J’ai pas suivi le sujet sur le forum officiel, mais ici j’ai vu personne d’autre dans ce cas…
Donc que tu vois le souci après la mise à jour OK. Mais c’est surement pas la cause…
Perso, quelque soit la solution retenue au final, tu as une belle marge d’optimisation dans ton recoder… 60j c’est déjà perturbant, mais sur l’ensemble de entités de HA
Que le souci soit apparu au moment où tu es passé en 2022.10 est un fait, et surement pas une coïncidence. Que ça semble persister avec le rollback en 2022.9, est aussi intéressant.
Tu disais avoir eu des soucis de sensors avec 2022.10 en plus de ces histoires d’historique figées. Est-ce que quelque chose à spammé ta DB vraiment fort le temps sur la nouvelle version et que maintenant elle a du mal et à ce genre de réaction après la purge?
En fait le auto_purge est actif par défaut même si tu ne le configure pas. le purge_keep_days, est à 10j par défaut aussi. Normalement il n’y à pas besoin de les ajouter.
Je rejoins @Pulpy-Luke sur la config du recorder. Je suis certain qu’il y a bcp d’entités qui s’enregistrent a haute fréquence pour lesquelles on n’a pas besoin de garder l’historique et qui aideraient a limiter la taille de la DB.
Je ne parles même pas de la durée de 60j
Sinon pour ton système, comme c’est un supervised installé toi-même il n’est pas optimisé, ajouter à ça une DB énorme et pas mal de containers dockers pas tjrs de HA, sur une Machine avec un processeur qui a 11 ans et qui je pense être équivalent à un Rpi3 (ou max).
Ca peut coincer à un moment en termes de ressources système et créer des soucis assez variés en termes de stabilité.
bon,
on a enfin trouvé la source du problème ! merci a tous pour votre aide !
c’est bien la purge qui pose problème
je viens de lancer manuellement la purge comme indiqué dans la rubrique recorder, en essayant de ne laisser que 30j
mais après quelques instants, mes graphique sont tout plats !
maintenant je ne sais pas si il fait finalement bien la purge et que je ne le laisse pas faire en forçant un redémarrage ou si la tache se plante toute seule et risque de ne jamais finir ??
en fait en regardant mes historiques, je retrouve des valeurs depuis le 11/08 et cela correspond a peu près au 11/12 octobre, jour où j’ai commencé a avoir des problèmes avec les 60 jours de retard
en regardant les logs, je n’ai aucune erreur ni warning que ce soit dans le superviseur, le core, le host
alors maintenant, vous laisseriez tourner jusqu’à une éventuelle fin ?
je vais aussi cherche si il y a moyen de se connecter à la DB en terminal pour lancer des commandes de purge
comme 
