En el inicio en el que estoy trabajando, ahora estamos considerando soluciones de escala para nuestra base de datos. Las cosas se ponen algo confusas (al menos para mí) con MySQL, que tiene el clúster MySQL , la replicación y la replicación del clúster MySQL (desde 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 el clúster , pero es difícil determinar cuándo usar una u otra.
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 usar cada una.
mysql
replication
scaling
cluster-computing
database-cluster
Eran Galperin
fuente
fuente
Respuestas:
He estado leyendo MUCHO sobre las opciones disponibles. También tuve en mis manos la segunda edición de MySQL de alto rendimiento, que recomiendo encarecidamente.
Esto es lo que he logrado reconstruir:
Clustering
La agrupación en clústeres en el sentido general consiste en distribuir la carga entre muchos servidores que a una aplicación externa le parecen un solo servidor.
Clúster MySQL NDB
MySQL NDB Cluster es un motor de almacenamiento distribuido, en memoria, que no comparte nada con replicación síncrona y partición automática de datos (disculpe, tomo prestado literalmente del libro High Performance, pero lo expresaron 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 tocan solo 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. Dado que la aplicación trata al clúster como una sola computadora, no puede decirle de qué nodo buscar los datos.
Además, el requisito en memoria no es viable para muchas bases de datos grandes.
Continuent Sequoia
Esta es otra solución de agrupamiento en clústeres para MySQL, que actúa como un middleware sobre el servidor MySQL. Ofrece replicación sincrónica, equilibrio de carga y conmutación por error. También asegura que las solicitudes siempre obtengan los datos de la última copia, eligiendo automáticamente un nodo que tenga los datos nuevos.
He leído algunas cosas buenas sobre él y, en general, suena bastante prometedor.
Federación
La federación es similar a la agrupación, por lo que también lo tiré aquí. MySQL ofrece federación a través del motor de almacenamiento federado. Al igual que la solución de clúster NDB, funciona bien solo con consultas simples, pero peor aún con el clúster para consultas complicadas (ya que la latencia de la red es mucho mayor).
Replicación y equilibrio de carga
MySQL tiene la capacidad incorporada para crear réplicas de una base de datos en diferentes servidores. Esto se puede utilizar 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 que un servidor maestro maneje principalmente las escrituras y uno o más esclavos manejen solo las lecturas. Una variación más avanzada es la de la configuración maestro-maestro , que también permite escalar 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 la replicación: dado que la replicación de MySQL es asincrónica, no todos los nodos tienen los datos más actualizados en todo momento. Esto requiere que la aplicación sea consciente de la replicación e incorpore consultas compatibles con la replicación para que funcione como se esperaba. Para algunas aplicaciones, esto puede no ser un problema, pero si siempre necesita los datos más recientes, las cosas se complican un poco.
La replicación requiere 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 usar soluciones de software y hardware dedicadas.
Fragmentación y partición
La fragmentación es un enfoque comúnmente utilizado para escalar soluciones de bases de datos. Divide los datos en fragmentos más pequeños y los distribuye por diferentes nodos del servidor. Esto requiere que la aplicación esté al tanto de la modificación en el almacenamiento de datos para funcionar de manera eficiente, ya que necesita saber dónde encontrar la información que necesita.
Hay marcos de abstracción disponibles para ayudar a lidiar con la fragmentación de datos, como Hibernate Shards , una extensión de Hibernate ORM (que desafortunadamente está en Java. Estoy usando PHP). HiveDB es otra solución de este tipo que también admite el reequilibrio de fragmentos.
Otros
Esfinge
Sphinx es un motor de búsqueda de texto completo que se puede utilizar 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 su uso con fragmentación.
En general, sphinx debe usarse con otras soluciones de escalado para obtener más del hardware y la infraestructura disponibles. La desventaja es que nuevamente necesitas que el código de la aplicación sea consciente de Sphinx para usarlo de manera inteligente.
Resumen
Las soluciones de escalado difieren según las necesidades de la aplicación que las necesita. Para nosotros y para la mayoría de las aplicaciones web, creo que la replicación (probablemente multimaestro) es el camino a seguir con un equilibrador de carga que distribuye la carga. La fragmentación de áreas problemáticas específicas (tablas enormes) también es imprescindible para poder escalar horizontalmente.
También voy a probar 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.
fuente
Descargo de responsabilidad: no he usado MySQL Cluster, por lo que solo me baso en lo que escuché.
MySQL Cluster es una solución HA (alta disponibilidad). Es rápido, porque todo está 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 deja de funcionar, debe 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 la base de datos quepa en la memoria. Eso significa que cada máquina del clúster debe 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 muy importante (léase: probablemente no), es más complicado (y dinero) de lo que vale. La replicación suele ser la mejor manera de hacerlo.
Editar: Olvidé mencionar también que Cluster no permite claves externas, y los escaneos de rango son más lentos que en otros motores. Aquí hay un enlace que habla sobre las limitaciones conocidas de MySQL Cluster
fuente
Hay algunas buenas discusiones sobre cómo la gente que mantiene drupal.org ha 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 ese momento eligieron la replicación.
fuente
Lo bueno de la replicación es que es fácil. Simplemente configure 2 cajas de mysql, cambie la ID del servidor en la segunda caja y luego apunte la segunda caja a la primera usando el comando change master to.
Aquí está el esclavo de muestra relevante my.cnf config
# # 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 = 2Así 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 contraseña a los que el esclavo pueda conectarse, luego ejecute cambiar maestro a MASTER_HOST = 'xxxx'; cambiar maestro a MASTER_PASSWORD = "xxxxx";
y así.
finalmente, ejecute "iniciar esclavo";
Viene tu esclavo y comienza a replicarse. dulce eh!
Esto supone que comienzas con 2 servidores vacíos. Luego puede volcar su base de datos en el servidor maestro y, a medida que 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 ...
fuente
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é el clúster DRBD mejor que el clúster NDB, ya que proporciona una mayor cantidad de transacciones por segundo.
Mysql Replication puede proporcionarle una máquina de respaldo que puede usarse como esclava de lectura o puede usarse en caso de recuperación ante desastres.
Con diferentes modos de gestión de transacciones proporcionados por DRBD, puede reducir en parte el impacto en el rendimiento de la replicación de datos a nivel de dispositivo en la red. Para un sistema confiable que no debería perder ninguna transacción en caso de falla, use el modo C, de lo contrario, elija B.
Intenté enumerar algunos de los aprendizajes que hice durante la configuración del clúster DRBD en http://www.techiegyan.com/?p=132
Funciona muy bien en una conexión dedicada para la replicación, es decir, reserva interfaces de alta velocidad separadas en ambas máquinas solo para la replicación 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 tengo que descubrir la configuración Master-Master en DRBD. Se actualizará cuando tenga éxito en eso.
Gracias.
fuente
en mi opinión, la confusión aquí me envía de regreso a Mnesia. Con fragmentación, forma declarativa y pragmática de manejar índices, transparencia de ubicación de réplicas de bases de datos, etc.
En nuestra configuración, ejecutamos MySQL Cluster y Mnesia. Nuestros datos son algo estacionales. Entonces, lo que sucede es que después de algún tiempo, liberamos mnesia de datos que ya no se usan y los arrojamos al clúster MYSQL. Esto mantiene nuestra mnesia eficiente. También tenemos aplicaciones implementadas en los principales lenguajes de transmisión (Python, Clojure, etc.) que usan datos directamente de MySQL.
En pocas palabras, ejecutamos mnesia sobre MySQL Cluster. MySQL Cluster puede manejar grandes conjuntos de datos, una base de datos puede crecer a más de 50 GB. Tenemos mnesia impulsando las aplicaciones Erlang / OTP . Java y PHP acceden a datos de mnesia a través de API REST (recientemente Thrift ) personalizadas que utilizan 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 antiguos enviados en MySQL Cluster si es necesario. Mnesia está aquí esencialmente para impulsar las aplicaciones de Erlang / OTP. Una vez que se llena de datos, los colocamos en MYSQL Cluster. La capa de acceso a datos puede acceder tanto a los datos en mnesia como a 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, temíamos que mnesia no manejara tantos registros como fuera posible debido a la limitación del tamaño de la tabla. Pero encontramos esta afirmación incorrecta. Con un buen ajuste (fragmentación), nuestras bases de datos de mnesia contienen un promedio de alrededor de 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 absorberlos sin cambios. Las aplicaciones Erlang / OTP son las más eficientes de todas las demás aplicaciones en idiomas heredados y con nuestro sistema estamos planeando migrarlo todo a la tecnología Erlang / OTP. Desde Erlang accedemos sin problemas a los datos de MySQL Cluster y ejecutamos consultas en sus servidores maravillosamente. De hecho, hemos deducido que es Erlang / OTP que puede usar completamente los recursos del servidor MySQL debido a su concurrencia masiva (Erlang).
Mnesia nos ha funcionado muy bien. Mnesia ha cambiado por completo la forma en que vemos las bases de datos debido a su emocionante rendimiento. Los núcleos de CPU de nuestro servidor Solaris se mantienen ocupados con un uso promedio de aproximadamente el 48% en las horas pico.
Le aconsejo que compruebe mnesia y quién sabe, puede responder a varias de sus necesidades de distribución o replicación.
fuente
No los he usado, pero de los documentos diría que la replicación es la solución preferida si la mayor carga es la lectura de la base de datos.
fuente
La limitación "en memoria" nos impide usar el clúster MySQL para nuestros casi 50 Gb de datos, por lo que estamos usando DRBD más linux Heartbeat .
Es como una matriz de incursión entre dos (o más) cajas que mantiene sincronizadas las bases de datos / registros / configuraciones (pero solo un servidor puede estar "en vivo" a la vez). La conmutación por error es automática, utiliza la misma dirección IP y es tan rápida como un reinicio de mysql, por lo que ha sido una buena solución para nosotros.
fuente
El clúster de MySQL es una bestia extraña y cada vez que lo evaluamos, se desempeñó muy mal o no fue confiable.
Es terriblemente complicado de configurar (necesita 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 proxy, etc.).
Es extremadamente inteligente, porque realiza particiones hash automáticas en la clave principal, lo que le permite escalar las escrituras, y también porque no tiene un solo punto de falla.
Pero realmente creo que se adapta mejor a los casos muy especiales para los que fue diseñado. En la mayoría de los casos, no puede reemplazar a otro motor de base de datos (por ejemplo, InnoDB) ni en rendimiento ni en funciones.
fuente