Prácticas recomendadas para configurar una instancia de Cloud SQL para MySQL

Cloud SQL para MySQL es un servicio de base de datos totalmente gestionado que te permite configurar, mantener y gestionar tus bases de datos relacionales de MySQL en Google Cloud. Cuando lo tengas todo listo para crear una instancia de Cloud SQL para MySQL, tienes varias opciones, como la consola de UI, la gcloud CLI, Terraform o la API REST. Puedes seguir nuestra documentación para obtener más información sobre cada una de estas rutas, pero en lo que respecta a este artículo, usaremos la interfaz de usuario para ilustrar cómo abordamos diversas prácticas recomendadas para configurar instancias.

Elegir una contraseña segura

Esta es la contraseña del usuario predeterminado de la base de datos "root"@"%" que se creará con la instancia. Si quieres mantener al usuario raíz como usuario administrador, elige aquí una contraseña segura. Si te preocupa la seguridad, te recomendamos que uses un usuario administrador menos habitual en lugar del raíz. Consulta la sección "Gestionar usuarios de bases de datos".

Crear una política de contraseña a nivel de instancia

La función de política de contraseñas mejora la seguridad de las bases de datos. Te permite configurar políticas sobre la longitud, la complejidad, la caducidad y la reutilización de contraseñas. Consulta el apartado sobre endurecimiento de instancias de MySQL para obtener más información.

Prueba la versión 8.0 para mejorar el rendimiento

Cloud SQL para MySQL admite varias versiones secundarias de la 8.0, con la versión 8.0.26 como opción predeterminada. Las pruebas comparativas con distintos tipos de máquinas muestran un mejor rendimiento de las consultas con la versión predeterminada 8.0 que con las versiones 5.7 y 5.6.  

No coloques la instancia de producción en la versión más reciente de GA 

A pesar de todas las pruebas que llevan a cabo Oracle y Cloud SQL, las actualizaciones de MySQL no se han sometido a pruebas exhaustivas con situaciones reales. Por tanto, te recomendamos que mantengas las instancias de producción en una versión estable y que utilices las instancias de desarrollo y las de staging para probar las últimas actualizaciones de la versión secundaria en Cloud SQL para MySQL.

Configurar varias zonas para tu instancia de producción

Cloud SQL para MySQL ofrece disponibilidad regional a través de la conmutación por error automática a una segunda zona como solución de alta disponibilidad. Para disfrutar de la mejor disponibilidad, configura la opción de varias zonas para las instancias de producción, de modo que tengas copias de seguridad diarias y recuperaciones a momentos dados. Consulta la sección Programación de copias de seguridad para obtener más información.

Evalúa el uso que haces de la CPU y la memoria para tomar decisiones fundamentadas sobre la migración

Al migrar una instancia a Cloud SQL, la carga de trabajo actual puede ayudarte a elegir el tamaño de máquina virtual adecuado. 

• CPU: ¿cuál es el uso de la CPU en condiciones normales de carga de trabajo? ¿Qué ocurre con los picos de cargas de trabajo? ¿La instancia está vinculada a la CPU o a la E/S? Si el porcentaje de uso de la CPU del usuario o del sistema es relativamente alto, significa que la carga de trabajo está vinculada a la CPU. Si el porcentaje de uso de E/S es relativamente alto, significa que la carga de trabajo está vinculada a la E/S. 
• Memoria: del mismo modo ¿cuál es el uso normal de la memoria de la instancia y cuál es el uso máximo? 

Como referencia, 1 vCPU de Cloud SQL para MySQL admite hasta 6,5 GB de memoria. 

Planifica un 20 % o un 50% más de espacio para CPU y memoria

Incluso en una instancia estable, planifica al menos un 20 % de espacio adicional para que la CPU y la memoria absorban los picos no planificados. Esto es aún más importante para una empresa en crecimiento: planifica un 50 % adicional. 

Cloud SQL facilita la actualización de tu tipo de máquina. Ten en cuenta que hay un periodo de inactividad asociado a las actualizaciones.

Usa una SSD para mejorar el rendimiento de las bases de datos

Cloud SQL para MySQL ofrece HDD como opción de almacenamiento económico, pero si necesitas una base de datos de alto rendimiento, opta por la opción de SSD. Consulta una comparativa del rendimiento de E/S. 

Busca un equilibrio entre el rendimiento y el coste en lo que respecta a la capacidad de almacenamiento

Las IOPS y el rendimiento del disco se relacionan con el tamaño del disco persistente. Cuanto mayor es la capacidad, mayor es el número de IOPS y la capacidad de rendimiento dentro del límite de la instancia. 

En el caso de SSD, las configuraciones de zona y regionales afectarán al rendimiento. Para obtener más información, consulta los datos de rendimiento de SSD locales y por zonas. Si has seleccionado la disponibilidad de varias zonas, consulta los datos de rendimiento de las SSDs regionales. En resumen, las IOPS de lectura y escritura son de 30 GB y el rendimiento es de 0,48 MB por GB. Con la SSD regional, los datos de rendimiento son similares, excepto el número de IOPS de escritura por instancia y el rendimiento de escritura. 

Ten en cuenta que el tamaño máximo de almacenamiento admitido es de 64 TB en una instancia de Cloud SQL. 

Facilita el aumento automático del almacenamiento y monitoriza el crecimiento de los discos

Cloud SQL tiene una función de aumento automático de almacenamiento para impedir que las instancias se queden sin espacio en disco (OOD). Cuando la función está habilitada, el almacenamiento se comprueba cada 30 segundos y se añade una capacidad de almacenamiento incremental cuando es necesario. 

Aunque esta función protege contra el OOD, el aumento de la capacidad es permanente; no puedes reducir tu instancia más adelante. Para empezar, configura alertas sobre el tamaño de tu disco para poder gestionar y planificar la capacidad de almacenamiento. 

Familiarízate con las opciones de encriptado

Cloud SQL encripta los datos en reposo de forma predeterminada. Sin embargo, existe la opción de utilizar una clave de encriptado administrada por el cliente (CMEK) en lugar de la clave predeterminada administrada y propiedad de Google si se adapta mejor a tus necesidades.

Evalúa la compensación entre la IP privada y la IP pública

Las IPs privadas y públicas hacen referencia a los tipos de direcciones que utilizan los dispositivos en una red. Una IP privada ofrece una mejor seguridad de la red y menor latencia de red que la IP pública. Sin embargo, la IP privada requiere configuraciones adicionales de APIs e IAM y, a veces, es necesaria una IP pública. Si sabes que necesitas utilizar una IP pública, pero quieres mejorar la seguridad, puedes optar por una red autorizada o utilizar el proxy de autenticación de Cloud SQL. 

Usar el proxy de autenticación de Cloud SQL para conexiones seguras

El proxy de autenticación de Cloud SQL proporciona acceso seguro a la instancia de Cloud SQL en lugar de tener que configurar SSLs o redes autorizadas. La aplicación se comunica con el cliente proxy de autenticación, que se ejecuta en el entorno local y utiliza un túnel seguro para comunicarse con el servidor proxy en la instancia de Cloud SQL.

Habilitar copias de seguridad y la recuperación a un momento dado, y revisar tu política de retención 

Hacer regularmente copias de seguridad de los datos y llevar a cabo la recuperación verificable de los datos es fundamental para gestionar las bases de datos en buen estado. Estas prácticas ofrecen un valor incalculable en situaciones como la corrupción de los datos o las operaciones de datos no deseadas, que pueden mitigarse mediante la alta disponibilidad. 

Cloud SQL ofrece procesos automatizados de copia de seguridad, verificación de copias de seguridad y recuperación a un momento dado. Están habilitados de forma predeterminada y son obligatorios en instancias con varias zonas. Las copias de seguridad automáticas se realizan a diario, y la política de retención predeterminada es de 7 copias de copias de seguridad y 7 días de registros binarios (obligatorio en PITR). Puedes ajustar la política de retención en la sección Opciones avanzadas.

Las marcas de bases de datos son configuraciones de servidor que van al archivo my.cnf. Hay una lista de marcas de bases de datos que se pueden configurar, y algunas marcas gestionadas no se pueden configurar. Te recomendamos que revises las marcas de base de datos y configures el valor adecuado en el momento de crear cada instancia. Algunas marcas de bases de datos no son dinámicas, por lo que cambiarlas provocaría el reinicio de la instancia. 

Revisar character_set_server 

En las instancias de Cloud SQL para MySQL, el valor predeterminado de character_set_server es utf8 en las versiones 5.6 y 5.7, y utf8mb4 en la versión 8.0. character_set_server configura character_set_client, character_set_connection, character_set_database y character_set_results con el mismo valor. El valor predeterminado de character_set_system es utf8mb3 en la versión 8.0. 

Si vas a migrar una instancia y la configuración actual utiliza un conjunto de caracteres diferente (por ejemplo, latin1), asegúrate de configurar character_set_server explícitamente en la nueva instancia. 

Revisar zona horaria

El valor predeterminado de la zona horaria es system_time_zone, que es UTC. Si quieres utilizar otra zona horaria, configúrala mediante default_time_zone. Esta marca usa dos formatos: compensación de zona horaria, por ejemplo, +08:00, y nombres de zonas horarias, como América/Los_Ángeles. Si la zona horaria se define mediante nombres de zona horaria, se ajusta automáticamente al horario de verano (si procede). La marca default_time_zone no es dinámica y requiere que se reinicie la instancia de la base de datos para hacer cambios. 

Habilitar registro de consultas lento 

De forma predeterminada, slow_query_log está desactivado. Recomendamos encarecidamente habilitar el registro de consultas lentas y establecer el valor de long_query_time en un umbral que tenga sentido para la aplicación. El registro de consultas lentas ayuda a capturar consultas de larga duración para análisis y optimización. Esta información no solo ayuda con las consultas individuales, sino también con el rendimiento general del servidor y el análisis retrospectivo de cargas de trabajo inesperadas. 

Revisar innodb_buffer_pool_size

Esta es la configuración más eficaz para el rendimiento de InnoDB. Cuantos más datos puedan almacenarse en búfer en la memoria, mejor será el rendimiento del servidor. Al mismo tiempo, debe haber suficientes memorias reservadas para búferes globales y búferes dinámicos por conversación. 

En Cloud SQL, los valores predeterminados, y los valores mínimos permitidos y máximos de innodb_buffer_pool_size dependen de la memoria de la instancia, tal como se describe en la documentación. 

Una propiedad innodb_buffer_pool_size bien escrita no tiene que contener todos los datos, solo los datos a los que se accede con frecuencia. Las variables de estado que reflejan la eficiencia del pool de búferes son Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests. Innodb_buffer_pool_read_requests es el número de solicitudes lógicas de lectura, mientras que Innodb_buffer_pool_reads es el número de lecturas lógicas que no se llevaron a cabo en el pool de búferes y tuvieron que leerse en el disco. En un caso ideal en el que los datos estén totalmente almacenados en el pool de búferes, la relación entre Innodb_buffer_pool_reads y Innodb_buffer_pool_read_requests sería casi cero. Monitorizar estas variables da una idea de la eficiencia del pool de búferes InnoDB. Si el valor de innodb_buffer_pool_size es el máximo permitido y la eficiencia del pool de búferes no es buena, y la aplicación está sufriendo problemas de rendimiento con las consultas, te recomendamos que actualices tu instancia para que tenga una memoria mayor. 

Esta variable se vuelve dinámica en las versiones 5.7 y 8.0 de MySQL, mientras que en la versión 5.6 habría que reiniciar la instancia. 

Revisar innodb_log_file_size

Antes de la versión 8.0.30, innodb_log_file_size e innodb_log_files_in_group y para cambiar innodb_log_file_size era necesario apagar el sistema. En la versión 8.0.30, se ha introducido innodb_redo_log_capacity para sustituir a innodb_log_file_size y a innodb_log_files_in_group.  

Las instancias de Cloud SQL para MySQL están configuradas tal que así: innodb_log_file_size=512 MB, innodb_log_files_in_group=2 o innodb_redo_log_capacity=1 GB). Esto permite que InnoDB retenga más cambios en el pool de búferes sin sincronizar con el disco, lo que mejora el rendimiento del servidor. El inconveniente de los archivos de registro de operaciones de rehacer demasiado grandes es el aumento del tiempo de recuperación por fallos. En función de los requisitos de alta disponibilidad y la configuración de la instancia, esta decisión requiere un equilibrio entre rendimiento y disponibilidad. 

Por lo general, te recomendamos que los archivos de registro de operaciones de rehacer sean lo suficientemente grandes como para contener actividades de escritura de una hora. Una forma de medirlo es observar Innodb_os_log_scrito a lo largo del día y asegurarse de que innodb_log_size_size * innodb_log_archivos_en_grupo sea lo suficientemente grande para la hora punta observada.

Revisar innodb_log_buffer_size 

En MySQL v5.6 y v5.7, innodb_log_buffer_size no es dinámico y, para cambiarlo, es necesario reiniciar la instancia. Por tanto, es mejor configurarlo en la inicialización.

Si el valor de innodb_log_buffer_size es lo suficientemente grande como para contener toda la transacción, durante el proceso de ejecución de la transacción no habrá ningún vaciado adicional en el disco. De forma predeterminada, innodb_log_buffer_size tiene un tamaño de 16 MB, que suele ser suficiente. No obstante, para hacerte una idea de si una transacción grande puede necesitar un búfer superior, monitoriza la variable de estado Innodb_log_waits cuando emitas una transacción de gran tamaño. Si el valor de innodb_log_buffer_size es demasiado pequeño y debe esperar a un vaciado, el valor de Innodb_log_waits aumentará en uno.

Ajustar variables dinámicas sobre la marcha

Algunas marcas de bases de datos relacionadas con el rendimiento son dinámicas, como table_open_cache o thread_cache_size. Es buena idea empezar por el tamaño adecuado, pero se recomienda fijar las mediciones y ajustarlas según sea necesario. 

El valor de table_open_cache corresponde al número de tablas abiertas. Si tienes suficiente caché, reducirás el tiempo de apertura de las tablas, lo que mejorará el rendimiento de las consultas. La variable de estado Opened_tables muestra el número de tablas que se han abierto. Si Opened_tables sigue creciendo, te recomendamos que aumentes el valor de table_open_cache. 

thread_cache_size se usa para almacenar en caché conversaciones que se pueden reutilizar después de que los clientes se desconecten. Si una instancia espera muchas conexiones nuevas simultáneas, fija un tamaño mayor. La proporción entre las variables de estado Threads_create y Connections muestra la eficiencia de la caché de conversaciones. Cuanto menor sea esta proporción, mejor. 

Ten cuidado con las marcas de memoria por conversación

Hay búferes de memoria por conversación que afectan al rendimiento de las consultas, como tmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size y más. Estas variables tienen alcance global y de sesión. El alcance global establece el valor por conversación para todas las conexiones nuevas, mientras que el alcance de sesión es efectivo para las consultas posteriores de la sesión actual. Cuanto mayor sea la memoria de estos ajustes, mejor será el rendimiento de las consultas. Sin embargo, como son dinámicos y asignan uno o varios por conversación, pueden provocar situaciones en las que la memoria no sea suficiente.

Es mejor usar números moderados para valores globales y reservar números más grandes para sesiones específicas para así conseguir un mejor rendimiento de una manera controlada.

Ten en cuenta performance_schema 

La propiedad performance_schema está desactivado de forma predeterminada antes de la versión 8.0.26 de MySQL y es necesario reiniciar para activarla. performance_schema ofrece una gran variedad de instrumentaciones, así como un amplio conjunto de datos para analizar las operaciones del servidor, pero conlleva costes de memoria y rendimiento. El nivel de instrumentación predeterminado disminuye alrededor del 5 %, y este porcentaje aumenta a medida que se van añadiendo más instrumentos. Compara las instrumentaciones con tu carga de trabajo, ya que el consumo de memoria puede ascender a 1 GB o más. Puedes observar este consumo de memoria en la tabla memory_summary_global_by_event_name.

Después de crear la instancia de Cloud SQL, hay un usuario de base de datos disponible, "root"@'%". Es probable que tengas que crear más usuarios de bases de datos. 

Restringir el acceso de los usuarios a las operaciones necesarias

Restringe siempre el acceso de los usuarios a las necesidades mínimas. 

Cuando crees usuarios mediante la CLI de MySQL, deberás conceder privilegios de forma explícita. 

Cuando se crea un usuario con la consola de Cloud, se le asignan los mismos privilegios que los del usuario raíz, ‘root’@’%’. En MySQL v5.6 y v5.7, los privilegios predeterminados incluyen todos los privilegios con opción de acceso, excepto los de SUPER y FILE. En la versión 8.0, el usuario tiene privilegios dinámicos y, aunque los privilegios SUPER y FILE siguen estando restringidos, los usuarios disponen de más roles de administrador (por ejemplo, APPLICATION_PASSWORD_ADMIN, SETTING_ADMIN, ROLE_ADMIN, SET_USER_ID y XA_RECOVER_ADMIN). Tendrás que revocar los privilegios innecesarios a través de la CLI de MySQL. En las instancias de la versión 8.0, la variable partial_revokes está habilitada. 

Sustituir ‘root’@’%’ por un usuario administrador concreto

El usuario ‘root’@’%’ es el superusuario predeterminado y más popular y, por lo tanto, suelen atacarlo los hackers. Te recomendamos que crees tus propios usuarios administradores con el mismo conjunto de privilegios que el usuario ‘root’@’%’ y lo sustituyas por ellos, a fin de preservar la seguridad.

Es muy importante monitorizar y hacer un seguimiento de diversos aspectos de las operaciones de las bases de datos y de los recursos del sistema. Te permite revisar y analizar el estado de las operaciones de tu instancia a lo largo del tiempo, lo que también puede ayudarte a planificar los recursos. 

• En la página de información general de la consola de Cloud se incluye una lista de las métricas principales. 
• Cloud Monitoring ofrece métricas adicionales. Puedes crear un panel de control con las métricas seleccionadas para tus instancias de base de datos. En el menú de navegación de la parte superior izquierda de la consola de Cloud, selecciona OPERACIONES --> Monitoring para acceder a Cloud Monitoring. 
• Utiliza Información útil sobre las consultas en Cloud SQL para analizar el rendimiento de las consultas. En la sección de información general se muestra la carga de CPU dividida en bases de datos, usuarios o direcciones de cliente. El uso de CPU también se desglosa para mostrar la espera de E/S y la espera de bloqueo. También incluye las consultas principales según el resumen de consultas. En cada resumen de consultas puedes ver el tiempo medio de ejecución, el número de consultas y la media de filas analizadas y devueltas. Estas métricas son muy útiles para identificar los puntos de interés y las consultas que se deben optimizar. 
• También puedes complementar las herramientas de arriba con herramientas de monitorización propias o de terceros. El objetivo principal es identificar las operaciones de tu base de datos que pueden influir en la optimización y en la solución de problemas de servidores y consultas. 

Las alertas adecuadas son fundamentales para mantener el estado del servidor. Ayudan a evitar que el servicio se interrumpa, por ejemplo, por falta de memoria o por fallos del sistema debido a la saturación de la CPU. 

Si usas Cloud Monitoring, puedes crear alertas basadas en métricas. Consulta más información en la documentación. 

Si utilizas otras herramientas de monitorización, recuerda configurar las alertas.

Para escalar lecturas, te recomendamos añadir réplicas de lectura. Puedes usar HAProxy, ProxySQL u otro balanceador de carga para distribuir las lecturas entre varias réplicas de lectura. 

Cloud SQL también es compatible con la replicación en cadena, de la que se puede obtener información en las replicaciones en cascada.  

Las réplicas de lectura se crean con la misma versión de MySQL que la instancia principal. Después de crearla, puedes cambiar la réplica a para que sea la versión principal.

Esta solución de alta disponibilidad ofrece alta redundancia de datos en una zona secundaria de la misma región. En caso de desastre, puede que una región deje de estar disponible. Las réplicas de lectura entre regiones son un recurso potente en un plan de recuperación tras fallos, ya que se pueden promocionar a una instancia principal cuando sea necesario. Consulta la documentación para obtener más información.