Toda empresa rentable requiere alta disponibilidad. Los sitios web y los blogs no son diferentes, ya que incluso las empresas más pequeñas y las personas requieren que sus sitios permanezcan activos para mantener su reputación.
WordPress es, con mucho, el CMS más popular del mundo que impulsa millones de sitios web, desde pequeños hasta grandes. Pero, ¿cómo puede asegurarse de que su sitio web se mantenga activo? Más específicamente, ¿cómo puedo asegurarme de que la falta de disponibilidad de mi base de datos no afecte a mi sitio web?
En esta publicación de blog, mostraremos cómo lograr la conmutación por error para su sitio web de WordPress usando ClusterControl.
La configuración que usaremos para este blog usará Percona Server 5.7. Tendremos otro host que contiene la aplicación Apache y Wordpress. No tocaremos la parte de alta disponibilidad de la aplicación, pero esto también es algo que desea asegurarse de tener. Usaremos ClusterControl para administrar bases de datos para garantizar la disponibilidad y usaremos un tercer host para instalar y configurar ClusterControl.
Suponiendo que ClusterControl esté funcionando, necesitaremos importar nuestra base de datos existente en él.
Importación de un clúster de base de datos con ClusterControl
Vaya a la opción Importar servidor/base de datos existente en el asistente de implementación.
Tenemos que configurar la conectividad SSH ya que este es un requisito para que ClusterControl ser capaz de administrar los nodos.
Ahora tenemos que definir algunos detalles sobre el proveedor, la versión y el usuario root acceso, el nodo en sí, y si queremos que ClusterControl gestione la autorrecuperación por nosotros o no. Eso es todo, una vez que el trabajo se realice correctamente, se le presentará un grupo en la lista.
Para configurar el entorno de alta disponibilidad, necesitamos ejecutar un par de acciones Nuestro entorno consistirá en...
- Par maestro - esclavo
- Dos instancias de ProxySQL para división de lectura/escritura y detección de topología
- Dos instancias de Keepalived para la administración de IP virtuales
La idea es simple:implementaremos el esclavo en nuestro maestro, por lo que tendremos una segunda instancia para la conmutación por error en caso de que falle el maestro. ClusterControl será responsable de la detección de fallas y promoverá el esclavo en caso de que el maestro no esté disponible. ProxySQL mantendrá un registro de la topología de replicación y redirigirá el tráfico al nodo correcto:las escrituras se enviarán al maestro, sin importar en qué nodo se encuentre, las lecturas pueden enviarse solo al maestro o distribuirse entre el maestro y los esclavos. . Finalmente, Keepalived se colocará con ProxySQL y proporcionará VIP para que la aplicación se conecte. Ese VIP siempre se asignará a una de las instancias de ProxySQL y Keepalived lo moverá a la segunda, en caso de que falle el nodo ProxySQL "principal".
Habiendo dicho todo eso, configuremos esto usando ClusterControl. Todo esto se puede hacer con solo un par de clics. Comenzaremos agregando el esclavo.
Agregar una base de datos esclava con ClusterControl
Comenzamos seleccionando el trabajo "Agregar esclavo de replicación". Luego se nos pide que completemos un formulario:
Tenemos que elegir el maestro (en nuestro caso, realmente no tenemos muchas opciones), tenemos que pasar la IP o nombre de host para el nuevo esclavo. Si tuviéramos copias de seguridad creadas previamente, podríamos usar una de ellas para provisionar el esclavo. En nuestro caso, esto no está disponible y ClusterControl aprovisionará el esclavo directamente desde el maestro. Eso es todo, el trabajo comienza y ClusterControl realiza las acciones requeridas. Puede monitorear el progreso en la pestaña Actividad.
Finalmente, una vez que el trabajo se completa con éxito, el esclavo debería estar visible en la lista de grupos.
Ahora procederemos a configurar las instancias de ProxySQL. En nuestro caso, el entorno es mínimo, por lo que, para simplificar las cosas, ubicaremos ProxySQL en uno de los nodos de la base de datos. Sin embargo, esta no es la mejor opción en un entorno de producción real. Idealmente, ProxySQL estaría ubicado en un nodo separado o junto con los otros hosts de aplicaciones.
El lugar para comenzar el trabajo es Administrar -> Equilibradores de carga.
Aquí debe elegir dónde debe instalarse ProxySQL, pasar las credenciales administrativas y agregue un usuario de la base de datos. En nuestro caso, usaremos nuestro usuario existente ya que nuestra aplicación de WordPress ya lo usa para conectarse a la base de datos. Luego tenemos que elegir qué nodos usar en ProxySQL (queremos tanto el maestro como el esclavo aquí) y dejar que ClusterControl sepa si usamos transacciones explícitas o no. Esto no es realmente relevante en nuestro caso, ya que volveremos a configurar ProxySQL una vez que se implemente. Cuando tenga esa opción habilitada, la división de lectura/escritura no estará habilitada. De lo contrario, ClusterControl configurará ProxySQL para división de lectura/escritura. En nuestra configuración mínima, deberíamos pensar seriamente si queremos que ocurra la división de lectura/escritura. Analicemos eso.
Las ventajas y desventajas de leer/escribir escupir en ProxySQL
La principal ventaja de usar la división de lectura/escritura es que todo el tráfico SELECT se distribuirá entre el maestro y el esclavo. Esto significa que la carga en los nodos será menor y el tiempo de respuesta también debería ser menor. Esto suena bien, pero tenga en cuenta que si un nodo falla, el otro nodo tendrá que poder acomodar todo el tráfico. No tiene mucho sentido tener una conmutación por error automatizada si la pérdida de un nodo significa que el segundo nodo se sobrecargará y, de hecho, tampoco estará disponible.
Puede tener sentido distribuir la carga si tiene varios esclavos:perder un nodo de cinco tiene menos impacto que perder uno de dos. Independientemente de lo que decida, puede cambiar fácilmente el comportamiento yendo al nodo ProxySQL y haciendo clic en la pestaña Reglas.
Asegúrese de mirar la regla 200 (la que captura todas las instrucciones SELECT ). En la captura de pantalla a continuación, puede ver que el grupo de host de destino es 20, lo que significa que todos los nodos en el clúster:la división de lectura/escritura y el escalado horizontal están habilitados. Podemos deshabilitar esto fácilmente editando esta regla y cambiando el Grupo de host de destino a 10 (el que contiene el maestro).
Si desea habilitar la división de lectura/escritura, puede hacerlo fácilmente hágalo editando esta regla de consulta nuevamente y configurando el grupo de host de destino nuevamente a 20.
Ahora, implementemos el segundo ProxySQL.
Para evitar pasar todas las opciones de configuración nuevamente podemos usar la opción “Importar configuración ” y elija nuestro ProxySQL existente como fuente.
Cuando se complete este trabajo, todavía tenemos que realizar el último paso para configurar nuestro entorno. Tenemos que implementar Keepalived sobre las instancias de ProxySQL.
Implementación de Keepalived sobre instancias de ProxySQL
Aquí elegimos ProxySQL como el tipo de balanceador de carga, pasamos ambas instancias de ProxySQL para Keepalived para ser instalado y escribimos nuestra interfaz de red y VIP.
Como puede ver, ahora tenemos todo configurado y listo. Tenemos un VIP de 10.0.0.111 que está asignado a una de las instancias de ProxySQL. Las instancias de ProxySQL redirigirán nuestro tráfico a los nodos back-end MySQL correctos y ClusterControl vigilará el entorno que realiza la conmutación por error si es necesario. La última acción que tenemos que tomar es reconfigurar Wordpress para usar la IP virtual para conectarse a la base de datos.
Para hacer eso, tenemos que editar wp-config.php y cambiar la variable DB_HOST a nuestra IP virtual:
/** MySQL hostname */
define( 'DB_HOST', '10.0.0.111' );Conclusión
A partir de ahora, Wordpress se conectará a la base de datos usando VIP y ProxySQL. En caso de que falle el nodo maestro, ClusterControl realizará la conmutación por error.
Como puede ver, se ha elegido un nuevo maestro y ProxySQL también apunta hacia nuevo maestro en el hostgroup 10.
Esperamos que esta publicación de blog le brinde una idea sobre cómo diseñar un entorno de base de datos de alta disponibilidad para un sitio web de Wordpress y cómo se puede usar ClusterControl para implementar todos sus elementos.
