Red de conocimientos sobre prescripción popular - Conocimiento dental - Cómo prevenir eficazmente el tiempo de inactividad del sistema del centro de datosEste artículo presenta principalmente varias soluciones para evitar la pérdida de datos MySQL cuando el servidor falla, y también presenta las aplicaciones de replicación, monitoreo y conmutación por error basadas en la práctica. . Los amigos necesitados pueden consultarlo. Para la mayoría de las aplicaciones, MySQL es el centro de almacenamiento de datos más crítico, por lo que cómo permitir que MySQL proporcione servicios HA es un problema que debemos enfrentar. Cuando el servidor principal falla, debemos pensar en cómo garantizar que no se pierdan tantos datos como sea posible, cómo garantizar que el servidor principal falle rápidamente y manejar la conmutación por error correspondiente. Aquí, el autor combinará el trabajo relacionado del agente MySQL y el conjunto de herramientas para hablar sobre la solución MySQL HA que adoptaremos en esta etapa y en el futuro del proyecto. La replicación es una buena manera de garantizar que los datos de MySQL no se pierdan, y MySQL también proporciona un poderoso mecanismo de replicación. Solo necesitamos saber que, por razones de rendimiento, la replicación adopta el modo asíncrono, es decir, los datos escritos no se actualizarán en el esclavo de forma sincrónica. Si el servidor principal falla en este momento, aún podemos enfrentar el riesgo de pérdida de datos. Para solucionar este problema, podemos utilizar la replicación semisincrónica. El principio de replicación semisincrónica es simple. Cuando el maestro haya terminado de procesar una transacción, esperará a que al menos un esclavo con capacidad de semisincronización reconozca que ha recibido el evento y lo escriba en el registro de retransmisión antes de regresar. De esta manera, incluso si el dispositivo maestro falla, al menos un dispositivo esclavo obtendrá datos completos. Sin embargo, la semisincronización no garantiza que no se pierda el 100% de los datos. Si el maestro falla al completar la transacción y enviarla al esclavo, aún puede ocurrir pérdida de datos. En comparación con la replicación asincrónica tradicional, la replicación semisincrónica puede mejorar en gran medida la seguridad de los datos. Más importante aún, no lento. Los autores de "MHA" dijeron que utilizan semisincrónico en el entorno de producción de Facebook (aquí), por lo que creo que realmente no hay necesidad de preocuparse por su rendimiento a menos que su nivel de negocio haya superado por completo a Facebook o Google. Como se menciona en este artículo, la replicación semisíncrona sin pérdidas está disponible a partir de MySQL 5.7, por lo que la probabilidad de perder datos es muy pequeña. Si realmente desea asegurarse completamente de que no se perderán datos, un mejor método en esta etapa es utilizar la solución de clúster MySQL gelera para garantizar que no se pierdan datos escribiendo tres copias al mismo tiempo. No tengo experiencia en el uso de gelera, pero sé que hay empresas en la industria que lo han utilizado en entornos de producción y el rendimiento no debería ser un problema. Sin embargo, gelera es muy intrusivo para el código MySQL y puede no ser adecuado para algunos estudiantes obsesionados con el código limpio :-) También podemos usar drbd para copiar datos MySQL. Hay una introducción detallada en la documentación oficial de MySQL, pero el autor no adoptó esta solución. El autor de MHA ha escrito algunos problemas sobre el uso de drdb, aquí son solo como referencia. En los próximos proyectos, el autor dará prioridad a las soluciones de replicación semisincrónica y, si los datos son realmente importantes, se considerará gelera. En el Monitor anterior, hablamos sobre el uso del mecanismo de replicación para garantizar que no se pierdan tantos datos como sea posible después de que el maestro falle, pero no podemos esperar hasta que el maestro haya estado funcionando durante unos minutos antes de saber que hay un problema. Por eso es esencial contar con un buen conjunto de herramientas de seguimiento. Cuando el servidor principal falla, el monitor puede detectar y realizar rápidamente acciones de seguimiento, como notificar al administrador por correo electrónico o notificar al demonio para una rápida conmutación por error. Por lo general, para monitorear un servicio, usamos keepalived o heartbeat, de modo que cuando el principal falla, podamos cambiar fácilmente a la máquina de respaldo. Pero todavía no pueden detectar inmediatamente que un servicio no está disponible. Actualmente, mi empresa usa keepalived, pero en el futuro me inclino más por usar zookeeper para resolver el monitoreo y la conmutación por error de todo el clúster MySQL. Para cualquier instancia de MySQL, tenemos los agentes correspondientes. El agente se coloca en la misma máquina que la instancia de MySQL y los comandos ping se envían periódicamente a la instancia de MySQL para verificar su disponibilidad. Al mismo tiempo, el agente se monta en el cuidador del zoológico de forma periódica.