Mejores prácticas generales

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

Si ocurren problemas con su instancia de Cloud SQL, revise lo siguiente durante la resolución de problemas:

Configuración y administración de instancias

Mejores prácticas Más información
Lea y siga las pautas operativas para asegurarse de que sus instancias estén cubiertas por el SLA de Cloud SQL .
Configure una ventana de mantenimiento para su instancia principal para controlar cuándo pueden ocurrir actualizaciones disruptivas. Ver ventana de Mantenimiento .
Para cargas de trabajo de lectura intensiva, agregue réplicas de lectura para descargar el tráfico de la instancia principal. Opcionalmente, puede utilizar un equilibrador de carga como HAProxy para administrar el tráfico a las réplicas.
Si elimina y vuelve a crear instancias periódicamente, utilice una marca de tiempo en el ID de instancia para aumentar la probabilidad de que se puedan utilizar nuevos ID de instancia.
No inicie una operación administrativa antes de que se haya completado la operación anterior.

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

El estado de la instancia en el Google Cloud La consola 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 comprobar si una operación se está ejecutando, vaya a la pestaña Operaciones y compruebe el estado de la operación más reciente.

Configure el almacenamiento para acomodar el mantenimiento crítico de la base de datos.

Si la configuración para habilitar el aumento automático de almacenamiento de instancias está deshabilitada o el límite de aumento automático de almacenamiento está habilitado, asegúrese de tener al menos un 20 % de espacio disponible para acomodar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar.

Para recibir alertas cuando el espacio en disco disponible caiga por debajo del 20 %, cree una política de alertas basada en métricas para la métrica de utilización del disco con una posición por encima del umbral y un valor de 0,8 . Para obtener más información, consulte Crear políticas de alertas basadas en métricas .

Evite el uso excesivo de su CPU.

Puede ver el porcentaje de CPU disponible que utiliza su instancia en la página de detalles de la instancia en el Google Cloud Consola. Para obtener más información, consulte Métricas . También puede supervisar el uso de la CPU y recibir alertas en un umbral específico mediante la opción "Crear políticas de alertas de umbral de métricas" .

Para evitar la sobreutilización, puede aumentar el número de CPU de su instancia. Cambiar las CPU requiere reiniciar la instancia. Si su instancia ya ha alcanzado el número máximo de CPU, debe fragmentar la base de datos en varias instancias.

Evite el agotamiento de la memoria.

Al buscar señales de agotamiento de la memoria, utilice principalmente la métrica de uso . Para evitar errores de memoria insuficiente, recomendamos mantener esta métrica por debajo del 90 %.

También puede utilizar la métrica total_usage para observar el porcentaje de memoria disponible que utiliza su instancia de Cloud SQL, incluida la memoria utilizada por el contenedor de la base de datos y la memoria asignada por el caché del sistema operativo.

Al observar la diferencia entre ambas métricas, puede identificar cuánta memoria utilizan los procesos en comparación con la caché del sistema operativo. Puede reutilizar la memoria de esta caché.

Para predecir problemas de memoria insuficiente, revise ambas métricas e interprételas 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 sea lo suficientemente grande 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. Cambiar el tamaño de memoria de la instancia requiere reiniciarla. Si tu instancia ya ha alcanzado el tamaño máximo de memoria, debes fragmentar la base de datos en varias instancias. Para obtener más información sobre la monitorización de ambas métricas en Google Cloud consola, ver Métricas .

Asegúrese de que su instancia tenga identificadores de transacción óptimos.

Puede ver el uso del ID de transacción de su instancia en la página Explorador de métricas en el Google Cloud Consola configurando el Resource Type como Cloud SQL Database y Metric como Percentage of instance's transaction IDs consumed . Para obtener más información, consulte Crear gráficos con el Explorador de métricas .

Ajustar y supervisar las instancias de base de datos puede ayudar a reducir o evitar los problemas relacionados con el vaciado automático. Supervise el uso del ID de transacción de su instancia y habilite y ajuste los parámetros autovacuum según la carga de trabajo. Para obtener más información, consulte Superar la protección envolvente del ID de transacción (TXID) .

Seguridad

Mejores prácticas Más información
Prefiero IP privada A menos que se requiera acceso a una IP pública , es preferible usar una IP privada . Esto ayudará a minimizar las conexiones de red no autorizadas a su base de datos.
Evite 0.0.0.0/0 en redes autorizadas Evite incluir 0.0.0.0/0 en Redes Autorizadas ya que esto permite el acceso desde Internet global sin restricciones.
Evite redes autorizadas excesivamente grandes Evite usar prefijos CIDR pequeños en redes autorizadas, ya que esto permite el acceso desde un número potencialmente excesivo de hosts. Recomendamos un prefijo CIDR no menor que /16, y preferiblemente mayor que /19.
Habilitar políticas de contraseñas Mediante las políticas de contraseñas de instancia , especifique las políticas de contraseñas adecuadas para su instancia de base de datos a fin de evitar la configuración de contraseñas débiles, establecer un tiempo de caducidad y configurar el bloqueo de cuentas en caso de intentos fallidos de inicio de sesión. Esto es especialmente importante si configura su instancia para una IP pública.

Arquitectura de datos

Mejores prácticas Más información
Divida sus instancias grandes en instancias más pequeñas, cuando sea posible. Siempre que sea posible, es mejor usar muchas instancias pequeñas de Cloud SQL que una sola instancia grande. Gestionar una instancia grande y monolítica presenta desafíos que no plantea un grupo de instancias más pequeñas.
No utilice demasiadas tablas de base de datos.

Mantenga el número de tablas de su instancia por debajo 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

Mejores prácticas Más información
Utilice buenas prácticas de gestión de conexiones, como agrupación de conexiones y retroceso exponencial. Usar estas técnicas mejora el uso de recursos de su aplicación y le ayuda a mantenerse dentro de los límites de conexión de Cloud SQL. Para obtener más información y ejemplos de código, consulte Administrar conexiones de bases de datos .
Pruebe la respuesta de su aplicación a las actualizaciones de mantenimiento, lo que puede ocurrir en cualquier momento durante la ventana de mantenimiento. Pruebe el mantenimiento de autoservicio para simular una actualización de mantenimiento. Durante el mantenimiento, su instancia deja de estar disponible por un breve periodo y se interrumpen las conexiones existentes. Probar las implementaciones de mantenimiento le permite comprender mejor cómo su aplicación gestiona el mantenimiento programado y la rapidez con la que el sistema se recupera.
Pruebe la respuesta de su aplicación a las conmutaciones por error, que pueden ocurrir en cualquier momento. Puede iniciar manualmente una conmutación por error utilizando el Google Cloud Consola, la CLI de gcloud o la API. Consulte Iniciar la conmutación por error .
Evite transacciones grandes. Mantenga las transacciones pequeñas y breves. Si necesita una actualización importante de la base de datos, hágalo en varias transacciones más pequeñas en lugar de una sola transacción grande.
Si está utilizando el proxy de autenticación de Cloud SQL, asegúrese de estar usando la versión más actualizada. Consulte Cómo mantener actualizado el proxy de autenticación de Cloud SQL .

Importación y exportación de datos

Mejores prácticas Más información
Utilice exportaciones sin servidor. Las exportaciones sin servidor transfieren la operación de exportación a una instancia temporal, lo que permite que la instancia principal continúe atendiendo consultas y realizando operaciones con su rendimiento habitual. Una vez finalizada la exportación de datos, la instancia temporal se elimina automáticamente.
Acelere las importaciones para instancias de tamaño pequeño. Para instancias pequeñas, puede aumentar temporalmente la CPU y la RAM de una instancia para mejorar el rendimiento al importar conjuntos de datos grandes.
Si está exportando datos para importarlos a Cloud SQL, asegúrese de utilizar el procedimiento adecuado. Consulte Exportación de datos desde un servidor de base de datos administrado externamente .

Copia de seguridad y recuperación

Mejores prácticas Más información
Proteja sus datos con la funcionalidad adecuada de Cloud SQL.

Las copias de seguridad, la recuperación puntual y las exportaciones ofrecen redundancia y protección de datos. Cada una protege contra diferentes escenarios y se complementa en una sólida estrategia de protección de datos.

Las copias de seguridad son sencillas; permiten restaurar los datos de la instancia al estado en que se encontraban al realizar la copia de seguridad. Sin embargo, tienen algunas limitaciones. Si se elimina la instancia, las copias de seguridad también se eliminan. No se puede realizar una copia de seguridad de una sola base de datos o tabla. Además, si la región donde se encuentra la instancia no está disponible, no se puede restaurar desde esa copia de seguridad, ni siquiera en una región disponible.

La recuperación a un punto en el tiempo permite recuperar una instancia a un punto específico. Por ejemplo, si un error provoca una pérdida de datos, se puede recuperar una base de datos a su estado anterior al error. Una recuperación a un punto en el tiempo siempre crea una nueva instancia; no se puede realizar una recuperación a un punto en el tiempo en una instancia existente.

Las exportaciones tardan más en crearse, ya que se crea un archivo externo en Cloud Storage que permite recrear los datos. Las exportaciones no se ven afectadas si se elimina la instancia. Además, solo se puede exportar una base de datos o incluso una tabla, según el formato de exportación elegido.

Dimensiona las instancias para tener en cuenta la retención del registro de transacciones (binarias). Una alta actividad de escritura en la base de datos puede generar un gran volumen de registros de transacciones (binarios), lo que puede consumir un espacio de disco considerable y provocar un crecimiento del disco en las instancias habilitadas para aumentar el almacenamiento automáticamente. Recomendamos dimensionar el almacenamiento de las instancias para tener en cuenta la retención de registros de transacciones.
Proteja su instancia y copias de seguridad contra eliminaciones accidentales.

Una instancia de Cloud SQL que crea en el Google Cloud La consola o mediante Terraform habilita 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 mayor protección. Usa Cloud Scheduler con la API REST para automatizar la gestión de las exportaciones. Para escenarios más avanzados, Cloud Scheduler con funciones de Cloud Run para la automatización.

Sintonizar y monitorear

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

La operación VACUUM tiene diferentes variantes con distintos niveles de bloqueo: VACUUM estándar y VACUUM FULL . La opción VACUUM FULL puede recuperar más espacio en disco, pero bloquea exclusivamente la tabla y su ejecución es lenta. En su lugar, utilice la forma estándar de VACUUM , que puede ejecutarse en paralelo con las operaciones de la base de datos de producción. Al usar la operación VACUUM , comandos como SELECT, INSERT, UPDATE, and DELETE seguirán funcionando con normalidad. No podrá modificar la definición de una tabla con comandos como ALTER TABLE mientras se está vaciando.

A continuación se presentan algunas recomendaciones que podrían ayudar a reducir el tiempo que lleva completar la operación VACUUM :

  • Aumentar 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. Tenga en cuenta que, al ejecutarse autovacuum, esta memoria puede asignarse hasta autovacuum_max_workers veces, así que tenga cuidado de no establecer el valor predeterminado demasiado alto.
  • La operación VACUUM genera una gran cantidad de registros de escritura anticipada (WAL). Si es posible reducir la cantidad de registros WAL, por ejemplo, no configurando réplicas para esta instancia, la operación se completa más rápidamente.
  • Si la tabla ha alcanzado el límite de dos mil millones de IDs de transacción porque ninguna de las tuplas está congelada, intente reducir la cantidad de trabajo realizado en modo monousuario. Una opción posible es establecer vacuum_freeze_min_age=1,000,000,000 (el valor máximo permitido, superior al predeterminado de 50,000,000). Este nuevo valor reduce el número de tuplas congeladas hasta dos veces.
  • PostgreSQL versión 12.0 y posteriores admiten operaciones de limpieza y VACUUM sin limpiar las entradas del índice. Esto es crucial, ya que limpiar el índice requiere un escaneo completo y, si hay varios índices, el tiempo total depende del tamaño del índice.
  • Los índices grandes consumen mucho tiempo para su escaneo, por lo que se recomienda INDEX_CLEANUP OFF para limpiar y congelar rápidamente los datos de la tabla. Las versiones de PostgreSQL anteriores a la 12.0 necesitan ajustar el número de índices. Es decir, si hay índices no críticos, puede ser útil descartar el índice NON-CRITICAL para acelerar la operación de vaciado.