¿Arquitectura de base de datos maestro-maestro vs maestro-esclavo?

117

He oído hablar de dos tipos de arquitecturas de bases de datos.

  • maestro maestro

  • maestro-esclavo

¿No es el maestro-maestro más adecuado para la web de hoy porque es como Git, cada unidad tiene el conjunto completo de datos y si uno falla, no importa del todo?

Maestro-esclavo me recuerda a SVN (que no me gusta) donde tienes una unidad central que se encarga de todo.

Preguntas:

  1. ¿Cuáles son los pros y los contras de cada uno?

  2. Si desea tener una base de datos local en su teléfono móvil como iPhone, ¿cuál es más apropiada?

  3. ¿Es la elección de uno de estos un factor crítico a considerar a fondo?

database 
— never_had_a_name
fuente
1
Teorema de CAP -> La tolerancia de partición de disponibilidad de consistencia establece que no puede tener los tres juntos. Dependiendo de la aplicación, puede elegir cualquiera.
— Pritam Banerjee

Respuestas:

87

Estamos negociando disponibilidad, consistencia y complejidad. Para abordar la última pregunta primero: ¿Importa esto? ¡Sí mucho! Las opciones relativas a cómo se administrarán sus datos son absolutamente fundamentales, y no hay "Mejores prácticas" que eludan las decisiones. Debe comprender sus requisitos particulares.

Hay una tensión fundamental:

Una copia: la consistencia es fácil, pero si resulta que todo el mundo está fuera del agua, y si la gente está lejos, entonces pueden pagar costos de comunicación horribles. Traiga dispositivos portátiles, que pueden necesitar operar desconectados, en la imagen y una copia no será suficiente.

Maestro esclavo: la coherencia no es demasiado difícil porque cada pieza de datos tiene exactamente un maestro propietario. Pero entonces, ¿qué haces si no puedes ver a ese maestro? Se necesita algún tipo de trabajo pospuesto.

Maestro-Maestro: bueno, si puedes hacer que funcione, parece que ofrece todo, ningún punto único de falla, todos pueden trabajar todo el tiempo. El problema con esto es que es muy difícil mantener una consistencia absoluta. Ver el artículo de wikipedia para obtener más información.

Wikipedia parece tener un buen resumen de las ventajas y desventajas

Ventajas

  • Si un maestro falla, otros maestros continuarán actualizando la base de datos.

  • Los maestros pueden estar ubicados en varios sitios físicos, es decir, distribuidos a través de la red.

Desventajas

  • La mayoría de los sistemas de replicación multimaestro son sólo vagamente coherentes, es decir, perezosos y asincrónicos, violando las propiedades de ACID.

  • Los sistemas de replicación ansiosos son complejos e introducen cierta latencia de comunicación.

  • Problemas como la resolución de conflictos pueden volverse intratables a medida que aumenta el número de nodos involucrados y disminuye la latencia requerida.

— djna
fuente
CouchDB usa MVCC. ¿Este tipo de maneja el problema de consistencia que enfrentan varios maestros? Cuando uno lo puse en línea nuevamente, el sistema de control de versiones maneja la consistencia y este maestro obtendrá los datos actualizados correctos.
— never_had_a_name
8
Pero, ¿qué sucede cuando dos usuarios hacen algo contradictorio, como dos usuarios que intentan comprar el último artículo en stock? Imagine un escenario en el que tenemos dos maestros y cada usuario está golpeando un maestro diferente, luego obtenemos algún tipo de falla de comunicación; al final, habrá un compromiso de integridad o una disponibilidad reducida; a un usuario se le dice "lo siento amigo, Realmente no sé qué está pasando hasta que hablo con el otro maestro ", o tenemos un conflicto desagradable cuando se restablecen las comunicaciones, y eso puede volverse realmente complicado.
— Djna
2
¿Qué utilizan el comercio financiero o los mercados de valores? ¿Estarían enfrentando este problema todo el tiempo?
— CMCDragonkai
3
Cuando necesite una "verdad" única y actualizada (como en los sistemas financieros), necesitará Maestro / Esclavo o, de hecho, solo Maestro. Donde puede arreglar la verdad más tarde (piense en conflictos de fusión en un sistema de control de revisión como Git), entonces puede usar Master / Master.
— Djna
djna hace una observación muy destacada. La base de datos ahora tiene que tener algún tipo de lógica de "desempate". ¿Qué es lo más importante? ¿Los datos más "recientes"? Eso tiene sentido si está reescribiendo un campo, pero no tiene sentido si está haciendo un "contador" y necesita que todos los procesos se incrementen (o disminuyan) antes de devolver un resultado. Especialmente para que no venda artículos agotados. Si tenía una partición de red, ¿qué sucede cuando se vuelve a armar? Todo esto es cosa de CAP theorum. Aquí también es donde puede tener algoritmos como Paxos, para desarrollar consenso entre diferentes máquinas.
— Peter Corless
95

Mientras investiga las diversas arquitecturas de bases de datos también. He recopilado una buena cantidad de información que podría ser relevante para otra persona que investigue en el futuro. Me encontré con

  1. Replicación maestro-esclavo
  2. Replicación maestro-maestro
  3. Clúster MySQL

He decidido conformarme con usar MySQL Cluster para mi caso de uso. Sin embargo, consulte a continuación los diversos pros y contras que he compilado

1. Replicación maestro-esclavo

Pros

  • Las aplicaciones analíticas pueden leer de los esclavos sin afectar al maestro
  • Copias de seguridad de toda la base de datos de relativamente ningún impacto en el maestro
  • Los esclavos se pueden desconectar y sincronizar con el maestro sin ningún tiempo de inactividad

Contras

  • En el caso de una falla, un esclavo debe ser ascendido a maestro para que ocupe su lugar. Sin conmutación por error automática
  • Tiempo de inactividad y posiblemente pérdida de datos cuando falla un maestro
  • Todas las escrituras también deben realizarse en el maestro en un diseño maestro-esclavo
  • Cada esclavo adicional agrega algo de carga al maestro, ya que el registro binario debe leerse y los datos se deben copiar a cada esclavo.
  • Es posible que la aplicación deba reiniciarse

2. Replicación maestro-maestro

Pros

  • Las aplicaciones pueden leer de ambos maestros
  • Distribuye la carga de escritura en ambos nodos maestros
  • Conmutación por error simple, automática y rápida

Contras

  • Vagamente consistente
  • No es tan simple como maestro-esclavo de configurar e implementar

3. Clúster MySQL

El nuevo chico de la ciudad basado en el diseño de clústeres MySQL. El clúster MySQL se desarrolló teniendo en cuenta la alta disponibilidad y escalabilidad y es la solución ideal para entornos que no requieren tiempo de inactividad, alta disponibilidad y escalabilidad horizontal.

Consulte MySQL Cluster 101 para obtener más información.

Pros

  • (Alta disponibilidad) Ningún punto único de falla
  • Rendimiento muy alto
  • 99,99% de tiempo de actividad
  • Auto-Sharding
  • Capacidad de respuesta en tiempo real
  • Operaciones en línea (cambios de esquema, etc.)
  • Escrituras distribuidas

Contras

Puede visitar el desglose completo de mi blog, incluidos los diagramas de arquitectura que detallan más sobre las 3 arquitecturas mencionadas.

— Skillachie
fuente
2
¿También puedes escribir algo sobre Galera? Clúster Percona XtraDB?
— Ivanov
"Es posible que la aplicación deba reiniciarse" como parte de los contras. Qué significa eso?
— Lily
1
Si tiene que cambiar la IP del servidor de base de datos, también deberá configurarlo en la aplicación para leer del nuevo maestro elegido. Como resultado, es posible que deba reiniciar su aplicación para recuperar los nuevos ajustes de configuración. Todo depende de tu configuración actual. También puede usar una IP flotante para evitar esto. Solo para darte una idea general
— Skillachie
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.