Prácticas recomendadas para configurar instancias de Cloud SQL para MySQL
Aunque puedes desplegar MySQL manualmente en tu propia máquina o incluso en una máquina virtual y gestionarlo tú, la opción más popular es usar un producto gestionado desde la nube. proveedor de servicios, que se encarga de los muchos aspectos operativos de la gestión de MySQL.
Artículos relacionados
Prácticas recomendadas
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 CLI de gcloud, 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 En este artículo, abordamos diversas prácticas recomendadas para configurar instancias.
Información de la instancia
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 una contraseña segura aquí. En el caso de los problemas de seguridad, te recomendamos que no uses un usuario administrador menos habitual. 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.
Versión de la base de datos
Prueba la versión 8.0 para mejorar el rendimiento
Cloud SQL MySQL admite varias versiones secundarias de 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 todos los esfuerzos que llevan a cabo las pruebas de Oracle y Cloud SQL, las versiones 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.
Alta disponibilidad
Configurar varias zonas para tu instancia de producción
Cloud SQL para MySQL ofrece una 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 una recuperación puntual. Consulta la sección Programación de copias de seguridad para obtener más información.
Tipo de máquina
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 CPU del usuario o del sistema es relativamente alto, significa que la carga de trabajo está vinculada a la CPU. Si el porcentaje de E/S es relativamente alto, significa que la carga de trabajo de la E/S está limitada.
- Memoria: ¿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, espera 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: considere 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 una actualización.
Personalizar almacenamiento
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.
Equilibra el rendimiento con 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 de rendimiento dentro del límite de la instancia.
En el caso de los 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 los SSD 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, la mayor 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, puedes utilizar una clave de encriptado gestionada por el cliente (CMEK) en lugar de la gestionada por Google predeterminada si así se adapta mejor a tus necesidades.
Configurar conexiones
Evalúa la compensación entre la IP privada y la IP pública
Las IP 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 API 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 requerir una red autorizada o utilizar Cloud SQL Proxy de autenticación
Prueba 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 configurar SSL 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.
Configurar la programación de copias de seguridad y la conservación
Habilita copias de seguridad y la recuperación a un momento dado, y revisa tu política de conservación
Hacer 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 por alta disponibilidad.
Cloud SQL ofrece copias de seguridad automatizadas, verificación de copias de seguridad y recuperación a un momento dado. Están habilitadas de forma predeterminada y son obligatorias en instancias con varias zonas. Las copias de seguridad automáticas se realizan a diario, y la política de conservació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 conservación en la sección Opciones avanzadas.
Configurar marcas de bases de datos
Las marcas de base 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 que algunas marcas gestionadas no se pueden configurar. Te recomendamos que revises las marcas de la base de datos y configures el valor adecuado en el momento de crearla. 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 la versión 5.6 y v5.7, y utf8mb4 en la versión 8.0. character_set_server define character_set_client, character_set_connection, character_set_database y character_set_results al 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 establecer 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 con 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 un cambio.
Habilitar registro de consultas lento
De forma predeterminada, slow_query_log está desactivado. Recomendamos encarecidamente habilitar el registro de consultas lentas y establecer el long_query_time en un umbral que tenga sentido para la aplicación. El registro de consultas lenta 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 recuerdos reservados para búferes globales y búferes dinámicos por conversación.
En Cloud SQL, los valores predeterminados, mínimos permitidos y máximos deltamaño_no_búfer_grupo depende de la memoria de la instancia, tal como se describe en la documentación.
Una buena propiedad innodb_buffer_pool_size 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 grupo 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 satisfacen del grupo de búferes y tenían que leerlo en el disco. En un caso ideal en el que los datos estén totalmente en el grupo de búferes, la relación de Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests sería casi cero. Monitorizar estas variables ofrece una idea de la eficiencia del grupo de búferes InnoDB. Si el valor de innodb_buffer_pool_size es el máximo permitido y la eficiencia del grupo de búferes no es buena, y la aplicación está sufriendo problemas de rendimiento de las consultas, te recomendamos que actualices tu instancia a tener 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, tendría que reiniciarse 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 no eran dinámicos, y para cambiar innodb_log_file_size era necesario apagarlo. En la versión 8.0.30, se ha introducido innodb_redo_log_capacity para sustituir innodb_log_file_size e innodb_log_files_in_group.
Las instancias de Cloud SQL para MySQL están configuradas con 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 grupo de búferes sin sincronizar con el disco, lo que mejora el rendimiento del servidor. El inconveniente de rehacer archivos de registro 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 rehagas los archivos de registro lo suficientemente grandes como para contener actividades de escritura de una hora. Una forma de medirlo es observarInnodb_os_log_scrito a lo largo del día, 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 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 un sofoco, 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, thread_cache_size. Es bueno 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 table_open_cache.
El 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, establece un tamaño mayor. La proporción de las variables de estado Threads_create y Conexiones muestra la eficiencia de la caché de conversaciones. Cuanto menor sea, 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, por ejemploTamaño de la tabla tmp .tamaño_máximo_tabla_máximo ,tamaño_búfer_ Unir .ordenar_búfer_talla 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 ajustes como estos, 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 conseguir un mejor rendimiento de una manera controlada.
Ten en cuenta performance_schema
El performance_schema está desactivado de forma predeterminada antes de la versión 8.0.26 de MySQL y es necesario reiniciar para activarlo. El parámetro performance_schema ofrece una gran variedad de instrumentaciones y proporciona 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 sigue creciendo a medida que se van añadiendo más instrumentos. Compara instrumentaciones con tu carga de trabajo, ya que el consumo de memoria puede aumentar a 1 GB o más. Puedes observar este consumo de memoria en la tabla Memory_summary_global_by_event_name.
Gestionar usuarios de bases de datos
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.
Restringe 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, también se le asigna el mismo privilegio que el usuario raíz @. En MySQL v5.6 y v5.7, los privilegios predeterminados incluyen todos los privilegios con opción de autenticación, 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.
Sustituye "'root'@'%' por un administrador
El usuario @raíz@% es el superusuario predeterminado y más popular y, por lo tanto, suelen atacarlo los hackers. Te recomendamos que crees tus propios usuarios con el mismo conjunto de privilegios que el usuario "raíz@@" y, a continuación, los sustituyas por motivos de seguridad.
Configurar la supervisión
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. También 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 OPERATIONS --> Monitoring para acceder a Cloud Monitoring.
- Utiliza Query Insights 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 entender las operaciones de tu base de datos que pueden influir en la optimización y la solución de problemas de servidores y consultas.
Configurar alertas
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.
Configurar réplicas
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 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 la versión principal.
Planifica la recuperación tras fallos
Esta solución ofrece alta redundancia de datos en la 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 del dispositivo de control para obtener más información.
Productos y servicios relacionados
Google Cloud ofrece una base de datos MySQL gestionada que se adapta a las necesidades de tu negocio, desde la retirada de tu centro de datos on‑premise, la ejecución de aplicaciones de software como servicio o la migración de sistemas empresariales fundamentales.
