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
Hum… c’est à mon avis exactement qu’il vaut mieux éviter. Si tu ne connais pas le modèle de données et si tu n’es pas habitué aux fonctionnement des bases, tu risques de laisser un tas d’incohérence en base, et ça va être pire que mieux…
Vire mariadb, reboot et point barre (de toute façon, tu semble avoir déjà perdu les données récentes). Tu fais du tri dans le recorder, réduit la durée d’historique (avec les sujets disponibles sur le forum) et ça ira tout seul.
Bon,
tu a raison,
je me laisse encore quelques jours de réflexion avant de tout mettre à plat !
par contre, je suppose que ma question bête va avoir une réponse toute aussi bête : il n’y a pas moyen de conserver les données de la partie énergie ??
et du coup, tant qu’à tout casser, il n’y a pas d’autre solution de base de donnée plus sure, tout au moins pour les données énergie ??
Il ne faut pas mélanger l’historique des capteurs et l’historique long terme.
L’historique des capteurs, de base pour HA c’est du très court terme, c’est pour ça que 10 jours c’est la config de base et que ce n’est pas trop recommandé d’aller trop haut pour garder un système stable et responsif.
L’historique long terme c’est principalement tout ce qui est lié à la partie Energie, et pour ça il n’y a pas de purge les données sont gardées dans une autre partie de la page de données sous forme agrégée.
Bon sinon, de mon côté, pour tout ce qui est énergie, je garde ça dans une autre base hors HA, car c’est des choses qui ne changeront plus jamais et qui, si jamais je voulais changer de système, ne seront pas impactées. J’ai toutes mes données par jour sur les 9 dernières années, malgré avoir changé 2 fois de système.
voilà, c’est fait, j’ai sauté le pas
j’ai supprimé mon ancien fichier de db, modifié mon configuration.yaml en retirant la mention db_url,
stoppé mariadb et redémarré,
tout est bien vide, surtout mon historique d’énergie
bon,
pour me coucher moins bête ce soir,
dans la version de base que je viens de remettre, il est où le fichier à long terme ?? que je puisse en prendre soin pour essayer de le conserver précieusement
et d’ailleurs, il y a 3 fichiers db maintenant :
le .db
le .db-shm
et le .db-wal
et enfin,
peut on mettre uniquement cette partie énergie séparés dans une db séparée, comme faire un contenair de gestion de base spécifiquement pour lui …?
Par définition ne touche pas aux fichiers de la base… La classique et celle à long terme. Tu laisses HA gérer le truc pour toi.
Si tu veux assurer le coup : tu fais des backup de HA (donc avec les bases) tous les jours, que tu externalises quelque part.
Eventuellement tu ajoutes une base complémentaire (perso influxdb mais tu peux prendre autre chose) et tu y colles les quelques valeurs que tu veux mettre de coté… Pas tout, juste ce dont tu as besoin