Solución:
Porque, como cualquier otra optimización, no se adapta a todas las cargas de trabajo.
Galera puede verse abrumada por una alta tasa de transacciones o cuando las transacciones actualizan muchas filas. También puede hacer que sus aplicaciones experimenten retrasos en COMMIT a medida que se sincroniza el clúster.
Galera tampoco actualiza otros nodos de forma síncrona. Simplemente transmite subproyectos de forma sincrónica. De esta manera, es un poco como la replicación estándar en modo semisincrónico. Por lo tanto, todavía existe una pequeña posibilidad de leer datos obsoletos de otro nodo del clúster. Hay una opción que puede configurar para forzar a SELECT a esperar hasta que la cola de subproyectos haya actualizado la base de datos, pero esto significa que tiene retrasos en SELECT. E incluso la posibilidad de llegar a un punto muerto en SELECT, lo que parece contrario a la intuición.
Galera es brillante, pero no una tecnología única para todos. Aún existen buenas razones para utilizar la replicación asincrónica.
Algunos inconvenientes de Galera incluyen:
- Soporte del motor de almacenamiento: limitado a InnoDB / XtraDB (más soporte experimental para MyISAM)
-
Soporte de sistema operativo: solo Oses tipo Linux / Unix
También hay algunas limitaciones que deben tenerse en cuenta, pero tal vez se puedan solucionar:
- De forma predeterminada (Total Order Isolation), las operaciones DDL bloquean todo el clúster hasta que se completan
- Cada tabla debe tener una clave primaria explícita, ya sea de una o varias columnas
- Bloqueo: algunos tipos de bloqueo explícito no son compatibles.
Para obtener más información, consulte los detalles en Codership (y aquí sobre el bloqueo de DDL), MariaDB y Percona.
EDITAR: Tenga en cuenta también que algunos argumentan que los clústeres de bases de datos estrechamente acoplados, como Galera, no deberían tener nodos distribuidos geográficamente debido a los problemas derivados de la falta de fiabilidad inherente de la capa de red. En su lugar, se deben utilizar soluciones asincrónicas en estos casos. Consulte: Cómo no hacer MySQL High Availability: Distribución de nodos geográficos con mal uso de la replicación basada en Galera. Sin embargo, el blog de Galera afirma que (2015):
El argumento a favor de la creación de clústeres de bases de datos distribuidas geográficamente es sólido. El enfoque de Galera para la replicación y las características específicas del producto hacen que sea práctico construir clústeres de Galera que abarquen múltiples centros de datos y múltiples usuarios ya tienen tales clústeres en producción.