la base de datos mysql tiene alrededor de 2 TB de datos.
Tengo una replicación maestro-esclavo-esclavo ejecutándose. la aplicación que usa la base de datos lee (SELECCIONAR) consultas solo en uno de los 2 esclavos y escribe (BORRAR/INSERTAR/ACTUALIZAR) consultas en el maestro. la aplicación realiza muchas más lecturas que escrituras.
Si tenemos un problema con las consultas de lectura (SELECT), podemos simplemente agregar otra base de datos esclava y decirle a la aplicación que hay otra solución. entonces escala bien...
Actualmente, el maestro está ejecutando alrededor del 40 % de la E/S del disco debido a las escrituras.
Así que estoy pensando en cómo escalar la base de datos en el futuro. Porque un día el maestro estará sobrecargado.
¿Cuál podría ser una solución allí?
¿Quizás el clúster MySQL? Si es así, ¿existen dificultades o limitaciones al cambiar la base de datos a ndb?
Muchas gracias por adelantado... :)
Respuesta1
No existe una respuesta única para escalar MySQL.Algunos consejos generales:
Escale "diagonalmente" tanto como pueda, es decir. mantenga las cosas en un único servidor MySQL siempre que pueda ejecutarlo en hardware básico. Eso probablemente significa 2 CPU de cuatro núcleos, más de 64 GB de RAM, 8 discos RAID 10 o superior. El extremo superior de lo que es "hardware básico" se está volviendo más rápido cada año.
Eche un vistazo a las presentaciones de Brad Fitzpatrick sobre cómo ampliar LiveJournal. Son prácticamente clásicos en lo que respecta a escalar LAMP. Enpáginas 25 - 26 de esta presentaciónVerá el problema que eventualmente enfrentará con la replicación de MySQL: las escrituras consumen todas las E/S de disco disponibles.
Leer "MySQL de alto rendimiento". Es un libro realmente bueno deAutores que han visto muchas instalaciones de MySQL de alta carga..
Evite fragmentar (difundir datos entre muchos servidores MySQL) tanto como sea posible.Cuando comienza a fragmentar, renuncia a la mayoría de los beneficios de las bases de datos relacionales y ralentiza el desarrollo. Si tiene que fragmentar, considere usar un almacén de datos NoSQL con un modelo de servidor múltiple incorporado: fx Riak, Cassandra, HBase, MongoDB. Lo ideal es realizar una "partición funcional" entre MySQL y NoSQL, de modo que siga usando MySQL para datos menos activos que se ajusten bien a un RDBMS, y use el motor NoSQL para datos "calientes" que no necesita unir con MySQL. datos.
¿Quizás el clúster MySQL? Si es así, ¿existen dificultades o limitaciones al cambiar la base de datos a ndb?
En "Operaciones Web" hay un capítulo sobre MySQL escrito por Baron Schwartz. Prácticamente simplemente dice "¡No!" al uso de MySQL Cluster/NDB en un entorno de sitio web. Cita: "... no funciona bien para uniones y consultas GROUP BY, y las aplicaciones web los necesitan".
Respuesta2
La agrupación en clústeres de MySQL le brindará escalabilidad de escritura al dividir su base de datos en fragmentos que se distribuyen en varias máquinas. Pero ralentizará drásticamente las consultas complejas que extraen datos de múltiples fragmentos. Sólo usted puede determinar el efecto de esto en el rendimiento de su aplicación.
Es posible que desee considerar la posibilidad de fragmentar los datos manualmente en lugar de dejar que el motor de agrupación lo haga por usted. Se necesitará más configuración, pero si comprende cómo su aplicación usa la base de datos, es posible que pueda idear un esquema de fragmentación que permita que la mayoría de las consultas solo accedan a un fragmento.
Respuesta3
Recuerde que la replicación de MySQL es de un solo subproceso, por lo que probablemente su replicación no estará limitada por la capacidad del maestro, sino por los esclavos, que no pueden mantenerse detrás del maestro y no estarán sincronizados.De este artículo:
El proceso de reproducción de replicación se ejecuta en un solo subproceso en las réplicas y, por lo tanto, no tiene esperanzas de mantenerse al día incluso con una carga de escritura moderadamente ocupada en el principal, donde se producen muchas actualizaciones al mismo tiempo.
Respuesta4
Puede pensar en agrupar la información en sí. Si es posible, separar las tablas que consumen escritura entre diferentes servidores.