Actualiza la versión principal de la base de datos de manera local

En esta página, se describe cómo actualizar la versión principal de la base de datos mediante la actualización de tu instancia de Cloud SQL in situ en lugar de hacerlo mediante la migración de datos.

Introducción

Periódicamente, los proveedores de software de base de datos lanzan nuevas versiones principales que contienen nuevas funciones y mejoras de rendimiento y seguridad. Cloud SQL toma versiones nuevas después de su lanzamiento. Una vez que Cloud SQL ofrece compatibilidad con una versión principal nueva, puedes actualizar las instancias para mantener la base de datos actualizada.

Puedes actualizar la versión de la base de datos de una instancia in situ o mediante la migración de datos. Las actualizaciones in situ son una forma más simple de actualizar la versión principal de la instancia. No es necesario migrar datos ni cambiar strings de conexión de la aplicación. Con las actualizaciones in situ, puedes conservar el nombre, la dirección IP y otros parámetros de configuración de la instancia actual después de la actualización. Las actualizaciones in situ no requieren que traslades archivos de datos y se pueden completar más rápido. En algunos casos, el tiempo de inactividad es más corto que el que implica la migración de tus datos.

Para 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, el proceso MySQL server controla la operación de actualización in situ de MySQL. Para obtener más información sobre la operación de actualización in situ, consulta Qué actualiza el proceso de actualización de MySQL.

Planifica una actualización de la versión principal

  1. Elige una versión principal de destino.

    gcloud

    Para obtener información sobre cómo instalar y comenzar a usar la CLI de gcloud, consulta Instala la CLI de gcloud. Para obtener información sobre cómo iniciar Cloud Shell, consulta Usa Cloud Shell.

    Para verificar las versiones de las bases de datos a las que puedes orientar una actualización in situ en tu instancia, haz lo siguiente:

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

      Reemplaza INSTANCE_NAME por el nombre de la instancia.

    2. En el resultado del comando, busca la sección etiquetada upgradableDatabaseVersions.
    3. Cada subartículo muestra una versión de base de datos que está disponible para actualización. En cada subartículo, revisa los siguientes campos.
      • majorVersion: la versión principal a la que puedes orientar la actualización in situ.
      • name: la cadena de versión de la base de datos que incluye la versión principal. En 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 verificar qué versiones de bases 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 de Cloud SQL Admin.

    Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

    • INSTANCE_NAME: El 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, expande una de estas opciones:

    Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

    
upgradableDatabaseVersions:

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

    REST v1beta4

    Para verificar qué versiones de bases 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 de Cloud SQL Admin.

    Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

    • INSTANCE_NAME: El 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, expande una de estas opciones:

    Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

    
upgradableDatabaseVersions:

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

    Para obtener la lista completa de las versiones de bases de datos compatibles con Cloud SQL, consulta Versiones de bases de datos y políticas de versiones

  2. Considera las características que se ofrecen en cada versión principal de la base de datos y aborda las incompatibilidades.

    Las nuevas versiones principales agregan 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 que puedas actualizar la instancia de la base de datos, debes revisar las notas de la versión principal de destino para determinar las incompatibilidades que debes abordar.

    Después de actualizar a una versión más reciente, el valor predeterminado de algunas variables del sistema puede cambiar. 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 de forma manual el valor de la marca de la base de datos a su valor anterior. Consulta Configura marcas de base de datos para obtener más información. La mayoría de los cambios de valores predeterminados se realizan en la comunidad de MySQL (consulta más información en Actualiza los valores predeterminados del servidor).

  3. Si actualizas de MySQL 8.0 a 8.4, primero debes actualizar tus instancias a MySQL 8.0.37 o una versión posterior para poder actualizar a MySQL 8.4. Para realizar la actualización de versión secundaria, consulta Actualiza la versión secundaria de la base de datos.

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

    • Si actualizas de MySQL 5.7 a 8.0, realiza una verificación previa de las actualizaciones de MySQL 5.7 a 8.0. Puedes usar la utilidad del verificador de actualizaciones en la shell de MySQL.

    • Si actualizas de MySQL 8.0 a 8.4, realiza una verificación previa de las actualizaciones de MySQL 8.0 a 8.4. Puedes usar la utilidad del verificador de actualizaciones en la shell de MySQL.

      Si se detectan problemas durante la verificación previa, corrígelos antes de continuar con la actualización. Cloud SQL no admite la verificación previa durante una actualización de versión principal. Un intento de actualizar una instancia que falló en la verificación previa también puede fallar.

  5. Verifica el espacio en el disco y los tipos de máquina de instancia.

    Una actualización de versión principal requiere recursos adicionales, como espacio de disco, para almacenar tablas actualizadas. Si el espacio en el disco no es suficiente, la actualización falla y se revierte. Para actualizar MySQL 5.7 a 8.0, se requiere memoria adicional a fin de convertir los metadatos antiguos en el diccionario de datos nuevo. Antes de ejecutar una actualización de versión principal, asegúrate de tener más de 100,000 de memoria para cada tabla. Puedes aumentar la memoria de forma temporal si cambias el tipo de máquina.

  6. Para las actualizaciones de MySQL 5.7 a MySQL 8.0, verifica si hay cambios en los permisos de los usuarios en MySQL 8.0.

    En la versión 8.0 de Cloud SQL para MySQL, se usa una marca llamada partial_revokes, que se configura como ON de forma predeterminada. A diferencia de MySQL 5.7, esta marca quita la capacidad de usar caracteres comodín en los comandos de GRANT de la base de datos. Para garantizar que los usuarios de la base de datos tengan acceso a los esquemas correctos, modifica los privilegios de los usuarios de la base de datos antes de actualizar a MySQL 8.0. Actualiza los privilegios del usuario para usar el nombre completo de los esquemas de bases de datos requeridos en lugar de usar caracteres comodín.

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

  7. Prueba la actualización con una ejecución de prueba.

    Realiza una ejecución de prueba del proceso de actualización de extremo a extremo 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 los que probarás el proceso de actualización.

    Además de validar que la actualización se complete con éxito, ejecuta pruebas para asegurarte de que la aplicación se comporte como se espera en la base de datos actualizada.

  8. Decide el momento de la actualización.

    La actualización requiere que la instancia deje de estar disponible durante un período. Planifica la actualización durante un período en el que la actividad de la base de datos sea baja.

Prepárate para una actualización de versión principal

Antes de realizar la actualización, completa los siguientes pasos:

  1. Para actualizaciones de MySQL 5.7 a 8.0 SOLO: Comprueba y soluciona los problemas incompatibles que se encontraron durante el proceso de comprobación previa. Estos son algunos de los problemas comunes que se encuentran:

    1. Se agregaron 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 la tabla.
    3. Transiciones de XA no confirmadas que se deben confirmar (con la declaración XA COMMIT) o revertir (con la declaració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 de combinación de columnas. Para obtener más información, consulta Tipo de datos espaciales.

    Si deseas obtener más información, consulta Prepara la instalación para la actualización y Actualiza a MySQL 8.0.

    Para actualizaciones de MySQL 8.0 a 8.4 SOLO: Comprueba y soluciona los problemas incompatibles que se encontraron durante el proceso de comprobación previa. Estos son algunos problemas comunes:

    • Terminología de replicación desactualizada. Los términos MASTER y SLAVE se quitaron por completo de MySQL 8.4. Si aún usas comandos o parámetros de configuración con estos términos, debes reemplazarlos o quitarlos. Para obtener más información sobre la eliminación y el reemplazo 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 existentes para usar el complemento de autenticación caching_sha2_password en lugar del complemento mysql_native_password obsoleto.

      Para cambiar las cuentas de usuario de la base de datos existentes 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';
      Reemplaza username y user_password por los valores de la cuenta de usuario que deseas actualizar.

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

    Las actualizaciones de versiones principales requieren espacio y memoria adicionales en el disco para almacenar las tablas actualizadas y el diccionario de datos nuevo. Si no hay el espacio necesario en el disco, la actualización fallará y se revertirá a la versión original. Cloud SQL recomienda que tengas un mínimo de 100,000 en memoria para cada tabla.

    Nota: Para aumentar la memoria de forma temporal, cambia el tipo de máquina antes de ejecutar la actualización de la versión principal. Para obtener más información, consulta Cambia el tipo de máquina.

  3. Actualiza las réplicas de lectura.

    Si usas réplicas de lectura, primero debes actualizar todas las réplicas de lectura antes de actualizar la instancia principal. Si la réplica se actualiza, pero la instancia principal no lo hace, puede que la replicación falle si la principal usa declaraciones o funciones que ya no son compatibles con una versión posterior de MySQL que la réplica usa. Para evitar estos problemas, Cloud SQL recomienda lo siguiente:

    1. Actualiza el nodo principal inmediatamente después de actualizar las réplicas.
    2. Evita ejecutar consultas que no sean compatibles con la versión nueva en la instancia principal hasta que la actualización se haya completado correctamente.
    3. Opcional: Pausa todas las declaraciones WRITE en la instancia principal hasta que se complete la actualización de forma correcta.
    4. Opcional: De manera opcional, quita todas las réplicas antes de actualizar la instancia principal y vuelve a crearlas una vez que se complete la actualización.

    Si la replicación se interrumpe, la réplica se revierte a la versión de la instancia principal. Puedes volver a actualizar la réplica, pero si el problema persiste, consulta las Preguntas frecuentes.

Actualiza la versión principal de la base de datos de manera local

Cuando inicias una operación de actualización, Cloud SQL primero verifica la configuración de tu instancia a fin de garantizar que sea compatible con una actualización. Después de verificar tu configuración, Cloud SQL hace que tu instancia deje de estar disponible, realiza una copia de seguridad previa a la actualización, ejecuta la actualización, hace que la instancia esté disponible otra vez y realiza una copia de seguridad posterior a la actualización.

Cuando actualizas a MySQL 8.0, Cloud SQL aprovisiona de forma automática tu instancia en la versión secundaria predeterminada.

Console

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

    Ir a Instancias de Cloud SQL

  2. Para abrir la página de Descripción general 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 deseas ir a la página de actualización.
  5. En la página Elige una versión para 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 base de datos disponibles.
  6. Haz clic en Continuar.
  7. En el cuadro ID de instancia, ingresa el nombre de la instancia y, luego, haz clic en el botón Iniciar actualización.
La operación tarda varios minutos en completarse.

Verifica que la versión principal de la base de datos actualizada aparezca debajo del nombre de la instancia en la página Descripción general 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, reemplaza lo siguiente:

    • INSTANCE_NAME: El nombre de la instancia
    • DATABASE_VERSION: La enumeración de la versión principal de la base de datos, que debe ser posterior que 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 esta enumeración como el primer paso del plan de actualización. Si necesitas una lista completa de las enumeraciones 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 indica que la operación está tardando más de lo esperado. Puedes ignorar este mensaje o ejecutar el comando gcloud sql operations wait para descartarlo.

  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, reemplaza la variable INSTANCE_NAME por el nombre de la instancia. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Supervisa el estado de la actualización.

    Usa el comando gcloud sql operations describe.

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

    gcloud sql operations describe OPERATION

REST v1

  1. Inicia la actualización local.

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

    Antes de usar cualquiera de los datos de la solicitud, reemplaza 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
}

    Reemplaza DATABASE_VERSION por la enumeración de la versión principal de la base de datos, que debe ser posterior que 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 esta enumeración como el primer paso del plan de actualización. Si necesitas una lista completa de las 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 reemplazar PROJECT_ID por el ID del proyecto.

    Método HTTP y URL:

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

  3. Supervisa el estado de la actualización.

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

    • PROJECT_ID: El ID del proyecto.
    • OPERATION_NAME: El nombre de la operación de actualización que se recuperó 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 tu configuración de Terraform en un proyecto de Google Cloud, completa los pasos de las siguientes secciones.

Prepara Cloud Shell

  1. Inicia Cloud Shell

  2. Establece el proyecto de Google Cloud predeterminado en el que deseas aplicar tus configuraciones de Terraform.

    Solo necesitas ejecutar este comando una vez por proyecto y puedes ejecutarlo en cualquier directorio.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

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

Prepara 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 dentro de ese directorio. El nombre del archivo debe tener la extensión .tf, por ejemplo, main.tf. En este instructivo, el archivo se denomina main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Si sigues un instructivo, puedes copiar el código de muestra en cada sección o paso.

    Copia el código de muestra en el main.tf recién creado.

    De manera opcional, copia el código de GitHub. Esto se recomienda cuando el fragmento de Terraform es parte de una solución de extremo a extremo.

  3. Revisa y modifica los parámetros de muestra que se aplicarán a tu entorno.
  4. Guarda los cambios.
  5. Inicializa Terraform. Solo debes hacerlo una vez por directorio. 
    terraform init

    De manera opcional, incluye la opción -upgrade para usar la última versión del proveedor de Google: 

    terraform init -upgrade

Aplica los cambios

  1. Revisa la configuración y verifica que los recursos que creará o actualizará Terraform coincidan con tus expectativas: 
    terraform plan

    Corrige la configuración según sea necesario.

  2. Para aplicar la configuración de Terraform, ejecuta el siguiente comando y, luego, escribe yes cuando se te solicite: 
    terraform apply

    Espera hasta que Terraform muestre el mensaje “¡Aplicación completa!”.

  3. Abre tu proyecto de Google Cloud para ver los resultados. En la consola de Google Cloud, navega a tus recursos en la IU para asegurarte de que Terraform los haya creado o actualizado.

Borra los cambios

Para borrar tus cambios, haz lo siguiente:

  1. Para inhabilitar la protección contra la eliminación, en tu archivo de configuración de Terraform, establece el argumento deletion_protection en false. 
    deletion_protection =  "false"
  2. Para aplicar la configuración actualizada de Terraform, ejecuta el siguiente comando y, luego, ingresa yes cuando se te solicite: 
    terraform apply

  1. Quita los recursos que se aplicaron antes con tu configuración de Terraform mediante la ejecución del siguiente comando y, luego, ingresa yes cuando se te solicite:

    terraform destroy

Cuando envías una solicitud de actualización local, Cloud SQL primero realiza una verificació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á con un mensaje que sugiere cómo abordar el problema. Consulta también Soluciona problemas de una actualización de versión principal.

Copias de seguridad automáticas de actualización

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

  • La primera copia de seguridad de actualización es la copia de seguridad previa a la actualización, que se realiza inmediatamente antes de comenzar la actualización. Puedes usar esta copia de seguridad para restablecer la instancia de la base de datos a su estado en la versión anterior.
  • La segunda copia de seguridad es la copia de seguridad posterior a la actualización, que se realiza inmediatamente después de que se permiten nuevas operaciones de escritura en la instancia de la base de datos actualizada.

Cuando ves tu lista de copias de seguridad, las copias de seguridad de actualización se enumeran con el tipo On-demand. Las copias de seguridad de actualización están etiquetadas para que puedas identificarlas con facilidad. Por ejemplo, si actualizas de MySQL 5.7 a MySQL 8.0, la copia de seguridad previa a la actualización se etiqueta como Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. y la copia de seguridad posterior a la actualización Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7.. Si actualizas de MySQL 8.0 a MySQL 8.4, la copia de seguridad previa a la actualización se etiqueta como Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. y la copia de seguridad posterior a la actualización 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 actualización persisten hasta que las borres o borres la instancia. Si tienes habilitada la PITR, no puedes borrar las copias de seguridad de actualización mientras se encuentran en el período de retención. Si necesitas borrar tus copias de seguridad de actualización, debes inhabilitar la PITR o esperar hasta que las copias de seguridad de actualización ya no estén en el período de retención.

Completa la actualización de la versión principal

Luego de que termines de actualizar la instancia principal, realiza los siguientes pasos para completar la actualización:

  1. Realiza pruebas de aceptación.

    Ejecuta pruebas para confirmar que el sistema actualizado tenga el rendimiento esperado.

  2. Opcional: Actualiza los privilegios de usuario.

    Si actualizaste MySQL 8.0, ten en cuenta que MySQL cambió los sistemas de administración de cuentas y seguridad. Para obtener más información, consulta Novedades de MySQL 8.0.

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

    Si actualizaste de MySQL 8.0 a MySQL 8.4, hay cambios adicionales en los privilegios de los usuarios, incluida la adición de privilegios que se introdujeron en MySQL 8.4 y la eliminación de los privilegios que existían en MySQL 8.0. Para obtener más información, consulta Privilegios de usuario de MySQL 8.4 (cloudsqlsuperuser).

    Para actualizar los privilegios del usuario en MySQL 8.0 o MySQL 8.4, haz lo siguiente:

    1. Crea un usuario con la función cloudsqlsuperuser otorgada.

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

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

    3. Otorga los privilegios esperados al usuario actualizado.

  3. Opcional: Crea una copia de seguridad.

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

  4. Opcional: Si actualizaste a Cloud SQL para MySQL 8.4, también actualiza todos los conectores, clientes y shells de MySQL a MySQL 8.4.

Soluciona problemas de una actualización de versión principal

Cloud SQL muestra 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 versión nueva.

Si tu solicitud de actualización falla, verifica su sintaxis. Si la solicitud tiene una estructura válida, intenta con las siguientes sugerencias.

Visualiza los registros de actualización

Si se produce algún problema con una solicitud de actualización válida, Cloud SQL publica 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 que te ayuda a identificarla con el error de actualización. Busca estos errores de actualización y resuélvelos.

Para ver los registros de errores, sigue estos pasos:

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

    Ir a Instancias de Cloud SQL

  2. Para abrir la página de Descripción general de una instancia, haz clic en su nombre.

  3. En el panel Operaciones y registros de la página Descripción general de la instancia, haz clic en el vínculo Ver registros de errores de MySQL.

    Se abrirá la página Explorador de registros.

  4. Visualiza los registros de la siguiente manera:

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

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

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

    por 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 de 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"

Restablece a la versión principal anterior

Si el sistema de la base de datos actualizada no funciona como se espera, es posible que debas restablecer la instancia a la versión anterior. Para ello, restablece tu copia de seguridad previa a la actualización en una instancia de recuperación de Cloud SQL, que es una instancia nueva que ejecuta la versión previa a la actualización.

Para restablecer a la versión anterior, realiza los siguientes pasos:

  1. Identifica la copia de seguridad previa a la actualización.

    Consulta Copias de seguridad automáticas de actualización.

  2. Crea una instancia de recuperación.

    Crea una nueva instancia de Cloud SQL con la versión principal que ejecutaba Cloud SQL cuando se hizo la copia de seguridad previa a la actualización. Establece las mismas marcas y la configuración de instancia que usa la instancia original.

  3. Restablece la copia de seguridad previa a la actualización.

    Restablece la copia de seguridad previa a la actualización en la instancia de recuperación. Esto puede tardar varios minutos en completarse.

  4. Agrega las réplicas de lectura.

    Si usabas réplicas de lectura, agrégalas de forma individual.

  5. Conecta tu aplicación.

    Después de recuperar el sistema de la base de datos, actualiza la aplicación con detalles sobre la instancia de recuperación y sus réplicas de lectura. Puedes reanudar la entrega de tráfico en la versión previa a la actualización de tu base de datos.

Limitaciones

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

  • No puedes realizar una actualización local de versión principal en una réplica externa.
  • La actualización de instancias de MySQL 5.7 a 8.0 que tienen más de 512,000 tablas podrían llevar mucho tiempo y generar tiempo de espera.
  • La actualización de instancias de MySQL 8.0 a 8.4 que tienen más de 512,000 tablas podrían llevar mucho tiempo y generar tiempo de espera.

  • Cuando actualizas de MySQL 8.0 a 8.4, si actualizaste una réplica a MySQL 8.4, pero no la instancia principal, es posible crear una cuenta de usuario nueva 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 bien crea solo cuentas de usuario nuevas en la instancia principal con el siguiente comando.

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

    Reemplaza USERNAME y PASSWORD por los valores adecuados.

Preguntas frecuentes

Las siguientes preguntas pueden surgir cuando actualizas la versión principal de la base de datos.

¿Mi instancia no está disponible durante una actualización?
Sí. Tu instancia permanece no disponible durante un período mientras Cloud SQL realiza la actualización.
¿Cuánto demora una actualización?

La actualización de una sola instancia suele tomar menos de 10 minutos. Si la configuración de tu instancia usa una pequeña cantidad de CPU virtuales o memoria, es posible que la actualización tarde más tiempo.

Si tu instancia aloja demasiadas bases de datos o tablas, o tus bases de datos son muy grandes, es posible que la actualización tarde horas o incluso se agote el tiempo de espera porque el tiempo de actualización corresponde a la cantidad de objetos en tus bases de datos. Si tienes que actualizar múltiples instancias, el tiempo de actualización total aumenta de forma proporcional.

¿Puedo supervisar cada paso de mi proceso de actualización?
Si bien Cloud SQL te permite supervisar si una operación de actualización aún está en curso, no puedes realizar un seguimiento de los pasos individuales en cada actualización.
¿Puedo cancelar la actualización después de iniciarla?
No, no puedes cancelar una actualización una vez que se inicia. Si la actualización falla, Cloud SQL recupera de forma automática la instancia en la versión anterior.
¿Qué sucede con mi configuración durante una actualización?

Cuando realizas una actualización local de versión principal, Cloud SQL conserva la configuración de tu base de datos, incluidos el nombre de la instancia, la dirección IP, los valores de marca configurados de manera explícita y los datos del usuario. Sin embargo, el valor predeterminado de las variables de sistema puede cambiar. Por ejemplo, el valor predeterminado de la marca character_set_server en MySQL 5.7 es utf8. Cuando actualizas a MySQL 8.0, el valor predeterminado de la marca cambia a utf8mb4. Para revertirlo a utf8, vuelve a establecer el valor de la marca en el valor anterior.

Para obtener más información, consulta Configura marcas de base de datos. Si una marca o un valor de marca determinados ya no son compatibles con tu versión de destino, Cloud SQL quita automáticamente la marca durante la actualización.

¿Qué puedo hacer si se interrumpe la replicación después de actualizar la réplica?
Si la replicación se interrumpe después de actualizar la réplica, se revierte a la versión de MySQL de la instancia principal. Puedes actualizar la réplica nuevamente, pero si el problema persiste, es posible que la replicación vuelva a fallar.

Si la réplica no se revierte, tienes dos opciones:

  1. Borra la réplica rota, crea una réplica nueva y actualiza la réplica nueva.

    Si la actualización vuelve a fallar, es probable que se deba a cambios incompatibles que se agregaron a la instancia principal cuando se actualizó. Realiza problemas para actualizar el problema, corrige la instancia principal y, luego, intenta actualizar la réplica. Consulta la solución de problemas para obtener más información.

  2. Actualiza la instancia principal

    La operación de actualización en la instancia principal vuelve a crear las réplicas si el subproceso de réplica no funciona.

¿Por qué mi réplica actualizada se revirtió a la versión anterior?

Si una actualización no se realiza con éxito, la réplica se revierte a la versión de la instancia principal. Puedes volver a actualizar la réplica, pero si el problema persiste, puedes verificar el registro mysql.err en 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 una consulta se esté ejecutando con privilegios de usuario de MySQL 5.7 en los esquemas de MySQL y sys, y podría fallar debido a los cambios en los sistemas de administración de cuentas y seguridad en MySQL 8.0. Para resolver este problema, deberás detener las consultas en la instancia principal antes de actualizar a la nueva versión y volver a intentar la actualización de la réplica. Cloud SQL recomienda detener todas las consultas de este tipo en la instancia principal antes de actualizar a la versión nueva, ya que esto podría causar problemas similares.

Si no ves el motivo de la falla, como Access denied for AuthID.... en los registros de MySQL, es probable que el problema se deba a datos incompatibles nuevos que podrían haberse agregado a la instancia principal después de que se haya actualizado la réplica. Consulta Prepárate para una actualización de versión principal sobre cómo solucionar problemas de incompatibilidad antes de volverlas a actualizar.

¿Qué sigue?