Actualización in situ

En esta página, se describe cómo realizar actualizaciones y cambios a versiones anteriores in situ de tus instancias de Cloud SQL.

Realiza cambios in situ en una instancia de Cloud SQL

Puedes usar los cambios in situ para actualizar o cambiar a una versión anterior de la edición de tu instancia de Cloud SQL, su tipo de máquina, tipo de almacenamiento o versión de la base de datos. Realizar cambios in situ es la forma más fácil y menos propensa a errores de volver a configurar una instancia.

Antes de comenzar

Asegúrate de que tu instancia se ejecute en la versión 8.0.31 de MySQL o una posterior.

Si tu instancia está en una versión anterior de MySQL, debes actualizar a MySQL 8.0.31 o una versión posterior. Para obtener más información, consulta Actualiza la versión principal de la base de datos en el lugar y Actualiza la versión secundaria de la base de datos.

Ten en cuenta los posibles cambios de almacenamiento relacionados con el tipo de máquina

Las diferentes ediciones admiten diferentes tipos de máquinas que usan diferentes opciones de almacenamiento. Los tipos de máquinas C4 y C4A de alto rendimiento usan Hyperdisk Balanced storage en lugar de una de las opciones de Persistent Disk que usan los tipos de máquinas más antiguos.

Cuando realizas un cambio en la edición o el tipo de máquina que usas, también puede cambiar el tipo de almacenamiento, lo que puede generar un tiempo de inactividad y un cambio en los costos de almacenamiento. Cuando te mudas a Google Cloud Hyperdisk Balanced, hay opciones de configuración adicionales que puedes especificar. Para obtener más información, consulta Cambios de almacenamiento.

Ten en cuenta los cambios de almacenamiento de registros de transacciones de PITR

Si actualizas una instancia de Cloud SQL Enterprise que almacena los registros binarios que se usan para PITR en el disco, ten en cuenta que el proceso de actualización a la edición Cloud SQL Enterprise Plus mueve la ubicación de almacenamiento de esos registros del disco a Cloud Storage. Para determinar la ubicación actual de los registros binarios de PITR de tu instancia, consulta Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR.

Para obtener una explicación completa de cómo las actualizaciones in situ pueden afectar la ubicación de los registros binarios, consulta Cambios en la ubicación de almacenamiento de los registros binarios para PITR.

Cambia la edición de una instancia in situ

En esta sección, se muestra cómo cambiar la edición de tu instancia de Cloud SQL in situ a la edición Cloud SQL Enterprise Plus o desde ella. La edición Cloud SQL Enterprise Plus ofrece algunos beneficios y mejoras de rendimiento que la edición Cloud SQL Enterprise no ofrece. Para obtener más información sobre las ediciones de Cloud SQL, consulta Descripción general de las ediciones de Cloud SQL.

La actualización a la edición Cloud SQL Enterprise Plus tarda unos minutos en completarse y tiene un tiempo de inactividad casi nulo. Si vuelves a la edición Cloud SQL Enterprise, se producirá un tiempo de inactividad más prolongado. Ninguno de los procesos requiere cambiar los extremos a los que se conectan tus aplicaciones.

Usa el procedimiento de esta sección para actualizar una instancia de Cloud SQL Enterprise a la edición Cloud SQL Enterprise Plus o para cambiar una instancia de Cloud SQL Enterprise Plus a la edición Cloud SQL Enterprise.

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

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

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Opciones para cambios in situ

Cambiar la edición de tu instancia de Cloud SQL puede requerir cambiar su serie de máquinas, lo que, a su vez, afecta su tipo de almacenamiento.

Cambios de máquina

Cuando cambias de edición, también debes cambiar el tipo de máquina. Consulta Elige una serie de máquinas para obtener más información sobre las series de máquinas que admite Cloud SQL.

Cuando actualizas de la edición Cloud SQL Enterprise a la edición Cloud SQL Enterprise Plus, puedes elegir entre las N2, C4A, y C4 series de máquinas.

Cuando cambias de la edición Cloud SQL Enterprise Plus a la edición Cloud SQL Enterprise, puedes elegir entre una de uso general con núcleo dedicado, y una serie de máquinas N4.

También puedes cambiar el tipo de máquina sin cambiar la edición. Después de elegir editar tu instancia, ve a la subsección Máquina de Configuración de la máquina en el área Personaliza tu instancia. Con el menú desplegable, puedes seleccionar un tipo de máquina diferente. También puedes elegir una cantidad diferente de CPU virtuales y habilitar o inhabilitar la caché de datos si es necesario.

Para obtener información más general, consulta también la documentación de Compute Engine para las series de máquinas N2, C4A, C4 y N4.

Cambios de almacenamiento

Si cambias de una serie de máquinas de uso general o N2 a una serie de máquinas N4, C4A o C4, tu almacenamiento se migrará de la unidad de estado sólido (SSD) al almacenamiento de Google Cloud Hyperdisk Balanced. Por lo general, esta actualización requiere un tiempo de inactividad mínimo.

El almacenamiento de Google Cloud Hyperdisk Balanced se puede personalizar para tu caso de uso si configuras lo siguiente:

• Capacidad de almacenamiento
• IOPS aprovisionadas
• Capacidad de procesamiento aprovisionada

Google Cloud Hyperdisk Balanced establece valores y límites predeterminados de IOPS y capacidad de procesamiento según la configuración de tu instancia, que incluye el tipo de máquina y la capacidad de almacenamiento. La capacidad de almacenamiento limita el valor predeterminado, y el tipo de máquina establece el valor máximo para las IOPS y la capacidad de procesamiento. Consulta Elige una opción de almacenamiento para obtener más detalles.

Cambios de ubicación de los registros binarios para PITR

Si tu instancia de Cloud SQL Enterprise almacena registros de transacciones para PITR en el disco, cuando se inicia el proceso de actualización a la edición Cloud SQL Enterprise Plus, se cambia la ubicación de almacenamiento de estos registros a Cloud Storage.

Se aplican las siguientes condiciones al cambio de ubicación:

• El proceso tarda aproximadamente la duración de la transactionLogRetentionDays configuración de la PITR para completar el cambio a Cloud Storage.
• Si tienes valores establecidos para las marcas expire_logs_days o binlog_expire_logs_seconds en tu instancia, esos valores se conservan.
• Durante el cambio a Cloud Storage, no puedes modificar los valores para las marcas expire_logs_days o binlog_expire_logs_seconds en la instancia.
• Durante el cambio a Cloud Storage, te recomendamos que no modifiques los parámetros de configuración de la PITR transactionLogRetentionDays. Incluso si aumentas transactionLogRetentionDays, los registros binarios no se conservarán en el disco más tiempo que el valor predeterminado de 7 días para una instancia de Cloud SQL Enterprise.

• Mientras el cambio está en curso, Cloud SQL solo retiene registros en el disco para el valor mínimo de uno de los siguientes:
  • La configuración de la PITR transactionLogRetentionDays antes del cambio, 7 días de forma predeterminada
  • las marcas expire_logs_days o binlog_expire_logs_seconds establecidas de forma manual en tu instancia
• Después del cambio, Cloud SQL retiene la misma cantidad de registros binarios en el disco que tenías antes del cambio a menos que hubieras configurado las marcas expire_logs_days o binlog_expire_logs_seconds en tu instancia. Si configuraste estas marcas, Cloud SQL retiene registros binarios en el disco según el valor mínimo de la configuración transactionLogRetentionDays o el valor de las marcas.

Valores predeterminados de almacenamiento de registros y copia de seguridad de la edición Cloud SQL Enterprise Plus

Una vez que se completa el cambio a Cloud Storage de una instancia, Cloud SQL aún retiene copias de los registros binarios en el disco para fines de replicación. Almacenar registros binarios en el disco puede ser útil si deseas explorar los registros binarios con la utilidad mysqlbinlog.

Si configuraste las marcas expire_logs_days y binlog_expire_logs_seconds en tu instancia antes de la actualización, los valores configurados permanecerán intactos.

Después del cambio, ya que los registros binarios que se usan para realizar la PITR ahora se almacenan en Cloud Storage, asegúrate de que los valores de las marcas reflejen la retención de los registros de transacciones en el disco que esperas. Cloud SQL solo retiene registros en el disco para el valor mínimo de uno de los siguientes:

• la configuración de la PITR transactionLogRetentionDays antes del cambio, 7 días de forma predeterminada
• las marcas expire_logs_days o binlog_expire_logs_seconds establecidas de forma manual en tu instancia

Si deseas ahorrar espacio en el disco, después de que se complete la actualización, configura el valor de la marca expire_logs_days o binlog_expire_logs_seconds en el equivalente a 1 día para poder reducir el tamaño de disco asignado y costos de almacenamiento en disco. Para obtener más información sobre el almacenamiento de registros de transacciones y la PITR, consulta Almacenamiento de registros para PITR.

Una vez que se completa la actualización a la edición Cloud SQL Enterprise Plus, el período predeterminado de retención de registros de transacciones para todas las instancias actualizadas aumenta a 14 días. Para este aumento y cualquier otro aumento que configures para el período de retención de los registros de transacciones, demora hasta el mayor valor nuevo en alcanzar el período de retención completo de la PITR. Por ejemplo, si el valor anterior para los días de retención de registros de transacciones es 7 y el valor nuevo se incrementa a 14, el período para la PITR durante los primeros 7 días después de la actualización es de solo 7 días. El octavo día, el período para la PITR es de 8 días, el noveno día es de 9 días, hasta que el período de retención finalmente aumenta a 14 días el día 14.

Además, la cantidad predeterminada de copias de seguridad automáticas aumenta de 8 a 15.

Si actualizas a la edición Enterprise Plus de Cloud SQL después de realizar una actualización de versión principal, no podrás realizar la PITR en un momento determinado que ocurra antes de la actualización de la versión principal. Esta limitación se aplica incluso si tu período de retención abarca ese período. Puedes restablecer la instancia a un momento determinado después de iniciar la actualización de la versión principal.