Actualizar la versión principal de la base de datos in situ

En esta página se describe cómo actualizar la versión principal de la base de datos actualizando la instancia de Cloud SQL in situ en lugar de migrando los datos.

Introducción

Los proveedores de software de bases de datos publican periódicamente nuevas versiones principales que contienen nuevas funciones, mejoras de rendimiento y mejoras de seguridad. Cloud SQL incorpora nuevas versiones después de que se publiquen. Cuando Cloud SQL ofrezca compatibilidad con una nueva versión principal, podrás actualizar tus instancias para mantener tu base de datos actualizada.

Puedes actualizar la versión de la base de datos de una instancia in situ o migrando los datos. Las actualizaciones in situ son una forma más sencilla de actualizar la versión principal de tu instancia. No es necesario migrar datos ni cambiar las cadenas de conexión de la aplicación. Con las actualizaciones in situ, puedes conservar el nombre, la dirección IP y otros ajustes de tu instancia actual después de la actualización. Las actualizaciones in situ no requieren que muevas archivos de datos y se pueden completar más rápido. En algunos casos, el tiempo de inactividad es menor que el que implica migrar tus datos.

En MySQL 8.0.15 y versiones anteriores, la operación de actualización in situ de MySQL usa la utilidad mysql_upgrade. En MySQL 8.0.16 y versiones posteriores, la operación de actualización in situ de MySQL se gestiona mediante el proceso MySQL server. Para obtener más información sobre la operación de actualización in situ, consulta Qué se actualiza en el proceso de actualización de MySQL.

Planificar una actualización de versión principal

  1. Confirma que tienes el rol necesario para realizar una actualización de versión principal: Propietario de Cloud SQL o Administrador de Cloud SQL.

  2. Elige una versión principal de destino.

    gcloud

    Para obtener información sobre cómo instalar y empezar a usar la CLI de gcloud, consulta el artículo Instalar la CLI de gcloud. Para obtener información sobre cómo iniciar Cloud Shell, consulta el artículo Usar Cloud Shell.

    Para comprobar las versiones de la base de datos a las que puedes actualizar tu instancia sin cambiarla, haz lo siguiente:

    1. Ejecuta el siguiente comando:
      2. gcloud sql instances describe INSTANCE_NAME

      Sustituye INSTANCE_NAME por el nombre de la instancia.

    2. En la salida del comando, busca la sección con la etiqueta upgradableDatabaseVersions.
    3. Cada subsección devuelve una versión de la base de datos que se puede actualizar. En cada subsección, revisa los siguientes campos.
      • majorVersion: la versión principal a la que puedes orientar la actualización in situ.
      • name: cadena de versión de la base de datos que incluye la versión principal. En el caso de Cloud SQL para MySQL, este campo también incluye la versión secundaria de la base de datos.
      • displayName: el nombre visible de la versión de la base de datos.

    REST v1

    Para comprobar qué versiones de la base de datos de destino están disponibles para una actualización in situ de una versión principal, usa el método instances.get de la API Admin de Cloud SQL.

    Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

    • INSTANCE_NAME: nombre de la instancia.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Para enviar tu solicitud, despliega una de estas opciones:

    Deberías recibir una respuesta JSON similar a la siguiente:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    REST v1beta4

    Para comprobar qué versiones de la base de datos de destino están disponibles para la actualización in situ de la versión principal de una instancia, usa el método instances.get de la API Admin de Cloud SQL.

    Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

    • INSTANCE_NAME: nombre de la instancia.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    Para enviar tu solicitud, despliega una de estas opciones:

    Deberías recibir una respuesta JSON similar a la siguiente:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    Para ver la lista completa de las versiones de la base de datos que admite Cloud SQL, consulta Versiones de la base de datos y políticas de versiones.

  3. Tenga en cuenta las funciones que se ofrecen en cada versión principal de la base de datos y resuelva las incompatibilidades.

    Las nuevas versiones principales introducen cambios incompatibles que pueden requerir que modifiques el código de la aplicación, el esquema o la configuración de la base de datos. Antes de actualizar tu instancia de base de datos, consulta las notas de la versión principal de destino para determinar las incompatibilidades que debes solucionar.

    Después de actualizar a una versión posterior, es posible que cambie el valor predeterminado de algunas variables del sistema. Por ejemplo, el valor predeterminado de character_set_server en MySQL 5.6 y MySQL 5.7 es utf8. Cuando actualizas a MySQL 8.0, el valor predeterminado de character_set_server cambia a utf8mb4. Para volver a utf8, debes cambiar manualmente el valor de la marca de base de datos por el valor anterior. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos. La mayoría de los cambios en los valores predeterminados los realiza la comunidad de MySQL (consulta más información en Upgrade Server Defaults [Actualizar valores predeterminados del servidor]).

  4. Realiza la comprobación previa para las actualizaciones.

    • Si vas a actualizar de MySQL 5.7 a 8.0, realiza una comprobación previa de las actualizaciones de MySQL 5.7 a 8.0. Puedes usar la utilidad de comprobación de actualizaciones en el shell de MySQL.

    • Si vas a actualizar de MySQL 8.0 a 8.4, realiza una comprobación previa de las actualizaciones de MySQL 8.0 a 8.4. Puedes usar la utilidad de comprobación de actualizaciones en el shell de MySQL.

      Si se detecta algún problema durante la comprobación previa, corríjalo antes de continuar con la actualización. Cloud SQL no admite la comprobación previa durante una actualización de versión principal. También puede fallar un intento de actualizar una instancia que no haya superado la comprobación previa.

  5. Comprueba el espacio en disco y los tipos de máquinas de las instancias.

    Para actualizar una versión principal, se necesitan recursos adicionales, como espacio en disco, para almacenar las tablas actualizadas. Si no hay suficiente espacio en el disco, la actualización fallará y se revertirá. Para actualizar de MySQL 5.7 a 8.0, se necesita memoria adicional para convertir los metadatos antiguos al nuevo diccionario de datos. Antes de actualizar a una versión principal, asegúrate de que tienes más de 100 KB de memoria para cada tabla. Puedes aumentar la memoria temporalmente cambiando el tipo de máquina.

  6. En el caso de las actualizaciones de MySQL 5.7 a MySQL 8.0, comprueba si se han producido cambios en las concesiones de usuarios en MySQL 8.0.

    La versión 8.0 de Cloud SQL para MySQL usa una marca llamada partial_revokes, que tiene el valor ON de forma predeterminada. A diferencia de MySQL 5.7, esta marca elimina la posibilidad de usar caracteres comodín en los comandos GRANT de la base de datos. Para asegurarse de que los usuarios de la base de datos tienen acceso a los esquemas de base de datos correctos, modifique los privilegios de los usuarios de la base de datos antes de actualizar a MySQL 8.0. Actualiza los privilegios del usuario para que use el nombre completo de los esquemas de base de datos necesarios en lugar de caracteres comodín.

    Para obtener más información sobre cómo funciona esta marca en MySQL 8.0, consulta revocaciones parciales en MySQL 8.0.

  7. Prueba la actualización con una prueba sin ejecutar.

    Realiza una prueba del proceso de actualización integral en un entorno de prueba antes de actualizar la base de datos de producción. Puedes clonar tu instancia para crear una copia idéntica de los datos en la que probar el proceso de actualización.

    Además de validar que la actualización se completa correctamente, ejecuta pruebas para asegurarte de que la aplicación se comporta como se espera en la base de datos actualizada.

  8. Decide cuándo quieres cambiarte a una versión superior.

    Para actualizar, la instancia debe dejar de estar disponible durante un periodo. Programa la actualización para un periodo en el que la actividad de la base de datos sea baja.

Prepararse para una actualización de versión principal

Antes de cambiar a una edición superior, completa los siguientes pasos:

  1. SOLO para actualizaciones de MySQL 5.7 a 8.0: comprueba y corrige los problemas de incompatibilidad que se hayan detectado durante el proceso de comprobación previa. Entre los problemas habituales que pueden presentarse, se encuentran los siguientes:

    1. Se han añadido nuevas palabras clave reservadas, como RANKS, GROUPS y FUNCTION, en procedimientos almacenados, activadores y otros objetos de base de datos. Consulta Palabras clave y palabras reservadas para obtener más información.
    2. Caracteres UTF no válidos en las definiciones de tabla.
    3. Transiciones XA no confirmadas que deben confirmarse (con la instrucción XA COMMIT) o deshacerse (con la instrucción XA ROLLBACK).
    4. Restricción de clave externa en nombres de más de 64 caracteres.
    5. Tipo de datos espaciales en el índice mixto de columnas. Para obtener más información, consulta Tipo de datos espaciales.

    Para obtener ayuda para solucionar errores y problemas conocidos durante la comprobación previa, consulta Problemas conocidos con la actualización in situ a MySQL 8.0. Para obtener más información sobre los problemas habituales de MySQL, consulta Preparar la instalación para la actualización y ¿Vas a actualizar a MySQL 8.0?.

    SOLO para actualizaciones de MySQL 8.0 a MySQL 8.4: comprueba y corrige los problemas de incompatibilidad que se hayan detectado durante el proceso de comprobación previa. Un problema habitual puede ser el siguiente:

    • Terminología de replicación obsoleta. Los términos MASTER y SLAVE se han eliminado por completo de MySQL 8.4. Si sigues usando comandos o configuraciones con estos términos, debes sustituirlos o quitarlos. Para obtener más información sobre la eliminación y la sustitución de estos términos, consulta Novedades de MySQL 8.4 desde MySQL 8.0.
    • Actualiza el complemento de autenticación de tus cuentas de usuario para que usen el complemento de autenticación caching_sha2_password en lugar del complemento mysql_native_password, que ya no está disponible.

      Para cambiar tus cuentas de usuario de la base de datos para que usen el complemento de autenticación caching_sha2_password, usa el siguiente comando: 
           ALTER USER 'username'@'%'
     IDENTIFIED WITH caching_sha2_password BY 'user_password';
      Sustituye username y user_password por los valores de la cuenta de usuario que quieras actualizar.

  2. Comprobar el espacio en disco y el tipo de máquina de la instancia

    Para actualizar a una versión principal, se necesita espacio en disco y memoria adicionales para almacenar las tablas actualizadas y el nuevo diccionario de datos. Si no hay suficiente espacio en el disco, la actualización fallará y se restaurará la versión original. Cloud SQL recomienda que cada tabla tenga un mínimo de 100 KB de memoria.

    Nota: Puedes aumentar la memoria temporalmente cambiando el tipo de máquina antes de ejecutar la actualización de la versión principal. Para obtener más información, consulta cómo cambiar el tipo de máquina.

Realizar la actualización de la versión principal

Puedes actualizar la versión principal de una sola instancia de Cloud SQL o de una instancia principal e incluir todas sus réplicas en la actualización, incluidas las réplicas en cascada y las réplicas entre regiones.

Actualizar la versión principal de una sola instancia

Cuando inicias una operación de actualización para una sola instancia, Cloud SQL hace lo siguiente:

  1. Comprueba la configuración de tu instancia para asegurarse de que es compatible con una actualización.
  2. Una vez que Cloud SQL verifique la configuración, la instancia dejará de estar disponible.
  3. Crea una copia de seguridad antes de la actualización.
  4. Realiza la actualización en la instancia.
  5. Hace que tu instancia esté disponible.
  6. Crea una copia de seguridad posterior a la actualización.
Cuando actualizas a MySQL 8.0, Cloud SQL aprovisiona automáticamente tu instancia en la versión secundaria predeterminada.

Consola

  1. En la Google Cloud consola, ve a la página Instancias de Cloud SQL.

    Ir a Instancias de Cloud SQL

  2. Para abrir la página Overview (Resumen) de una instancia, haz clic en su nombre.
  3. Haz clic en Editar.
  4. En la sección Información de la instancia, haz clic en el botón Actualizar y confirma que quieres ir a la página de actualización.
  5. En la página Elige una versión de la base de datos, haz clic en la lista Versión de la base de datos para la actualización y selecciona una de las versiones principales de la base de datos disponibles.
  6. Haz clic en Continuar.
  7. En el cuadro ID de instancia, introduce el nombre de la instancia y, a continuación, haz clic en el botón Iniciar actualización.
La operación tarda varios minutos en completarse.

Comprueba que la versión principal de la base de datos actualizada aparece debajo del nombre de la instancia en la página Resumen de la instancia.

gcloud

  1. Inicia la actualización.

    Usa el comando gcloud sql instances patch con la marca --database-version.

    Antes de ejecutar el comando, sustituye lo siguiente:

    • INSTANCE_NAME: el nombre de la instancia.
    • DATABASE_VERSION: el enum de la versión principal de la base de datos, que debe ser posterior a la versión actual. Especifica una versión de la base de datos para una versión principal que esté disponible como destino de actualización de la instancia. Puedes obtener este enum como primer paso de Plan for upgrade (Plan para el cambio a un plan superior). Si necesitas una lista completa de enums de versiones de bases de datos, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Las actualizaciones de versiones principales tardan varios minutos en completarse. Es posible que veas un mensaje que indique que la operación está tardando más de lo previsto. Puedes ignorar este mensaje o ejecutar el comando gcloud sql operations wait para cerrarlo.

  2. Obtén el nombre de la operación de actualización.

    Usa el comando gcloud sql operations list con la marca --instance.

    Antes de ejecutar el comando, sustituye la variable INSTANCE_NAME por el nombre de la instancia. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitoriza el estado de la actualización.

    Usa el comando gcloud sql operations describe.

    Antes de ejecutar el comando, sustituye la variable OPERATION por el nombre de la operación de actualización que has obtenido en el paso anterior. 

    gcloud sql operations describe OPERATION

REST v1

  1. Inicia la actualización in situ.

    Usa una solicitud PATCH con el método instances:patch.

    Antes de usar los datos de la solicitud, sustituye estas variables:

    • PROJECT_ID: el ID del proyecto.
    • INSTANCE_NAME: el nombre de la instancia.

    Método HTTP y URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Cuerpo JSON de la solicitud: 

    {
  "databaseVersion": DATABASE_VERSION
}

    Sustituye DATABASE_VERSION por el enum de la versión principal de la base de datos, que debe ser posterior a la versión actual. Especifica una versión de la base de datos para una versión principal que esté disponible como destino de actualización de la instancia. Puedes obtener este enum como primer paso de Plan for upgrade (Plan para el cambio a un plan superior). Si necesitas una lista completa de enumeraciones de versiones de bases de datos, consulta SqlDatabaseVersion.

  2. Obtén el nombre de la operación de actualización.

    Usa una solicitud GET con el método operations.list después de sustituir PROJECT_ID por el ID del proyecto.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitoriza el estado de la actualización.

    Usa una solicitud GET con el método operations.get después de sustituir las siguientes variables:

    • PROJECT_ID: el ID del proyecto.
    • OPERATION_NAME: nombre de la operación de actualización obtenida en el paso anterior.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Para actualizar la versión de la base de datos, usa un recurso de Terraform y el proveedor de Terraform para Google Cloud, versión 4.34.0 o posterior.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Aplica los cambios

Para aplicar la configuración de Terraform en un proyecto, sigue los pasos que se indican en las siguientes secciones. Google Cloud

Preparar Cloud Shell

  1. Abre Cloud Shell.

  2. Define el Google Cloud proyecto Google Cloud predeterminado en el que quieras aplicar tus configuraciones de Terraform.

    Solo tiene que ejecutar este comando una vez por proyecto y puede hacerlo en cualquier directorio.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Las variables de entorno se anulan si defines valores explícitos en el archivo de configuración de Terraform.

Preparar el directorio

Cada archivo de configuración de Terraform debe tener su propio directorio (también llamado módulo raíz).

  1. En Cloud Shell, crea un directorio y un archivo nuevo en ese directorio. El nombre del archivo debe tener la extensión .tf. Por ejemplo, main.tf. En este tutorial, nos referiremos al archivo como main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Si estás siguiendo un tutorial, puedes copiar el código de ejemplo de cada sección o paso.

    Copia el código de ejemplo en el archivo main.tf que acabas de crear.

    También puedes copiar el código de GitHub. Se recomienda cuando el fragmento de Terraform forma parte de una solución integral.

  3. Revisa y modifica los parámetros de ejemplo para aplicarlos a tu entorno.
  4. Guarda los cambios.
  5. Inicializa Terraform. Solo tienes que hacerlo una vez por directorio. 
    terraform init

    Si quieres usar la versión más reciente del proveedor de Google, incluye la opción -upgrade: 

    terraform init -upgrade

Aplica los cambios

  1. Revisa la configuración y comprueba que los recursos que va a crear o actualizar Terraform se ajustan a tus expectativas: 
    terraform plan

    Haga las correcciones necesarias en la configuración.

  2. Aplica la configuración de Terraform ejecutando el siguiente comando e introduciendo yes en la petición: 
    terraform apply

    Espera hasta que Terraform muestre el mensaje "Apply complete!".

  3. Abre tu Google Cloud proyecto para ver los resultados. En la Google Cloud consola, ve a tus recursos en la interfaz de usuario para asegurarte de que Terraform los ha creado o actualizado.

Eliminar los cambios

Para eliminar los cambios, sigue estos pasos:

  1. Para inhabilitar la protección contra la eliminación, en el archivo de configuración de Terraform, asigna el valor false al argumento deletion_protection. 
    deletion_protection =  "false"
  2. Aplica la configuración de Terraform actualizada ejecutando el siguiente comando e introduciendo yes en la petición: 
    terraform apply

  1. Para quitar los recursos que se hayan aplicado anteriormente con tu configuración de Terraform, ejecuta el siguiente comando e introduce yes en la petición:

    terraform destroy

Cuando envías una solicitud de actualización in situ, Cloud SQL primero realiza una comprobación previa a la actualización. Si Cloud SQL determina que tu instancia no está lista para una actualización, tu solicitud de actualización fallará y se mostrará un mensaje con sugerencias para solucionar el problema. Consulta también Solucionar problemas al actualizar una versión principal.

Incluir réplicas en la actualización de la versión principal

Si tu instancia principal tiene réplicas, puedes incluirlas todas en la actualización. Cloud SQL puede actualizar todas las réplicas de la instancia principal, incluidas las réplicas interregionales y las réplicas en cascada.

Cuando incluyes réplicas en una actualización de versión principal, Cloud SQL hace lo siguiente:

  1. Comprueba la configuración de tu instancia principal y de las réplicas para asegurarse de que la instancia y las réplicas son compatibles con una actualización.
  2. Hace que tu instancia principal no esté disponible.
  3. Crea una copia de seguridad previa a la actualización de la instancia principal.
  4. Detiene la replicación de todas las réplicas.
  5. Realiza la actualización en la instancia principal.
  6. Si la actualización de la instancia principal se realiza correctamente, la instancia principal vuelve a estar disponible y se reinicia la replicación.
  7. Cloud SQL crea una copia de seguridad de la instancia principal después de la actualización.
  8. Cloud SQL procede a actualizar todas las réplicas.

Aunque falle la actualización de la versión principal de una réplica, la instancia principal seguirá estando disponible.

Para incluir réplicas en una actualización de versión principal, no puedes usar laGoogle Cloud consola ni Terraform. Solo puedes usar gcloud CLI o la API Admin de Cloud SQL.

gcloud

  1. Inicia la actualización.

    Usa el comando gcloud sql instances patch con las marcas --database-version y --include-replicas-for-major-version-upgrade.

    Antes de ejecutar el comando, sustituye lo siguiente:

    • INSTANCE_NAME: nombre de la instancia principal.
    • DATABASE_VERSION: el enum de la versión principal de la base de datos, que debe ser posterior a la versión actual. Especifica una versión de la base de datos para una versión principal que esté disponible como destino de actualización de la instancia. Puedes obtener este enum como primer paso de Plan for upgrade (Plan para el cambio a un plan superior). Si necesitas una lista completa de enums de versiones de bases de datos, consulta SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
  --database-version=DATABASE_VERSION \
  --include-replicas-for-major-version-upgrade

    Las actualizaciones de versiones principales tardan varios minutos en completarse. Es posible que veas un mensaje que indique que la operación está tardando más de lo previsto. Puedes ignorar este mensaje o ejecutar el comando gcloud sql operations wait para cerrarlo. La actualización de las réplicas puede tardar varios minutos en completarse. Para comprobar el estado de la actualización, sigue estos pasos:

  2. Obtén el nombre de la operación de actualización.

    Usa el comando gcloud sql operations list con la marca --instance.

    Antes de ejecutar el comando, sustituye la variable INSTANCE_NAME por el nombre de la instancia. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Monitoriza el estado de la actualización.

    Usa el comando gcloud sql operations describe.

    Antes de ejecutar el comando, sustituye la variable OPERATION por el nombre de la operación de actualización que has obtenido en el paso anterior. 

    gcloud sql operations describe OPERATION

REST

  1. Inicia la actualización in situ.

    Usa una solicitud PATCH con el método instances:patch.

    Antes de usar los datos de la solicitud, sustituye estas variables:

    • PROJECT_ID: el ID del proyecto.
    • INSTANCE_NAME: el nombre de la instancia.

    Método HTTP y URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Cuerpo JSON de la solicitud: 

    {
  "databaseVersion": DATABASE_VERSION
  "includeReplicasForMajorVersionUpgrade": true
}

    • Sustituye DATABASE_VERSION por el enum de la versión principal de la base de datos, que debe ser posterior a la versión actual. Especifica una versión de la base de datos para una versión principal que esté disponible como destino de actualización de la instancia. Puedes obtener este enum como primer paso de Plan for upgrade (Plan para el cambio a un plan superior). Si necesitas una lista completa de enumeraciones de versiones de bases de datos, consulta SqlDatabaseVersion.
    • En el campo includeReplicasForMajorVersionUpgrade, especifica true.

  2. Obtén el nombre de la operación de actualización.

    Usa una solicitud GET con el método operations.list después de sustituir PROJECT_ID por el ID del proyecto.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Monitoriza el estado de la actualización.

    Usa una solicitud GET con el método operations.get después de sustituir las siguientes variables:

    • PROJECT_ID: el ID del proyecto.
    • OPERATION_NAME: nombre de la operación de actualización obtenida en el paso anterior.

    Método HTTP y URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Copias de seguridad de actualizaciones automáticas

Cuando realizas una actualización de versión principal, Cloud SQL crea automáticamente dos copias de seguridad bajo demanda, llamadas copias de seguridad de actualización:

  • La primera copia de seguridad de la actualización es la copia de seguridad previa a la actualización, que se crea inmediatamente antes de iniciar la actualización. Puedes usar esta copia de seguridad para restaurar tu instancia de base de datos al estado que tenía en la versión anterior.
  • La segunda copia de seguridad es la copia de seguridad posterior a la actualización, que se crea inmediatamente después de que se permitan nuevas escrituras en la instancia de base de datos actualizada.

Cuando consultes tu lista de copias de seguridad, las copias de seguridad de la actualización se mostrarán con el tipo On-demand. Las copias de seguridad de actualización están etiquetadas para que puedas identificarlas rápidamente. Por ejemplo, si vas a actualizar de MySQL 5.7 a MySQL 8.0, la copia de seguridad anterior a la actualización se etiquetará como Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. y la posterior como Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. Si vas a actualizar de MySQL 8.0 a MySQL 8.4, la copia de seguridad anterior a la actualización se etiquetará como Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. y la posterior como Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0..

Al igual que con otras copias de seguridad bajo demanda, las copias de seguridad de la actualización se conservan hasta que las elimines o elimines la instancia. Si tienes habilitada la recuperación a un momento dado, no podrás eliminar tus copias de seguridad de la actualización mientras estén en tu periodo de conservación. Si necesitas eliminar las copias de seguridad de la actualización, debes inhabilitar PITR o esperar hasta que las copias de seguridad de la actualización ya no estén en tu ventana de conservación.

Completar la actualización de la versión principal

Una vez que hayas terminado de actualizar tu instancia principal, sigue estos pasos para completar la actualización:

  1. Realizar pruebas de aceptación.

    Realiza pruebas para confirmar que el sistema actualizado funciona correctamente.

  2. Opcional: Actualiza los privilegios de usuario.

    Si has actualizado a MySQL 8.0, ten en cuenta que MySQL ha cambiado los sistemas de seguridad y de gestión de cuentas. Para obtener más información, consulta el artículo Novedades de MySQL 8.0.

    Esto puede provocar que los usuarios creados en la versión 5.7 de MySQL de la instancia no tengan los mismos privilegios que los usuarios creados directamente en MySQL 8.0. Por ejemplo, un usuario que haya actualizado de MySQL 5.7 puede que no tenga los privilegios CREATE ROLE y DROP ROLE porque no existían en MySQL 5.7. Cloud SQL recomienda que restablezcas los privilegios de usuario después de actualizar las versiones para solucionar cualquier problema relacionado con los privilegios de usuario.

    Si has actualizado de MySQL 8.0 a MySQL 8.4, se han producido cambios adicionales en los privilegios de usuario, como la adición de privilegios introducidos en MySQL 8.4 y la eliminación de privilegios que existían en MySQL 8.0. Para obtener más información, consulta Privilegios de usuario de MySQL 8.4 (cloudsqlsuperuser).

    Puedes actualizar los privilegios de usuario en MySQL 8.0 o MySQL 8.4 siguiendo estos pasos:

    1. Crea un usuario con el rol cloudsqlsuperuser concedido.

    2. Usa el usuario creado para revocar todos los privilegios anteriores de un usuario actualizado con el siguiente comando:

      REVOKE ALL PRIVILEGES ON *.* FROM user@host
    3. Concede los privilegios esperados al usuario actualizado.

  3. Opcional: Crea una copia de seguridad.

    Aunque Cloud SQL crea automáticamente una copia de seguridad después de actualizar la instancia principal, Cloud SQL recomienda que crees una copia de seguridad por tu cuenta para poder recuperar la base de datos si es necesario.

  4. Opcional: Si has actualizado a Cloud SQL para MySQL 8.4, también debes actualizar todos tus conectores, clientes y shells de MySQL a MySQL 8.4.

Solucionar problemas al cambiar a una versión principal

Cloud SQL devuelve un mensaje de error si intentas ejecutar un comando de actualización no válido. Por ejemplo, si tu instancia contiene marcas de base de datos no válidas para la nueva versión.

Si tu solicitud de actualización falla, comprueba la sintaxis de la solicitud. Si la solicitud tiene una estructura válida, prueba a seguir estas sugerencias.

Ver los registros de errores

Si se produce algún problema con una solicitud de actualización válida, Cloud SQL publicará los registros de errores en projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Cada entrada de registro contiene una etiqueta con el identificador de instancia para ayudarte a identificar la instancia con el error de actualización. Busca estos errores de actualización y resuélvelos.

Para ver los registros de errores, usa la Google Cloud consola::

  1. En la Google Cloud consola, ve a la página Instancias de Cloud SQL.

    Ir a Instancias de Cloud SQL

  2. Para abrir la página Overview (Resumen) de una instancia, haz clic en su nombre.

  3. En el panel Operaciones y registros de la página Resumen de la instancia, haga clic en el enlace Ver registros de errores de MySQL.

    Se abrirá la página Explorador de registros.

  4. Para ver los registros, sigue estos pasos:

    • Para ver todos los registros de errores de un proyecto, selecciona el nombre del registro en el filtro de registro Nombre del registro.

    Para obtener más información sobre los filtros de consulta, consulta Consultas avanzadas.

    • Para filtrar los registros de errores de actualización de una sola instancia, introduce la siguiente consulta en el cuadro Buscar en todos los campos, después de sustituir DATABASE_ID

    con el ID del proyecto seguido del nombre de la instancia en este formato: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

    Por ejemplo, para filtrar los registros de errores de actualización por una instancia llamada shopping-db que se ejecuta en el proyecto buylots, usa el siguiente filtro de consulta:

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

    Puede revisar todos los registros notificados en un periodo determinado o filtrar los registros por gravedad. Una opción habitual para solucionar problemas puede ser seleccionar los siguientes filtros:

    • Emergencia
    • Alerta
    • Crítica
    • Error

    Es posible que experimentes algunos problemas conocidos durante la comprobación previa y la actualización de la versión 5.7 a la 8.0 de MySQL. Si necesitas ayuda para solucionar estos problemas, consulta Problemas conocidos con la actualización in situ a MySQL 8.0.

Restaurar la instancia principal a la versión principal anterior

Si el sistema de base de datos actualizado no funciona como se esperaba, es posible que tengas que restaurar la instancia principal a la versión anterior. Para ello, restaura la copia de seguridad anterior a la actualización en una instancia de recuperación de Cloud SQL, que es una instancia nueva que ejecuta la versión anterior a la actualización.

Para restaurar una instancia principal a la versión anterior, sigue estos pasos:

  1. Identifica la copia de seguridad que has creado antes de actualizar.

    Consulta Copias de seguridad de actualizaciones automáticas.

  2. Crea una instancia de recuperación.

    Crea una instancia de Cloud SQL con la versión principal que tenía Cloud SQL cuando se creó la copia de seguridad previa a la actualización. Define las mismas marcas y los mismos ajustes de instancia que la instancia original.

  3. Restaura la copia de seguridad que creaste antes de actualizar.

    Restaura la copia de seguridad que creaste antes de la actualización en la instancia de recuperación. Este proceso puede tardar varios minutos.

  4. Añade tus réplicas de lectura.

    Si usas réplicas de lectura, añádelas de forma individual.

  5. Conecta tu aplicación.

    Una vez que hayas recuperado tu sistema de base de datos, actualiza tu aplicación con los detalles sobre la instancia de recuperación y sus réplicas de lectura. Puedes reanudar el servicio de tráfico en la versión anterior a la actualización de tu base de datos.

Limitaciones

En esta sección se enumeran las limitaciones de una actualización de versión principal in situ.

  • No puedes realizar una actualización de versión principal in situ en una réplica externa.
  • Si actualizas instancias de MySQL 5.7 a 8.0 que tienen más de 512.000 tablas,el proceso puede tardar mucho y agotarse el tiempo de espera.
  • Si actualizas instancias de MySQL 8.0 a 8.4 que tienen más de 512.000 tablas,el proceso puede tardar mucho y agotarse el tiempo de espera.

  • Al actualizar de MySQL 8.0 a 8.4, si has actualizado una réplica a MySQL 8.4, pero no la instancia principal, es posible crear una cuenta de usuario en una instancia principal no actualizada con el complemento de autenticación mysql_native_password obsoleto. Para evitar esta situación, asegúrate de actualizar la instancia principal inmediatamente después de actualizar las réplicas o de crear cuentas de usuario solo en la instancia principal mediante el siguiente comando.

    CREATE USER 'USERNAME'@'%' IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

    Sustituye USERNAME y PASSWORD por los valores que correspondan.

Preguntas frecuentes

Pueden surgir las siguientes preguntas al actualizar la versión principal de la base de datos.

¿Mi instancia no estará disponible durante una actualización?
Sí. Tu instancia no estará disponible durante un periodo mientras Cloud SQL realiza la actualización.
¿Cuánto tiempo tarda una actualización?

La actualización de una sola instancia suele tardar menos de 10 minutos. Si la configuración de tu instancia tiene un número reducido de vCPUs o de memoria, es posible que la actualización tarde más tiempo.

Si tu instancia aloja demasiadas bases de datos o tablas, o si tus bases de datos son muy grandes, la actualización puede tardar horas o incluso agotarse el tiempo de espera, ya que el tiempo total de actualización corresponde al número de objetos de tus bases de datos. Si tienes varias instancias que necesitan actualizarse, el tiempo de actualización aumentará proporcionalmente. Si incluyes réplicas en la actualización, la operación puede tardar hasta una hora en completarse, en función del número de réplicas que tenga tu instancia principal.

¿Puedo monitorizar cada paso del proceso de actualización?
Aunque Cloud SQL te permite monitorizar si una operación de actualización sigue en curso, no puedes hacer un seguimiento de los pasos individuales de cada actualización.
¿Puedo cancelar el cambio a un plan superior después de haberlo iniciado?
No, no puedes cancelar una actualización una vez que haya empezado. Si la actualización falla, Cloud SQL recupera automáticamente la instancia en la versión anterior.
¿Qué ocurre con mi configuración durante una actualización?

Cuando realizas una actualización in situ de la versión principal, Cloud SQL conserva los ajustes de tu base de datos, incluido el nombre de la instancia, la dirección IP, los valores de las marcas configuradas explícitamente y los datos de usuario. Sin embargo, el valor predeterminado de las variables del sistema puede cambiar. Por ejemplo, el valor predeterminado de la marca character_set_server en MySQL 5.7 es utf8. Cuando actualices a MySQL 8.0, el valor predeterminado de la marca cambiará a utf8mb4. Para volver a utf8, restaura el valor anterior de la marca.

Para obtener más información, consulta Configurar marcas de bases de datos. Si una marca o un valor concretos ya no se admiten en la versión de destino, Cloud SQL quitará automáticamente la marca durante la actualización.

¿Qué puedo hacer si la replicación deja de funcionar después de actualizar una réplica?

Si la replicación se interrumpe después de actualizar una réplica, Cloud SQL revierte la réplica a la versión principal de MySQL de la instancia principal. Puedes volver a actualizar la réplica, pero si el problema persiste, es posible que la replicación vuelva a fallar. Por este motivo, te recomendamos que incluyas tus réplicas cuando realices una actualización de versión principal en lugar de actualizar cada réplica por separado.

Si la réplica no se revierte a la misma versión principal que la instancia principal, tienes dos opciones:

  1. Elimina la réplica dañada, crea una nueva y actualízala.

    Si la actualización vuelve a fallar, es probable que se deba a cambios incompatibles que se añadieron a la instancia principal cuando se actualizó. Soluciona los problemas de la actualización para localizar el problema, corrige la instancia principal e intenta actualizar la réplica. Para obtener más información, consulta Solucionar problemas.

  2. Actualizar la instancia principal

    Si el subproceso de réplica no funciona, la operación de actualización en la instancia principal volverá a crear las réplicas.

¿Por qué mi réplica actualizada ha vuelto a la versión principal anterior?

Si una actualización no se realiza correctamente, la réplica se restaura a la versión de la instancia principal. Puedes volver a actualizar la réplica, pero, si el problema persiste, puedes consultar el registro mysql.err de la réplica para encontrar la fuente. Busca palabras clave como [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Si el mensaje de error contiene Access denied for AuthId.... con cambios en los privilegios de usuario, es probable que se esté ejecutando una consulta con los privilegios de usuario de MySQL 5.7 en los esquemas mysql y sys, y que se produzca un error debido a los cambios en los sistemas de seguridad y gestión de cuentas de MySQL 8.0. Para solucionar este problema, debes detener las consultas en la instancia principal antes de actualizarla a la nueva versión y, a continuación, volver a intentar actualizar la réplica. Cloud SQL recomienda que detenga temporalmente todas esas consultas en la instancia principal antes de actualizar a la nueva versión, ya que podría provocar un problema similar.

Si no ves el motivo del fallo, como Access denied for AuthID.... en los registros de MySQL, es probable que el problema se deba a que se han añadido datos nuevos incompatibles a la instancia principal después de que se actualizara la réplica. Consulta cómo prepararte para actualizar una versión principal para solucionar los problemas de incompatibilidad antes de volver a actualizar.

Siguientes pasos