Tous les systèmes sont opérationnels

Incidents antérieurs

12th janvier 2020

Aucun incident signalé

11th janvier 2020

Matrix Matrix coupé

Après une alerte de surconsommation de la RAM, Matrix est tombé et n'est pas répartie.

  • Matrix semble de nouveau opérationnel après une réinstallation complète

  • 10th janvier 2020

    Aucun incident signalé

    9th janvier 2020

    Aucun incident signalé

    8th janvier 2020

    Matrix Problème de communication entre Matrix et d'autre instances

    Suite à de nombreuse remonté, Matrix ne reçoit pas les messages de matrix.org (entre autre). Ces problèmes remontent à l'incident de base de donnée de la semaine dernière. Aucun log me permettent de comprendre le problème.

  • Le service avait au final un problème de MTU.

    C'est corrigé.

  • Au vu du temps que va prendre la restauration, je repart sur le backup et je relancerai la tache vers 22h.

  • Une tentative de première réparation est en cours. Le but est de recréer une base de donnée vierge et d'y importer les données. Cela prend du temps du fait de la taille de la base de donnée.

  • 7th janvier 2020

    Aucun incident signalé

    6th janvier 2020

    Perte de l'IPv4

    L'IPv4 ne fonctionne plus, rendant les services inaccessibles. Nous sommes sur le coup

  • Problème résolu. Le NAT ne s'était pas remis en place.

  • 5th janvier 2020

    Aucun incident signalé

    4th janvier 2020

    Aucun incident signalé

    3rd janvier 2020

    Aucun incident signalé

    2nd janvier 2020

    Aucun incident signalé

    1st janvier 2020

    Aucun incident signalé

    31st décembre 2019

    Problème de performance sur PostgreSQL

    La restauration de Mastodon hier a posé un problème lors de la recréation d'index à cause d'entrées dupliquées. Je fais tout mon possible afin de recréer cette entré.

  • La base de donnée est maintenant restauré et les problèmes de performance semblent avoir disparu.

    Nous surveillons notre métrologie afin de détecter le moindre problème.

  • Les différentes tentatives de réparations n'ont rien corrigé. Je remet le backup d'hier 9h qui était fonctionnel. Toutes mes excuses pour la gêne occasionnée

  • Même après une chute de l'utilisation du disque, celui ci reste très solicité par Mastodon. Je cherche des solutions

  • L'utilisation disque a chuté, l'index a été créé. Mastodon est plus réactif. Mais j'ai toujours un load de 10 sur le serveur PostgreSQL a cause de Matrix.

  • Tous les tags ont été dupliqué le 25 décembre, je les ai donc supprimé à partir de cette date. L'index se reconstruit.

  • Matrix Serveur Matrix arrêté

    La base de donnée de Matrix a augmenté de 50Go de manière anormal. Le service Matrix a donc été arrêté le temps de la suppression et du vacuum des events dans la base de donnée afin de revenir à une taille normale.

    Toutes mes excuses pour la gêne occasioné.

  • La base de donnée est de nouveau fonctionnelle !

  • Matrix est de nouveau fonctionnel Mastodon n'a pas eu cette chance

  • La base de donnée de Mastodon ne se réimporte pas

    psql:mastodon.dump:32082526: ERROR:  could not create unique index "index_tags_on_name_lower"
    DETAIL:  Key (lower(name::text))=(ヤギ) is duplicated.
    CONTEXT:  parallel worker
    
  • Catlife, DryCron et Invidious sont de nouveau UP. Il y a eu un défaut avec la restauration de la base de Mastodon car il s'agissait d'une sauvegarde avant de restaurer le cluster afin de ne pas perdre de donnée), j'ai relancé un import.

  • Le recovery est terminé. Je réimporte les dumps de mastodon et plume afin de ne pas perdre de donnée.

  • PostgreSQL a été relancé. Il récupère les xlogs afin de finir sa réparation.

  • La restauration des backups prennent plus de temps que prévu... J'ai rencontré des soucis entre la restauration dans le mauvais répertoire et l'espace disque qui a saturé.

  • Les actions ont généré d'autre problème, le service n'est plus accessible.

  • Le service est revenu.

  • 30th décembre 2019

    Aucun incident signalé