Soluciones de escalamiento para MySQL(Replicación, Agrupación)
replication scaling (9)
Descargo de responsabilidad: no he usado MySQL Cluster, así que solo voy por lo que he escuchado.
MySQL Cluster es una solución HA (alta disponibilidad). Es rápido, porque está todo en la memoria, pero su verdadero punto de venta es la disponibilidad. No hay un solo punto de falla. Con la replicación, por otro lado, si el maestro se cae, tienes que cambiar a la réplica, y puede haber una pequeña cantidad de tiempo de inactividad. (aunque la solución DRBD es otra alternativa que tiene alta disponibilidad)
El clúster requiere que toda su base de datos se ajuste a la memoria. Eso significa que cada máquina del clúster necesita tener suficiente memoria para almacenar toda la base de datos. Entonces, esta no es una solución factible para bases de datos muy grandes (o al menos es una solución muy costosa).
Creo que a menos que HA sea súper importante (léase: probablemente no), es más molestia (y dinero) de lo que vale. La replicación es más a menudo la mejor manera de hacerlo.
Editar: Olvidé mencionar también que el Clúster no permite claves externas, y los escaneos de rango son más lentos que en otros motores. Aquí hay un enlace que habla sobre Limitaciones conocidas del clúster MySQL
En el inicio en el que estoy trabajando ahora estamos considerando soluciones de escala para nuestra base de datos. Las cosas se vuelven algo confusas (al menos para mí) con MySQL, que tiene el clúster MySQL , la replication y la replicación del clúster MySQL (de la versión 5.1.6), que es una versión asincrónica del clúster MySQL. El manual de MySQL explica algunas de las diferencias en sus preguntas frecuentes sobre clústeres , pero es difícil determinar cuándo usar uno u otro.
Agradecería cualquier consejo de personas que estén familiarizadas con las diferencias entre esas soluciones y cuáles son los pros y los contras, y cuándo recomienda utilizarlas.
El clúster de MySQL es una extraña bestia y cada vez que lo evaluamos, se ejecutó muy mal o no fue confiable.
Es terriblemente complicado de configurar (se necesitan al menos tres nodos, posiblemente más). Además, no hay ninguna disposición para que los clientes fallen, por lo que debe hacerlo usted mismo (o usar otra cosa para actuar como un proxy, etc.).
Es extremadamente inteligente, ya que hace particiones de hash automáticas en la clave principal que le permite escalar escrituras, y también porque no tiene un solo punto de falla.
Pero realmente creo que es más adecuado para los casos muy especiales para los que fue diseñado. En la mayoría de los casos, no puede reemplazar otro motor de base de datos (por ejemplo, InnoDB) ni en rendimiento ni en características.
Hay algunas buenas discusiones sobre cómo las personas que mantienen drupal.org han estructurado sus servidores de base de datos:
Ambos son de 2007, por lo que el soporte de Clustering puede ser más fuerte ahora, pero en el momento en que eligieron la replicación.
He estado MUCHAS leyendo sobre las opciones disponibles. También tuve en mis manos la segunda edición de High Performance MySQL, que recomiendo encarecidamente.
Esto es lo que he logrado juntar:
Agrupación
La agrupación en el sentido general es la distribución de carga entre muchos servidores que aparecen en una aplicación externa como un solo servidor.
Clúster MySQL NDB
MySQL NDB Cluster es un motor de almacenamiento distribuido, en memoria y sin compartición, con replicación sincrónica y partición automática de datos (discúlpeme, lo tomo literalmente del libro High Performance, pero lo ponen muy bien allí). Puede ser una solución de alto rendimiento para algunas aplicaciones, pero la aplicación web generalmente no funciona bien en ella.
El principal problema es que más allá de las consultas muy simples (que solo tocan una tabla), el clúster generalmente tendrá que buscar datos en varios nodos, lo que permite que la latencia de la red se filtre y ralentice significativamente el tiempo de finalización de las consultas. Como la aplicación trata al clúster como una sola computadora, no puede decirle de qué nodo extraer los datos.
Además, el requisito de memoria no es viable para muchas bases de datos grandes.
Continuent Sequoia
Esta es otra solución de clúster para MySQL, que actúa como un middleware en la parte superior del servidor MySQL. Ofrece replicación sincrónica, balanceo de carga y failover. También garantiza que las solicitudes obtengan siempre los datos de la copia más reciente, eligiendo automáticamente un nodo que tenga los datos nuevos.
Leí algunas cosas buenas y, en general, suena bastante prometedor.
Federación
La federación es similar a la agrupación, así que también la arrastré aquí. MySQL ofrece federación a través del motor de almacenamiento federado. Similar a la solución de clúster NDB, funciona bien solo con consultas simples, pero lo que es peor es el clúster para las más complicadas (ya que la latencia de la red es mucho mayor).
Replicación y equilibrio de carga
MySQL tiene la capacidad incorporada para crear replicaciones de una base de datos en diferentes servidores. Esto se puede usar para muchas cosas: dividir la carga entre servidores, copias de seguridad en caliente, crear servidores de prueba y conmutación por error.
La configuración básica de la replicación implica un servidor maestro que se encarga principalmente de la escritura y uno o más esclavos que manejan solo las lecturas. Una variación más avanzada es la de la configuración master-master , que permite escalar también las escrituras al tener varios servidores escribiendo al mismo tiempo.
Cada configuración tiene sus pros y sus contras, pero un problema que todos comparten es el retraso de replicación: dado que la replicación de MySQL es asincrónica, no todos los nodos tienen los datos más recientes en todo momento. Esto requiere que la aplicación tenga en cuenta la replicación e incorpore consultas con capacidad de replicación para que funcionen como se espera. Para algunas aplicaciones, esto podría no ser un problema, pero si siempre necesitas los datos más frescos, las cosas se complican un poco.
La replicación requiere un cierto equilibrio de carga para dividir la carga entre los nodos. Esto puede ser tan simple como algunas modificaciones en el código de la aplicación o el uso de soluciones de software y hardware dedicadas.
Sharding y partioning
Sharding es un enfoque comúnmente utilizado para escalar soluciones de bases de datos. Divides los datos en fragmentos más pequeños y los distribuyes alrededor de diferentes nodos del servidor. Esto requiere que la aplicación tenga en cuenta la modificación del almacenamiento de datos para que funcione de manera eficiente, ya que necesita saber dónde encontrar la información que necesita.
Existen marcos de abstracción disponibles para ayudar a manejar el sharding de datos, como Hibernate Shards , una extensión del Hibernate ORM (que desafortunadamente está en Java. Estoy usando PHP). HiveDB es otra solución de este tipo que también es compatible con el reequilibrio de fragmentos.
Otros
Esfinge
Sphinx es un motor de búsqueda de texto completo, que puede usarse para mucho más que búsquedas de prueba. Para muchas consultas, es mucho más rápido que MySQL (especialmente para agrupar y ordenar), y puede consultar sistemas remotos en paralelo y agregar los resultados, lo que lo hace muy útil en el uso con fragmentación.
En general, sphinx debe usarse con otras soluciones de escala para obtener más hardware e infraestructura disponible. El inconveniente es que, una vez más, necesita el código de la aplicación para estar al tanto de sphinx para usarlo con prudencia.
Resumen
Las soluciones de escala difieren según las necesidades de la aplicación que lo necesita. Para nosotros y para la mayoría de las aplicaciones web, creo que la replicación (probablemente multi-master) es el camino a seguir con un equilibrador de carga que distribuya la carga. La fusión de áreas con problemas específicos (tablas enormes) también es una necesidad para poder escalar horizontalmente.
También voy a darle una oportunidad a Continuent Sequoia y ver si realmente puede hacer lo que promete ya que implicará la menor cantidad de cambios en el código de la aplicación.
La limitación "en la memoria" nos impide utilizar el clúster MySQL para nuestros casi 50 Gb de datos, por lo que estamos utilizando DRBD más Linux Heartbeat .
Es como una matriz de ataques entre dos (o más) cajas que mantiene sincronizadas las bases de datos / logs / configs (pero solo un servidor puede estar "activo" a la vez). La conmutación por error es automática, utiliza la misma dirección IP y es rápida como un reinicio de MySQL, por lo que ha sido una buena solución para nosotros.
Lo bueno de hacer la replicación es que es fácil. Simplemente configure 2 cuadros de mysql, cambie el ID de servidor en el segundo cuadro y luego señale el segundo cuadro al principio con el comando change master to.
Aquí está la configuración esclava de muestra my.cnf relevante
#
# Log names
#
log-bin=binlog
relay-log=relaylog
log-error=errors.log
#
# Log tuning
#
sync_binlog = 1
binlog_cache_size = 1M
#
# Replication rules (what are we interested in listening for...)
#
# In our replicants, we are interested in ANYTHING that isn''t a permission table thing
#
replicate-ignore-db = mysql
replicate-wild-ignore-table=mysql.%
#
# Replication server ID
#
server-id = 2
Así que asegúrese de que cada esclavo obtenga un ID de servidor incrementado en 1 (por lo que el siguiente esclavo es el servidor 3)
configure un nombre de usuario y una contraseña con los que el esclavo pueda conectarse, luego ejecute change master en MASTER_HOST = ''xxxx''; cambiar maestro a MASTER_PASSWORD = "xxxxx";
y así.
finalmente, ejecute "start slave";
Up viene tu esclavo y comienza a replicar. dulce eh!
Esto supone que comienzas con 2 servidores vacíos. Luego puede volcar su db en el servidor maestro, y mientras se carga allí, también se cargará en el esclavo.
Puede verificar el estado del esclavo ejecutando:
mostrar el estado del esclavo / G
Diviértete con eso ... tan fácil ...
Mientras hacía el estudio de Alta Disponibilidad, encontré muchas soluciones y probablemente en nuestro caso, que era un sistema más intensivo en escritura, encontré que el clúster DRBD era mejor que el clúster NDB, ya que proporciona más transacciones por segundo.
Mysql Replication puede proporcionarle una máquina de copia de seguridad que puede ser utilizada como esclava de lectura o puede usarse en caso de recuperación de desastres.
Con diferentes modos de administración de transacciones proporcionados por DRBD, puede reducir el rendimiento alcanzado por la replicación de datos a nivel de dispositivo a través de la red. Para un sistema confiable que no debe perder ninguna transacción en caso de falla, use el modo C, de lo contrario vaya por B.
Intenté enumerar algunos de los aprendizajes que hice durante la configuración del clúster de DRBD en http://www.techiegyan.com/?p=132
Funciona muy bien en la conexión dedicada para replicación, es decir, reserva interfaces de alta velocidad separadas en ambas máquinas solo para la replicación de drbd. Heartbeat puede controlar el clúster muy bien con todos los servicios uno por uno, es decir, direcciones IP, particiones, drbd y mysql.
Todavía estoy por descubrir la configuración Master-Master en DRBD. Se actualizará a medida que tenga éxito en eso.
Gracias.
No los he usado, pero de los documentos diría que la replicación es la solución preferida si la carga más grande es la lectura de la base de datos.
en mi opinión, la confusión aquí solo me devuelve a Mnesia. Con la fragmentación, la forma declarativa y pragmática de manejar índices, la transparencia de ubicación de las réplicas de bases de datos, etc.
En nuestra configuración, ejecutamos MySQL Cluster y Mnesia. Nuestros datos son un poco estacionales. Entonces, lo que sucede es después de algún tiempo, relevamos la mnesia de datos que ya no se usan y los lanzamos al clúster MYSQL. Esto mantiene nuestra mnesia eficiente. También tenemos aplicaciones implementadas en los principales lenguajes de flujo (Python, Clojure, etc.) que usan datos directos de MySQL.
En pocas palabras, ejecutamos mnesia sobre MySQL Cluster. El MySQL Cluster puede manejar grandes conjuntos de datos, una base de datos puede crecer hasta 50GB más. Tenemos a mnesia alimentando las aplicaciones Erlang / OTP . Java y PHP acceden a los datos de mnesia a través de API REST (recientemente Thrift ) adaptadas utilizando JSON y XML como formatos de intercambio.
La capa de acceso a los datos ha abstraído el acceso a los datos en Mnesia y los datos enviados anteriormente en MySQL Cluster si es necesario. Mnesia está aquí esencialmente para alimentar las aplicaciones Erlang / OTP. Una vez que se acapara con los datos, los lanzamos al MYSQL Cluster. La capa de acceso a datos puede acceder a ambos datos en mnesia y MySQL en una API abstraída en nombre de todas las aplicaciones.
Lo que puedo decir aquí es que Mnesia ha sido la mejor opción para nosotros. Las tablas están muy fragmentadas e indexadas, las consultas funcionan muy bien y la base de datos se replica en 2 ubicaciones conectadas a través de un túnel.
Anteriormente, temimos que Mnesia no manejara tantos registros como fuera posible debido a la limitación del tamaño de la tabla. Pero encontramos esta declaración incorrecta. Con un buen ajuste (fragmentación), nuestras bases de datos de mnesia tienen un promedio de aproximadamente 250 millones de registros por año.
Nos hemos beneficiado de la compleja estructura de datos de Erlang y del hecho de que Mnesia puede tragarse sin cambios. Las aplicaciones Erlang / OTP son las más eficientes de todas las demás aplicaciones en lenguajes heredados y con nuestro sistema planeamos migrarlo todo a la tecnología Erlang / OTP. Desde Erlang accedemos a datos de MySQL Cluster y ejecutamos consultas en sus servidores de forma muy maravillosa. De hecho, dedujimos que su Erlang / OTP puede usar completamente los recursos del servidor MySQL debido a su concurrencia masiva (Erlang).
Mnesia nos ha funcionado muy bien. Gracias a su excelente rendimiento, la forma en que Mónica ha cambiado las bases de datos ha cambiado completamente. Nuestros núcleos de CPU del servidor Solaris se mantienen ocupados a un promedio de aproximadamente el 48% de uso en las horas punta.
Le aconsejo que consulte a mnesia y, quién sabe, puede responder a varias de sus necesidades de distribución o replicación.