Actualización in situ

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

Realiza cambios en una instancia de Cloud SQL

Puedes usar los cambios in situ para actualizar o cambiar a una versión anterior la edición, el tipo de máquina o el tipo de almacenamiento de tu instancia de Cloud SQL, o bien para actualizar su versión de 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 o posterior de MySQL.

Si tu instancia está en una versión anterior de MySQL, debes actualizarla 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 distintas opciones de almacenamiento. Los tipos de máquinas C4 y C4A de alto rendimiento usan el almacenamiento Hyperdisk Balanced en lugar de una de las opciones de disco persistente que usan los tipos de máquinas más antiguos.

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

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

Si actualizas una instancia de Cloud SQL Enterprise que almacena los registros binarios que se usan para la 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 la 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 la PITR.

Cómo cambiar la edición de una instancia en el lugar

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 Enterprise Plus de Cloud SQL ofrece algunos beneficios y mejoras de rendimiento que la edición Enterprise de Cloud SQL no ofrece. Para obtener más información sobre las ediciones de Cloud SQL, consulta la Descripción general de las ediciones de Cloud SQL.

La actualización a la edición Enterprise Plus de Cloud SQL tarda unos minutos en completarse y tiene un tiempo de inactividad casi nulo. Si vuelves a cambiar a la edición de Cloud SQL Enterprise, el tiempo de inactividad será 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 que cambies su serie de máquinas, lo que, a su vez, afecta su tipo de almacenamiento.

Cambios en la 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 series de máquinas N2, C4A y C4.

Cuando cambias de la edición Cloud SQL Enterprise Plus a la edición Cloud SQL Enterprise, puedes elegir entre un núcleo dedicado de uso general 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 máquina en el área Personaliza tu instancia. En el menú desplegable, puedes seleccionar otro tipo de máquina. También puedes elegir una cantidad diferente de CPUs 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 en el 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 unidad de disco de estado sólido (SSD) a almacenamiento Google Cloud Hyperdisk balanced. Por lo general, esta actualización requiere un tiempo de inactividad mínimo.

El almacenamiento de Hyperdisk Balanced de Google Cloud se puede personalizar para tu caso de uso con los siguientes parámetros de configuración:

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

Google Cloud Hyperdisk Balanced establece los valores predeterminados y los límites 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 la 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 configuración de la PITR transactionLogRetentionDays para completar el cambio a Cloud Storage.
• Si tienes valores establecidos para la marca 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 tu instancia.
• Durante el cambio a Cloud Storage, te recomendamos que no modifiques el parámetro 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 conserva los registros en el disco para el valor mínimo de una de las siguientes opciones:
  • El parámetro de configuración de la PITR transactionLogRetentionDays anterior al cambio, que es de 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 la 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.