¿Está buscando comenzar con la base de datos de código abierto más popular del mundo y se pregunta cómo debe configurar su alojamiento MySQL? Muchos usan Amazon RDS de manera predeterminada, cuando MySQL funciona excepcionalmente bien en Azure Cloud. Si bien Microsoft Azure ofrece una solución administrada, Azure Database, la solución tiene algunas limitaciones importantes que debe conocer antes de migrar sus implementaciones de MySQL. En esta publicación, describimos la mejor manera de alojar MySQL en Azure, incluidas las soluciones administradas, los tipos de instancias, la replicación de alta disponibilidad, las copias de seguridad y los tipos de discos que se pueden usar para optimizar el rendimiento de su base de datos en la nube.
MySQL DBaaS frente a MySQL autogestionado
Lo primero que debe tener en cuenta al sopesar entre la autogestión y una solución MySQL Database-as-a-Service (DBaaS) es qué recursos internos tiene disponibles. Si está leyendo esto, es probable que ya conozca la magnitud de las tareas operativas asociadas con el mantenimiento de una implementación de producción, pero para un resumen rápido, hay aprovisionamiento, desaprovisionamiento, configuraciones maestro-esclavo, copias de seguridad, escalado, actualizaciones, rotaciones de registro, parches del sistema operativo. y monitoreo, por nombrar algunos.
Un experto interno en MySQL, o un equipo de administradores de bases de datos, según el tamaño de su aplicación, sin duda puede manejarlos con su organización por usted, pero la pregunta es dónde quiere que se concentren los esfuerzos de su equipo. . Muchos deciden pasar a MySQL DBaaS para automatizar estas tareas que requieren mucho tiempo y así poder concentrarse más en el desarrollo y la optimización de las bases de datos de sus aplicaciones. Un buen ejemplo sería el análisis de consultas lentas. Si bien casi todos los DBaaS ofrecen una herramienta MySQL Slow Query Analyzer para ayudar a identificar consultas problemáticas, esta tarea aún requiere habilidad e intuición humana para determinar cómo optimizar esas consultas que afectan el rendimiento de su aplicación.
Ya sea que sea una empresa nueva o una empresa Fortune 500, encontrará que muchas organizaciones optan por aprovechar un DBaaS para optimizar el tiempo de su DBA, mientras que los mismos tipos y tamaños de empresas también optar por apegarse a la autogestión interna. Para muchas empresas, la decisión se reduce en gran medida a la personalización y el control. Esta es la razón por la que advertimos contra el uso predeterminado de Azure Database, o su competidor de AWS, Amazon RDS, ya que no le permiten mantener el acceso de superusuario de MySQL o incluso el acceso SSH a sus máquinas. Además, la capacidad de personalizar la configuración de su implementación es muy limitada, como los tipos de instancia, la RAM, el tamaño del disco o las IOPS que puede usar. Obtendrá más información sobre los mejores tipos de instancias y discos para usar a continuación, y puede consultar esta Comparación de proveedores de MySQL para ver las ventajas y limitaciones de las cuatro principales soluciones administradas de MySQL, ScaleGrid, Compose, Azure Database y Amazon RDS.
Implementación de alta disponibilidad
Si está implementando en producción, siempre debe configurar MySQL como una implementación maestro-esclavo. Las implementaciones independientes son un solo nodo sin ninguna replicación y, en realidad, solo deben usarse para entornos de desarrollo o prueba. Con las implementaciones maestro-esclavo, puede configurar una alta disponibilidad, de modo que si uno de sus nodos falla, puede conmutar por error a un esclavo sin tiempo de inactividad. Por lo general, se configura como un maestro-esclavo-esclavo de 3 nodos o como un quórum maestro-esclavo de 2+1 nodos. La ventaja de usar un quórum es que es una alternativa de menor costo, pero la desventaja es que solo tiene 2 nodos que contienen datos, ya que el otro actúa como un nodo de quórum para determinar el mejor curso de conmutación por error. Si su aplicación puede leer desde el esclavo, entonces necesita escalar la lectura para que devuelvan los mismos datos del volumen del clúster con un retraso mínimo.
La mejor manera de alojar MySQL en Azure CloudClick To Tweet
Al usar una configuración maestro-esclavo de MySQL, recomendamos configurar la replicación semisincrónica para mejorar la integridad de sus datos con redundancia de datos. Esto asegura que cuando una confirmación regresa con éxito, los datos existen tanto en el maestro como en el esclavo, por lo que en caso de que un centro de datos se caiga, su maestro MySQL puede conmutar por error a un esclavo sin pérdida de datos. Puede hacer esto con la replicación asincrónica o semisincrónica, y obtenga más información al respecto en nuestra publicación de blog MySQL High Availability Explained - Part II.
Entonces, ¿cómo configuramos la alta disponibilidad para MySQL en Azure? Necesitamos distribuir nuestras instancias esclavas en diferentes zonas de disponibilidad de Azure (AZ). Por lo tanto, queremos asegurarnos de elegir una región de Azure que tenga al menos 3 AZ, colocando cada instancia en una AZ diferente. Hacemos esto porque las garantías de disponibilidad están en todas las AZ, por lo que si una zona se cae, la base de datos de su aplicación aún puede permanecer en línea a través de las otras 2 AZ. Las zonas de disponibilidad son bastante nuevas para Azure, por lo que si trabaja en una región que no ofrece AZ, tiene la opción de usar conjuntos de disponibilidad. Estos son un poco más débiles que los de AZ, pero asegúrese de que esté implementado en diferentes dominios y bastidores para protegerlo contra una posible interrupción. También existe la opción de implementar en todas las regiones, pero esta es una configuración más complicada, por lo que recomendamos comunicarse para discutir antes de implementar.
Redes virtuales de Azure
La mejor manera de proteger su base de datos de Internet es implementarla en una subred privada para asegurarse de que no esté expuesta. Azure facilita la configuración mediante el uso de una red virtual (VNET) que se puede configurar para sus servidores MySQL. Con Azure VNET para MySQL, puede configurar comunicaciones seguras entre sus servidores, Internet e incluso su red de nube privada local. Por lo general, se configuran para comunicarse a través de una sola red, pero si necesita conectar más de una región, puede crear varias VNET para comunicarse a través del emparejamiento de redes virtuales.
Además, puede administrar su control de acceso de MySQL a través de reglas de grupos de seguridad de red (NSG) sin tener que lidiar con listas blancas de IP. Esto no está disponible a través de Azure Database for MySQL, pero tanto VNET como NSG se pueden configurar a través de nuestros planes MySQL Bring Your Own Cloud (BYOC) en Azure, donde puede hospedar sus clústeres a través de su propia cuenta en la nube.
Tipos de instancias de Azure
Otro aspecto importante a considerar es el rendimiento de sus instancias de MySQL en la nube pública. La nube de Azure ofrece varios tipos de instancias que se pueden usar para su alojamiento de MySQL, incluidos Es2 v3, Ds2, v2 y Ls4.
Recomendamos comenzar con un tipo de instancia optimizada para memoria, ya que las bases de datos requieren mucha RAM y buscan la velocidad de disco más rápida posible para obtener el mejor rendimiento. La serie Es2 suele ser un buen punto de partida para la mayoría de las cargas de trabajo de MySQL. A partir de ahí, puede realizar algunas pruebas de rendimiento para ver si necesita más CPU, en cuyo caso, los tipos de instancia equilibrados o los tipos de instancia con uso intensivo de CPU podrían satisfacer mejor sus necesidades de MySQL, como los tipos de instancia Dv3. Sus pruebas de rendimiento también pueden mostrar que necesita más E/S (entrada/salida), puede pasar a un tipo de instancia de disco intensivo.
Si planea aprovechar Azure como su proveedor de nube de MySQL durante los próximos 1 a 3 años y mantener configuraciones de implementación bastante consistentes, también puede considerar las instancias reservadas. Estas son esencialmente instancias prepagas que le permiten lograr ahorros de costos considerables para su alojamiento MySQL. De media, puede ahorrar entre un 20 % y un 30 % en las instancias reservadas de un año y entre un 40 % y un 50 % en las instancias reservadas de 3 años.
Tipos de discos de Azure
La primera determinación que debe tomar cuando se trata de elegir un tipo de disco de Azure para sus implementaciones de MySQL es si optar por un disco administrado o no administrado. Los discos no administrados son los discos heredados que ofrece Azure en los que debe configurar la cuenta de almacenamiento, asignar su disco a la cuenta de almacenamiento y monitorear el uso y los límites de IOPS para esa cuenta de almacenamiento. Recomendamos encarecidamente el uso de discos administrados y, si aún realiza la implementación con discos no administrados, debería considerar pasar a los administrados.
Entornos de desarrollo/prueba de MySQL:discos estándar
Hay varios tipos de discos administrados disponibles a través de Azure, siendo los discos estándar los predeterminados. Los discos estándar pueden admitir hasta 500 IOPS (operaciones de entrada/salida por segundo) y son buenos para operaciones de desarrollo y prueba, ya que se pueden cambiar de tamaño dinámicamente, pero no se deben usar para implementaciones de producción de MySQL.
Implementaciones de producción de MySQL:Discos Premium
Para sus servidores de producción de MySQL, recomendamos aprovechar los discos premium de Azure. Hay una amplia variedad de discos premium entre los que puede elegir. Para cada disco premium, puede elegir el mejor tamaño, y cada tamaño viene con diferentes IOPS aprovisionadas para que pueda seleccionar el que mejor se adapte a las necesidades de su aplicación.
Implementaciones de producción de MySQL:SSD local
Las unidades SSD locales de Azure son una alternativa de alto rendimiento a los discos premium y, por lo general, son más adecuadas para clústeres grandes. Los SSD locales proporcionan un rendimiento de E/S mucho mayor y el mejor rendimiento en Azure. Pero tienen el inconveniente de que son discos efímeros, no un almacenamiento permanente, por lo que si detiene la instancia, los datos desaparecen. Recomendamos la serie Ls v2, que es muy rápida, pero tenga en cuenta que la CPU es muy débil, lo que puede causar cuellos de botella en la máquina.
Copias de seguridad de MySQL en Azure
La mejor forma de hacer una copia de seguridad de sus datos de MySQL en Azure es mediante el uso de instantáneas de discos administrados. Una instantánea es una versión puntual de solo lectura de un disco. Estas copias de seguridad se pueden leer, copiar o eliminar, pero tenga en cuenta que no se pueden modificar. Es una buena idea hacer copias de seguridad completas para que todas sus bases de datos, usuarios y configuraciones estén respaldadas en la instancia en caso de que necesite recuperar una base de datos MySQL. También es una buena idea cifrar sus instantáneas de copia de seguridad para que la copia de seguridad solo se pueda restaurar en la máquina en la que se realizó la copia de seguridad.
Sus copias de seguridad de MySQL generarán cargos adicionales por almacenamiento de datos de Azure, a menos que esté aprovechando una solución MySQL en Azure con todo incluido, como nuestros planes de alojamiento dedicado en ScaleGrid. Para controlar los costos, es una buena idea automatizar sus copias de seguridad a través de un programa personalizable que le permita configurar la frecuencia de sus copias de seguridad, la cantidad máxima de copias de seguridad para retener y su objetivo de copia de seguridad. Por supuesto, esto también lo ayuda a garantizar que sus datos de MySQL se respalden regularmente en caso de pérdida de datos en su implementación de producción para que pueda recuperarlos rápidamente con una copia de seguridad reciente.
Si tiene alguna pregunta sobre la mejor manera de alojar MySQL en Azure, déjenos un comentario a continuación o póngase en contacto con nosotros en support@scalegrid. yo. También puede iniciar una prueba gratuita de 30 días para explorar las ventajas de aprovechar un servicio MySQL completamente administrado para mejorar el rendimiento de sus implementaciones.
