Gérer et surveiller AlloyDB Omni

Cette page explique comment gérer les rôles utilisateur AlloyDB Omni, surveiller l'activité de votre serveur AlloyDB Omni, et mettre à jour ou supprimer votre installation AlloyDB Omni.

Gérer les rôles utilisateur

AlloyDB Omni utilise le même ensemble de rôles utilisateur PostgreSQL prédéfinis qu'AlloyDB, avec les différences suivantes:

• AlloyDB Omni inclut un rôle de super-utilisateur nommé alloydbadmin et un rôle non super-utilisateur nommé alloydbmetadata.

• L'utilisateur postgres par défaut dispose du rôle de super-utilisateur.

• Tous les autres rôles utilisateur prédéfinis n'ont aucun droit. Elles sont réservées à une utilisation future potentielle.

Comme pour AlloyDB, il est recommandé de suivre ces étapes lors de la configuration d'une base de données:

1. Définissez ou importez vos bases de données à l'aide du rôle utilisateur postgres. Dans une nouvelle installation, ce rôle dispose des droits de super-utilisateur et ne nécessite aucun mot de passe.

2. Créez des rôles utilisateur disposant du niveau d'accès approprié aux tables de votre application, à l'aide du rôle utilisateur postgres.

3. Configurez votre application pour qu'elle se connecte à la base de données à l'aide de ces nouveaux rôles à accès limité.

Vous pouvez créer et définir autant de rôles utilisateur que nécessaire. Ne modifiez ni ne supprimez aucun des rôles utilisateur fournis avec AlloyDB Omni.

Pour en savoir plus, consultez la section Gérer les rôles utilisateur AlloyDB.

Surveiller AlloyDB Omni

Surveiller votre installation AlloyDB Omni consiste à lire et à analyser ses fichiers journaux.

AlloyDB Omni exécuté sur Kubernetes dispose également d'un ensemble de métriques de base disponibles en tant que points de terminaison Prometheus. Pour obtenir la liste des métriques disponibles, consultez la section Métriques AlloyDB Omni.

Serveur unique

Par défaut, pour récupérer les journaux AlloyDB Omni, exécutez:

 docker logs CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Pour configurer le comportement de journalisation d'AlloyDB Omni, consultez Personnaliser votre installation d'AlloyDB Omni.

Kubernetes

Trouver les fichiers journaux de votre cluster de base de données

Vous trouverez les fichiers postgresql.audit et postgresql.log dans le système de fichiers du pod de base de données. Pour y accéder, procédez comme suit:

1. Définissez une variable d'environnement contenant le nom du pod de la base de données.

   export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

   Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données. Il s'agit du même nom de cluster de base de données que vous avez déclaré lors de sa création.

2. Exécutez une interface système sur le pod de base de données en tant que racine.

   kubectl exec ${DB_POD} -it -- /bin/bash

3. Recherchez les fichiers journaux dans le répertoire /obs/diagnostic/:

   • /obs/diagnostic/postgresql.audit
   • /obs/diagnostic/postgresql.log

Répertorier les services de surveillance

v1.0

Lorsque vous créez un cluster de base de données, AlloyDB Omni crée le service de surveillance suivant pour chaque instance CR du cluster de base de données dans le même espace de noms:

al-INSTANCE_NAME-monitoring-system

Pour lister les services de surveillance, exécutez la commande suivante.

kubectl get svc -n NAMESPACE | grep monitoring

Remplacez NAMESPACE par un espace de noms auquel appartient votre cluster.

L'exemple de réponse suivant montre les services al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system et al-4bc0-dbc-monitoring-system. Chaque service correspond à une instance.

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

Version < 1.0

Lorsque vous créez un cluster de base de données, AlloyDB Omni crée les services de surveillance suivants dans le même espace de noms que le cluster de base de données:

• DB_CLUSTER-monitoring-db

• DB_CLUSTER-monitoring-system

Pour lister les services de surveillance, exécutez la commande suivante.

kubectl get svc -n NAMESPACE | grep monitoring

Remplacez NAMESPACE par un espace de noms auquel appartient votre cluster.

L'exemple de réponse suivant affiche le service al-2953-dbcluster-foo7-monitoring-system et al-2953-dbcluster-foo7-monitoring-db.

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

Afficher les métriques Prometheus depuis la ligne de commande

Le port 9187 est nommé metricsalloydbomni pour tous les services de surveillance.

1. Configurez le transfert de port de votre environnement local vers le service de surveillance.

   kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
   

   Remplacez les éléments suivants :

   • MONITORING_SERVICE: nom du service de surveillance que vous souhaitez transférer (par exemple, al-1060-dbc-monitoring-system).

   • NAMESPACE: espace de noms auquel appartient votre cluster.

   • MONITORING_METRICS_PORT: port TCP local disponible.

   La réponse suivante indique que les services sont transférés.

   Forwarding from 127.0.0.1:9187 -> 9187
   Forwarding from [::1]:9187 -> 9187
   

2. Pendant l'exécution de la commande précédente, vous pouvez accéder aux métriques de surveillance via HTTP sur le port que vous avez spécifié. Par exemple, vous pouvez utiliser curl pour afficher toutes les métriques au format texte brut:

   curl http://localhost:MONITORING_METRICS_PORT/metrics
   

Afficher les métriques à l'aide de l'API Prometheus

La clé de libellé alloydbomni.internal.dbadmin.goog/task-type et le port metricsalloydbomni sont disponibles par défaut pour tous les services de surveillance dans AlloyDB Omni. Vous pouvez les utiliser avec une seule ressource personnalisée serviceMonitor pour sélectionner tous les services de tous les espaces de noms de votre cluster de bases de données.

Pour en savoir plus sur l'utilisation de l'API Prometheus, consultez la documentation de l'opérateur Prometheus.

Voici un exemple de champ spec de la ressource personnalisée serviceMonitor qui inclut la clé de libellé alloydbomni.internal.dbadmin.gdc.goog/task-type et le port metricsalloydbomni. La ressource personnalisée serviceMonitor surveille et collecte tous les services Kubernetes dans tous les espaces de noms.

Pour en savoir plus sur la définition complète de ServiceMonitor, consultez la définition de la ressource personnalisée ServiceMonitor .

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

Version < 1.0

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

Mettre à niveau AlloyDB Omni

Pour passer d'AlloyDB Omni 15.5.2 ou version antérieure à la version 15.5.4, suivez les instructions de la section Passer d'une version antérieure d'AlloyDB Omni à la dernière version.

Remarque :La version 15.5.3 est une version preview d'AlloyDB Omni.

Pour passer de la version 15.5.4 ou ultérieure:

1. Redémarrez AlloyDB Omni à l'aide d'une nouvelle version d'image.

2. Veillez à spécifier le même chemin d'accès que celui utilisé dans les versions précédentes d'AlloyDB Omni pour votre répertoire de données.

Désinstaller AlloyDB Omni

Serveur unique

Pour désinstaller AlloyDB Omni, arrêtez et supprimez le conteneur AlloyDB Omni à l'aide de la commande suivante:

 docker container stop CONTAINER_NAME
 docker container rm CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom de votre conteneur AlloyDB Omni.

Attention :Vous devez monter un répertoire de données externe pour que les données de votre base de données ne soient pas supprimées lorsque vous supprimez le conteneur.

Vous pouvez déplacer, archiver ou supprimer un répertoire de données externe selon que vous souhaitez conserver vos données et comment vous souhaitez le faire après avoir désinstallé AlloyDB Omni.

Kubernetes

Supprimer votre cluster de base de données

Pour supprimer votre cluster de base de données, définissez isDeleted sur true dans son fichier manifeste. Pour ce faire, exécutez la commande suivante.

Attention :L'exécution de la commande suivante efface définitivement toutes les données stockées dans le cluster de base de données nommé.

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

Remplacez DB_CLUSTER_NAME par le nom de votre cluster de bases de données. Il s'agit du même nom de cluster de base de données que vous avez déclaré lors de sa création.

Désinstaller l'opérateur AlloyDB Omni

Attention :En suivant ces étapes, vous supprimez définitivement toutes les bases de données AlloyDB Omni de votre cluster Kubernetes.

Pour désinstaller l'opérateur Kubernetes AlloyDB Omni de votre cluster Kubernetes, procédez comme suit:

1. Supprimez tous vos clusters de bases de données:

   for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
   for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
   kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
   done
   done

2. Attendez que l'opérateur Kubernetes AlloyDB Omni supprime tous vos clusters de bases de données. Utilisez la commande suivante pour vérifier si des ressources de base de données restent:

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

3. Supprimez les autres ressources créées par l'opérateur Kubernetes AlloyDB Omni:

   kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

4. Désinstallez l'opérateur Kubernetes AlloyDB Omni:

   helm uninstall alloydbomni-operator --namespace alloydb-omni-system

5. Nettoyez les secrets, les descriptions de ressources personnalisées et les espaces de noms associés à l'opérateur Kubernetes AlloyDB Omni:

   kubectl delete certificate -n alloydb-omni-system --all
   kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
   kubectl delete crd -l alloydb-omni=true
   kubectl delete ns alloydb-omni-system

Redimensionner votre cluster de base de données basé sur Kubernetes

Pour redimensionner le processeur, la mémoire ou le stockage de votre cluster de base de données basé sur Kubernetes, mettez à jour le champ resources des fichiers manifestes qui définissent son pod. L'opérateur AlloyDB Omni applique immédiatement les nouvelles spécifications à votre pod de base de données.

Pour en savoir plus sur la syntaxe du fichier manifeste de l'opérateur AlloyDB Omni, consultez la section Créer un cluster de bases de données.

Les restrictions suivantes s'appliquent à la modification des ressources d'un cluster de base de données en cours d'exécution:

• Vous ne pouvez augmenter la taille d'un disque que si l'storageClass spécifiée est compatible avec l'extension de volume.
• Vous ne pouvez pas réduire la taille d'un disque.