Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Créer un compte par application ou besoin distinct. Limiter les droits aux bases et opérations nécessaires, ainsi que les sources réseau autorisées lorsque le moteur le permet. Ne pas utiliser le compte administrateur de la base dans la configuration quotidienne d’un site.
Une base interne n’a généralement pas à écouter sur Internet. Filtrer les accès au port depuis les serveurs applicatifs et le poste d’administration autorisés. Le réseau et les droits de la base constituent deux niveaux complémentaires ; l’un ne remplace pas l’autre.
Relever la configuration applicative, les règles réseau, les autorisations de connexion et les éventuelles vérifications TLS. Un changement de VLAN peut modifier l’adresse source vue par la base ; un compte autorisé depuis l’ancienne adresse peut alors être refusé. Préparer la nouvelle autorisation limitée, tester, puis retirer l’ancienne après validation.
Ne pas réinitialiser le compte root ou élargir les droits à toutes les sources parce qu’une connexion échoue. Identifier le message exact et utiliser un compte d’administration déjà autorisé. Les secrets doivent rester dans un coffre ou un fichier protégé, jamais dans une page publique ou un historique de commande partagé.
Choisir l’outil natif adapté au moteur et à la cohérence attendue. Inclure comptes et paramètres nécessaires selon le plan de reprise, sans diffuser leurs secrets. Une copie brute des fichiers pendant l’activité peut être invalide. Tester la restauration sur une instance isolée et vérifier des données métier, pas seulement la création de la base.
Surveiller espace, erreurs, connexions, requêtes lentes et durée des sauvegardes. Appliquer les correctifs selon le cycle supporté. Les versions majeures demandent une procédure spécifique et une sauvegarde vérifiée. Éviter les changements simultanés de moteur, réseau et application : ils compliquent fortement l’identification d’une panne.
Une application a besoin de l’hôte, du port ou socket, du nom de base, de l’utilisateur et du secret. Le mode de chiffrement peut ajouter CA et vérification du nom. localhost peut sélectionner un socket Unix dans certains clients, alors que 127.0.0.1 force généralement TCP ; ne pas les considérer comme strictement équivalents.
| Paramètre | Exemple pédagogique | Choix |
|---|---|---|
| Host | db.lab.home.arpa | Serveur privé joignable uniquement depuis sources autorisées |
| Port | Port du moteur réellement configuré | Ne pas l’exposer directement sur WAN |
| Database | app_gestion | Base distincte par application si architecture adaptée |
| User | compte dédié | Pas root ni un compte partagé par toutes les applications |
| Source autorisée | IP de l’application | Éviter % sans nécessité et contrôle réseau |
| TLS | Selon réseau et politique, avec validation | Chiffrer sans vérifier l’identité laisse une faiblesse |
'utilisateur'@'hote' désigne une identité avec une origine autorisée. Lorsqu’un CT change de VLAN, le compte correspondant à l’ancienne IP peut ne plus convenir. Créer/adapter l’autorisation à partir d’un compte administrateur réellement habilité, tester la nouvelle application puis retirer l’ancienne permission selon procédure. Le compte root Linux n’est pas automatiquement un administrateur SQL.
Commandes SQL de lecture depuis une session autorisée :
SELECT VERSION();
SELECT USER(), CURRENT_USER();
SHOW GRANTS;
SHOW VARIABLES LIKE 'bind_address';
USER() et CURRENT_USER() permettent de distinguer l’identité présentée de celle utilisée pour les privilèges. SHOW GRANTS examine les droits du compte courant. Ne pas afficher les tables de comptes complètes dans un ticket public.
Lister les opérations de l’application. Son runtime peut avoir des droits de lecture/écriture sur sa seule base ; une migration peut nécessiter temporairement des opérations DDL supplémentaires selon l’éditeur. Ne pas imposer un ensemble minimal incompatible avec les mises à jour, mais documenter cette différence. Éviter les droits globaux, accès fichiers et délégation inutiles.
Le pare-feu, l’adresse d’écoute et les comptes SQL se complètent. Une base liée à toutes les interfaces n’est pas nécessairement publique si le réseau filtre, mais restreindre l’écoute réduit l’exposition accidentelle. Tester depuis la source autorisée et depuis une source interdite après modification.
Une sauvegarde logique exporte structures et données ; elle facilite certaines migrations mais peut être longue. Une copie physique dépend davantage du moteur et de sa version. Copier les fichiers d’une base active comme de simples documents n’assure pas leur cohérence.
Pour un export transactionnel MariaDB, vérifier moteurs de tables et absence d’opérations incompatibles pendant l’export. --single-transaction ne garantit pas à lui seul les tables non transactionnelles. Inclure procédures, événements, triggers et autres objets réellement utilisés selon les options de l’outil. Fournir les secrets par mécanisme protégé, pas directement dans la ligne de commande ou l’historique.
Restaurer sur une instance isolée compatible, avec les bons encodages/collations. Contrôler erreurs d’import, volumes, objets et quelques opérations métier. Les comptes système ne se migrent pas aveuglément par copie des tables internes entre versions majeures. Vérifier les recommandations du moteur.
Pour diagnostiquer la lenteur, commencer par connexions, requêtes lentes et plans d’exécution autorisés. Un index peut améliorer une lecture mais coûte espace et écritures. Sauvegarder et tester avant changement de schéma ; ne pas régler les buffers sur un pourcentage de la RAM de l’hôte si la base tourne dans un CT limité.