Je vais tester dans les prochains jours cette version sur ma PROD à la maison.
Si jamais les tests sont concluants, j’aimerais savoir si un déploiement la dernière semaine d’août est envisageable ou si beaucoup d’entre vous seront encore en vacances ?
Cette mise à jour étant une mise à jour majeure, je veux assurer le coup et ne pas créer de soucis chez des utilisateurs en vacances qui ne seront pas chez eux pour surveiller la mise à jour
2024-08-06T21:10:19 DuckDB: Migrating data from SQLite
...
2024-08-06T21:11:47 DuckDB: Finished migrating DuckDB.
(Pour rappel, la migration est non bloquante donc pendant ce temps là, mon instance tournait sans souci)
Avant après:
Base de donnée SQLite: 905 Mo Base de donnée DuckDB: 18 Mo
C’est impressionnant !
Ce qui est encore plus impressionnant, c’est la réactivité des graphiques.
Je peux sans souci afficher des mois d’historiques de températures, c’est très fluide et on voit des valeurs beaucoup plus propre car 2 soucis sont désormais résolu par cette techno :
Pas d’arrondi bizarre hors vu 24h sur les graphiques
Il n’y a plus que des données « live », et donc les données de la dernière heure sont visibles sur tous les graphiques !
J’ai lancé un nettoyage de la base de donnée, ce qui a été presque instantanée chez moi.
Ensuite, j’ai redémarré Gladys.
Le résultat
1008K Aug 6 19:34 gladys-production.db
32K Aug 6 19:34 gladys-production.db-shm
278K Aug 6 19:34 gladys-production.db-wal
3.1M Aug 6 19:11 gladys-production.duckdb
15M Aug 6 19:34 gladys-production.duckdb.wal
Total = 19 Mo
Avec une taille avant de 905 Mo, cela fait -97,9%
Je vais continuer d’observer mon instance les prochains jours et voir ce que ça donne
Je ne sais pas comment c’est possible. Je pense avoir fait un refresh de la page et que la requête a été renvoyée…
Sinon, ça avance. Lentement mais ça avance 4% après une heure) !
Voici plus en détail comment la migration s’est passée.
De manière générale, pas de souci.
Tout d’abord, j’ai été étonné que la migration commence sitôt le container démarré. En soi, ça ne pose pas de problème.
Par contre, l’étape suivante, la purge… Fût pénible !
Plusieurs très longues heures pendant lesquelles Gladys était, chez moi, proche de la paralysie…
Ce matin, je vois que
Je lance donc un nettoyage de la base de données qui, comme prévu, bloque Gladys une heure environ.
Mais après vérification, je constate que l’ancienne db n’est pas vide :
Évidemment, c’est très peu, voire pas compressé (est-ce donc encore nécessaire?)
Temps total… Près de 30h…
On est d’accord que les étapes de purge et de nettoyage ne sont pas indispensables mais elles ont permis de régler mon problème de stockage
Oui, en soit la migration est obligatoire, l’ancien code pour SQLite n’est plus présent, et tant que la migration n’a pas terminée, tu as un fonctionnement de Gladys qui n’est pas complet (les graphiques seront vide sinon)
La migration n’est pas linéaire, le pourcentage représente le pourcentage de fonctionnalités migré. Certaines fonctionnalités ont beaucoup d’états, d’autres moins.
Vouloir faire une progress bar encore plus précise serait contre productif, ça prendrait du temps de calculer combien d’états a chaque fonctionnalités, et ça ralentirait la migration.
Oui le fait d’avoir lancé 2 fois la tâche a dû doubler la charge Je ne sais pas comment tu as fais ^^ Pareil pour le pourcentage qui se bloque, les deux tâches ont fait chacun le travail et donc à mi-chemin le job a dû être fini, et elles ne pouvaient plus avancer. En soit, c’est pas très très grave ^^ Tu as bien fais de relancer la tâche après le redémarrage, ça a finit le boulot.
Yes, j’ai déployé 2 mises à jour de l’image DuckDB, mercredi soir et jeudi soir, pour corriger divers soucis que j’avais remarqué sur ma prod. Watchtower a du passer ensuite.
C’est une veille trad, pas nouveau à cette release, mais je vais corriger ^^
Désormais, le fichier de sauvegarde exporté par DuckDB est au format .parquet, et ce format est plus lourd que le format de stockage de DuckDB qui est très compressé. Il y aura donc moins de différence entre la sauvegarde Gladys Pus et les fichiers locaux, voir le fichier sur Gladys Plus sera un peu plus lourd. Mais quand on voit les tailles de fichiers…
Merci pour ton retour très complet !
Malgré le petit couac du double lancement de la tâche de purge, la migration est clairement un succès chez toi.
Avec 13 millions d’états, 11 Go de DB SQLite, et tout ça sur un setup pas des plus puissants qui existe (Rpi 4 + SSD en USB je crois), c’est franchement propre !
Si jamais tu veux garder ce setup en tant que PROD (pour ne pas refaire la migration une deuxième fois), tu peux. Il te suffira de re-basculer à l’image tagguée v4 dès que je publie ça en PROD (fin du mois).
Moi non plus mais en relançant la tâche après le redémarrage de Gladys, ça l’a refait, à nouveau en double et dans les deux cas, à un petit quart d’heure d’écart. La deuxième fois, je suis sûr de ne pas avoir re-cliqué ni refresh cette page…
Après 1h il a l’air d’être dans le dur, les refresh de page sont de plus en plus lent (1 minute à peu près) et le % n’avance plus (bloqué à 31% depuis 15 minutes ^^) mais les états montent bien ^^ Donc pas de soucis ^^
EDIT : 400k états purgés en 15 minutes … on va le laisser travailler ^^ car si on prend un raisonnement à plat : 26 700 états par minutes => 3.000 minutes => 50h ^^
Gladys est de nouveau disponible.
1% après 20 minutes
Ça m’étonne pas, la purge est faite très doucement pour que l’instance puisse continuer à vivre (continuer à recevoir des valeurs de capteurs, exécuter des scènes)
Tout ce qui touche à la DB SQLite reste ralenti bien sûr, mais pas entièrement bloqué non plus !
Petite question @pierre-gilles,
Est-il normal de ne plus avoir de graphique / historique après migration et pendant la purge ? Car pour ma part je n’ai pour le moment plus aucune données à part la dernière valeur.
La purge serait donc obligatoire avant d’utiliser la base DuckDB ou était-ce censé prendre le relais après la migration ?
Comme le message n’apparait plus en haut de page une fois la migration terminée et qu’il n’est pas indiqué de redémarrer, j’ai un doute ^^
EDIT: Bon bah j’ai ma réponse une fois que les états SQLite sont tombés à 0 tout est revenu ^^ Donc purge obligatoire avant usage DuckDB. Par contre la purge dans les tâches est toujours en cours (69%) :
Je ne touche à rien pour le moment (pas de nettoyage de la DB) ?
Résultat de la suppression des états SQLite : 23h pour 80 millions d’états (2024-08-15 12:55:28.297 +00:00 => 2024-08-16 11:56:34.779 +00:00) … En attente de fin de la purge définitive.
