MySQL / MariaDB

Installer MariaDB

apt install mariadb-server -y
mysql_secure_installation

Configuration de MariaDB

Modifiez le fichier de configuration de MariaDB (my.cnf ou mariadb.cnf). Sur la plupart des systèmes, il se trouve dans /etc/mysql/ ou /etc/mariadb/.

cd /etc/mysql/
# ou, selon la distribution :
# cd /etc/mariadb/
nano /etc/mysql/mariadb.cnf

Ces valeurs sont également consultables dans phpMyAdmin, via Accueil / Variables et paramètres du serveur.

[mysqld]
#port = 3306
#bind-address = 127.0.0.1
#datadir = /var/lib/mysql
#socket = /var/run/mysqld/mysqld.sock
#log_error = /var/log/mysql/error.log
#pid-file = /var/run/mysqld/mysqld.pid
#
#max_connections = 100
#query_cache_size = 16M
#query_cache_type = 1
#innodb_buffer_pool_size = 256M
#innodb_log_file_size = 64M
#innodb_flush_log_at_trx_commit = 1
#
#skip-networking      # Désactive les connexions réseau, n'autorisant que les connexions locales via le socket Unix.
#skip-name-resolve    # Désactive la résolution de nom d'hôte pour améliorer les performances.
#
#log_bin = /var/log/mysql/mysql-bin.log
#server_id = 1          # Identifiant unique du serveur pour la réplication.
#binlog_format = MIXED  # (ROW, STATEMENT, MIXED)
#relay_log = /var/log/mysql/mysql-relay-bin.log
#
#default_storage_engine = InnoDB
#character_set_server = utf8mb4
#collation_server = utf8mb4_general_ci

systemctl restart mariadb
systemctl status mariadb

# Désinstallation complète
systemctl stop mariadb
apt-get remove --purge mariadb-server mariadb-client mariadb-common
apt-get autoremove
apt-get autoclean
rm -rf /etc/mysql /var/lib/mysql
deluser mysql
delgroup mysql

Se connecter et explorer les bases

mysql -u root -p                          # Ouvrir le client (le mot de passe est demandé)
mariadb -u root -p                        # Client MariaDB, équivalent sur les versions récentes
mysql -u app -p -h 127.0.0.1 ma_base      # Connexion réseau directement sur une base

SHOW DATABASES;                           -- Lister les bases
USE ma_base;                              -- Sélectionner la base courante
SHOW TABLES;                              -- Lister les tables de la base courante
DESCRIBE clients;                         -- Colonnes et types d'une table
SHOW CREATE TABLE clients\G               -- Instruction de création complète (\G = affichage vertical)
SELECT VERSION();                         -- Version du serveur
STATUS;                                   -- Informations de connexion et du serveur
EXIT;                                     -- Quitter le client (ou \q)

Commandes SQL de base

-- Créer une base et une table
CREATE DATABASE boutique CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE boutique;

CREATE TABLE clients (
  id       INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  nom      VARCHAR(100) NOT NULL,
  email    VARCHAR(150) NOT NULL UNIQUE,
  cree_le  DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- Insérer des données
INSERT INTO clients (nom, email) VALUES ('Ada Lovelace', 'ada@exemple.fr');
INSERT INTO clients (nom, email) VALUES
  ('Grace Hopper', 'grace@exemple.fr'),
  ('Alan Turing',  'alan@exemple.fr');

-- Lire (SELECT)
SELECT * FROM clients;
SELECT nom, email FROM clients WHERE nom LIKE 'A%' ORDER BY nom ASC LIMIT 10;
SELECT COUNT(*) FROM clients;

-- Jointure entre deux tables
SELECT c.nom, co.total
FROM clients c
JOIN commandes co ON co.client_id = c.id
WHERE co.total > 100;

-- Mettre à jour et supprimer (ne jamais oublier le WHERE)
UPDATE clients SET email = 'ada.l@exemple.fr' WHERE id = 1;
DELETE FROM clients WHERE id = 3;

-- Faire évoluer la structure et indexer
ALTER TABLE clients ADD COLUMN ville VARCHAR(80);
CREATE INDEX idx_clients_nom ON clients (nom);

-- Supprimer une table ou une base
DROP TABLE commandes;
DROP DATABASE boutique;

Gérer les utilisateurs et les privilèges

-- Créer un utilisateur : local (socket) puis réseau
CREATE USER 'app'@'localhost' IDENTIFIED BY 'MotDePasseFort';
CREATE USER 'app'@'%'         IDENTIFIED BY 'MotDePasseFort';   -- depuis n'importe quel hôte

-- Accorder des privilèges CIBLÉS sur une seule base (principe du moindre privilège)
GRANT SELECT, INSERT, UPDATE, DELETE ON boutique.* TO 'app'@'localhost';

-- Inspecter, retirer, supprimer
SHOW GRANTS FOR 'app'@'localhost';
REVOKE INSERT, UPDATE, DELETE ON boutique.* FROM 'app'@'localhost';
DROP USER 'app'@'localhost';

-- Changer un mot de passe
ALTER USER 'app'@'localhost' IDENTIFIED BY 'NouveauMotDePasse';

FLUSH PRIVILEGES;                         -- Recharger la table des privilèges

Accordez toujours le minimum nécessaire : une application web se contente en général de SELECT, INSERT, UPDATE, DELETE sur sa base, sans ALL PRIVILEGES ni GRANT OPTION, réservés à l'administration.

Sauvegarde et restauration

La sauvegarde logique repose sur mysqldump, qui exporte la structure et les données sous forme d'instructions SQL. La restauration réinjecte ce fichier avec le client mysql (ou mariadb).

Sauvegarder une base

# Une base précise
mysqldump -u root -p ma_base > ma_base.sql

# Compressée à la volée (recommandé) → fichier .sql.gz
mysqldump -u root -p ma_base | gzip > ma_base_$(date +%F).sql.gz

# Toutes les bases du serveur
mysqldump -u root -p --all-databases | gzip > full_$(date +%F).sql.gz

# Seulement la structure (sans les données)
mysqldump -u root -p --no-data ma_base > ma_base_schema.sql

# Seulement les données (sans le schéma)
mysqldump -u root -p --no-create-info ma_base > ma_base_data.sql

# Plusieurs bases nommées
mysqldump -u root -p --databases base1 base2 | gzip > bases_$(date +%F).sql.gz

Quelques options utiles pour une sauvegarde cohérente, en particulier sur des tables InnoDB :

# --single-transaction : dump cohérent sans verrouiller les tables (InnoDB)
# --quick              : lit ligne par ligne, ménage la mémoire sur les grosses tables
# --routines           : inclut les procédures stockées et fonctions
# --triggers           : inclut les déclencheurs
# --events             : inclut les événements planifiés
mysqldump -u root -p \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  ma_base | gzip > ma_base_$(date +%F).sql.gz

Attention lors de la copie d'une commande sur plusieurs lignes : un commentaire placé après la barre oblique inverse (\ # ...) interrompt la continuation. Le shell n'échappe alors plus le retour à la ligne et exécute chaque ligne séparément. Le dump peut donc être lancé sans les options prévues. Placez les commentaires au-dessus du bloc, jamais en fin de ligne.

Sélectionner ou exclure des tables

On peut ne sauvegarder que certaines tables, ou au contraire en écarter. Les tables à inclure se listent après le nom de la base ; les tables à exclure passent par --ignore-table, à répéter et à préfixer par le nom de la base.

# Seulement certaines tables (les noms suivent la base)
mysqldump -u root -p ma_base clients commandes > ma_base_partiel.sql

# Toute la base SAUF certaines tables (--ignore-table à répéter, préfixé par la base)
mysqldump -u root -p ma_base \
  --ignore-table=ma_base.logs \
  --ignore-table=ma_base.sessions \
  | gzip > ma_base_sans_logs_$(date +%F).sql.gz

# Exclure les données volumineuses mais garder leur structure :
# 1) tout sauvegarder en excluant les données des tables lourdes
mysqldump -u root -p ma_base --ignore-table=ma_base.logs | gzip > ma_base_$(date +%F).sql.gz
# 2) ajouter uniquement le schéma des tables exclues
mysqldump -u root -p --no-data ma_base logs | gzip >> ma_base_$(date +%F).sql.gz

Pour exclure une même table sur toutes les bases lors d'un --all-databases, chaque --ignore-table doit malgré tout nommer la base concernée : il n'existe pas de motif générique, on répète l'option pour chaque couple base.table.

Restaurer une base

# La base cible doit exister au préalable
mysql -u root -p -e "CREATE DATABASE ma_base CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"

# Depuis un fichier .sql
mysql -u root -p ma_base < ma_base.sql

# Depuis un fichier compressé .sql.gz (sans le décompresser)
gunzip < ma_base_2026-07-05.sql.gz | mysql -u root -p ma_base
# variante équivalente :
zcat ma_base_2026-07-05.sql.gz | mysql -u root -p ma_base

Un dump créé avec --all-databases ou --databases contient déjà les instructions CREATE DATABASE / USE : on le restaure alors sans préciser de base.

zcat full_2026-07-05.sql.gz | mysql -u root -p

Avec le client mariadb et un utilisateur applicatif, le mot de passe peut être passé directement à la suite de -p (sans espace). Le dump --databases portant déjà le CREATE DATABASE / USE, aucune base n'est précisée :

# Restaurer : décompresser et réinjecter dans MariaDB
gunzip < /var/bases.sql.gz | mariadb -u user -p'password'

#  sauvegarder et compresser
mariadb-dump -u user -p'password' --databases bases | gzip > bases.sql.gz

Passer le mot de passe dans la commande l'expose dans l'historique du shell et la liste des processus (ps). Pour un usage régulier, préférez ~/.my.cnf (chmod 600) décrit plus bas, ou l'invite interactive avec -p seul. Sur MariaDB récent, mariadb/mariadb-dump remplacent mysql/mysqldump, qui restent disponibles comme alias.

Variante ZIP (.sql.zip)

Contrairement à gzip, zip produit une archive (elle peut contenir plusieurs fichiers) et non un simple flux compressé : on ne peut donc pas l'enchaîner par un pipe aussi directement. Il faut d'abord installer les outils :

apt install zip unzip -y

# Sauvegarder : dump vers un .sql, puis archivage en .sql.zip
mysqldump -u root -p --databases ma_base > ma_base.sql
zip ma_base.sql.zip ma_base.sql   # crée l'archive
rm ma_base.sql                    # on ne garde que le .zip

# Variante en une ligne, sans fichier intermédiaire :
# le contenu est envoyé sur l'entrée standard de zip (l'entrée s'appelle alors « - »)
mysqldump -u root -p --databases ma_base | zip ma_base.sql.zip -

# Restaurer : extraire le contenu de l'archive vers l'entrée de MariaDB
# -p écrit le fichier extrait sur la sortie standard (peu importe son nom dans l'archive)
unzip -p ma_base.sql.zip | mariadb -u synapxlab -p'xxxxxxxxxxxxxxxxx'

Un dump --databases embarquant déjà CREATE DATABASE / USE, aucune base n'est précisée à la restauration. À taille de données égale, zip compresse un peu moins bien que gzip sur un dump SQL ; on le choisit surtout pour la compatibilité (archive ouvrable sous Windows d'un double-clic).

Automatiser avec cron

crontab -e

# Sauvegarde quotidienne à 2 h, conservée 7 jours
0 2 * * * mysqldump -u root -p'MOT_DE_PASSE' --single-transaction --routines ma_base | gzip > /var/backups/mysql/ma_base_$(date +\%F).sql.gz
30 2 * * * find /var/backups/mysql -name '*.sql.gz' -mtime +7 -delete

Pour éviter d'exposer le mot de passe dans la ligne de commande ou la crontab, on le place dans un fichier protégé ~/.my.cnf :

# ~/.my.cnf  (chmod 600)
[client]
user = root
password = MOT_DE_PASSE

mysqldump et mysql liront alors ces identifiants automatiquement, sans option -u ni -p.

Le piège du pipe : une sauvegarde vide qui semble réussie

Dans mysqldump ... | gzip > fichier.gz, le shell renvoie par défaut le code de sortie du dernier maillon, ici gzip. Si mysqldump échoue en raison d'un mot de passe modifié, d'une base renommée, d'un disque plein ou d'une table corrompue, gzip peut tout de même créer une archive valide mais presque vide et se terminer avec le code 0. La tâche cron paraît alors réussie.

L'option pipefail propage au pipeline le code d'échec de l'une de ses commandes.

set -o pipefail
mysqldump -u root ma_base | gzip > ma_base.sql.gz || echo "ÉCHEC de la sauvegarde"

Un dump arrivé à son terme se termine par la ligne -- Dump completed. Vérifier cette ligne, en plus de l'intégrité de la compression, permet de détecter un fichier tronqué.

# Intégrité de la compression
gzip -t ma_base.sql.gz

# Le dump va-t-il jusqu'au bout ?
zcat ma_base.sql.gz | tail -1
# -- Dump completed on 2026-07-23 2:00:14

Un script de sauvegarde qui signale les échecs

Les contrôles précédents peuvent être réunis dans un court script appelé par cron à la place de la commande directe.

#!/bin/bash
# /usr/local/bin/backup-mariadb.sh  (chmod 700)
set -euo pipefail

BASE="ma_base"
DEST="/var/backups/mysql"
RETENTION=7
FICHIER="$DEST/${BASE}_$(date +%F_%H%M).sql.gz"

mkdir -p "$DEST"

mariadb-dump --defaults-file=/root/.my.cnf \
  --single-transaction --quick --routines --triggers --events \
  "$BASE" | gzip > "$FICHIER"

# Contrôles : archive lisible et dump terminé
gzip -t "$FICHIER"
zcat "$FICHIER" | tail -1 | grep -q '^-- Dump completed' \
  || { echo "Dump tronqué : $FICHIER" >&2; exit 1; }

# Rotation : on ne purge qu'une fois la nouvelle sauvegarde validée
find "$DEST" -name "${BASE}_*.sql.gz" -mtime +$RETENTION -delete

echo "OK $(du -h "$FICHIER" | cut -f1) $FICHIER"

0 2 * * * /usr/local/bin/backup-mariadb.sh >> /var/log/backup-mariadb.log 2>&1

La purge ne s'exécute qu'après validation du nouveau fichier. Grâce à set -e, le script s'arrête avant la rotation si un contrôle échoue et conserve les sauvegardes précédentes.

Sauvegarder aussi les utilisateurs et leurs privilèges

mysqldump ma_base n'exporte que la base demandée. Les comptes, les informations d'authentification et les privilèges sont stockés dans la base système mysql. Après une réinstallation, restaurer uniquement le dump applicatif rétablit donc les données, mais pas les comptes nécessaires à l'application.

# MariaDB 10.7 et suivants : export dédié des comptes et de leurs droits
mariadb-dump --system=users > utilisateurs.sql

# Équivalent portable : générer les SHOW GRANTS de tous les comptes
mariadb -N -B -e \
  "SELECT CONCAT('SHOW GRANTS FOR ''', user, '''@''', host, ''';') \
   FROM mysql.global_priv WHERE user <> ''" \
  | mariadb -N -B | sed 's/$/;/' > grants.sql

Restaurer une seule table depuis un dump complet

Une erreur de manipulation peut ne concerner qu'une table. Restaurer l'ensemble du dump écraserait les modifications effectuées depuis la sauvegarde. Comme un dump SQL est un fichier texte, la partie correspondante peut être extraite seule.

# Extraire les instructions relatives à la seule table « commandes »
zcat ma_base_2026-07-05.sql.gz | awk '
  /^-- Table structure for table/ { garde = ($6 == "`commandes`") }
  garde
' > commandes.sql

Une méthode plus sûre et plus lisible consiste à restaurer d'abord le dump dans une base de travail, puis à recopier uniquement la table concernée.

mariadb -u root -p -e "CREATE DATABASE restauration;"
zcat ma_base_2026-07-05.sql.gz | mariadb -u root -p restauration
mariadb-dump -u root -p restauration commandes | mariadb -u root -p ma_base
mariadb -u root -p -e "DROP DATABASE restauration;"

Accélérer la restauration d'un gros dump

Restaurer un dump est généralement plus long que le produire : pendant l'import, le serveur écrit les données, met à jour les index et vérifie les contraintes. Sur une base volumineuse, les réglages suivants réduisent une partie de ce coût.

-- Fichier acceleration.sql, à concaténer avant le dump
SET autocommit = 0;
SET unique_checks = 0;
SET foreign_key_checks = 0;

{ cat acceleration.sql; zcat ma_base.sql.gz; \
  echo "SET foreign_key_checks = 1; SET unique_checks = 1; COMMIT;"; } \
  | mariadb -u root -p ma_base

Ces réglages sont réservés à la restauration d'un dump cohérent dans une base vide. Sur une base en service, la désactivation des contrôles peut laisser entrer des données qui enfreignent les contraintes.

Quand le dump logique ne suffit plus : mariadb-backup

mysqldump recrée la base instruction par instruction. Sur de gros volumes, cette opération peut prendre plusieurs heures. Une sauvegarde physique, au contraire, copie directement les fichiers de données pendant que le serveur fonctionne et se restaure en les remettant en place.

apt install mariadb-backup -y

# Sauvegarde complète à chaud
mariadb-backup --backup --target-dir=/var/backups/full --user=root --password='...'

# Rendre la copie cohérente (rejoue le journal de transactions)
mariadb-backup --prepare --target-dir=/var/backups/full

# Sauvegarde incrémentale, basée sur la précédente
mariadb-backup --backup --target-dir=/var/backups/inc1 \
  --incremental-basedir=/var/backups/full --user=root --password='...'

Pour la restauration, le serveur doit être arrêté, car le répertoire de données est remplacé :

systemctl stop mariadb
mv /var/lib/mysql /var/lib/mysql.old        # on conserve l'ancien répertoire
mariadb-backup --copy-back --target-dir=/var/backups/full
chown -R mysql:mysql /var/lib/mysql          # étape systématiquement oubliée
systemctl start mariadb

En contrepartie, une copie physique reste liée à la version du serveur et à son architecture, alors qu'un dump SQL est inspectable et plus facilement portable d'une version à l'autre.

Revenir à un instant précis avec les journaux binaires

Avec une sauvegarde quotidienne à 2 h, un incident à 17 h peut faire perdre jusqu'à quinze heures de modifications. Les journaux binaires enregistrent toutes les modifications au fil de l'eau. Associés au dernier dump, ils permettent de rejouer l'activité jusqu'à l'instant qui précède l'erreur.

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mariadb]
log_bin = /var/log/mysql/mysql-bin
expire_logs_days = 14

Le dump doit enregistrer sa position dans le journal afin de déterminer le point de départ de la relecture :

mariadb-dump --single-transaction --source-data=2 --all-databases \
  | gzip > full_$(date +%F).sql.gz
# La position est inscrite en commentaire dans le dump :
# -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=1074;

La restauration suit alors deux étapes : réinjecter le dump, puis rejouer les journaux jusqu'à l'instant choisi.

# 1) restaurer la dernière sauvegarde complète
zcat full_2026-07-22.sql.gz | mariadb -u root -p

# 2) rejouer les journaux jusqu'à la minute qui précède l'incident
mariadb-binlog --start-position=1074 \
  --stop-datetime="2026-07-23 16:59:00" \
  /var/log/mysql/mysql-bin.0000{42,43,44} \
  | mariadb -u root -p

Avant cette seconde étape, l'inspection du journal permet de repérer la requête fautive et de choisir le point d'arrêt :

mariadb-binlog --base64-output=DECODE-ROWS --verbose \
  --start-datetime="2026-07-23 16:00:00" /var/log/mysql/mysql-bin.000044 | less

Erreurs fréquentes à la restauration

Message d'erreur	Cause probable	Correctif
MySQL server has gone away	Une instruction du dump dépasse la taille de paquet autorisée, notamment avec des colonnes BLOB ou LONGTEXT	mariadb --max-allowed-packet=512M -u root -p ma_base < dump.sql
Access denied; you need SUPER privilege	Le dump contient des vues ou des routines associées, par la clause DEFINER, à un compte absent	sed -E 's/DEFINER=[^]+@[^]+//g' dump.sql > dump_clean.sql
Unknown table 'COLUMN_STATISTICS'	Le dump a été créé avec le client mysqldump de MySQL 8 pour un serveur MariaDB	Ajouter --column-statistics=0 au dump
Unknown collation: 'utf8mb4_uca1400_ai_ci'	Le dump provient de MariaDB 11.x et est restauré sur une version antérieure	Créer un dump compatible avec l'ancienne version au moyen de --compatible, ou remplacer la collation par utf8mb4_general_ci
Table doesn't exist sur des clés étrangères	Une table est restaurée avant celle dont dépendent ses clés étrangères	Encadrer la restauration de SET foreign_key_checks = 0;

Tester, externaliser et protéger les sauvegardes

Seule une restauration régulière, par exemple chaque mois dans une base tampon, valide le fonctionnement de la chaîne de bout en bout.

Une copie conservée sur le serveur qu'elle protège disparaît avec lui en cas de panne, de vol ou de sinistre. La règle 3-2-1 — trois copies, sur deux supports, dont une hors site — évite ce point de défaillance unique.

Enfin, une copie hors site qui reste accessible en écriture depuis un serveur compromis peut être supprimée ou chiffrée. Pour résister à cette compromission, elle doit être verrouillée en écriture pendant toute sa durée de rétention. Ce principe est détaillé dans construire une véritable archive inaltérable.

Maintenance, diagnostic et optimisation

SHOW PROCESSLIST;                         -- Requêtes en cours d'exécution
SHOW STATUS LIKE 'Threads_connected';     -- Connexions actives
SHOW VARIABLES LIKE 'max_connections';    -- Valeur d'un paramètre du serveur
EXPLAIN SELECT * FROM clients WHERE nom = 'Ada Lovelace';  -- Plan d'exécution (l'index est-il utilisé ?)
ANALYZE TABLE clients;                    -- Met à jour les statistiques d'index
OPTIMIZE TABLE clients;                   -- Défragmente et réordonne la table
CHECK TABLE clients;                      -- Vérifie l'intégrité
REPAIR TABLE clients;                     -- Répare (surtout utile en MyISAM)

# Vérifier et réparer toutes les tables depuis le shell
mysqlcheck -u root -p --all-databases --check
mysqlcheck -u root -p --all-databases --auto-repair --optimize

Si le mot de passe root est perdu, on redémarre MariaDB en mode sans privilèges pour le réinitialiser :

sudo systemctl stop mariadb
sudo mysqld_safe --skip-grant-tables --skip-networking &
mysql -u root

-- Une fois connecté sans mot de passe :
FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NouveauMotDePasseRoot';

# Puis on arrête le mode dégradé et on relance normalement
sudo kill "$(pgrep mysqld)"
sudo systemctl start mariadb

phpMyAdmin

Accès via http://votre_ip/phpmyadmin.

apt install phpmyadmin -y

apt install pwgen      # générateur de mots de passe en ligne de commande
pwgen -syB 24 1
# -s → mode sécurisé (cryptographique)
# -y → inclure des caractères spéciaux
# -B → pas de caractères ambigus (0, O, l, 1...)

À la question « Faut-il configurer la base de données de phpMyAdmin avec dbconfig-common ? », répondre non permet de conserver la maîtrise de la configuration sans créer d'utilisateurs ou de bases superflus.

-- Accès : http://IP/phpmyadmin/
-- mysql -u root -p

CREATE USER 'admin'@'localhost' IDENTIFIED BY '+@%Xw7YVd5.ceO7uvJ_]';
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Générer une clef blowfish_secret pour phpMyAdmin

blowfish_secret sert à sécuriser les cookies ; cette clef est indispensable au bon fonctionnement de phpMyAdmin en mode sécurisé. Elle doit comporter au minimum 32 caractères et être aléatoire.

blowfish=$(pwgen -syB 32 1)
echo "\$cfg['blowfish_secret'] = '$blowfish';"
# ou avec nano :
nano /var/lib/phpmyadmin/blowfish_secret.inc.php

Thèmes alternatifs pour phpMyAdmin (mode sombre)

Quelques dépôts de thèmes sombres :

• https://github.com/pma-theme/metronome-dark
• https://github.com/evilpie/phpmyadmin-dark-theme
• https://github.com/PMA-Theme-Generator/themes

cd /usr/share/phpmyadmin/themes/
apt install git -y
git clone https://github.com/evilpie/phpmyadmin-dark-theme.git darkmode
systemctl reload apache2
nano /etc/phpmyadmin/config.inc.php

$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = 'phpmyadmin';
$cfg['Servers'][$i]['password'] = 'your_password';

$cfg['UploadDir'] = '';
$cfg['MaxFileSize'] = 16777216; // 16 MB en octets
$cfg['ExecTimeLimit'] = 300;    // 5 minutes

Privilèges et gestion des bases

-- mariadb
GRANT ALL PRIVILEGES ON *.* TO 'phpmyadmin'@'localhost' WITH GRANT OPTION;
SHOW GRANTS FOR 'phpmyadmin'@'localhost';
ALTER USER 'phpmyadmin'@'localhost' IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON *.* TO 'phpmyadmin'@'localhost' WITH GRANT OPTION;
CREATE USER 'doc_user'@'localhost' IDENTIFIED BY 'doc_password';
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'doc_user'@'localhost';
FLUSH PRIVILEGES;
CREATE DATABASE testdb;

systemctl restart mariadb
systemctl restart apache2
mariadb -u phpmyadmin -p

Désinstaller phpMyAdmin

apt-get remove --purge phpmyadmin
apt-get autoremove
apt-get autoclean
rm -rf /usr/share/phpmyadmin /var/lib/phpmyadmin /etc/phpmyadmin
systemctl restart apache2