Re: Crash MySQL

On Sat, 2022-02-05 at 13:10 +0100, Marc BERLIOUX wrote:
> Le 04/02/2022 à 17:15, Arnaud a écrit :
>
>
> Cela dit, ça n'a pas fait réapparaître les entrées manquantes. Je ne
> sais toujours pas où elles sont passées, ni pourquoi elles n'ont pas
> été
> enregistrées immédiatement en dur. C'est d'autant plus bizarre que
> quand
> je crée ou modifie une tâche et que je l'enregistre, la base est
> immédiatement relue pour m'afficher les tâches du projet et je suis
> sûr
> que celles qui manquent se sont affichées. Si MySQL utilise un cache
> et
> n'enregistre pas immédiatement les données en dur dans les fichiers
> de
> la base, il va falloir que je trouve le moyen de faire un 'sync'
> d'une
> façon ou d'une autre pour ne plus rien perdre. RTFM donc..
>
> Merci en tous cas pour les conseils

Bonjour Marc

Si le serveur MySQL est configuré avec la production de fichiers de log
pour les requêtes SQL, il est possible de rejouer celle de l'intervale
de temps qui semblent te manquer.

Si ce n'est pas le cas, je ne peux que te le recommander, en complément
des définitions des périodes et volume de rétention - tout en sachant
que lors de gros travaux de maintenance (import ou restore), il faut
anticiper et désactiver ce logging (histoire de ne pas remplir les
disques ou de perdre les traces récentes)

Ces logs m'ont sauvé la vie lors d'un crash similaire avec le serveur
Jira de ma boîte... après avoir découvert avec horreur que Debian ne
configurait pas le stockage InnoDB par défaut à l'époque.

Et surtout il faut abandonner ce format de stockage MyISAM pour InnoDB
<troll>voire mieux migrer à PostgreSQL</troll>

Bon courage
--
Yves Martin