Prácticas recomendadas generales

Esta página proporciona prácticas recomendadas para obtener el mejor rendimiento, durabilidad y disponibilidad de Cloud SQL.

Si tienes problemas con tu instancia de Cloud SQL, revisa lo siguiente durante la solución de problemas:

Configuración y administración de instancias

Práctica recomendada Más información
Lee y sigue las directrices operativas para asegurarte de que tus instancias estén cubiertas por el acuerdo de nivel de servicio de Cloud SQL.
Configura una ventana de mantenimiento para tu instancia principal y controla cuándo se pueden producir actualizaciones disruptivas. Consulta Ventana de mantenimiento.
En el caso de las cargas de trabajo con muchas lecturas, añade réplicas de lectura para descargar el tráfico de la instancia principal. También puedes usar un balanceador de carga, como HAProxy, para gestionar el tráfico a las réplicas.
Si elimina y vuelve a crear instancias con regularidad, utilice una marca de tiempo en el ID de instancia para aumentar la probabilidad de que los nuevos IDs de instancia se puedan usar.
No inicies una operación administrativa antes de que se haya completado la anterior.

Las instancias de Cloud SQL no aceptarán nuevas solicitudes de operación hasta que hayan completado la operación anterior. Si intentas iniciar una nueva operación antes de tiempo, la solicitud de operación fallará. Esto incluye reinicios de instancias.

El estado de la instancia en la consola Google Cloud no refleja si una operación se está ejecutando. La marca de verificación verde solo indica que la instancia está en el estado RUNNABLE. Para ver si una operación está en curso, ve a la pestaña Operaciones y comprueba el estado de la operación más reciente.

Configura el almacenamiento para que se adapte al mantenimiento crítico de la base de datos.

Si el ajuste de instancia Habilitar aumentos automáticos del almacenamiento está inhabilitado o el límite de aumento automático del almacenamiento está habilitado, asegúrese de que tiene al menos un 20% de espacio disponible para dar cabida a las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL.

Para recibir una alerta cuando el espacio de disco disponible sea inferior al 20%, crea una política de alertas basada en métricas para la métrica Utilización del disco con la posición Por encima del umbral y el valor 0,8. Para obtener más información, consulta Crear políticas de alertas basadas en métricas.
Evita que se utilice en exceso la CPU.

Puedes ver el porcentaje de CPU disponible que está usando tu instancia en la página de detalles de la instancia de la Google Cloud consola. Para obtener más información, consulta Métricas. También puedes monitorizar el uso de la CPU y recibir alertas cuando se alcance un umbral específico con la opción Crear políticas de alertas de umbral de métricas.

Para evitar que se sobreutilice, puedes aumentar el número de CPUs de tu instancia. Para cambiar las CPUs, es necesario reiniciar la instancia. Si tu instancia ya tiene el número máximo de CPUs, debes fragmentar tu base de datos en varias instancias.
Evita que se agote la memoria.

Cuando busques señales de agotamiento de la memoria, debes usar principalmente la métrica Uso. Para evitar errores de falta de memoria, te recomendamos que esta métrica se mantenga 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 que usa el contenedor de la base de datos y la memoria asignada por la caché del sistema operativo.

Al observar la diferencia entre las dos métricas, puedes identificar cuánta memoria usan los procesos y cuánta usa la caché del sistema operativo. Puedes reutilizar la memoria en esta caché.

Para predecir problemas de falta de memoria, comprueba ambas métricas e interprétalas conjuntamente. Si las métricas son altas, es posible que la instancia tenga poca memoria. Esto puede deberse a una configuración personalizada, a que la instancia no tenga el tamaño adecuado 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 una instancia, es necesario reiniciarla. Si tu instancia ya tiene el tamaño máximo de memoria, debes fragmentar tu base de datos en varias instancias. Para obtener más información sobre cómo monitorizar ambas métricas en la Google Cloud consola, consulta Métricas.
Asegúrate de que tu instancia tenga IDs de transacción óptimos.

Puedes ver el uso del ID de transacción de tu instancia en la página Explorador de métricas de la consola de Google Cloud . Para ello, define Resource Type como Cloud SQL Database y Metric como Percentage of instance's transaction IDs consumed. Para obtener más información, consulta Crear gráficos con el explorador de métricas.

Ajustar y monitorizar las instancias de base de datos puede ayudar a reducir o evitar los problemas relacionados con el vacío. Monitoriza el uso del ID de transacción de tu instancia y habilita y ajusta los parámetros autovacuum según la carga de trabajo de tu instancia. Para obtener más información, consulta el artículo Superar la protección de envoltorio de la ID de transacción (TXID).

Seguridad

Práctica recomendada Más información
Preferir IP privada A menos que sea necesario el acceso a la IP pública, es preferible usar la IP privada. De esta forma, se minimizan las conexiones de red no autorizadas a tu base de datos.
Evita usar 0.0.0.0/0 en Redes autorizadas No incluya 0.0.0.0/0 en Redes autorizadas, ya que permite el acceso desde Internet en todo el mundo sin restricciones.
Evita redes autorizadas demasiado grandes Evita usar prefijos CIDR pequeños en Redes autorizadas, ya que esto permite el acceso desde un número de hosts potencialmente excesivo. Recomendamos que el prefijo CIDR no sea inferior a /16 y, preferiblemente, que sea superior a /19.
Habilitar políticas de contraseñas Con las políticas de contraseñas de instancias, especifica las políticas de contraseñas adecuadas para tu instancia de base de datos para evitar que se configuren contraseñas débiles, define el tiempo de vencimiento y configura el bloqueo de cuentas en caso de intentos de inicio de sesión fallidos. Esto es especialmente importante si vas a configurar tu instancia para usar una IP pública.

Arquitectura de datos

Práctica recomendada Más información
Divide las instancias grandes en instancias más pequeñas, si es posible. Cuando sea posible, es mejor usar muchas instancias de Cloud SQL más pequeñas que una instancia grande. Gestionar una instancia monolítica grande plantea problemas que no se dan en un grupo de instancias más pequeñas.
No utilices demasiadas tablas de bases de datos.

El número de tablas de tu instancia no debe superar las 10.000. Si una base de datos tiene demasiadas tablas, puede afectar al tiempo de actualización de la base de datos.

Implementación de aplicaciones

Práctica recomendada Más información
Aplica prácticas recomendadas de gestión de conexiones, como la agrupación de conexiones o el tiempo de espera exponencial. Si usas estas técnicas, tu aplicación aprovechará mejor los recursos y te ayudará a mantenerte dentro de los límites de conexión de Cloud SQL. Para obtener más información y ejemplos de código, consulta Gestionar conexiones de bases de datos.
Prueba la respuesta de tu aplicación a las actualizaciones de mantenimiento, que pueden producirse en cualquier momento durante la ventana de mantenimiento. Prueba el mantenimiento de autoservicio para simular una actualización de mantenimiento. Durante el mantenimiento, tu instancia no estará disponible durante un breve periodo y se interrumpirán las conexiones existentes. Probar los lanzamientos de mantenimiento te permite comprender mejor cómo gestiona tu aplicación el mantenimiento programado y con qué rapidez se puede recuperar el sistema.
Prueba la respuesta de tu aplicación a las conmutaciones por error, que pueden producirse en cualquier momento. Puedes iniciar manualmente una conmutación por error mediante la Google Cloud consola, la CLI de gcloud o la API. Consulta Iniciar la conmutación por error.
Evita las transacciones grandes. Asegúrate de que las transacciones sean pequeñas y cortas. Si es necesario hacer una actualización grande de la base de datos, hazla en varias transacciones más pequeñas en lugar de en una sola transacción grande.
Si usas el proxy de autenticación de Cloud SQL, asegúrate de que sea la versión más reciente. Consulta Mantener actualizado el proxy de autenticación de Cloud SQL.

Importación y exportación de datos

Práctica recomendada Más información
Usa exportaciones sin servidor. Las exportaciones sin servidor descargan la operación de exportación en una instancia temporal, lo que permite que la instancia principal siga respondiendo a las consultas y realizando operaciones con su rendimiento habitual. Cuando se completa la exportación de datos, la instancia temporal se elimina automáticamente.
Acelera las importaciones en instancias pequeñas. En el caso de las instancias pequeñas, puedes aumentar temporalmente la CPU y la RAM de una instancia para mejorar el rendimiento al importar conjuntos de datos grandes.
Si va a exportar datos para importarlos en Cloud SQL, asegúrese de seguir el procedimiento adecuado. Consulta Exportar datos de un servidor de base de datos gestionado externamente.

Copia de seguridad y sistema de 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 a un momento dado y las exportaciones son formas de proporcionar redundancia y protección de datos. Cada una de ellas protege contra diferentes situaciones y se complementan entre sí en una estrategia de protección de datos sólida.

Las copias de seguridad son ligeras y te permiten restaurar los datos de tu instancia al estado que tenían en el momento en que se creó la copia de seguridad. Sin embargo, las copias de seguridad tienen algunas limitaciones. Si eliminas la instancia, también se eliminarán las copias de seguridad. No puedes crear copias de seguridad de una sola base de datos o tabla. Además, si la región en la que se encuentra la instancia no está disponible, no podrás restaurarla a partir de esa copia de seguridad, aunque sea en una región disponible.

La recuperación a un momento dado te ayuda a recuperar una instancia a un momento específico. Por ejemplo, si un error provoca una pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produjera el error. La recuperación a un momento dado siempre crea una instancia nueva. No puedes realizar una recuperación a un momento dado en una instancia que ya tengas.

Las exportaciones tardan más en crearse porque se crea un archivo externo en Cloud Storage que se puede usar para recrear tus datos. Las exportaciones no se verán afectadas si eliminas la instancia. Además, solo puedes exportar una base de datos o una tabla, en función del formato de exportación que elijas.

Ajusta el tamaño de las instancias para tener en cuenta la conservación de los registros de transacciones (binarios). Una actividad de escritura alta en la base de datos puede generar un gran volumen de registros de transacciones (binarios), lo que puede consumir una cantidad significativa de espacio en disco y provocar que el disco crezca en las instancias en las que se ha habilitado el aumento automático del almacenamiento. Te recomendamos que dimensionemos el almacenamiento de instancias para tener en cuenta la conservación de los registros de transacciones.
Protege tu instancia y tus copias de seguridad frente a la eliminación accidental.

Las instancias de Cloud SQL que creas en la Google Cloud consola o mediante Terraform tienen habilitada la prevención de eliminación accidental de forma predeterminada.

Usa la función de exportación de Cloud SQL para exportar tus datos y obtener una protección adicional. Usa Cloud Scheduler con la API REST para automatizar la gestión de las exportaciones. Para casos más avanzados, puedes usar Cloud Scheduler con funciones de Cloud Run para la automatización.

Ajustar y monitorizar

Ajustar y monitorizar las instancias de base de datos puede ayudar a reducir o evitar los problemas relacionados con el vacío.

La operación VACUUM tiene diferentes variantes con distintos niveles de bloqueo: VACUUM y VACUUM FULL. La opción VACUUM FULL puede recuperar más espacio en disco, pero bloquea la tabla de forma exclusiva y se ejecuta lentamente. En su lugar, usa el formato estándar de VACUUM, que se puede ejecutar en paralelo con las operaciones de la base de datos de producción. Cuando usas 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 se esté limpiando.

A continuación, te ofrecemos algunas recomendaciones que pueden ayudarte a reducir el tiempo que se tarda en completar la operación VACUUM:

  • Aumenta la memoria del sistema y el maintenance_work_mem. De esta forma, se agrupan más tuplas en cada iteración y se completa el trabajo lo más rápido posible. Ten en cuenta que, cuando se ejecuta autovacuum, se puede asignar hasta autovacuum_max_workers veces esta memoria, por lo que debes tener cuidado de no definir un valor predeterminado demasiado alto.
  • La operación VACUUM genera muchos registros de escritura previa (WAL). Si es posible reducir el número de registros WAL, por ejemplo, si no hay réplicas configuradas para esta instancia, la operación se completará más rápido.
  • Si la tabla ha alcanzado el límite de dos mil millones de IDs de transacción porque ninguno de los tuplas está inmovilizado, intenta reducir la cantidad de trabajo realizado en el modo de un solo usuario. Una opción es definir vacuum_freeze_min_age=1,000,000,000 (el valor máximo permitido, que ha aumentado desde el valor predeterminado de 50.000.000). Este nuevo valor reduce el número de tuplas inmutables hasta dos veces.
  • Las versiones 12.0 y posteriores de PostgreSQL admiten operaciones de limpieza y VACUUM sin limpiar las entradas de índice. Esto es fundamental, ya que la limpieza del índice requiere un análisis completo del índice y, si hay varios índices, el tiempo total depende del tamaño del índice.
  • Los índices más grandes consumen una cantidad de tiempo considerable para el análisis del índice, por lo que se prefiere INDEX_CLEANUP OFF para limpiar y congelar rápidamente los datos de la tabla. Las versiones de PostgreSQL anteriores a la 12.0 deben ajustar el número de índices. Es decir, si hay índices no críticos, puede ser útil eliminar el índice NON-CRITICAL para acelerar la operación de vacío.