Gestionar y monitorizar AlloyDB Omni

Selecciona una versión de la documentación:

En esta página se describe cómo gestionar los roles de usuario de AlloyDB Omni, monitorizar la actividad de tu servidor de AlloyDB Omni y actualizar o quitar tu instalación de AlloyDB Omni.

Gestionar roles de usuario

AlloyDB Omni usa el mismo conjunto de roles de usuario de PostgreSQL predefinidos que incluye AlloyDB, con las siguientes diferencias:

  • AlloyDB Omni no tiene el rol alloydbiamuser.

  • AlloyDB Omni incluye un rol de superusuario llamado alloydbadmin.

Al igual que con AlloyDB, es recomendable seguir estos pasos al configurar una base de datos:

  1. Define o importa tus bases de datos con el rol de usuario postgres. En una instalación nueva, este rol tiene privilegios de creación de bases de datos y de roles, y no tiene contraseña.

  2. Cree nuevos roles de usuario que tengan el nivel de acceso adecuado a las tablas de su aplicación. Para ello, vuelva a usar el rol de usuario postgres.

  3. Configure su aplicación para que se conecte a la base de datos mediante estos nuevos roles de acceso limitado.

Puedes crear y definir tantos roles de usuario como necesites. No modifiques ni elimines ninguno de los roles de usuario con los que se distribuye AlloyDB Omni.

Para obtener más información, consulta Gestionar roles de usuario de AlloyDB.

Monitorizar AlloyDB Omni

Para monitorizar la instalación de AlloyDB Omni, debes leer y analizar sus archivos de registro.

AlloyDB Omni que se ejecuta en Kubernetes también tiene un conjunto de métricas básicas disponibles como endpoints de Prometheus. Para ver una lista de las métricas disponibles, consulte Métricas de AlloyDB Omni.

Un solo servidor

AlloyDB Omni registra su actividad en dos ubicaciones:

  • AlloyDB Omni registra la actividad de la base de datos en data/log/postgres, en relación con el directorio que hayas definido en el archivo de configuración dataplane.conf.

    Puedes personalizar el nombre y el formato de este archivo de registro mediante las distintas directivas log_* definidas en /var/alloydb/config/postgresql.conf. Para obtener más información, consulta Error Reporting y Logging.

  • AlloyDB Omni registra su actividad de instalación, inicio y cierre en /var/alloydb/logs/alloydb.log.

Para comprobar el estado de ejecución inmediato de tu servidor, consulta Comprobar el estado de AlloyDB Omni.

Kubernetes

Buscar los archivos de registro de tu clúster de bases de datos

Puedes encontrar archivos postgresql.audit y postgresql.log en el sistema de archivos del pod de la base de datos. Para acceder a estos archivos, sigue estos pasos:

  1. Define una variable de entorno que contenga el nombre del pod de la base de datos.

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

    Sustituye DB_CLUSTER_NAME por el nombre de tu clúster de base de datos. Es el mismo nombre de clúster de base de datos que declaraste cuando lo creaste.

  2. Ejecuta un shell en el pod de la base de datos como root.

    kubectl exec ${DB_POD} -it -- /bin/bash
  3. Busca los archivos de registro en el directorio /obs/diagnostic/:

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

Mostrar servicios de monitorización

v1.0

Cuando creas un clúster de base de datos, AlloyDB Omni crea el siguiente servicio de monitorización para cada CR de instancia del clúster de base de datos en el mismo espacio de nombres:

al-INSTANCE_NAME-monitoring-system

Para ver la lista de servicios de monitorización, ejecuta el siguiente comando.

kubectl get svc -n NAMESPACE | grep monitoring

Sustituye NAMESPACE por un espacio de nombres al que pertenezca tu clúster.

En el siguiente ejemplo de respuesta se muestran los servicios al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system y al-4bc0-dbc-monitoring-system. Cada servicio corresponde a una instancia.

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

Versión < 1.0

Cuando creas un clúster de base de datos, AlloyDB Omni crea los siguientes servicios de monitorización en el mismo espacio de nombres que el clúster de base de datos:

  • DB_CLUSTER-monitoring-db

  • DB_CLUSTER-monitoring-system

Para ver la lista de servicios de monitorización, ejecuta el siguiente comando.

kubectl get svc -n NAMESPACE | grep monitoring

Sustituye NAMESPACE por un espacio de nombres al que pertenezca tu clúster.

En el siguiente ejemplo de respuesta se muestran los servicios al-2953-dbcluster-foo7-monitoring-system y 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

Ver métricas de Prometheus desde la línea de comandos

El puerto 9187 se denomina metricsalloydbomni en todos los servicios de monitorización.

  1. Configura el reenvío de puertos desde tu entorno local al servicio de monitorización.

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

    Haz los cambios siguientes:

    • MONITORING_SERVICE: el nombre del servicio de monitorización que quieras reenviar (por ejemplo, al-1060-dbc-monitoring-system).

    • NAMESPACE: el espacio de nombres al que pertenece tu clúster.

    • MONITORING_METRICS_PORT: un puerto TCP local disponible.

    La siguiente respuesta muestra que los servicios se están reenviando.

    Forwarding from 127.0.0.1:9187 -> 9187
    Forwarding from [::1]:9187 -> 9187
    
  2. Mientras se ejecuta el comando anterior, puedes acceder a las métricas de monitorización a través de HTTP en el puerto que hayas especificado. Por ejemplo, puedes usar curl para ver todas las métricas como texto sin formato:

    curl http://localhost:MONITORING_METRICS_PORT/metrics
    

Ver métricas con la API de Prometheus

La clave de etiqueta alloydbomni.internal.dbadmin.goog/task-type y el puerto metricsalloydbomni están disponibles de forma predeterminada para todos los servicios de monitorización de AlloyDB Omni. Puedes usarlos junto con un único recurso personalizado ServiceMonitor para seleccionar todos los servicios de todos los espacios de nombres de tu clúster de base de datos.

Para obtener más información sobre cómo usar la API de Prometheus, consulta la documentación de Prometheus Operator.

A continuación, se muestra un ejemplo del campo spec del recurso personalizado ServiceMonitor que incluye la clave de etiqueta alloydbomni.internal.dbadmin.gdc.goog/task-type y el puerto metricsalloydbomni. El recurso personalizado ServiceMonitor monitoriza y recoge todos los servicios de Kubernetes de todos los espacios de nombres.

Para obtener más información sobre la definición completa de ServiceMonitor, consulta la definición de recurso personalizado de ServiceMonitor .

v1.0

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

Versión < 1.0

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

Actualizar AlloyDB Omni

Un solo servidor

Estas instrucciones solo se aplican a AlloyDB Omni 15.2.0 y versiones posteriores.

Antes de empezar

Tu máquina debe tener instalada la versión 1.2 o una posterior de la CLI de AlloyDB Omni.

Realizar la actualización

Para actualizar tu instalación de AlloyDB Omni, ejecuta el siguiente comando:

sudo alloydb database-server upgrade

Kubernetes

Los pasos que sigas para actualizar AlloyDB Omni en Kubernetes dependen de la versión de AlloyDB Omni que estés ejecutando y de la versión a la que quieras actualizar.

Determinar los números de versión actuales

Para comprobar la versión de AlloyDB Omni que usa tu clúster de base de datos, ejecuta este comando:

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

Haz los cambios siguientes:

  • DB_CLUSTER_NAME: el nombre de tu clúster de bases de datos. Es el mismo nombre de clúster de base de datos que declaraste cuando lo creaste.

  • NAMESPACE: el espacio de nombres de Kubernetes de tu clúster de base de datos.

Si ejecutas la versión 1.0.0 o una posterior del operador AlloyDB Omni, este comando imprimirá la versión de AlloyDB Omni que usa tu clúster de base de datos.

Para comprobar la versión del operador AlloyDB Omni instalada en tu clúster de Kubernetes, ejecuta este comando:

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

Si ejecutas la versión 1.0.0 o una posterior del operador AlloyDB Omni, este comando imprimirá el número de versión del operador AlloyDB Omni que se esté ejecutando en tu clúster de Kubernetes.

Si estás ejecutando una versión del operador AlloyDB Omni anterior a la 1.0.0, no puedes realizar una actualización in situ de tu clúster de base de datos ni del operador AlloyDB Omni. En su lugar, debes seguir las instrucciones que se indican en Actualizar desde un operador de AlloyDB Omni anterior a la versión 1.0.0.

En caso contrario, ve a la siguiente sección.

Determinar los números de versión de destino

Si tienes una versión del operador de AlloyDB Omni 1.0.0 o posterior, los pasos que debes seguir dependen de la versión de AlloyDB Omni a la que quieras actualizar. Para ello, es necesario conocer el número de versión de AlloyDB Omni.

El número de versión de AlloyDB Omni consta de tres partes:

  • El número de versión principal de su compatibilidad con PostgreSQL
  • El número de versión secundaria de su compatibilidad con PostgreSQL
  • Número de versión del parche de esta versión de AlloyDB Omni.

Por ejemplo, la versión 15.5.2 de AlloyDB Omni es la versión de parche 2 de AlloyDB Omni que admite la versión 15.5 de PostgreSQL.

Si quieres actualizar a una versión de AlloyDB Omni que admita una versión más reciente de PostgreSQL, debes actualizar el operador de AlloyDB Omni junto con tu clúster de base de datos. Cada conjunto de versiones de AlloyDB Omni que admite una versión secundaria concreta de PostgreSQL tiene su propio número de versión del operador de AlloyDB Omni asociado, que puedes encontrar en las notas de la versión de AlloyDB Omni.

Si solo quieres actualizar a una versión de parche más reciente de AlloyDB Omni, puedes actualizar solo tu clúster de base de datos sin necesidad de actualizar el operador de AlloyDB Omni. Puedes ir directamente a las instrucciones de Actualizar el clúster de base de datos.

En caso contrario, ve a la siguiente sección.

Actualizar el operador de AlloyDB Omni

Para actualizar el operador AlloyDB Omni, haz lo siguiente:

  1. Define las variables de entorno necesarias:

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

    Sustituye OPERATOR_VERSION por la versión del operador de AlloyDB Omni a la que vas a actualizar (por ejemplo, 1.1.0).

  2. Descarga la versión más reciente del operador de AlloyDB Omni:

    gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
    tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz
  3. Aplica las definiciones de recursos personalizados del operador AlloyDB Omni más recientes:

    kubectl apply -f alloydbomni-operator/crds
  4. Actualiza el gráfico de Helm del operador AlloyDB Omni:

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

Para hacer un seguimiento de la actualización del operador AlloyDB Omni, actualiza tanto el manifiesto de Kubernetes como el clúster de base de datos. Para ello, sigue las instrucciones de la siguiente sección inmediatamente después de completar los pasos anteriores.

Actualizar el clúster de base de datos

Para actualizar el clúster de bases de datos, actualiza los siguientes campos de la sección spec del archivo de manifiesto que lo define:

  • Define databaseVersion con el número de versión completo de AlloyDB Omni al que quieras actualizar este clúster de base de datos.

  • Si también has actualizado AlloyDB Omni Operator, asigna a controlPlaneAgentsVersion el número de versión completo de AlloyDB Omni Operator que has actualizado.

Si solo vas a actualizar la versión de parche de AlloyDB Omni (por ejemplo, de databaseVersion a 15.5.1), este paso es todo lo que tienes que hacer.15.5.2

Si vas a actualizar la versión secundaria de la compatibilidad con PostgreSQL (por ejemplo, de databaseVersion a 15.4.1 o 15.5.2), también debes actualizar controlPlaneAgentsVersion. En ese caso, asegúrate de haber seguido los pasos adicionales que se indican en Actualizar el operador de AlloyDB Omni.

Por ejemplo, el siguiente fragmento de manifiesto define un clúster de base de datos que ejecuta la versión 15.5.2 del operador AlloyDB Omni, con la versión 1.0.0 del operador AlloyDB Omni:

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

En este ejemplo, para actualizar el clúster de base de datos a la versión 15.5.3 de AlloyDB Omni, cambia databaseVersion: 15.5.2 por databaseVersion: 15.5.3.

Actualizar desde una versión anterior a la 1.0.0 del operador de AlloyDB Omni

Si estás ejecutando una versión del operador AlloyDB Omni anterior a la 1.0.0, para actualizar una instalación de AlloyDB Omni basada en Kubernetes, debes desinstalar y volver a instalar el operador AlloyDB Omni después de crear una copia de seguridad de tus datos. Sigue estos pasos:

  1. Lista todos tus clústeres de bases de datos:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  2. En cada clúster de bases de datos, usa el comando pg_dumpall para exportar todos sus datos.

  3. Desinstala el operador de AlloyDB Omni. Esto incluye la eliminación de todos tus clústeres de bases de datos.

  4. Reinstala el operador AlloyDB Omni. Puedes usar los mismos comandos que usaste para instalar la versión anterior del operador de AlloyDB Omni sin tener que especificar un nuevo número de versión.

  5. Vuelve a crear tus clústeres de bases de datos. Puedes adaptar los mismos archivos de manifiesto que usaste al crear tus clústeres de bases de datos. Es posible que tengas que actualizar los archivos para reflejar los cambios en la API que se introdujeron en la versión 1.0.0 del operador AlloyDB Omni, como el atributo databaseVersion, que sustituye al atributo version anterior.

  6. Usa pg_restore o el comando \i en psql para importar los datos que hayas exportado anteriormente a los clústeres recreados.

Restaurar una versión anterior

Estas instrucciones solo se aplican a las versiones de AlloyDB Omni de la 15.2.1 a la 15.5.2. No se aplican a las implementaciones basadas en Kubernetes de AlloyDB Omni.

Para restaurar la versión instalada anteriormente de AlloyDB Omni, ejecuta este comando:

sudo alloydb database-server rollback

Desinstalar AlloyDB Omni

Un solo servidor

Para desinstalar AlloyDB Omni, ejecuta el siguiente comando:

sudo alloydb database-server uninstall

El directorio de datos permanece en tu sistema de archivos después de desinstalar AlloyDB Omni. Puedes mover, archivar o eliminar este directorio, en función de si quieres conservar tus datos y cómo quieres hacerlo después de desinstalar AlloyDB Omni.

Kubernetes

Eliminar un clúster de base de datos

Para eliminar tu clúster de bases de datos, asigna el valor isDeleted a true en su manifiesto. Para ello, usa el siguiente comando.

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

Sustituye DB_CLUSTER_NAME por el nombre de tu clúster de bases de datos. Es el mismo nombre de clúster de base de datos que declaraste cuando lo creaste.

Desinstalar el operador de AlloyDB Omni

Para desinstalar el operador de AlloyDB Omni Kubernetes de tu clúster de Kubernetes, sigue estos pasos:

  1. Elimina todos los clústeres de bases de datos:

    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. Espera a que el operador de Kubernetes de AlloyDB Omni elimine todos tus clústeres de bases de datos. Usa el siguiente comando para comprobar si quedan recursos de la base de datos:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  3. Elimina otros recursos que haya creado el operador de Kubernetes de 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. Desinstala el operador de AlloyDB Omni de Kubernetes:

    helm uninstall alloydbomni-operator --namespace alloydb-omni-system
  5. Elimina los secretos, las descripciones de recursos personalizados y los espacios de nombres relacionados con el operador de AlloyDB Omni de Kubernetes:

    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

Cambiar el tamaño de un clúster de base de datos basado en Kubernetes

Para cambiar el tamaño de la CPU, la memoria o el almacenamiento de tu clúster de base de datos basado en Kubernetes, actualiza el campo resources de los manifiestos que definen su pod. El operador AlloyDB Omni aplica las nuevas especificaciones a tu pod de base de datos inmediatamente.

Para obtener más información sobre la sintaxis del manifiesto del operador de AlloyDB Omni, consulta Crear un clúster de base de datos.

Se aplican las siguientes restricciones al modificar los recursos de un clúster de bases de datos en ejecución:

  • Solo puedes aumentar el tamaño de un disco si el storageClass especificado admite la expansión de volumen.
  • No puedes reducir el tamaño de un disco.