Un petit ennui : les fichiers "binlog" ne sont plus supprimés malgré la présence du paramètre adéquat : expire_logs_days        = 3 
Ce phénomène m'a été montré par l'augmentation anormale de la taille de la partition qui supporte ces fichiers et son approche des 100% fatidiques. 
Après quelques recherches sur Internet je ne trouve rien à ce sujet. 
J'essaye de purger ces fichus binlog avec la commande "purge binlog until '2022-06-14' " ou "purge binlog to '0000xxxxxxxxxx' ". 
Ces commandes me répondent invariablement "fichier log non trouvé dans l'index" .... ???? .... 
J'allais me résoudre à une manip hasardeuse de destruction "manuelle avec rm ..." et mise à jour du fichier d'index, lorsque j'ai remarqué que le fichier index, "mysql-binlog.index" chez moi, comportait une ligne blanche en tête. 
Je stoppe MariaDB et supprime cette fichue ligne "blanche" et, miracle, lors du redémarrage de MariaDB tous les vieux binlog disparaissent en respectant bien la limite à trois jours et la partition revient à un pourcentage et un nombre de fichiers bien plus sympathique. 
Depuis 2 jours tout est normal et aucun fichier ne date de plus de 3 jours .... le problème semble donc réglé.

J'ai eu récemment un plantage violent de Mysql suite à une mise à jour d'une Debian 9. Le process Mysql avait une fâcheuse tendance à consommer tout le CPU et manifestait son mécontentement par de nombreux messages, le total fait plus de 4000 lignes, j'en ai extrait les parties les plus typiques :

J'ai commencé par copier l'intégralité des fichiers de la base sur un autre disque afin de préserver leur état. 
Après recherche sur Internet et plusieurs essais de redémarrage infructueux, y compris par l'utilisation de "innodb_force_recovery = 1". 
J'ai alors songé à examiner le syslog et j'y ai trouvé de nombreux messages tels que :

Note : chez moi les données de Mysql sont stockées dans une partition spécifique (sur SSD) montée sur /MYSQL_DATA/mysql.

J'ai alors cherché un fichier "usr.sbin.mysqld", vainement, dans /etc/apparmor.d, aucune trace d'un tel fichier !  
Je n'ai pas pu trouver l'origine de cette disparition, probablement la dernière mise à jour et j'ai du récupérer ce fichier "usr.sbin.mysqld" et son copain dans "/etc/apparmor.d/local" sur une autre machine et le personnaliser à nouveau car cette base utilise une partition séparée ... 
J'ai aussi voulu mettre apparmor en mode "complain" pour mysqld mais je me suis aperçu que le paquet "apparmor-utils" qui contient, entre autres, la fonction "aa-complain" qui permet de gérer cela brillait par son absence, j'ai donc du installer ce paquet pour placer /usr/sbin/mysqld en mode "complain" en attendant d'analyser les données fournies par les logs. 
Ensuite Mysql a démarré sans encombres et fonctionne normalement depuis.

En fait les messages de Mysql sont le reflet des erreurs induites par les blocages effectués par Apparmor suite à l'absence (inexpliquée à ce jour d'un fichier de paramétrage de Apparmor) et non dus à un dysfonctionnement de Mysql ou d'un problème système quelconque (librairies, disque ....). 
Enfin ce type d'erreur est de plus en plus rare, les "paquets" sont, en général, bien configurés coté "apparmor".

Juste avant de partir une semaine en congés, j'ai effectué une mise à jour du système qui "supporte", entre autres choses, la machine virtuelle (KVM) de ce site, j'ai eu le malheur de ré-démarrer le machine, petit nettoyage de la mémoire avant de partir ... 
Je n'ai pas vérifié que tout se passait bien au redémarrage et, quelques heures après en consultant mes mails j'ai constaté que la base de données de ce système était inaccessible et que certains logiciels ne fonctionnaient plus car ils utilisent cette base Mysql ... 
Dans le coin où j'étais en congés les liaisons téléphoniques étaient tellement mauvaises que je n'ai pas pu prendre la main à distance pour étudier ce phénomène. J'ai du attendre le retour pour me pencher sur cet ennui. 
Mysql ne se lançait plus et, comme d'habitude, les renseignements fournis par systemd étaient insuffisants pour toute analyse sérieuse : le service a retourné une erreur ... ce n'est pas très informatif sur la nature de l'erreur et donc franchement inutile ! 
Une erreur c'est bien de le savoir, mais il serait mieux de savoir laquelle en ayant un message sensé aidant à comprendre le pourquoi ! 
En lançant Mysql "à la main" en tant qu'utilisateur "mysql" (il faut modifier le shell de démarrage dans /etc/password de /bin/false à /bin/bash) j'ai tout de suite eu un message "fichier my.cnf inexistant", ce qui était beaucoup plus clair que "le service a retourné une erreur'. Ne pas oublier de repasser cet utilisateur à "/bin/false" après la manip ! 
Je me précipite dans /etc/mysql et ... le fichier "my.cnf" est présent sous la forme d'un lien vers /etc/alternatives/my.cnf", or en tentant de le lister j'obtiens un message de fichier inexistant ... et dans /etc/alternatives il existe bien un fichier "my.cnf" mais sous la forme d'un lien vers /etc/mysql/my.cnf !!! 
Je crée donc un "vrai" fichier "my.cnf" contenant :

[mysqld] 
!includedir /etc/mysql/mysql.conf.d/

Et systemd lance la base de données sans aucun message alarmant, mais je ne saurais jamais comment et par qui ce lien "en boucle" a été mis en place.