Gérer et surveiller AlloyDB Omni

Sélectionnez une version de la documentation :

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 ne dispose pas de rôle alloydbiamuser.

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

Comme pour AlloyDB, il est recommandé de suivre ces étapes lorsque vous configurez 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 création de bases de données et de rôles, et n'a pas de mot de passe.

  2. Créez des rôles utilisateur disposant du niveau d'accès approprié aux tables de votre application, en utilisant à nouveau le 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 Gérer les rôles utilisateur AlloyDB.

Surveiller AlloyDB Omni

Pour surveiller votre installation AlloyDB Omni, vous devez 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 Métriques AlloyDB Omni.

Serveur unique

AlloyDB Omni enregistre son activité à deux emplacements :

  • AlloyDB Omni enregistre l'activité de la base de données dans data/log/postgres, par rapport au répertoire que vous avez défini dans votre fichier de configuration dataplane.conf.

    Vous pouvez personnaliser le nom et le format de ce fichier journal à l'aide des différentes directives log_* définies dans /var/alloydb/config/postgresql.conf. Pour en savoir plus, consultez Rapports d'erreurs et journalisation.

  • AlloyDB Omni enregistre son activité d'installation, de démarrage et d'arrêt dans /var/alloydb/logs/alloydb.log.

Pour vérifier l'état d'exécution immédiat de votre serveur, consultez Vérifier l'état d'AlloyDB Omni.

Kubernetes

Trouver les fichiers journaux de votre cluster de bases 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 accéder à ces fichiers, procédez comme suit :

  1. Définissez une variable d'environnement contenant le nom du pod de 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 un shell 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

Lister les services de surveillance

v1.0

Lorsque vous créez un cluster de bases de données, AlloyDB Omni crée le service de surveillance suivant pour chaque CR d'instance du cluster de bases 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 bases de données, AlloyDB Omni crée les services de surveillance suivants dans le même espace de noms que le cluster de bases 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 montre le al-2953-dbcluster-foo7-monitoring-system et le service 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 en 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 Prometheus Operator.

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 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

Serveur unique

Ces instructions ne s'appliquent qu'à AlloyDB Omni version 15.2.0 et ultérieure.

Avant de commencer

La version 1.2 ou ultérieure de la CLI AlloyDB Omni doit être installée sur votre machine.

Procéder à la mise à niveau

Pour mettre à niveau votre installation AlloyDB Omni, exécutez la commande suivante :

sudo alloydb database-server upgrade

Kubernetes

La procédure de mise à niveau d'AlloyDB Omni dans Kubernetes dépend de la version d'AlloyDB Omni que vous exécutez et de la version vers laquelle vous effectuez la mise à niveau.

Déterminer vos numéros de version actuels

Pour vérifier la version d'AlloyDB Omni utilisée par votre cluster de bases de données, exécutez la commande suivante :

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'

Remplacez les éléments suivants :

  • DB_CLUSTER_NAME : 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.

  • NAMESPACE : espace de noms Kubernetes de votre cluster de bases de données.

Si vous exécutez la version 1.0.0 ou ultérieure de l'opérateur AlloyDB Omni, cette commande affiche la version d'AlloyDB Omni utilisée par votre cluster de bases de données.

Pour vérifier la version de l'opérateur AlloyDB Omni installé sur votre cluster Kubernetes, exécutez la commande suivante :

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'

Si vous exécutez la version 1.0.0 ou une version ultérieure de l'opérateur AlloyDB Omni, cette commande affiche le numéro de version de l'opérateur AlloyDB Omni exécuté sur votre cluster Kubernetes.

Si vous exécutez une version d'AlloyDB Omni Operator antérieure à la version 1.0.0, vous ne pouvez pas effectuer de mise à niveau sur place de votre cluster de bases de données ni de l'AlloyDB Omni Operator. Vous devez suivre les instructions de la section Mettre à niveau un opérateur AlloyDB Omni antérieur à la version 1.0.0.

Sinon, passez à la section suivante.

Déterminer les numéros de version cibles

Si vous exécutez une version de l'opérateur AlloyDB Omni 1.0.0 ou ultérieure, les étapes suivantes dépendent de la version d'AlloyDB Omni vers laquelle vous souhaitez effectuer la mise à niveau. Pour ce faire, vous devez comprendre le numéro de version d'AlloyDB Omni.

Le numéro de version d'AlloyDB Omni comporte trois parties :

  • Numéro de version majeure de sa compatibilité avec PostgreSQL
  • Numéro de version mineure de sa compatibilité PostgreSQL
  • Numéro de version du correctif de cette version d'AlloyDB Omni

Par exemple, la version 15.5.2 d'AlloyDB Omni est la version du correctif 2 d'AlloyDB Omni compatible avec la version 15.5 de PostgreSQL.

Si vous souhaitez passer à une version d'AlloyDB Omni compatible avec une version plus récente de PostgreSQL, vous devez mettre à niveau l'opérateur AlloyDB Omni lui-même, en plus de votre cluster de bases de données. Chaque ensemble de versions AlloyDB Omni compatibles avec une version mineure PostgreSQL spécifique possède son propre numéro de version AlloyDB Omni Operator associé, que vous trouverez dans les notes de version de la version AlloyDB Omni.

Si vous souhaitez uniquement passer à une version corrective plus récente d'AlloyDB Omni, vous pouvez mettre à niveau uniquement votre cluster de bases de données, sans avoir besoin de mettre à niveau l'opérateur AlloyDB Omni lui-même. Vous pouvez passer directement aux instructions de la section Mettre à niveau votre cluster de bases de données.

Sinon, passez à la section suivante.

Mettre à niveau l'opérateur AlloyDB Omni

Pour mettre à niveau l'opérateur AlloyDB Omni :

  1. Définissez les variables d'environnement nécessaires :

    export GCS_BUCKET=alloydb-omni-operator
export OPERATOR_VERSION=OPERATOR_VERSION
export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz

    Remplacez OPERATOR_VERSION par la version de l'opérateur AlloyDB Omni vers laquelle vous effectuez la mise à niveau, par exemple 1.1.0.

  2. Téléchargez la dernière version de l'opérateur AlloyDB Omni :

    gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz

  3. Appliquez les définitions de ressources personnalisées de l'opérateur AlloyDB Omni les plus récentes :

    kubectl apply -f alloydbomni-operator/crds

  4. Mettez à niveau le chart Helm de l'opérateur AlloyDB Omni :

    helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
--namespace alloydb-omni-system \
--atomic \
--timeout 5m

Pour finaliser la mise à niveau de votre AlloyDB Omni Operator en mettant à niveau à la fois votre fichier manifeste Kubernetes et votre cluster de bases de données, suivez les instructions de la section suivante immédiatement après avoir terminé les étapes précédentes.

Mettre à niveau votre cluster de bases de données

Pour mettre à niveau votre cluster de bases de données, mettez à jour les champs suivants dans la section spec du fichier manifeste qui le définit :

  • Définissez databaseVersion sur le numéro de version complet d'AlloyDB Omni vers lequel vous souhaitez mettre à niveau ce cluster de bases de données.

  • Si vous avez également mis à niveau l'opérateur AlloyDB Omni, définissez controlPlaneAgentsVersion sur le numéro de version complet de l'opérateur AlloyDB Omni que vous avez mis à niveau.

Si vous ne mettez à niveau que la version du correctif d'AlloyDB Omni (par exemple, en passant de 15.5.1 à 15.5.2), cette étape est tout ce que vous avez à faire.databaseVersion

Si vous mettez à niveau la version mineure de la compatibilité PostgreSQL (par exemple, en passant de 15.4.1 à 15.5.2 pour databaseVersion), vous devez également mettre à jour controlPlaneAgentsVersion. Dans ce cas, assurez-vous d'avoir suivi les étapes supplémentaires listées dans Mettre à niveau l'opérateur AlloyDB Omni.

Par exemple, l'extrait de fichier manifeste suivant définit un cluster de bases de données exécutant la version 15.5.2 d'AlloyDB Omni Operator, avec la version 1.0.0 d'AlloyDB Omni Operator :

apiVersion: alloydbomni.dbadmin.goog/v1 
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 15.5.2
  controlPlaneAgentsVersion: 1.0.0

Dans cet exemple, pour mettre à niveau le cluster de bases de données afin qu'il exécute la version 15.5.3 d'AlloyDB Omni, remplacez databaseVersion: 15.5.2 par databaseVersion: 15.5.3.

Mettre à niveau un opérateur AlloyDB Omni antérieur à la version 1.0.0

Si vous exécutez une version d'AlloyDB Omni Operator antérieure à la version 1.0.0, la mise à niveau d'une installation AlloyDB Omni basée sur Kubernetes implique la désinstallation, puis la réinstallation d'AlloyDB Omni Operator après avoir sauvegardé vos données. Procédez comme suit :

  1. Répertoriez tous vos clusters de bases de données :

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

  2. Pour chaque cluster de bases de données, utilisez la commande pg_dumpall pour exporter toutes ses données.

  3. Désinstallez l'opérateur AlloyDB Omni. Cela inclut la suppression de tous vos clusters de bases de données.

  4. Réinstallez l'opérateur AlloyDB Omni. Vous pouvez utiliser les mêmes commandes que celles utilisées pour installer la version précédente de l'opérateur AlloyDB Omni, sans avoir à spécifier de nouveau numéro de version.

  5. Recréez vos clusters de bases de données. Vous pouvez adapter les fichiers manifestes que vous avez utilisés lors de la création de vos clusters de bases de données. Vous devrez peut-être mettre à jour les fichiers pour refléter les modifications apportées à l'API par la version 1.0.0 de l'opérateur AlloyDB Omni, comme l'attribut databaseVersion qui remplace l'ancien attribut version.

  6. Utilisez pg_restore ou la commande \i dans psql pour importer vos données précédemment exportées dans les clusters recréés.

Effectuer le rollback d'une mise à niveau

Ces instructions ne s'appliquent qu'à la version 15.2.1 à 15.5.2 d'AlloyDB Omni. Elles ne s'appliquent pas aux déploiements d'AlloyDB Omni basés sur Kubernetes.

Pour rétablir la version précédemment installée d'AlloyDB Omni, exécutez la commande suivante :

sudo alloydb database-server rollback

Désinstaller AlloyDB Omni

Serveur unique

Pour désinstaller AlloyDB Omni, exécutez la commande suivante :

sudo alloydb database-server uninstall

Votre répertoire de données reste dans votre système de fichiers après la désinstallation d'AlloyDB Omni. Vous pouvez déplacer, archiver ou supprimer ce répertoire, selon que vous souhaitez ou non conserver vos données après la désinstallation d'AlloyDB Omni.

Kubernetes

Supprimer votre cluster de bases de données

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

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

Pour désinstaller l'opérateur AlloyDB Omni Kubernetes 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. Exécutez la commande suivante pour vérifier s'il reste des ressources de base de données :

    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 bases 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 AlloyDB Omni Operator, consultez Créer un cluster de bases de données.

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

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