Drupal es un sistema de administración de contenido (CMS) diseñado para crear de todo, desde pequeños hasta grandes sitios web corporativos. Más de 1,000,000 de sitios web se ejecutan en Drupal y se utiliza para crear muchos de los sitios web y aplicaciones que usa todos los días (incluido este). Drupal tiene un gran conjunto de características estándar, como la creación de contenido fácil, un rendimiento confiable y una seguridad excelente. Lo que distingue a Drupal es su flexibilidad, ya que la modularidad es uno de sus principios fundamentales.
Drupal también es una excelente opción para crear marcos digitales integrados. Puedes ampliarlo con los miles de complementos disponibles. Estos módulos amplían la funcionalidad de Drupal. Los temas le permiten personalizar la presentación de su contenido y las distribuciones (paquetes de Drupal) son paquetes que puede usar como kits de inicio. Puede usar todas estas funcionalidades para mezclar y combinar para mejorar las capacidades principales de Drupal o para integrar Drupal con servicios externos. Es un software de gestión de contenidos potente y escalable.
Drupal utiliza bases de datos para almacenar su contenido web. Cuando su sitio web o aplicación basado en Drupal experimenta una gran cantidad de tráfico, puede tener un impacto en su servidor de base de datos. Cuando se encuentre en esta situación, necesitará equilibrio de carga, alta disponibilidad y una arquitectura redundante para mantener su base de datos en línea.
Cuando comencé a investigar este blog, me di cuenta de que hay muchas respuestas a este problema en línea, pero las soluciones recomendadas estaban muy anticuadas. Esto podría ser el resultado del aumento en la participación de mercado de WordPress, lo que resulta en una comunidad de código abierto más pequeña. Lo que sí encontré fueron algunos ejemplos sobre la implementación de alta disponibilidad usando Maestro/Maestro (Alta disponibilidad) o Maestro/Maestro/Esclavo (Alta disponibilidad/Alto rendimiento).
Drupal ofrece soporte para una amplia gama de bases de datos, pero inicialmente fue diseñado usando variantes de MySQL. Aunque el uso de MySQL es totalmente compatible, existen mejores enfoques que puede implementar. Sin embargo, la implementación de estos otros enfoques, si no se hace correctamente, puede hacer que su sitio web experimente una gran cantidad de tiempo de inactividad, hacer que su aplicación sufra problemas de rendimiento y puede provocar problemas de escritura en sus esclavos. Realizar el mantenimiento también sería difícil, ya que necesita una conmutación por error para aplicar las actualizaciones o parches del servidor (hardware o software) sin tiempo de inactividad. Esto es especialmente cierto si tiene una gran cantidad de datos, lo que puede causar un gran impacto en su negocio.
Estas son situaciones que no desea que sucedan, por lo que en este blog discutiremos cómo puede implementar la conmutación por error de la base de datos para sus bases de datos MySQL o PostgreSQL.
¿Por qué su sitio web de Drupal necesita conmutación por error de la base de datos?
De Wikipedia “la conmutación por error es cambiar a un servidor, sistema, componente de hardware o red redundante o en espera ante la falla o terminación anormal de la aplicación, el servidor, el sistema, el componente de hardware o la red previamente activos. La conmutación por error y la conmutación son esencialmente la misma operación, excepto que la conmutación por error es automática y, por lo general, funciona sin previo aviso, mientras que la conmutación requiere intervención humana”.
En operaciones de bases de datos, conmutación también es un término que se usa para la conmutación por error manual, lo que significa que requiere que una persona opere la conmutación por error. La conmutación por error resulta útil para cualquier administrador, ya que aísla los problemas no deseados, como la eliminación/eliminación accidental de tablas, largas horas de tiempo de inactividad que causa un impacto en el negocio, corrupción de la base de datos o corrupción a nivel del sistema.
Database Failover consta de más de un solo nodo de base de datos, ya sea física o virtualmente. Idealmente, dado que la conmutación por error requiere que cambie a un nodo diferente, también podría cambiar a un servidor de base de datos diferente, si un host ejecuta varias instancias de base de datos en un solo host. Eso todavía puede ser conmutación o conmutación por error, pero normalmente es más redundancia y alta disponibilidad en caso de que ocurra una catástrofe en ese host actual.
Conmutación por error de MySQL para Drupal
La realización de una conmutación por error para su aplicación basada en Drupal requiere que los datos manejados por la base de datos no se diferencien ni se separen. Hay varias soluciones disponibles, y ya hemos discutido algunas de ellas en blogs anteriores de Variousnines. Es posible que desee leer nuestra Introducción a la conmutación por error para la replicación de MySQL:el blog 101.
El cambio maestro-esclavo
Los enfoques más comunes para MySQL Failover son usar el cambio maestro-esclavo o la conmutación por error manual. Hay dos enfoques que puede hacer aquí:
- Puede implementar su base de datos con una replicación asíncrona típica maestro-esclavo.
- o se puede implementar con la replicación asíncrona maestro-esclavo mediante la replicación basada en GTID.
Cambiar a otro maestro podría ser más rápido y fácil. Esto se puede hacer con la siguiente sintaxis de MySQL:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */o con GTID, simplemente puede hacer,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitUsar el enfoque sin GTID requiere que determine primero el archivo de registro del maestro y la posición del registro del maestro. Puede determinar esto observando el estado del maestro en el nodo maestro antes de cambiar.
mysql> MASTER STATUS;También puede considerar fortalecer su servidor agregando sync_binlog =1 e innodb_flush_log_at_trx_commit =1 ya que, en caso de que su maestro falle, tendrá una mayor probabilidad de que las transacciones del maestro no estén sincronizadas con su esclavo ( s). En tal caso, el maestro promocionado tiene una mayor probabilidad de ser un nodo de origen de datos coherente.
Sin embargo, es posible que este no sea el mejor enfoque para su base de datos de Drupal, ya que podría imponer tiempos de inactividad prolongados si no se realiza correctamente, como que se elimine abruptamente. Si el nodo de su base de datos maestra experimenta un error que hace que una base de datos se bloquee, necesitará que su aplicación apunte a otra base de datos que espera en espera como su nuevo maestro o que promueva a su esclavo para que sea el maestro. Deberá especificar exactamente qué nodo debe hacerse cargo y luego determinar el retraso y la consistencia de ese nodo. Lograr esto no es tan fácil como simplemente hacer SET GLOBAL read_only=1; CAMBIAR MAESTRO A… (etc), hay ciertas situaciones que requieren un análisis más profundo, mirando las transacciones viables requeridas para estar presentes en ese servidor en espera o maestro promocionado, para hacerlo.
Conmutación por error de Drupal usando MHA
Una de las herramientas más comunes para la conmutación por error automática y manual es MHA. Ha existido durante mucho tiempo y todavía es utilizado por muchas organizaciones. Puede consultar estos blogs anteriores que tenemos sobre el tema, Principales problemas comunes con MHA y cómo solucionarlos o Herramientas de alta disponibilidad de MySQL:comparación de MHA, MRM y ClusterControl.
Conmutación por error de Drupal con Orchestrator
Orchestrator ha sido ampliamente adoptado ahora y está siendo utilizado por grandes organizaciones como Github y Booking.com. No solo le permite administrar una conmutación por error, sino también la administración de topología, el descubrimiento de host, la refactorización y la recuperación. Hay un buen blog externo aquí que me resultó muy útil para aprender sobre su mecanismo de conmutación por error con Orchestrator. Es una serie de blogs de dos partes; primera y segunda parte.
Conmutación por error de Drupal usando MaxScale
MaxScale no es solo un equilibrador de carga diseñado para el servidor MariaDB, sino que también amplía la alta disponibilidad, escalabilidad y seguridad para MariaDB y, al mismo tiempo, simplifica el desarrollo de aplicaciones al desacoplarla de la infraestructura de la base de datos subyacente. Si está utilizando MariaDB, entonces MaxScale podría ser una tecnología relevante para usted. Consulte nuestros blogs anteriores sobre cómo puede utilizar el mecanismo de conmutación por error de MaxScale.
Conmutación por error de Drupal usando ClusterControl
ClústerControl de Variosnines ofrece una amplia variedad de soluciones de monitoreo y administración de bases de datos. Parte de las soluciones que ofrecemos es la conmutación por error automática, la conmutación por error manual y la recuperación de clúster/nodo. Esto es muy útil como si actuara como su administrador de base de datos virtual, notificándole en tiempo real en caso de que su clúster esté en "modo de pánico", todo mientras el sistema administra la recuperación. Puede consultar este blog Cómo automatizar la conmutación por error de la base de datos con ClusterControl para obtener más información sobre la conmutación por error de ClusterControl.
Otras soluciones MySQL
Algunos de los enfoques antiguos todavía son aplicables cuando desea una conmutación por error. Hay MMM, MRM, o puede verificar Group Replication o Galera (nota:Galera no usa replicación asíncrona, sino síncrona). La conmutación por error en un clúster de Galera no funciona de la misma manera que con la replicación asíncrona. Con Galera puede simplemente escribir en cualquier nodo o, si implementa un enfoque maestro-esclavo, puede dirigir su aplicación a otro nodo que será el escritor activo del clúster.
Conmutación por error de Drupal PostgreSQL
Dado que Drupal es compatible con PostgreSQL, también revisaremos las herramientas para implementar un proceso de conmutación por error o conmutación para PostgreSQL. PostgreSQL usa la replicación de transmisión integrada; sin embargo, también puede configurarla para usar una replicación lógica (agregada como un elemento central de PostgreSQL en la versión 10).
Conmutación por error de Drupal usando pg_ctlcluster
Si su entorno es Ubuntu, usar pg_ctlcluster es una manera sencilla y fácil de lograr la conmutación por error. Por ejemplo, puede simplemente ejecutar el siguiente comando:
$ pg_ctlcluster 9.6 pg_7653 promoteo con RHEL/Centos, puede usar el comando pg_ctl como,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingTambién puede activar la conmutación por error de un servidor en espera de trasvase de registros creando un archivo de activación con el nombre de archivo y la ruta especificados por el archivo de activación en el archivo recovery.conf.
Debe tener cuidado con la promoción en espera o la promoción de esclavo aquí, ya que es posible que deba asegurarse de que solo un maestro acepte la solicitud de lectura y escritura. Esto significa que, mientras realiza el cambio, es posible que deba asegurarse de que el maestro anterior se haya relajado o detenido.
Cuidar el cambio o la conmutación por error manual del servidor primario al servidor en espera puede ser rápido, pero requiere algo de tiempo para volver a preparar el clúster de conmutación por error. Cambiar regularmente de primario a standby es una práctica útil, ya que permite un tiempo de inactividad regular en cada sistema para el mantenimiento. Esto también sirve como prueba del mecanismo de conmutación por error, para asegurarse de que realmente funcionará cuando lo necesite. Siempre se recomiendan los procedimientos de administración por escrito.
Conmutación por error automática de Drupal PostgreSQL
En lugar de un enfoque manual, es posible que necesite una conmutación por error automática. Esto es especialmente necesario cuando un servidor deja de funcionar debido a una falla de hardware o corrupción de la máquina virtual. También puede necesitar una aplicación para realizar automáticamente la conmutación por error para reducir el tiempo de inactividad de su aplicación Drupal. Ahora repasaremos algunas de estas herramientas que se pueden utilizar para la conmutación por error automática.
Conmutación por error de Drupal usando Patroni
Patroni es una plantilla para que cree su propia solución personalizada de alta disponibilidad utilizando Python y, para máxima accesibilidad, un almacén de configuración distribuido como ZooKeeper, etcd, Consul o Kubernetes. Los ingenieros de bases de datos, DBA, ingenieros de DevOps y SRE que buscan implementar rápidamente HA PostgreSQL en el centro de datos, o en cualquier otro lugar, lo encontrarán útil.
Conmutación por error de Drupal usando Pgpool
Pgpool-II es un software proxy que se ubica entre los servidores PostgreSQL y un cliente de base de datos PostgreSQL. Además de tener una conmutación por error automática, tiene múltiples funciones que incluyen agrupación de conexiones, equilibrio de carga, replicación y limitación de las conexiones excedentes. Puede leer más sobre esta herramienta en nuestro blog de tres partes; primera parte, segunda parte, tercera parte.
Conmutación por error de Drupal usando pglookout
pglookout es un demonio de supervisión y conmutación por error de replicación de PostgreSQL. pglookout monitorea los nodos de la base de datos, su estado de replicación y actúa de acuerdo con ese estado. Por ejemplo, llamar a un comando de conmutación por error predefinido para promover un nuevo maestro en caso de que falte el anterior.
pglookout admite dos tipos de nodos diferentes, los que están instalados en los propios nodos de la base de datos y los nodos de observación que pueden instalarse en cualquier lugar. El propósito de tener pglookout en los nodos de base de datos PostgreSQL es monitorear el estado de replicación del clúster y actuar en consecuencia, los observadores tienen un mandato más limitado:solo observan el estado del clúster para dar otro punto de vista al estado del clúster.
Conmutación por error de Drupal usando repmgr
repmgr es un conjunto de herramientas de código abierto para administrar la replicación y la conmutación por error en un clúster de servidores PostgreSQL. Mejora las capacidades de espera en caliente integradas de PostgreSQL con herramientas para configurar servidores en espera, monitorear la replicación y realizar tareas administrativas como conmutación por error o operaciones de conmutación manual.
repmgr ha brindado soporte avanzado para los mecanismos de replicación integrados de PostgreSQL desde que se introdujeron en 9.0. La serie repmgr actual, repmgr 4, es compatible con los últimos desarrollos en la funcionalidad de replicación introducidos desde PostgreSQL 9.3, como la replicación en cascada, el cambio de línea de tiempo y las copias de seguridad base a través del protocolo de replicación.
Conmutación por error de Drupal usando ClusterControl
ClusterControl admite la conmutación por error automática para PostgreSQL. Si tiene un incidente, su esclavo puede ascender al estado de maestro automáticamente. Con ClusterControl también puede implementar una base de datos PostgreSQL independiente, replicada o en clúster. También puede agregar o eliminar fácilmente un nodo con una sola acción.
Otras soluciones de conmutación por error de Drupal de PostgreSQL
Ciertamente hay soluciones automáticas de conmutación por error que podría haber pasado por alto en este blog. Si lo hice, agregue sus comentarios a continuación para que podamos conocer sus pensamientos y experiencias con su implementación y configuración para la conmutación por error, especialmente para sitios web o aplicaciones de Drupal.
Soluciones adicionales para la conmutación por error de Drupal
Si bien las herramientas que mencioné anteriormente definitivamente manejan la solución a sus problemas con la conmutación por error, agregar algunas herramientas que hacen que la conmutación por error sea bastante más fácil, más segura y que tenga un aislamiento total entre su capa de base de datos puede ser satisfactorio.
Conmutación por error de Drupal usando ProxySQL
Con ProxySQL, puede apuntar sus sitios web o aplicaciones de Drupal al host del servidor ProxySQL y designará qué nodo recibirá escrituras y qué nodos recibirán lecturas. La magia ocurre de forma transparente dentro de la capa TCP y no se necesitan cambios para la configuración de su aplicación/sitio web. Además de eso, ProxySQL también actúa como su equilibrador de carga para sus solicitudes de escritura y lectura para el tráfico de su base de datos. Esto solo es aplicable si está utilizando variantes de base de datos MySQL.
Drupal Failover usando HAProxy con Keepalived
Usar HAProxy y Keepalived agrega más alta disponibilidad y redundancia dentro de su base de datos de Drupal. Si desea una conmutación por error, puede hacerlo sin que su aplicación sepa lo que está sucediendo dentro de su capa de base de datos. Simplemente apunte su aplicación a la IP vrrp que configuró en su Keepalived y todo se manejará con total aislamiento de su aplicación. Su aplicación manejará una conmutación por error automática de forma transparente y sin saberlo, por lo que no es necesario que se produzcan cambios una vez, por ejemplo, se ha producido un desastre y se aplicó una recuperación o una conmutación por error. Lo bueno de esta configuración es que es aplicable para bases de datos MySQL y PostgreSQL. Le sugiero que consulte nuestro blog Equilibrio de carga de PostgreSQL con HAProxy y Keepalived para obtener más información sobre cómo hacerlo.
Todas las opciones anteriores son compatibles con ClusterControl. Puede implementar o importar la base de datos y luego implementar ProxySQL, MaxScale o HAProxy &Keepalived. Todo será administrado, monitoreado y configurado automáticamente sin necesidad de ninguna configuración adicional por su parte. Todo sucede en segundo plano y crea automáticamente un archivo listo para producción.
Conclusión
Tener un sitio web o una aplicación de Drupal siempre activo, especialmente si espera una gran cantidad de tráfico, puede ser complicado de crear. Sin embargo, si tiene las herramientas adecuadas, la configuración correcta y la pila de tecnología correcta, es posible lograr una alta disponibilidad y redundancia.
¿Y si no? Bueno, entonces ClusterControl lo configurará y lo mantendrá por usted. Alternativamente, puede crear una configuración utilizando las tecnologías mencionadas en este blog, la mayoría de las cuales son herramientas gratuitas de código abierto que se adaptan a sus necesidades.
