Exploitation des bases de données

L’exploitation des bases de données combine la santé du moteur et l’infrastructure qui rend le moteur utilisable : disponibilité du nœud Storage, stockage, liens des liaisons, connectivité des charges de travail et identité d’accès. Surveillez toutes ces couches avant de traiter l’échec d’une requête applicative comme un incident du moteur.

Protégez d’abord les données, puis rétablissez le chemin client avec le plus petit changement qui fonctionne. Une reprise est terminée lorsque le chemin client d’origine fonctionne, que la cause est connue, que les éléments de preuve sont conservés et que tout accès ou toute exposition temporaire est retiré.

Convenez de l’objectif de point de reprise (RPO), de l’objectif de temps de reprise (RTO), de la responsabilité de l’escalade et des preuves de restauration avant que la base ne devienne critique. La supervision et les contrôles de redémarrage réduisent le temps de diagnostic, mais ne remplacent pas un plan de restauration des données testé.

Ce qu’il faut surveiller

Pour une base de données managée en cours d’exécution, surveillez la santé du moteur, la disponibilité du nœud Storage, la croissance du stockage, la latence, la pression sur les connexions, les résultats des opérations récentes et l’état de chaque liaison. La vue de détail de la base expose aussi les métriques propres au moteur, les journaux et les fonctions Explorer ou Console éligibles.

Les connexions externes bénéficient des mêmes vérifications de santé, métriques du moteur, Explorer et Console, mais sans journaux du moteur, actions de cycle de vie ni liaisons, car Opfield n’exécute pas le moteur. Si une connexion externe affiche TLS certificate is not verified, ajoutez son certificat de CA ou utilisez Test and enable verification ; voir Vérification des certificats TLS. Voir Bases de données managées et externes en un coup d’œil.

Une instance en pause désactive intentionnellement le comportement normal de santé, de métriques, d’Explorer et de Console jusqu’à sa reprise. Ne déclenchez pas d’alerte sur cette absence attendue comme s’il s’agissait d’une panne du moteur ; consignez la fenêtre de pause et vérifiez que le service revient à Ready avant de réactiver les charges de travail dépendantes.

Journaux, Explorer et Console

Utilisez les journaux pour classer les erreurs de démarrage, de stockage, d’authentification, de permissions et de reprise. Lisez l’étape d’une opération avant d’apporter une correction, en particulier après un provisionnement, un redimensionnement ou une suppression. N’utilisez l’Explorer ou la Console qu’avec la permission de lecture, d’écriture ou d’administration requise, et évitez les requêtes de production non bornées via une interface d’opérateur.

L’Explorer parcourt les schémas et les lignes pour PostgreSQL et ClickHouse ; les modifications de schéma, comme l’ajout ou la modification de colonnes, sont disponibles pour PostgreSQL. Les stockages clé-valeur utilisent la Console de commandes. Chaque instruction de la Console est classée comme une opération de lecture, d’écriture ou d’administration et nécessite respectivement databases:query:read, databases:query:write ou databases:query:admin.

Les sauvegardes de configuration d’Opfield ne contiennent pas les données des bases. Sauvegardez les données avec une politique de sauvegarde, conservez les résultats des restaurations et testez les restaurations sur une cible distincte. Planifiez une sauvegarde avant tout travail de cycle de vie destructif, tout redimensionnement important ou toute migration impliquant des données persistantes. Le jeu de reprise du plan de contrôle est décrit dans Mises à jour, sauvegardes et restauration.

Sur une instance PostgreSQL managée, la base de données et chaque objet applicatif qu’elle contient appartiennent au rôle applicatif de l’instance, et chaque liaison agit sous ce rôle. La Console SQL exécute aussi les instructions d’écriture et d’administration sous le rôle applicatif ; une table créée ou remplie depuis la Console est donc immédiatement utilisable par chaque liaison ; les instructions en lecture seule conservent un principal en lecture seule. Pour une instruction qui nécessite le principal de contrôle propre à Opfield, comme la création d’un rôle ou d’une extension qui requiert un superutilisateur, commencez la requête par RESET ROLE ; les objets qu’elle crée sont remis au rôle applicatif juste après. Opfield répare aussi cette propriété chaque fois qu’il crée ou réconcilie une liaison, ce qui corrige les tables créées depuis la Console par des versions antérieures. La réparation ne modifie que des objets de la base applicative et ignore les schémas système et les membres d’extensions. Les liaisons restent prêtes pendant la reconnexion du nœud de la base.

La Console interactive est volontairement limitée par un budget d’exécution partagé entre les instructions. C’est un outil d’opérateur, et non un exécuteur de migrations par lots. Préférez des outils de migration versionnés pour les modifications de schéma et la maintenance de longue durée, et utilisez une identité en lecture seule ou à privilèges restreints chaque fois que possible. Une déconnexion du navigateur ne doit pas être considérée comme la preuve qu’une requête a été annulée ; vérifiez l’état résultant du moteur avant de réessayer.

La collecte de supervision s’exécute en arrière-plan. Opfield démarre la collecte après l’amorçage et lorsqu’une base de données managée devient prête ; l’ouverture de la page de détail de la base n’en est pas le déclencheur. Lors d’une première visite, un graphique peut attendre le premier échantillon réel ou une requête historique, mais l’interface doit distinguer l’absence de données d’un échantillon sain.

Rétablir une liaison de charge de travail en échec

Vérifiez une liaison en échec dans cet ordre :

1. Confirmez que la base de données managée est Ready et que son nœud Storage est en ligne.
2. Confirmez que le nœud Docker cible et la charge de travail sont en ligne et signalent un état à jour.
3. Examinez l’état souhaité durable de la liaison et sa dernière opération.
4. Vérifiez que le lien de la liaison sur le connecteur secure-link partagé du nœud est réconcilié et que la charge de travail est rattachée au réseau du lien.
5. Vérifiez le principal distinct de la liaison dans le moteur et ses permissions prévues.
6. Vérifiez la configuration reçue par la charge de travail et les journaux de l’application.

Préférez la réconciliation ou une relance ciblée après avoir corrigé la cause racine. Ne supprimez pas manuellement les objets réseau ou les identités de moteur appartenant à Opfield ; cela peut transformer un problème de lien récupérable en incohérence d’état ou en problème de nettoyage orphelin.

Changements opérationnels et suppression

La mise en pause et la reprise, le redémarrage, le redimensionnement, la rotation des identifiants, la rotation des certificats, la publication directe, la suppression d’une liaison et la suppression d’une base doivent chacun être suivis de la vérification appropriée : santé du moteur, connexion client, état de la route ou de l’écouteur, journaux, métriques et résultat de tâche enregistré. La publication directe est facultative ; surveillez-la comme un chemin de client externe, séparément des liaisons privées.

Lors de la suppression d’une base, retirez ou migrez d’abord les liaisons et attendez le nettoyage de leurs liens et identités. Une suppression en échec doit rester dans l’historique des opérations d’Opfield pour la reprise. Ne forcez pas la suppression du stockage ou des utilisateurs au niveau du démon ou du moteur, sauf si une procédure de reprise explicite l’exige.

Runbook de sauvegarde et de restauration

Définissez un objectif de point de reprise et un objectif de temps de reprise propres au moteur avant toute utilisation en production. Configurez une politique de sauvegarde avec une destination de stockage hors du nœud et un nombre de sauvegardes à conserver. Conservez les sauvegardes hors du nœud Storage, chiffrez-les, consignez la version du moteur et la commande de restauration, et testez-les sur une cible isolée. Une sauvegarde réussie sans test de restauration réussi ne constitue pas une preuve de reprise.

Pour un exercice de restauration :

1. Créez une cible distincte avec un moteur compatible et une capacité de stockage suffisante.
2. Restaurez la sauvegarde sans écraser l’instance active ; la restauration Opfield crée par défaut une nouvelle base managée et exige une cible vide.
3. Exécutez des contrôles d’intégrité et des requêtes applicatives représentatives.
4. Recréez les accès avec de nouvelles liaisons ou des identités client étroitement délimitées.
5. Comparez le nombre de lignes, de clés et de tables ainsi que les invariants applicatifs.
6. Consignez la durée, les étapes manuelles et toute contrainte de version découverte.

Les sauvegardes Opfield sont des sauvegardes natives planifiées, et non une restauration à un instant donné : le calendrier détermine la quantité de données qu’une restauration peut faire perdre. Conservez au moins une destination de sauvegarde hors site. La réplication vers d’autres nœuds Storage est disponible en Business et Enterprise via Availability.

Classification des incidents

Classez avant de modifier l’état : les pannes du plan de contrôle affectent les tâches ou la réconciliation ; les pannes de nœud affectent la fraîcheur du démon et l’exécution locale ; les pannes du moteur apparaissent dans les journaux et la santé de la base ; les pannes de stockage affectent le montage ou la capacité ; les pannes de liaison affectent l’état de l’écouteur ou du principal ; les pannes applicatives apparaissent une fois la connectivité établie. Cet ordre évite de redémarrer un moteur sain pour résoudre une erreur de permission applicative.

Après la reprise, vérifiez le chemin client d’origine, et pas seulement l’écran d’administration. Confirmez une vraie requête, les permissions attendues, une collecte de santé stable, et qu’aucune publication directe temporaire, aucun rôle élevé, aucun jeton de débogage ni aucune modification réseau manuelle ne subsiste.