Prácticas recomendadas generales

MySQL | PostgreSQL | SQL Server

En esta página, se proporcionan las prácticas recomendadas para obtener rendimiento, durabilidad y disponibilidad óptimos de Cloud SQL.

Si se producen problemas con tu instancia de Cloud SQL, revisa lo siguiente cuando trates de solucionarlos:

Configuración y administración de instancia

Práctica recomendada	Más información
Lee y sigue los lineamientos operativos para asegurarte de que tus instancias estén cubiertas por el ANS de Cloud SQL.
Configura un período de mantenimiento para tu instancia principal a fin de controlar cuándo pueden ocurrir las actualizaciones con interrupciones.	Consulta Período de mantenimiento.
Para cargas de trabajo con alto contenido de lectura, agrega réplicas de lectura con el objetivo de aliviar el tráfico de la instancia principal.	De forma opcional, puedes usar un balanceador de cargas, como HAProxy para gestionar el tráfico hacia las réplicas.
Si borras y vuelves a crear instancias con regularidad, usa una marca de tiempo en el ID de instancia para aumentar la probabilidad de que puedan usarse ID de instancia nuevos.
No inicies una operación administrativa antes de que haya finalizado la operación anterior.	Las instancias de Cloud SQL no aceptan solicitudes de operación nuevas hasta haber completado la operación anterior. Si intentas iniciar una operación nueva de forma prematura, fallará la solicitud de operación. Esto incluye reinicios de la instancia. El estado de la instancia en la consola de Google Cloud no refleja si una operación se está ejecutando. La marca de verificación verde solo indica que la instancia está en estado `RUNNABLE`. Para verificar si hay una operación en ejecución, ve a la pestaña Operaciones y verifica el estado de la operación más reciente.
Configura el almacenamiento para adaptar el mantenimiento fundamental de la base de datos.	Si la configuración para habilitar los aumentos de almacenamiento automáticos está inhabilitada o si el límite de aumento de almacenamiento automático está habilitado, asegúrate de tener al menos un 20% disponible de espacio para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar. A fin de recibir alertas sobre el espacio disponible en el disco que sea inferior al 20%, crea una política de alertas basada en métricas para la métrica de uso del disco con una posición de límite superior y un valor de 0.8. Para obtener más información, consulta Crea políticas de alertas basadas en métricas.
Evita el uso excesivo de tu CPU.	Puedes ver el porcentaje de CPU disponible que está utilizando tu instancia en la página de detalles de la instancia en la consola de Google Cloud. Para obtener más información, consulta Métricas. También puedes supervisar el uso de CPU y recibir alertas en un límite especificado mediante Crea políticas de alertas de límite de métricas. Para evitar el uso excesivo, puedes aumentar la cantidad de CPU para tu instancia. Para cambiar las CPU, se debe reiniciar la instancia. Si la instancia ya tiene la cantidad máxima de CPU, debes fragmentar la base de datos en varias instancias.
Evita el agotamiento de la memoria.	Cuando busques signos de agotamiento de memoria, debes usar principalmente la métrica de uso. Para evitar errores de memoria insuficiente, te recomendamos que esta métrica permanezca por debajo del 90%. También puedes usar la métrica total_usage para observar el porcentaje de memoria disponible que usa tu instancia de Cloud SQL, incluida la memoria usada por el contenedor de la base de datos y la memoria asignada por la caché del sistema operativo. Si observas la diferencia entre las dos métricas, puedes identificar cuánta memoria usan los procesos y cuánto usa la caché del sistema operativo. Puedes volver a usar la memoria en esta caché. Para predecir problemas de memoria insuficiente, verifica ambas métricas y, luego, impleméntalas. Si las métricas parecen altas, es posible que la instancia tenga poca memoria. Esto puede deberse a una configuración personalizada, a que la instancia tiene un tamaño insuficiente para la carga de trabajo o a una combinación de estos factores. Escala tu instancia de Cloud SQL para aumentar el tamaño de su memoria. Para cambiar el tamaño de la memoria de la instancia, se debe reiniciar la instancia. Si tu instancia ya tiene el tamaño máximo de memoria, debes fragmentar la base de datos en varias instancias. Para obtener más información sobre cómo supervisar ambas métricas en la consola de Google Cloud, consulta Métricas.
Asegúrate de que tu instancia tenga los ID de transacción óptimos.	Puedes ver el uso del ID de transacción de tu instancia en la página Explorador de métricas en la consola de Google Cloud si estableces `Resource Type` como `Cloud SQL Database` y `Metric` como `Percentage of instance's transaction IDs consumed`. Para obtener más información, consulta Crea gráficos con el Explorador de métricas. El ajuste y la supervisión de instancias de bases de datos pueden ayudar a reducir o evitar problemas relacionados con la aspiradora. Supervisa el uso del ID de transacción de tu instancia y habilita y ajusta los parámetros de `autovacuum` según la carga de trabajo en tu instancia. Para obtener más información, consulta Supera la protección integral de ID de transacción (TXID).

Arquitectura de datos

Práctica recomendada	Más información
Divide tus instancias grandes en instancias más pequeñas, de ser posible.	Siempre que sea posible, el uso de varias instancias más pequeñas de Cloud SQL es mejor que usar una instancia grande. Gestionar una instancia grande y monolítica presenta desafíos que no ocurren con un grupo de instancias más pequeñas.
No uses demasiadas tablas de base de datos.	Mantén el recuento de tablas de tu instancia en menos de 10,000. Demasiadas tablas de base de datos pueden afectar el tiempo de actualización de la base de datos.

Implementación de la aplicación

Práctica recomendada	Más información
Implementa prácticas adecuadas de administración de conexiones, como la agrupación de conexiones y la retirada exponencial.	El uso de estas técnicas mejora el uso de los recursos por parte de tu aplicación y te ayuda a mantenerte dentro de los límites de conexión de Cloud SQL. Para obtener más información y ejemplos de códigos, consulta la página Administra conexiones de bases de datos.
Verifica la respuesta de tu aplicación a las actualizaciones de mantenimiento, que pueden ocurrir en cualquier momento durante el período de mantenimiento.	Prueba el mantenimiento de autoservicio para simular una actualización de mantenimiento. Durante el mantenimiento la instancia deja de estar disponible durante un período breve y las conexiones existentes se descartan. La prueba de los lanzamientos de mantenimiento te permite comprender mejor cómo tu aplicación controla el mantenimiento programado y qué tan rápido se puede recuperar el sistema.
Verifica la respuesta de tu aplicación a las conmutaciones por error, que pueden ocurrir en cualquier momento.	Puedes iniciar una conmutación por error de forma manual con la consola de Google Cloud, la CLI de gcloud o la API. Consulta Inicia la conmutación por error.
Evita las transacciones grandes.	Mantén las transacciones pequeñas y cortas. Si se requiere una actualización grande de la base de datos, hazla en varias transacciones más pequeñas en lugar de en una transacción grande.
Si usas el proxy de Cloud SQL Auth, asegúrate de usar la versión más reciente.	Consulta Mantén el proxy de Cloud SQL Auth actualizado.

Importación y exportación de datos

Práctica recomendada	Más información
Usa las exportaciones sin servidores.	Las exportaciones sin servidores descargan la operación de exportación en una instancia temporal, lo que permite que la instancia principal continúe entregando consultas y realizando operaciones con su rendimiento habitual. Cuando se completa la exportación de datos, la instancia temporal se borra de forma automática.
Acelera las importaciones para tamaños de instancia más pequeños.	Para las instancias pequeñas, puedes aumentar temporalmente la CPU y la RAM de una instancia a fin de mejorar el rendimiento cuando importas conjuntos de datos grandes.
Si exportas datos para importarlos a Cloud SQL, asegúrate de usar el procedimiento adecuado.	Consulta Exporta datos desde un servidor de base de datos administrado de forma externa.

Copia de seguridad y recuperación

Práctica recomendada	Más información
Protege tus datos con la función de Cloud SQL adecuada.	Las copias de seguridad, la recuperación de un momento determinado y las exportaciones son formas de proporcionar redundancia y protección de datos. Cada una brinda protección frente a situaciones diferentes y se complementan en una estrategia sólida de protección de datos. Las copias de seguridad son livianas; proporcionan una forma de restablecer los datos en tu instancia al estado en el que se encontraban cuando se creó la copia de seguridad. Sin embargo, las copias de seguridad tienen algunas limitaciones. Si borras la instancia, también se borrarán las copias de seguridad. No puedes realizar una copia de seguridad de una sola tabla o base de datos. Si la región donde se encuentra la instancia no está disponible, no podrás restablecer la instancia desde esa copia de seguridad, incluso en una región disponible. Con la recuperación de un momento determinado, puedes recuperar una instancia tal como se encontraba en un punto específico en el tiempo. Por ejemplo, si un error provoca una pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produzca el error. Una recuperación de un momento determinado siempre crea una instancia nueva. No puedes realizar una recuperación de un momento determinado en una instancia existente. Las exportaciones toman más tiempo para crearse porque se genera un archivo externo en Cloud Storage que puede usarse a fin de recrear tus datos. Las exportaciones no se ven afectadas si borras la instancia. Además, puedes exportar solo una base de datos única o incluso una tabla, según el formato de exportación que elijas.
Ajusta el tamaño de las instancias para que se tome en cuenta la retención del registro de transacciones (binario).	La actividad de escritura alta en la base de datos puede generar un gran volumen de registros de transacciones (binario), que, a su vez, puede consumir un espacio de disco significativo y provocar el crecimiento del disco para instancias habilitadas a fin de aumentar el almacenamiento de forma automática. Recomendamos que ajustes el tamaño del almacenamiento de la instancia para tener en cuenta la retención del registro de transacciones.
Protege la instancia y las copias de seguridad contra la eliminación accidental.	Una instancia de Cloud SQL que creas en la consola de Google Cloud o a través de Terraform habilita la prevención de eliminación accidental de forma predeterminada. Usa la función de exportación en Cloud SQL para exportar tus datos y obtener una protección adicional. Usa Cloud Scheduler con la API de REST para automatizar la administración de exportaciones. En situaciones más avanzadas, Cloud Scheduler con funciones de Cloud Run para la automatización.

Práctica recomendada

Más información

Protege tus datos con la función de Cloud SQL adecuada.

Las copias de seguridad, la recuperación de un momento determinado y las exportaciones son formas de proporcionar redundancia y protección de datos. Cada una brinda protección frente a situaciones diferentes y se complementan en una estrategia sólida de protección de datos.

Las copias de seguridad son livianas; proporcionan una forma de restablecer los datos en tu instancia al estado en el que se encontraban cuando se creó la copia de seguridad. Sin embargo, las copias de seguridad tienen algunas limitaciones. Si borras la instancia, también se borrarán las copias de seguridad. No puedes realizar una copia de seguridad de una sola tabla o base de datos. Si la región donde se encuentra la instancia no está disponible, no podrás restablecer la instancia desde esa copia de seguridad, incluso en una región disponible.

Con la recuperación de un momento determinado, puedes recuperar una instancia tal como se encontraba en un punto específico en el tiempo. Por ejemplo, si un error provoca una pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produzca el error. Una recuperación de un momento determinado siempre crea una instancia nueva. No puedes realizar una recuperación de un momento determinado en una instancia existente.

Las exportaciones toman más tiempo para crearse porque se genera un archivo externo en Cloud Storage que puede usarse a fin de recrear tus datos. Las exportaciones no se ven afectadas si borras la instancia. Además, puedes exportar solo una base de datos única o incluso una tabla, según el formato de exportación que elijas.

Ajusta el tamaño de las instancias para que se tome en cuenta la retención del registro de transacciones (binario).

La actividad de escritura alta en la base de datos puede generar un gran volumen de registros de transacciones (binario), que, a su vez, puede consumir un espacio de disco significativo y provocar el crecimiento del disco para instancias habilitadas a fin de aumentar el almacenamiento de forma automática. Recomendamos que ajustes el tamaño del almacenamiento de la instancia para tener en cuenta la retención del registro de transacciones.

Protege la instancia y las copias de seguridad contra la eliminación accidental.

Una instancia de Cloud SQL que creas en la consola de Google Cloud o a través de Terraform habilita la prevención de eliminación accidental de forma predeterminada.

Usa la función de exportación en Cloud SQL para exportar tus datos y obtener una protección adicional. Usa Cloud Scheduler con la API de REST para automatizar la administración de exportaciones. En situaciones más avanzadas, Cloud Scheduler con funciones de Cloud Run para la automatización.

Ajusta y supervisa

El ajuste y la supervisión de instancias de bases de datos pueden ayudar a reducir o evitar problemas relacionados con la aspiradora.

La operación VACUUM tiene diferentes variantes con diferentes niveles de bloqueo: VACUUM y VACUUM FULL estándar. La opción VACUUM FULL puede recuperar más espacio en el disco, pero bloquea de forma exclusiva la tabla y se ejecuta con lentitud. En su lugar, usa la forma estándar de VACUUM que se puede ejecutar en paralelo con las operaciones de base de datos de producción. Cuando uses la operación VACUUM, los comandos como SELECT, INSERT, UPDATE, and DELETE seguirán funcionando con normalidad. No podrás modificar la definición de una tabla con comandos como ALTER TABLE mientras esté en silencio.

Estas son algunas recomendaciones que pueden ayudar a reducir el tiempo que lleva completar la operación VACUUM:

Aumenta la memoria del sistema y maintenance_work_mem. Esto agrupa más tuplas en cada iteración y completa el trabajo lo más rápido posible. Ten en cuenta que, cuando se ejecuta autovacuum, se pueden asignar hasta autovacuum_max_workers veces esta memoria, por lo que debes tener cuidado de no establecer el valor predeterminado demasiado alto.
La operación VACUUM genera muchos registros de escritura por adelantado (WAL). Si es posible reducir la cantidad de registros WAL, como no tener réplicas configuradas para esta instancia, la operación se completa con mayor rapidez.
Si la tabla alcanzó el límite de 2,000 millones de ID de transacción porque ninguna de las tuplas está congelada, intenta reducir la cantidad de trabajo realizado en el modo de usuario único. Una opción posible es establecer vacuum_freeze_min_age=1,000,000,000 (el valor máximo permitido, del valor predeterminado de 50,000,000). Este valor nuevo reduce la cantidad de tuplas que se congelan hasta dos veces.
La versión 12.0 de PostgreSQL y las versiones posteriores admiten limpieza y operaciones VACUUM sin limpiar las entradas de índice. Esto es crucial, ya que limpiar el índice requiere un análisis de índice completo y, si hay varios, el tiempo total depende del tamaño del índice.
Los índices más grandes consumen una cantidad significativa de tiempo para su análisis, por lo que se prefiere usar INDEX_CLEANUP OFF con el objetivo de limpiar e inmovilizar rápidamente los datos de la tabla. Las versiones de PostgreSQL anteriores a la 12.0 necesitan ajustar la cantidad de índices. Es decir, si hay índices que no son críticos, podría ser útil descartar el índice NON-CRITICAL para acelerar la operación de vacío.

¿Qué sigue?

Para obtener más información sobre las prácticas generales por motor de base de datos, consulta los siguientes artículos: