Actualizar a una versión secundaria de la base de datos de AlloyDB Omni en Kubernetes

Selecciona una versión de la documentación:

En esta página se describe cómo actualizar a una versión secundaria de la base de datos de AlloyDB Omni en Kubernetes.

Para actualizar a una versión secundaria de la base de datos, tienes dos opciones:

  • Actualización con poco tiempo de inactividad: en entornos de alta disponibilidad (HA) que ejecuten AlloyDB Omni versión 15.7.1 o posterior, AlloyDB Omni actualiza primero las instancias de espera. A continuación, el operador de AlloyDB Omni realiza un cambio, lo que hace que una de las instancias de espera actualizadas se convierta en tu nueva instancia principal. Una vez que se haya completado el cambio, se actualizará tu instancia principal anterior.

    Este proceso garantiza que el tiempo de inactividad durante la actualización sea mínimo.

  • Actualización simultánea: en el resto de los casos, el operador de AlloyDB Omni actualiza todas las instancias simultáneamente. Esto significa que experimentarás un tiempo de inactividad durante la actualización.

Limitaciones

En las actualizaciones con poco tiempo de inactividad, una instancia de espera no está disponible en un momento dado. Para asegurarte de que tu clúster de base de datos no alcance el objetivo de punto de recuperación (RPO) cero y no corra el riesgo de perder datos, debe tener una instancia principal y al menos dos de espera.

Antes de empezar

  • Si tu clúster tiene alta disponibilidad y la versión de AlloyDB Omni es anterior a la 15.7.1, sigue los pasos que se indican en Actualizar los clústeres de bases de datos antes de seguir este proceso de actualización de versión secundaria.
  • Identifica un periodo de poco tráfico en el que puedas realizar la actualización de la versión secundaria.
  • Para evitar que se pierdan datos, crea una copia de seguridad de tus datos.

Habilitar el proceso de actualización de la versión secundaria de la base de datos con un tiempo de inactividad reducido

Para habilitar el proceso de actualización de la versión secundaria de la base de datos con un tiempo de inactividad reducido, añade la siguiente anotación a tu clúster de base de datos.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

Sustituye la siguiente variable:

  • 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 proporcionaste al crearlo. Para obtener más información, consulta Instalar AlloyDB Omni en Kubernetes.

Actualizar la versión de AlloyDB Omni

Para actualizar la versión 16.8.0, actualiza los campos databaseVersion y controlPlaneAgentsVersion del archivo de manifiesto del clúster y, a continuación, vuelve a aplicar el archivo.

A continuación, se muestra el principio de un archivo de manifiesto que especifica la versión 16.8.0 para databaseVersion y la versión 1.5.0 para controlPlaneAgentsVersion:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "16.8.0"
    controlPlaneAgentsVersion: "1.5.0"
...

Sustituye la siguiente variable:

  • 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 proporcionaste al crearlo. Para obtener más información, consulta Instalar AlloyDB Omni en Kubernetes.

Monitorizar el proceso de actualización

Una vez que hayas actualizado el archivo de manifiesto, el operador de AlloyDB Omni iniciará el proceso de actualización. Para monitorizar el proceso de actualización, comprueba la condición DBCUpgradeInProgress.

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

Sustituye la siguiente variable:

  • 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 proporcionaste al crearlo. Para obtener más información, consulta Instalar AlloyDB Omni en Kubernetes.

Mientras el proceso está en curso, el estado es true. Cuando se complete el proceso, el estado de la condición cambiará a false.

Solución de problemas

Si recibes algún mensaje de error durante el proceso de actualización, consulta las siguientes secciones:

Errores previos a la actualización

Si se produce un error antes de la actualización en tu clúster de base de datos, consulta el mensaje y soluciona el problema.

Si quieres omitir el mensaje de error previo a la actualización, puedes habilitar la anotación force-upgrade.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

Sustituye la siguiente variable:

  • 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 proporcionaste al crearlo. Para obtener más información, consulta Instalar AlloyDB Omni en Kubernetes.

Una vez que se haya completado el proceso de actualización, define la anotación force-upgrade como false.

Errores de actualización

Durante el proceso de actualización automática, hay varios puntos en los que puede fallar en entornos de alta disponibilidad. Para obtener más información sobre cada situación de fallo y las acciones posteriores que lleva a cabo el operador de AlloyDB Omni, consulta la siguiente tabla.

Mensaje de error Descripción Acciones necesarias del usuario
standby instance upgrade succeeded but the replication lag of the standby(s) is too high to be promoted to synchronous standby(s)

El proceso de actualización se ha completado correctamente, pero la instancia de espera no se ha puesto al día con la instancia principal para establecer la replicación síncrona.

Una gran cantidad de tráfico se dirige a la instancia principal. A medida que el tráfico disminuye, la instancia de espera se pone al día gradualmente. Cuando esto ocurra, la condición HAReady pasará a ser true.

Elige una opción en Corregir instancias principales y de espera con diferentes versiones secundarias .

all standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby.

Tus instancias de espera se han actualizado correctamente, pero el proceso de cambio se ha producido un error.

  1. Comprueba el estado del recurso personalizado de cambio para determinar qué ha provocado el fallo.
  2. Elige una opción en Corregir instancias principales y de espera con versiones secundarias diferentes .
standby instance upgrade failed but rollback succeeded.

Tu instancia de espera no se ha actualizado correctamente, pero el operador de AlloyDB Omni la ha restaurado a su versión anterior correctamente.

  1. Comprueba los mensajes de error de la actualización.
  2. Elige una opción en Corregir instancias principales y de espera con versiones secundarias diferentes .
standby instance upgrade failed and rollback failed.

Tu instancia de espera no se ha actualizado correctamente y el operador de AlloyDB Omni no puede restaurar la instancia a su versión anterior.

Ponte en contacto con el equipo de Asistencia de Google para solucionar el problema.

Corregir instancias principales y de espera con versiones secundarias diferentes

Para solucionar este problema, elija una de las siguientes opciones:

  • Si se ha solucionado el problema que ha provocado el fallo de la actualización, vuelve a intentarlo.

    Para volver a intentar la actualización, quita la anotación start-time de la actualización de tu instancia. Después de quitar la anotación, el operador de AlloyDB Omni genera una nueva hora de inicio y vuelve a iniciar el proceso de actualización.

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-
    

    Sustituye la siguiente variable:

    • 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 proporcionaste al crearlo. Para obtener más información, consulta Instalar AlloyDB Omni en Kubernetes.
  • Si el problema que ha provocado el fallo de la actualización persiste, degrada tu instancia a la versión anterior del operador de AlloyDB Omni.

    Para cambiar a una versión anterior de tu instancia, sigue el proceso de actualización y cambia los campos databaseVersion y controlPlaneAgentsVersion del archivo de manifiesto a la versión que usabas antes.