Base de données MariaDB

Documentation technique

Packaging

Le packaging de MariaDB est pris directement dans nixpkgs.

Mises à jour

MariaDB donne des instructions sur son site sur la procédure à appliquer à chaque upgrade. Les points d’arrêt nécessaires y sont également renseignés.

  • Vérifier la compatibilité de MariaDB avec les applications (voir Compatibilité MySQL)

  • Nettoyer si possible les fichiers mariadb-bin.* avant de commencer la mise à jour. Pour ne pas casser les éventuels réplicats, il ne faut pas supprimer les fichiers qui n’ont pas encore été synchronisés. Il est possible de démarrer un nouveau fichier. Les instructions sont données sur le site de MariaDB En résumé, RESET MASTER; va supprimer tous les logs, et PURGE BINARY LOGS TO 'mariadb-bin.000063'; ne va supprimer que les logs jusqu’au fichier donné.

  • Arrêter mysql, ainsi que les éventuels réplicas.

  • Faire une copie du dossier de données de MariaDB (/var/lib/mysql)

  • Déployer la mise à jour.

  • Lancer mariadb-upgrade et s’assurer que tous les checks passent.

  • Redémarrer les réplicas.

Authentification

L’authentification peut se faire par deux moyens :

  • Soit un mot de passe stocké directement dans MariaDB (pour les outils ou les comptes ad-hoc)

  • Soit via PAM configuré pour interroger LDAP (pour les utilisateurs). À cause du mécanisme utilisé, cette méthode est généralement peu pratique pour être utilisée dans des scripts et sert principalement pour des accès par des « humains ».

Interruption du réplica

Il arrive que le réplica sur backup-2 cesse de fonctionner. La cause n’a pas encore été trouvée, mais elle a pour conséquence un arrêt de la synchronisation de la base de données. Par ailleurs, le monitoring n’est pas en capacité de déterminer ce problème, car l’information donnée par MariaDB n’est pas cohérente avec l’état réel du réplica.

Pour remettre en place, il suffit généralement de vider le dossier et réinitialiser le processus. Attention cependant, le dump initial vérouille en écriture la base principale pendant tout le dump:

cd /backup2/eldiron
systemctl stop mysql_backup_eldiron.service
mkdir mysql
chown mysql:mysql mysql
systemctl start mysql_backup_eldiron.service

Le service mysql_backup_eldiron.service contient déjà le nécessaire pour réaliser le dump initial et démarrer la réplication. La dernière commande peut prendre pas mal de temps.

Compatibilité MySQL

La compatibilité entre MariaDB et MySQL est documentée sur le site de MariaDB. Certaines applications (en php) nécessitent d’indiquer la version de MySQL utilisée.

Outils/Déboggage

Sur backup-2: la commande mysql_backup_eldiron permet d’accéder directement à l’instance MariaDB du réplica. Attention à ne pas faire de modifications sur la base de données !

Maintenance

Les binlog ne sont pas purgés par défaut, pour éviter un nettoyage aggressif alors que les réplicats ne sont pas à jour. Voir le site de MariaDB pour les instructions sur le nettoyage de ces fichiers.

Suivi des versions

Suivi des bugs

Suivi des CVE

Accès / Suppression des données

  • Hormis les bases de données privées qui appartiennent en propre à un utilisateur, il existe plusieurs bases de données « partagées »:

    • La base de données de status-engine (cf Status Engine)

    • La base de données des rapports DMARC.

    • La base de données postfix contenant les règles d’alias des e-mails.

  • Les utilisateurs peuvent avoir plusieurs comptes dans la base de données.

  • Les dumps de base de données sont fusionnés en un seul fichier. Ces dumps sont conservé sur des temps très longs et ne peuvent pas être divisés facilement (l’opération peut être faite manuellement).