Tengo un clúster de 3 servidores mySQL/PHP/Apache (cada uno en diferentes continentes para una máxima resiliencia). He leído muchos consejos que dicen: ¡no hagas esto!
Básicamente, las razones por las que quiero hacer esto son:
- Resiliencia: 2 de 3 servidores podrían caer y los usuarios aún pueden iniciar sesión y ver sus datos/hacer su trabajo
- Copia de seguridad: algo así como lo anterior
- Compartir carga: puedo distribuir la carga front-end Y los procesos del servidor back-end entre las diferentes cajas
He analizado diferentes opciones, incluida la percona galera, y todas parecen tener inconvenientes. El principal es la transparencia: en algún momento un enlace o servidor dejará de funcionar, luego obtendrás errores vagos de BINLOG y luego todo será un problema enorme...
Así que lo he implementado yo mismo: tengo un conjunto de scripts que crean activadores INSERTAR/ACTUALIZAR/ELIMINAR en cada tabla; cualquier cambio se registra en una tabla de replicación. Un proceso cada minuto envía estos cambios a los otros 2 servidores. También cuento con procesos que verifican el CHECKSUM y alertan sobre cualquier discrepancia.
Funciona muy bien. ¡No es fácil, te lo reconozco! Múltiples cosas complicadas, que incluyen:
- no utilizar el tipo de columna flotante (0,3434 no es igual a 0,3434...)
- evitando claves de incremento automático (si se insertan datos en 2 servidores diferentes al mismo minuto, ambos podrían tomar el siguiente valor, entonces las inserciones recíprocas fallarán).
- recuerde volver a ejecutar el script de creación de activadores si cambia la estructura de una tabla
Entonces mi pregunta es... ¿Qué podría salir mal? ¿Dónde y por qué esto va a fallar? Que no se yo??
Respuesta1
Al contrario de lo anterior, creo que esta es una pregunta excelente. No están pidiendo un análisis de lo que han hecho, sólo una "cuarta ventana" general de cuáles son las incógnitas desconocidas.
Las aplicaciones intensivas en datos son unaexcelente libro Lo llaman replicación de múltiples líderes en lugar de maestro-maestro y tienen una buena discusión sobre por qué esto tiene inconvenientes. Como has visto, los servicios con Galera y Percona no lo hacen, así que debe haber una buena razón (aún no he jugado con Blackhole).
Creo que el mensaje clave es que debe asegurarse de que la estructura de la tabla pueda soportar la replicación de múltiples clientes potenciales, por lo que si se agregan 2 nuevas entradas en servidores separados, no querrá (como usted dice) tener una clave de incremento automático. campo: debe haber diseñado la tabla y la aplicación para usar tal vez la identificación del usuario y la marca de tiempo, etc. (eso es un trabajo manual complicado).
Probablemente también necesite herramientas decentes para poder comparar rápidamente tablas entre bases de datos y detectar inconsistencias.