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 incluye un rol de superusuario llamado
alloydbadmin
y un rol de no superusuario llamadoalloydbmetadata
.El usuario
postgres
predeterminado tiene el rol de superusuario.El resto de los roles de usuario predefinidos no tienen privilegios. Se reservan para posibles usos en el futuro.
Al igual que con AlloyDB, es recomendable seguir estos pasos al configurar una base de datos:
Define o importa tus bases de datos con el rol de usuario
postgres
. En una instalación nueva, este rol tiene privilegios de superusuario y no requiere contraseña.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
.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.
Para ver una lista de las métricas disponibles, consulte Métricas de AlloyDB Omni.
AlloyDB Omni que se ejecuta en Kubernetes también tiene un conjunto de métricas básicas disponibles como endpoints de Prometheus.
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:
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.Ejecuta un shell en el pod de la base de datos como root.
kubectl exec ${DB_POD} -it -- /bin/bash
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.
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
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
Para actualizar de AlloyDB Omni 15.5.2 o versiones anteriores a 15.5.4, sigue las instrucciones de Migrar de una versión anterior de AlloyDB Omni a la más reciente.
Para actualizar desde la versión 15.5.4 o una posterior, sigue estos pasos:
Reinicia AlloyDB Omni con una nueva versión de la imagen.
Asegúrate de especificar el directorio de datos para que coincida con la misma ruta que se usaba en versiones anteriores de AlloyDB Omni.
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:
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
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
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
Desinstala el operador de AlloyDB Omni de Kubernetes:
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
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.