D’après ./gql/src/queries/txs_history.rs les transactions devraient être triées par numéro de bloc d’écriture :
// both_txs étant les txs envoyées suivies des txs reçues
both_txs.sort_unstable_by(|(_, db_tx1), (_, db_tx2)| {
db_tx1
.written_block
.number
.cmp(&db_tx2.written_block.number)
});
Edit: mais il y a d’autres requêtes pour l’historique des txs, de laquelle est-il question ?
Pour info après màj vers 1.8.7, j’ai la même erreur que moul :
2023-08-06T21:48:20+02:00 - error: Error: SQL error “SQLITE_ERROR: no such column: issuer” on query "
BEGIN;
CREATE TABLE IF NOT EXISTS txs (
…
C’est parti pour une resynchro, en espérant que ça passe…
Duniter V1.8.7 installé mais pas moyen de synchroniser … Des conseils pour y arriver ?
(Linux mint, 4 Mo de mémoire, 3 cpu)
Et je vois beaucoup de noeuds en V1.9.0, est-ce bien de migrer en 1.8.7 ?
Merci d’avance.
Salut j’ai ce message d’erreur après la validation d’un virement dans l’extension cesium 1.7.6 dans Firefox :
A mon avis cela devrait pointer vers un noeud local en 1.8.7 hébergé dans le domaine duniter.org, ou sinon vers un noeud en 1.8.7 comme g1.e-is.pro.
Je veux bien regarder, mais je voie pas de quelle branche develop tu parles. Je prépare une MR en dev avec les modifs de la 1.8.7 ?
[edit] ok j’ai trouvé la branche develop en question, tu parlais de cesium, je pensais que tu parlais de reporter les modifications de duniter 1.8.7 en 1.9.
Ca me semble compliqué, mais pas impossible, g1specte recense 10 instances en 1.9.0, il faudrait contacter chacun des admins et attendre qu’il accepte de stopper son instance (perso je fais tourner un noeud, il en reste plus que 9 :p). Autrement, est-ce qu’il serait possible de sortir une nouvelle version de cesium qui filtre les noeuds pour interagir uniquement avec les versions < 1.9 ? Cela permettrait de fixer les problèmes et tester à la fois en 1.8.7 et en 1.9-dev.
Quel nœud utilises-tu ? Il est surement désynchronisé.
Pour référence :
4Go de mémoire je suppose ? C’est peut-être un peu juste du coup. Personnellement, j’ai réussi à synchroniser en indiquant 10Go à node (mais 8 devrait probablement marcher aussi). Le truc, c’est qu’une fois synchro ça fonctionne sans avoir besoin d’autant. Peut-être devrions-nous songer à nous passer des répertoires déjà synchro, même si c’est très très moyen car il faut avoir confiance dans l’envoyeur.
Pi utilise l’extension firefox de cesium en version 1.7.6. Au lancement, la sélection automatique du noeud a choisit le noeud g1v1.p2p.legal avec une piscine pleine et en retard de ~20k blocks.
tu dois avoir le mode expert enclenché du coup pas d’ analyse complete du réseau
où simplement ne pas syncro dans la ram …
Le problème c’est que si on ne le fait pas en ram, c’est très très lent actuellement, même avec un SSD…
à 2oM/s sans ssd et sans fibre donc, telecharger 5Gigas prend 25oo secondes
Souvent, le noeud g1v1.p2p.legal ne donne rien de bon. Il faut fermer césium puis relancer pour qu’il choisisse un autre noeud qui est synchro.
C’est ce que j’ai expérimenté.
Je viens de tester à nouveau en forçant g1v1.p2p.legal et je n’ai plus d’opérations, dés que je remets g1.duniter.org, je retrouve mes opérations …
La synchro n’est pas qu’un téléchargement. L’application des blocs est coûteuse en lecture/écriture synchrone et non séquentielle de la bdd, ce qui est lent.
Je ne suis pas certain de la configuration d’avant, mais je penses qu’il y avait un nœud de l’infra Duniter. Sans doute géré par Ansible. cc @moul @cgeek une idée ?
Finalement, j’ai trouvé un contournement pour la prochaine version (1.8.8) de Cesium : implémenter un cas spécial pour ce noeud, et l’exclure de la sélection du noeud au démarrage. Ainsi, il pourra toujours être utilisé par les vieux Cesium < 1.7 (en évitant l’étranglement).
En attendant cette version de Cesium, est-ce qu’on peut à minima le faire pointer vers des noeuds 1.8.7 ?
Oui, en réalité c’est exactement ce que j’ai codé (avant de lire tous vos messages). C’est effectivement plus simple, mais cela fait N requêtes de plus au démarrage (appel de /node/summary sur chaque noeud).
J’ai donc ajouté à Cesium un filtrage pour exclure les noeuds 1.9.0.
IMPORTANT: Il faudra donc releaser la prochaine version 1.9.x de Duniter en 1.9.1 (et donc sauter la 1.9.0 - qui correspond à une beta)
Pouvez-vous tester autant que vous pouvez sur différents noeuds, et me redire sur quel noeuds les opérations sont mal triés ? en donnant le noeud, la version et sa config de storage (issu de /node/summary)
C’est peut-etre aussi les noeuds 1.8 qui n’archivent pas les TX ?
Pour ce problème de piscines pleine, j’ai ajouté plusieurs trucs :
Avec tout ca, je vais donc pouvoir sortir une version de Cesium 1.8.8, qui réglera la plupart des problème des utilisateurs.
Reste le fait que tous ne seront pas encore sur cette version… et surtout qu’il faudra bien la tester !
En effet c’est bien dans ansible et il y a bien un noeud local.
@Moul il suffirait de retirer les lignes 141 à 156 ?
C’est un peu plus compliqué que cela mais si c’est le choix je peux m’en charger
Il s’agit de répondre à ces questions. Savoir ce qu’on fait avant de le faire. Qu’est-ce que l’on veut comme résultat ?
Je trouvais le LB pas très malin, car tu te retrouves avec des vues différentes dans le cas de piscines différentes entre autres problèmes. Il a été mis en place en première place pour parer à la lenteur de clients BMA qui n’était plus acceptable pour l’expérience utilisateur.
Si les problèmes de lenteurs sont rendus raisonnables avec Duniter v1.8.7, on pourrait supprimer le LB et le faire pointer vers le nœud local g1.duniter.fr. Préalablement, ce nœud doit être mis en v1.8.7 afin de bénéficier des performances qu’elle offre.
Qu’en pensez-vous ?
Je pense que c’est exactement ce qu’il faut faire
Très bien, donc on veut rediriger vers le nœud local (sur redshift). Actuellement ce nœud est en 1.8.5. Est-ce que du coup j’attends avant de modifier ?
Actuellement, il y a trois nœuds up sur 6 :
Si c’est urgent (d’après le sujet), est-ce que je dirige vers vit.fdn.org en attendant que redshift soit mis à jour ? Je peux essayer de m’occuper de ladite mise à jour mais n’étant pas à l’aise avec les nœuds je préférerais que quelqu’un d’autre le fasse (c’est un container docker, il suffit peut être de faire un git pull et relancer ? Je peux tenter mais si je me plante il ne reste plus que deux nœuds).
