Preguntas y respuestas: MySQL en la nube: migración, mejores prácticas, alta disponibilidad, escalabilidad

En este blog, proporcionaremos respuestas de preguntas y respuestas para el seminario web MySQL en la nube: migración, mejores prácticas, alta disponibilidad y escalado.

En primer lugar, nos gustaría agradecer a todos por asistir al seminario web el 7 de junio de 2017. El registro y las diapositivas para el seminario web están disponibles aquí. La siguiente es una lista de preguntas que no pudimos responder durante el seminario web:

¿Cómo funciona el clúster de Percona XtraDB con AWS para la agrupación en clústeres de MySQL?

Percona XtraDB Cluster funciona especialmente bien en entornos de nube, incluido Amazon EC2. Dado que Percona XtraDB Cluster requiere solo un viaje de transacción en red por transacción para los compromisos de transacciones de escritura y mantiene todas las lecturas locales, permite implementar múltiples clústeres AZ, así como múltiples regiones de alto rendimiento. El hecho de que cada nodo del clúster Percona XtraDB contenga todos los datos le permite evitar depender del almacenamiento de EBS. Puede ejecutar Percona XtraDB Cluster en almacenamiento basado en NVMe i3 nodos EC2 para lograr un alto rendimiento incluso con cargas de trabajo de E/S muy intensivas. La agrupación automática y la autorreparación le permiten escalar fácilmente el clúster. Tenemos un tutorial simple sobre cómo implementar Percona XtraDB Cluster en AWS. Compruébelo aquí.

¿Cómo abordar el modelo maestro-maestro? ¿Hay motivos suficientes para utilizar el modelo para implementar la escala multisitio?

Existen dos modos multimaestro distintos. Una solución síncrona maestro-maestro, como la que ofrece Percona XtraDB Cluster (prácticamente síncrona para ser precisos), asegura que no haya conflictos de datos ya que se conecta a nodos ubicados en diferentes sitios. La desventaja de este modelo es que la escritura puede ser costosa. Como tal, funciona bien en entornos con baja latencia entre diferentes sitios, o cuando se puede tolerar una alta latencia para las actualizaciones. Percona XtraDB Cluster está altamente optimizado, ya que solo se necesita un viaje de ida y vuelta a través de la red para completar una transacción de comisión. Esto reduce significativamente la latencia adicional en comparación con muchas otras soluciones.

Por el contrario, Master-Master asíncrono significa que puede escribir en el acto, sin tener que esperar en un viaje de ida en red. Viene con el lado de posibles conflictos de datos. En MySQL, se puede implementar con MySQL Replication. Sin embargo, la replicación de MySQL solo detecta conflictos en este punto y se detiene si detecta un conflicto. No tiene una buena resolución integral de conflictos. Garantizar que no se produzcan conflictos en el nivel de la aplicación es difícil y propenso a errores, y solo se recomienda en casos excepcionales. La mayoría de las aplicaciones no utilizan Active Master-Master, sino que diseñan una arquitectura en la que cada conjunto de replicación de base de datos opera con un solo nodo grabable.

¿Las herramientas de Percona funcionan en la nube, como lo hacen en Amazon Aurora?

Intentamos ejecutar el software Percona en la nube cuando tiene sentido. Por ejemplo, Percona Toolkit y Percona Monitoring Management son compatibles con Amazon RDS y Amazon Aurora. Percona XtraBackup no lo es, ya que requiere acceso físico a los archivos de la base de datos (Amazon RDS y Aurora no brindan esto). Dicho esto, Amazon actualizó recientemente su documentación de migración de Aurora para incluir el uso de XtraBackup. amazona aurora soportes y copias de seguridad realizadas por Percona XtraBackup como una forma de importar datos.

¿Cuál es la forma más rápida de verificar y validar las copias de seguridad creadas por XtraBackup para bases de datos de alrededor de 2-3 TB?

En general, intente realizar copias de seguridad realizando algún tipo de restauración y validación. Esto se puede hacer manualmente, pero es mucho mejor si se automatiza. Hay tres niveles de tal validación:

  • Validación básica. Ejecute -apply-log y asegúrese de que finalice correctamente. Inicie la instancia de MySQL y ejecute algunas consultas básicas para asegurarse de que funciona. A menudo es una buena idea hacer algunas preguntas para ver si hay datos recientes.
  • Validación de consistencia. Además, ejecute Comprobar tabla en todas las tablas para asegurarse de que no haya daños. De esta forma se validan las estructuras de datos de tablas e índices.
  • Validación completa. Restaure la copia de seguridad y conecte la copia de seguridad restaurada como un esclavo MySQL (posiblemente a uno de los esclavos existentes). Deja que se enfríe y luego corre. pt-table-checksum para validar la coherencia y asegurarse de que los datos de la copia de seguridad coincidan con los del origen.

Ejecutar una lista de verificación de base de datos en instancias optimizadas de AWS IO lleva hasta ocho horas. ¿Alguna otra sugerencia sobre cómo reemplazar la tabla de verificación válida?»

Sin conocer el tamaño de la mesa, me resulta difícil evaluar si ocho horas son razonables para su entorno. Sin embargo, en general, no se debe realizar una validación completa en cada copia de seguridad. La validación completa se lleva a cabo antes de toda la canalización de copia de seguridad y restauración. Si no ves ningún problema, hacerlo una vez al mes es suficiente. Desea realizar comprobaciones más ligeras a diario y semanalmente.

¿Qué enfoque recomendaría para un almacén de datos que necesita alrededor de 80 000 IOPS, actualmente en FusionIO bare metal? ¿Qué solución en la nube sería mi mejor apuesta?

Esta es una pregunta complicada. Se necesita más información para responder a esta pregunta. Necesitamos saber qué tipo de operaciones hace su base de datos. trabajando con un Consultor Percona para hacer un A&D para tu entorno Te daría la mejor respuesta. Sin embargo, en general, EBS (incluso con una gran cantidad de IOP proporcionados) no corresponde a FusionIO en la latencia de la aplicación IO. Instancias de E/S alta I3 con almacenamiento NVMe es una coincidencia más cercana. Si el presupuesto no es una preocupación, puede buscar instancias X1. Estos pueden contener hasta 2 TB de memoria y, a menudo, le permiten obtener toda (o una gran parte) de la base de datos en la memoria para un rendimiento aún mayor.

¡Gracias por asistir al seminario web MySQL en la nube: migración, mejores prácticas, alta disponibilidad, escalabilidad! Publique más comentarios de MySQL en la nube a continuación.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario