Después de un problema de datos masivo de mi proveedor en Alemania, ahora me veo obligado a lidiar con escenarios de conmutación por error. Pero hay algunas preguntas para las que no puedo encontrar ninguna respuesta real. Entonces espero que alguien pueda ayudarme aquí.
Actualmente tengo el servidor1 ejecutando dos bases de datos MySQL en contenedores acoplables separados. Estos ahora deberían replicarse en un segundo servidor. En caso de que el servidor1 falle, puedo cambiar al servidor2 relativamente rápido a través de un ClusterIP.
En caso de que sea importante saberlo: el software que utiliza la base de datos es un sistema de gestión de competiciones deportivas que realiza muchas operaciones de escritura en la base de datos (no probado, pero en total no escribe operaciones de lectura).
Las preguntas para mí son ahora:
- ¿Qué método de replicación es el más adecuado?
- Según tengo entendido, MASTER <-> MASTER sería el más apropiado. Pero también he leído aquí una y otra vez que pueden surgir problemas.
- Con MASTER <-> SLAVE surge la pregunta de que el esclavo sólo puede leer. ¿Qué pasa si el maestro falla? ¿El esclavo se convierte entonces automáticamente en maestro y también puede escribir?
- ¿O es un clúster la mejor solución? Por el momento solo tengo un nodo activo. En el futuro se podría añadir otro nodo de base de datos en EE. UU. Pero por el momento no existe.
Realmente aprecio cualquier ayuda, porque necesito una solución que funcione rápidamente y este tema general parece ser muy amplio y no tan fácil.
Respuesta1
Planteas dos cuestiones.
Topología MySQLEn orden (de OK a Mejor)
- Primario -> Réplica: se puede lograr una "conmutación por error", pero requiere esfuerzo manual y, por lo tanto, tiempo.
- Primario <=> Primario: esto es sólo un poco más complejo de configurar, pero proporciona un uso "instantáneo" del otro servidor.
- Clúster de al menos 3 servidores. Esto automatiza aún más la conmutación por error. Consulte "InnoDB CLuster" (MySQL 8) o "Galera" (incluido con MariaDB).
Geografía: tenga en cuenta que incluso un centro de datos puede fallar. Por ejemplo, ¿cuánto de, digamos, Florida, puede quedar fuera de servicio por un solo huracán?
Tenga en cuenta el escenario del "cerebro dividido". Aquí es donde sólo tienes dos servidores y ambos están funcionando y bien, pero la red no funciona. No pueden decirlo y usted no puede decir cuál es la situación. Si cada uno piensa que es el único servidor vivo y continúa escribiendo, terminará con un desastre. Entonces, en lugar de eso, hay que asumir que todo el sistema está caído.
En pocas palabras: necesita al menos 3 servidores, físicamente separados.
Apoderado
Todavía existe el problema declientelasaber qué parte del sistema de base de datos está viva (para lectura y/o escritura). Cuando sólo la "lectura" es importante, muchas topologías con cualquier número de réplicas son suficientes y proporcionan un escalado "ilimitado". "Los escritos" son donde están los verdaderos desafíos.
Hay varios productos de terceros que son buenos para darse cuenta de que un servidor está inactivo y "hacer lo correcto" al redirigir a otro servidor. Investigarlos.
Codificación
Cuando ocurre una falla, es probable que su código reciba algún tipo de error. Debes comprobar si hay errores, algunos no se reparan solos. Y la mayoría de los errores de red tardan algún tiempo en notarse.