No me preocupa el cerebro dividido ya que la conexión entre los dos servidores es sólida (y porque no tengo una tercera máquina)
Quiero tener alguna replicación de MariaDB con conmutación por error automática, de modo que incluso si una base de datos muere, continúa funcionando. He visto MaxScale, pero como solo tengo dos máquinas, tendría que ejecutarse en la misma máquina que uno de los servidores y si ese servidor muere, entonces nada funciona. AFAIK, los clústeres de MariaDB Galera se negarán a permitirme ejecutar solo dos y tendrán conmutación por error automática (requerirá quórum). Sin embargo, es posible que pueda ejecutar un árbitro en otra máquina o incluso ejecutar otra base de datos en ella, pero sería lento.
Además, el backend es PHP: estoy dispuesto a cambiar la configuración de mysqli y demás, pero no sé si tendría que cambiar allí o qué.
EDITAR: Estoy dispuesto a renunciar a la conmutación por error automática, pero el comportamiento que desearía sería el siguiente:
Si me conecto al servidor A, se conecta a la base de datos A (maestra) y lee/escribe normalmente.
Si me conecto al servidor B, se conecta a la base de datos B (esclavo de solo lectura) y se lee bien. Si tiene que escribir, podrá hacerlo, pero los enviará a la base de datos A.
¿Sería posible usar MaxScale en ambos servidores o algo así?
Respuesta1
Tienes dos nodos. No use maestro-maestro de ningún tipo, es increíblemente propenso a dividir el cerebro en dos nodos (es casi seguro que sucederá eventualmente).
No se puede esperar que este tipo de aplicación con estado maneje muy bien una implementación de clúster de dos nodos por sí sola; será necesaria la intervención del operador o un CRM para que el clúster sea robusto en caso de falla, que es la razón por la que se agrupados en primer lugar.
Tienes un clúster de dos nodos. Absolutamente debería preocuparse por el cerebro dividido, porque esa arquitectura es muy propensa a condiciones de cerebro dividido. El hecho de que el vínculo de red entre nodos sea sólido hoy no significa que siempre será así, y este es uno de los mayores componentes de riesgo en un clúster de dos nodos. Perder ese vínculo dividirá instantáneamente el cerebro del clúster a menos queESGRIMAoQUÓRUMse establece entre nodos. Esta es una de las consideraciones más importantes en un clúster de dos nodos, ya que el cercado reduce las posibilidades de condiciones de cerebro dividido de altas a casi cero.
Recomendaría manejar esto con Pacemaker/Corosync. Es una pila complicada, pero proporciona los mecanismos necesarios para generar un clúster de nivel de producción en dos nodos. También recomendaría usar solo una instancia maestra a la vez, en lugar de varias instancias maestras, incluso cuando esté bajo la aplicación de dicho administrador de clúster.
Existe una buena guía para HA MariaDB que puede servir como punto de partida. NO cubre el uso de cercas. Si no puede lograr la barrera, Corosync también tiene la capacidad de utilizar un pequeño nodo árbitro que ejecuta un demonio de votación para proporcionar quórum a la implementación general sin costos generales de la aplicación (consulte la información en Corosync qdevice).
Está detrás de un muro de suscripción, pero es unaGuía de principio a fin sobre cómo configurar un clúster MySQL activo-pasivo, ejecutarlo en un nodo a la vez y replicar el almacenamiento en bloque entre nodos.
Los tipos de recursos avanzados de Pacemaker cubren la mayoría de sus preguntas sobre cómo orquestar la conmutación por error de manera elegante, con la capacidad de agrupar recursos en cadenas de dependencia lineal, así como expresar la semántica de elección de líder de varios estados para ejecutar más de una instancia de una aplicación en todos los nodos.Eso se puede encontrar aquí.
Los paquetes son una forma de lograr el aislamiento de aplicaciones en Pacemaker a través de tiempos de ejecución de contenedores como Docker y RKT. Esto abre otra vía de vallado, ya que estos paquetes aparecen en el clúster como nodos Pacemaker, por lo que el clúster puede "cercarlos" independientemente de otras aplicaciones.Eso se puede encontrar aquí.
Respuesta2
Ejecuté varias bases de datos (Mongo, Elasticsearch, SQL Server, otras) con la misma filosofía "No me importan los problemas, solo puedo ejecutar dos nodos".
Era un MUNDO de dolor.
Si ejecutas maestro-esclavo, está bien. Pero habrá dolores de cabeza.
Después de años de darle vueltas al tema y de lidiar con varios dolores de cabeza de Devops creados por mi insistencia en solo dos nodos (en lo que insistí porque nuestras bases de datos eran muy grandes y el costo de un tercer nodo era material), finalmente comencé a ejecutar tres. nodos.
Y luego todo mejoró.
La lección que aprendí de años de baile es: Hay dos opciones:
- Nodo único con repuesto de ish caliente (por ejemplo, maestro-esclavo)
- Tres nodos
Según mi experiencia, nunca volvería a ejecutar dos nodos activo-activo (a menos que haya una pieza mágica que evite por completo la división del cerebro, lo cual he visto y que es increíblemente feo).
De cinco años de ejecutar múltiples bases de datos de 0,5 a 1,5 TB en varias pilas.
Respuesta3
Una opción sería ejecutar una replicación maestro-maestro asíncrona con keepalived para conmutar por error una IP flotante. No es genial, pero cubriría el escenario de falla total del servidor.
¿Tiene ILO o alguna otra forma de hacer que una máquina apague a la otra por la fuerza (STONITH)? Esto es realmente necesario para evitar fallas parciales, por ejemplo, una máquina falla pero no completamente, por lo que todavía está lo suficientemente viva como para responder a los paquetes de latidos pero, por lo demás, no funciona. Esto puede provocar que la conmutación por error no se produzca cuando debería.