Cette page présente la documentation de la version 15.5.2 d'AlloyDB Omni. Pour obtenir la documentation de la dernière version d'AlloyDB Omni, cliquez ici.

Cette page a été traduite par l'API Cloud Translation.

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 ne dispose pas d'un rôle alloydbiamuser.
AlloyDB Omni inclut un rôle super-utilisateur nommé alloydbadmin.

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

Définissez ou importez vos bases de données à l'aide du rôle utilisateur postgres. Dans une nouvelle installation, ce rôle dispose d'autorisations de création de bases de données et de rôles, et ne nécessite aucun mot de passe.
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.
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

AlloyDB Omni consigne son activité dans deux emplacements:

AlloyDB Omni consigne 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 la section Signalement et journalisation des erreurs.
AlloyDB Omni consigne 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 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:

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

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

Serveur unique

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

Avant de commencer

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

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 base 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 base 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 base 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 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 antérieure à la version 1.0.0 de l'opérateur AlloyDB Omni, vous ne pouvez pas effectuer de mise à niveau sur place de votre cluster de base de données ni de l'opérateur AlloyDB Omni. Vous devez plutôt suivre les instructions de la section Mettre à niveau à partir d'un opérateur AlloyDB Omni antérieur à la version 1.0.0.

Sinon, passez à la section suivante.

Déterminer vos 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 se compose de trois parties:

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

Par exemple, la version 15.5.2 d'AlloyDB Omni correspond à la version 2 du correctif 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, ainsi que votre cluster de base de données. Chaque ensemble de versions AlloyDB Omni compatibles avec une version mineure PostgreSQL particulière est associé à un numéro de version de l'opérateur AlloyDB Omni, que vous trouverez dans la note de version de la version AlloyDB Omni.

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

Sinon, passez à la section suivante.

Mettre à niveau l'opérateur AlloyDB Omni

Pour mettre à niveau l'opérateur AlloyDB Omni, procédez comme suit:

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

Téléchargez l'opérateur AlloyDB Omni plus récent:

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

Appliquez les définitions de ressources personnalisées plus récentes de l'opérateur AlloyDB Omni:
```
kubectl apply -f alloydbomni-operator/crds
```

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 suivre la mise à niveau de l'opérateur AlloyDB Omni en mettant à niveau à la fois votre fichier manifeste Kubernetes et votre cluster de base 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 base de données

Pour mettre à niveau votre cluster de base 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 base 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 de correctif d'AlloyDB Omni (par exemple, en passant de 15.5.1 à 15.5.2 pour databaseVersion), cette étape est la seule que vous devez effectuer.

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 décrites dans la section Mettre à niveau l'opérateur AlloyDB Omni.

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

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 base 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 à partir d'un opérateur AlloyDB Omni antérieur à la version 1.0.0

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

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

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

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

Avertissement :Ne passez pas cette étape. Si vous n'exportez pas vos données, l'étape suivante les effacera de manière irrécupérable.
Désinstallez l'opérateur AlloyDB Omni. Cela inclut la suppression de tous vos clusters de bases de données.
Réinstallez l'opérateur AlloyDB Omni. Vous pouvez utiliser les mêmes commandes que celles que vous avez 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.
Recréez vos clusters de bases de données. Vous pouvez adapter les mêmes fichiers manifestes que ceux 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 Omni AlloyDB, comme l'attribut databaseVersion qui remplace l'ancien attribut version.
Utilisez pg_restore ou la commande \i dans psql pour importer les 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'aux versions AlloyDB Omni 15.2.1 à 15.5.2. Ils ne s'appliquent pas aux déploiements AlloyDB Omni basés sur Kubernetes.

Pour rétablir AlloyDB Omni à la version précédemment installée, 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 conserver vos données et comment 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.

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 Kubernetes AlloyDB Omni de votre cluster Kubernetes, procédez comme suit:

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

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

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

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

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

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.