Una implementación de alta disponibilidad de Nextcloud con Galera es un sistema coordinado, no solo tres servidores de base de datos. También se necesitan nodos de aplicación Nextcloud redundantes, una capa de datos de archivos compartida y duradera, almacenamiento en caché distribuido y bloqueo de archivos, equilibrio de carga, monitorización y copias de seguridad probadas. Galera puede mantener el servicio de base de datos disponible tras un fallo de un nodo de base de datos si se mantiene el quórum, pero no puede garantizar la alta disponibilidad de los demás componentes.
Esta guía utiliza un diseño Linux independiente del proveedor con MariaDB Galera y un proxy inverso o balanceador de carga. Los nombres de los paquetes, los nombres de los servicios, las rutas del proveedor Galera, los comandos de arranque y las integraciones de comprobación de estado del proxy varían según la distribución y la versión de MariaDB. Confírmelos con la documentación de la versión exacta antes de la implementación. El manual de administración estable actual de Nextcloud enumera PostgreSQL y MariaDB como motores de base de datos recomendados y advierte que las versiones compatibles varían; consulte los requisitos del sistema de Nextcloud para la versión que planea ejecutar. Este artículo se verificó con el manual estable de Nextcloud 35 el 6 de octubre de 2026.
Galera ofrece replicación síncrona y multiprimaria para servidores compatibles con MySQL. Una transacción se certifica en todo el clúster, lo que ayuda a mantener la coherencia entre los miembros, pero añade una sobrecarga de coordinación y las transacciones conflictivas pueden ser rechazadas. Añadir nodos de base de datos no multiplica automáticamente el rendimiento de Nextcloud. La guía para desarrolladores de Nextcloud indica que los clústeres conllevan un coste de rendimiento y que la base de datos y el almacenamiento siguen siendo recursos compartidos críticos.
| Elección de diseño | Buen ajuste | Principal compensación |
|---|---|---|
| Un servidor MariaDB o PostgreSQL | Despliegues pequeños que requieren las operaciones más sencillas. | El mantenimiento o fallo de la base de datos puede interrumpir el servicio. |
| MariaDB con Galera | Equipos que necesitan redundancia de nodos de base de datos y pueden operar procedimientos de quórum, red, proxy y recuperación. | Más elementos en movimiento, coordinación de la redacción, manejo de conflictos y complejidad de la recuperación. |
| Dos nodos de base de datos más un árbitro | Sitios con exactamente dos servidores de bases de datos, pero con un dominio de fallo independiente para la votación del quórum. | El árbitro ayuda al quórum; no almacena datos ni reemplaza una copia de la base de datos de terceros. |
| Galera detrás de un proxy con reconocimiento de base de datos | Implementaciones que requieren un punto final de conexión estable y enrutamiento controlado. | Las comprobaciones de estado del proxy y las reglas de enrutamiento se convierten en otro servicio para operar. |
Para una nueva instalación, un clúster Galera de tres nodos de datos distribuidos en hosts independientes es un punto de partida común cuando el equipo operativo puede brindar soporte. El quórum de Galera requiere una mayoría: un clúster de dos nodos no puede realizar una conmutación por error segura automáticamente tras la pérdida de un miembro. Tres nodos pueden tolerar la indisponibilidad de un miembro mientras los otros dos permanecen conectados. Coloque los nodos en dominios de fallo cuando sea factible, pero no extienda la replicación síncrona a través de enlaces de alta latencia sin realizar pruebas. Para un entorno de menor complejidad, es preferible una única base de datos compatible, junto con un plan de copia de seguridad y recuperación bien probado.
Anota los fallos que pretendes tolerar: un proceso web, un servidor web, un servidor de base de datos, un balanceador de carga, un punto final de almacenamiento, una ruta de red o un sitio web completo. Define objetivos de recuperación para cada uno. Un diseño con tres nodos de base de datos y un balanceador de carga no es totalmente redundante. Tampoco lo es un clúster de aplicaciones cuyos archivos de usuario solo se encuentran en el disco local de un servidor web.
Utilice una versión de Nextcloud, un entorno de ejecución de PHP, un conjunto de aplicaciones y una configuración consistentes en cada nodo de la aplicación. Seleccione versiones de MariaDB y Galera compatibles entre sí y compatibles con la versión de Nextcloud elegida. Los requisitos de la base de datos de Nextcloud incluyen InnoDB, aislamiento de transacciones READ COMMITTED y la desactivación del registro binario o el formato ROW; no copie valores de ajuste de una versión diferente sin verificar los requisitos actuales.
Cree nombres DNS privados o direcciones estables para cada miembro de la base de datos, cada nodo web, el servicio de caché, el almacenamiento compartido y el punto final web público. Reserve un punto final de base de datos estable independiente para los nodos PHP de Nextcloud. Mantenga el tráfico de la aplicación, la replicación y el tráfico público en rutas de red adecuadamente separadas, siempre que su infraestructura lo permita. El nombre de un nodo debe ser único y cada miembro del clúster debe resolver los pares de Galera de forma consistente.
Instale MariaDB Server y el proveedor Galera utilizando el repositorio del proveedor recomendado para su sistema operativo. Mantenga la misma familia principal de servidores y proveedores en todos los miembros. No combine paquetes de la comunidad arbitrarios con una biblioteca de proveedor descargada por separado. Antes de continuar, confirme la ruta de actualización, el método SST, la unidad de servicio y el directorio de inclusión de configuración compatibles para ese conjunto de paquetes específico.
Configure el servidor para usar InnoDB y el nivel de aislamiento de transacciones READ COMMITTED. Use el registro binario ROW si está habilitado. Verifique los valores efectivos después del reinicio en lugar de asumir que se incluyó un archivo de configuración. Nextcloud documenta estos requisitos en su guía de configuración de base de datos y requisitos del sistema .
Utilice la referencia de configuración de su proveedor para establecer el nombre del clúster, la lista de direcciones de pares, el nombre y la dirección únicos de cada nodo, la biblioteca del proveedor y el método de transferencia de instantáneas de estado (SST). SST es el proceso que aprovisiona un nodo de unión con el estado de la base de datos. Una configuración típica de un clúster MariaDB contiene opciones de esta familia:
[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTEDModifique los valores específicos de cada nodo en cada servidor. Las rutas de proveedor y los métodos SST compatibles dependen de los paquetes instalados; utilice el método y las credenciales documentadas para su versión. Proteja las credenciales SST, los certificados y las contraseñas de la base de datos como secretos. Nunca utilice una dirección de clúster vacía como configuración permanente: MariaDB indica que esto puede provocar que un servidor inicie un nuevo clúster en lugar de unirse al existente.
Permita que la capa web acceda únicamente al punto final del servicio de base de datos y que los miembros de la base de datos se comuniquen entre sí mediante los puertos de replicación y transferencia de estado de Galera requeridos por el proveedor y el método SST elegidos. Las implementaciones comunes de Galera utilizan TCP y, según la configuración del proveedor, UDP para la comunicación de grupo; los valores predeterminados relevantes suelen incluir el puerto 4567 para la replicación, el 4568 para la transferencia de estado incremental y el 4444 para la transferencia de instantáneas de estado. Considere estos puertos como una lista de verificación para comprobar su versión y configuración, no como una razón para abrir todos los puertos indiscriminadamente. Mantenga el puerto SQL privado y deniegue el acceso público.
Inicialice el clúster una sola vez utilizando el procedimiento de arranque documentado en el paquete MariaDB de su distribución. Tras confirmar que el primer miembro constituye el componente principal, inicie los demás miembros de forma habitual para que se unan a él y reciban el estado mediante IST o SST. IST transfiere los conjuntos de escritura faltantes cuando están disponibles; SST realiza una transferencia de estado completa. No inicie cada host de forma independiente ni considere un reinicio como una acción de arranque.
Ejecute esta consulta en cada miembro de la base de datos después de que se una:
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Confirma que cada nodo esté conectado y listo, pertenezca al componente principal, informe del tamaño de clúster esperado y haya alcanzado un estado sincronizado. MariaDB explica estos indicadores en su guía de monitorización de Galera .
Cree la base de datos con el conjunto de caracteres y la intercalación requeridos por la guía de instalación actual de Nextcloud. Cree un usuario de base de datos dedicado restringido a la red de la aplicación y otorgue solo los privilegios necesarios para la configuración y el funcionamiento normal de Nextcloud. Use TLS para las conexiones que cruzan hosts o segmentos de red no confiables y valide los certificados donde su implementación lo admita. No coloque credenciales de root en config.php.
Instale la misma versión de código de Nextcloud, extensiones de PHP, aplicaciones habilitadas y configuración de servidor en cada nodo web. Configure un único punto de acceso a la base de datos compartida, en lugar de diferentes hosts de base de datos en archivos por nodo. Todos los nodos deben usar el mismo ID de instancia, secreto, claves de cifrado, política de dominio de confianza y demás ajustes de instancia. Almacene la configuración en un proceso de implementación compartida controlada o distribúyala de forma segura para que las actualizaciones sean idénticas.
La capa de datos de archivos de usuario también debe ser común a los nodos de la aplicación. Utilice un sistema de archivos compartido compatible o un diseño de almacenamiento de objetos primario compatible que se ajuste a su versión de Nextcloud y a sus requisitos operativos. Los datos de usuario locales en un servidor web impiden la conmutación por error: una solicitud dirigida a otro servidor no accedería a los mismos archivos. Mantenga el código de la aplicación y las rutas de los datos modificables diferenciadas, y valide la semántica de bloqueo y almacenamiento de archivos antes de la puesta en producción.
Nextcloud normalmente crea la configuración de su base de datos durante la instalación. Una vez que el punto final de la base de datos y el almacenamiento compartido estén listos, verifique que cada nodo resuelva los mismos valores. Un fragmento de configuración representativo tiene este aspecto; mantenga las credenciales reales en un flujo de trabajo de gestión de secretos protegido y no copie este fragmento sobre una configuración de producción existente:
'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'redis.internal',
'port' => 6379,
'password' => 'REPLACE_WITH_SECRET',
],Adapta la opción de almacenamiento en caché y el directorio de datos a las opciones compatibles con tu versión de Nextcloud. Instala y configura las extensiones PHP necesarias, si procede.
Utilice APCu para el almacenamiento en caché local por host, si procede, y un servicio compartido compatible con Redis, como Redis o Valkey, para el almacenamiento en caché distribuido y el bloqueo de archivos transaccionales. Todos los nodos web deben hacer referencia al mismo servicio de caché o clúster de caché compatible, no a localhost. Nextcloud documenta la configuración del clúster de Redis para configuraciones en clúster e indica que, de lo contrario, el bloqueo de archivos transaccionales depende de la base de datos por defecto. Proteja la caché con restricciones de red, autenticación y TLS cuando sea necesario; la disponibilidad de la caché y el comportamiento de conmutación por error requieren un diseño específico.
Configure Nextcloud para que apunte a un punto final estable proporcionado por un proxy de base de datos u otra capa de enrutamiento compatible. El proxy debe dejar de enviar nuevas conexiones a nodos que no pertenezcan al componente principal, no estén sincronizados o no estén listos. Una comprobación básica del puerto TCP solo demuestra que un socket acepta conexiones; no demuestra que Galera pueda servir la aplicación de forma segura. Revise el comportamiento de la comprobación de estado y los modos de fallo del proxy elegido. Si utiliza un balanceador de carga TCP simple, combínelo con una comprobación de disponibilidad de Galera fiable y reglas de enrutamiento conservadoras.
No añada la división de lectura/escritura ni el enrutamiento round-robin a la ligera. El manual para desarrolladores de Nextcloud describe la compatibilidad con conexiones primarias/réplicas y advierte que el enrutamiento de lecturas a través de un clúster puede generar problemas de coherencia si los datos no se han propagado o si un proxy no puede mantener las lecturas transaccionales en el nodo correcto. Comience con un punto final estable con capacidad de escritura, analícelo e introduzca el enrutamiento especializado solo cuando comprenda las implicaciones en cuanto a coherencia y compatibilidad.
Coloque al menos dos nodos web detrás de un balanceador de carga y utilice un mecanismo de disponibilidad independiente para el propio balanceador, como un servicio gestionado, un par redundante o un diseño de IP virtual probado. Configure la terminación TLS, el tamaño de la solicitud, el comportamiento del tiempo de espera y los requisitos de sesión persistente según su implementación. Consulte la documentación del proxy inverso de Nextcloud y configúrelo trusted_proxiescon las direcciones de proxy reales; confiar en rangos de cliente arbitrarios debilita la gestión de las IP de los clientes.
Primero, prueba las actualizaciones en una copia de prueba con la misma topología. Pon Nextcloud en modo de mantenimiento cuando lo requiera el procedimiento de actualización, aplica la misma versión de la aplicación a cada nodo y vuelve a ponerlos en servicio solo después de que las comprobaciones de estado sean satisfactorias. Para el mantenimiento rutinario del host, vacía un nodo web a la vez y confirma que la capacidad restante sea suficiente. Aplica las actualizaciones de la base de datos utilizando el proceso de actualización progresiva de MariaDB/Galera compatible con las versiones exactas involucradas; no inventes un orden a partir de un tutorial genérico.
Realice copias de seguridad de la base de datos y de la capa de datos de archivos de usuario mediante un procedimiento documentado y coherente con la aplicación. Mantenga la configuración, el material de cifrado y los secretos disponibles para los operadores de recuperación autorizados. Una réplica de Galera no es una copia de seguridad: la eliminación accidental y la corrupción lógica pueden replicarse en todos los miembros. Almacene las copias de seguridad fuera del dominio de fallo del clúster y realice simulacros de restauración periódicos. Galera documenta las consideraciones sobre la transferencia de estado y las copias de seguridad en su guía de copias de seguridad del clúster ; valide que cualquier procedimiento que adopte sea compatible con su versión de MariaDB.
Galera es una opción práctica cuando se necesita redundancia de nodos de base de datos, se tienen múltiples dominios de fallo y se puede monitorizar el quórum y practicar una recuperación controlada. Puede resultar inadecuada cuando el objetivo principal son operaciones más sencillas, cuando la carga de trabajo de la base de datos está dominada por escrituras conflictivas o cuando el equipo no puede responder de forma segura a la pérdida de quórum. En esos casos, una implementación de base de datos más sencilla con soporte y copias de seguridad robustas, o un servicio de base de datos gestionado, pueden ofrecer una mayor fiabilidad operativa.
Para un servicio autogestionado de menor tamaño, primero asegúrese de que los nodos de la aplicación sean intercambiables, traslade los archivos de usuario a un almacenamiento compartido persistente, configure el bloqueo compartido de Redis y pruebe las copias de seguridad. Añada Galera solo después de que las mediciones demuestren que el fallo de un nodo único de la base de datos o la ventana de mantenimiento representan un riesgo inaceptable y que la organización puede mantener la capa adicional. La prueba de éxito significativa no es que "los tres servidores de base de datos estén en funcionamiento", sino que la URL de Nextcloud siga siendo utilizable durante una pérdida de nodo planificada, que las cargas y descargas funcionen en todos los nodos web, que la base de datos mantenga el quórum y que el equipo pueda restaurar tanto la base de datos como los datos de los archivos a partir de la copia de seguridad.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
