Uma implementação de alta disponibilidade do Nextcloud com Galera é um sistema coordenado, não apenas três servidores de banco de dados. Você também precisa de nós de aplicação Nextcloud redundantes, uma camada de dados e arquivos compartilhada e durável, cache distribuído e bloqueio de arquivos, balanceamento de carga, monitoramento e backups testados. O Galera pode manter o serviço de banco de dados disponível após a falha de um nó de banco de dados, desde que o quorum seja mantido, mas não pode garantir a alta disponibilidade desses outros componentes.
Este guia utiliza um design Linux independente de fornecedor com MariaDB Galera e um proxy reverso ou balanceador de carga. Os nomes dos pacotes, nomes dos serviços, caminhos dos provedores Galera, comandos de inicialização e integrações de verificação de integridade do proxy variam de acordo com a distribuição e a versão do MariaDB. Confirme-os com a documentação da versão específica antes da implantação. O manual de administração da versão estável atual do Nextcloud lista o PostgreSQL e o MariaDB como mecanismos de banco de dados recomendados e alerta que as versões suportadas variam; verifique os requisitos de sistema do Nextcloud para a versão que você pretende executar. Este artigo foi verificado com o manual da versão estável 35 do Nextcloud em 6 de outubro de 2026.
Galera é uma replicação síncrona com múltiplos servidores primários compatíveis com MySQL. Uma transação é certificada em todo o cluster, o que ajuda a manter a consistência entre os membros, mas adiciona sobrecarga de coordenação e transações conflitantes podem ser rejeitadas. Adicionar nós de banco de dados não multiplica automaticamente a taxa de transferência do Nextcloud. O guia para desenvolvedores do Nextcloud observa que os clusters têm um custo de desempenho e que o banco de dados e o armazenamento continuam sendo recursos compartilhados críticos.
| Escolha de design | Ajuste perfeito | Principal compensação |
|---|---|---|
| Um servidor MariaDB ou PostgreSQL | Implantações de pequeno porte que exigem operações muito simples. | A manutenção ou falha do banco de dados pode interromper o serviço. |
| MariaDB com Galera | Equipes que precisam de redundância de nós de banco de dados e que podem operar procedimentos de quorum, rede, proxy e recuperação. | Mais variáveis, coordenação de escrita, gestão de conflitos e complexidade de recuperação |
| Dois nós de banco de dados mais um árbitro | Sites com exatamente dois hosts de banco de dados, mas um domínio de falha separado para votação de quórum. | O árbitro auxilia no quórum; ele não armazena dados nem substitui uma cópia de um banco de dados de terceiros. |
| Galera por trás de um proxy com conhecimento de banco de dados | Implantações que necessitam de um ponto de extremidade de conexão estável e roteamento controlado. | As verificações de integridade do proxy e as regras de roteamento tornam-se mais um serviço a ser operado. |
Para uma nova instalação, um cluster Galera com três nós de dados em hosts independentes é um ponto de partida comum, quando a equipe operacional tem capacidade para suportá-lo. O quorum do Galera exige maioria: um cluster com dois nós não consegue realizar failover automático com segurança após a perda de um membro. Três nós podem tolerar a indisponibilidade de um membro enquanto os outros dois permanecem conectados. Posicione os nós em domínios de falha sempre que possível, mas não estenda a replicação síncrona por links de alta latência sem testes. Para um ambiente de menor complexidade, prefira um banco de dados único com suporte, além de um plano de backup e recuperação bem testado.
Anote as falhas que você pretende suportar: um processo web, um host web, um host de banco de dados, um balanceador de carga, um endpoint de armazenamento, um caminho de rede ou um site completo. Defina objetivos de recuperação para cada uma delas. Um projeto com três nós de banco de dados e um balanceador de carga não é totalmente redundante. O mesmo se aplica a um cluster de aplicativos cujos arquivos de usuário existem apenas no disco local de um servidor web.
Utilize uma versão consistente do Nextcloud, um ambiente de execução PHP, um conjunto de aplicativos e uma configuração em todos os nós de aplicação. Selecione versões do MariaDB e do Galera que sejam compatíveis entre si e suportadas pela versão do Nextcloud escolhida. Os requisitos de banco de dados do Nextcloud incluem InnoDB, isolamento de transação READ COMMITTED e registro binário ou formato ROW desativados; não copie valores de ajuste de uma versão diferente sem verificar os requisitos atuais.
Crie nomes DNS privados ou endereços estáveis para cada membro do banco de dados, cada nó web, o serviço de cache, o armazenamento compartilhado e o endpoint web público. Reserve um endpoint de banco de dados estável separado para os nós PHP do Nextcloud. Mantenha o tráfego de aplicação, replicação e público em caminhos de rede adequadamente separados, sempre que sua infraestrutura permitir. O nome de um nó deve ser único e cada membro do cluster deve resolver os peers do Galera de forma consistente.
Instale o servidor MariaDB e o provedor Galera usando o repositório do fornecedor recomendado para o seu sistema operacional. Mantenha a mesma versão principal do servidor e da família do provedor em todos os membros. Não combine pacotes da comunidade aleatórios com uma biblioteca de provedor baixada separadamente. Antes de prosseguir, confirme o caminho de atualização, o método SST, a unidade de serviço e o diretório de inclusão de configuração suportados para esse conjunto de pacotes específico.
Configure o servidor para usar InnoDB e o nível de isolamento de transação READ COMMITTED. Use o registro binário ROW se estiver habilitado. Verifique os valores efetivos após a reinicialização, em vez de presumir que um arquivo de configuração foi incluído. O Nextcloud documenta esses requisitos em seu guia de configuração de banco de dados e requisitos de sistema .
Use a documentação de configuração do seu fornecedor para definir o nome do cluster, a lista de endereços dos nós pares, o nome e endereço exclusivos de cada nó, a biblioteca do provedor e o método de transferência de snapshot de estado (SST). O SST é o processo que provisiona um nó ingressante com o estado do banco de dados. Uma configuração típica de cluster MariaDB contém opções desta família:
[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-COMMITTEDAltere os valores específicos de cada nó em cada servidor. Os caminhos do provedor e os métodos SST suportados dependem dos pacotes instalados; use o método e as credenciais documentados para a sua versão. Proteja as credenciais SST, os certificados e as senhas do banco de dados como segredos. Nunca use um endereço de cluster vazio como configuração permanente: a documentação do MariaDB informa que isso pode fazer com que um servidor inicie um novo cluster em vez de retornar ao existente.
Permita que a camada web acesse apenas o endpoint do serviço de banco de dados e permita que os membros do banco de dados se comuniquem entre si nas portas de replicação e transferência de estado do Galera exigidas pelo provedor e método de transferência de estado escolhidos. Implementações comuns do Galera usam TCP e, dependendo das configurações do provedor, UDP para comunicação em grupo; os padrões relevantes geralmente incluem 4567 para replicação, 4568 para transferência incremental de estado e 4444 para transferência de snapshot de estado. Considere isso como uma lista de verificação para comparar com sua versão e configuração, e não como uma justificativa para abrir todas as portas indiscriminadamente. Mantenha a porta SQL privada e negue o acesso público.
Inicialize o cluster exatamente uma vez usando o procedimento de bootstrap documentado pelo pacote MariaDB da sua distribuição. Após confirmar que o primeiro membro forma o componente primário, inicie os membros restantes normalmente para que se juntem a ele e recebam o estado por meio do IST ou SST. O IST transfere os conjuntos de escrita ausentes quando disponíveis; o SST realiza uma transferência completa de estado. Não inicialize cada host independentemente e não trate uma reinicialização como uma ação de bootstrap.
Execute esta consulta em cada membro do banco de dados após a sua junção:
SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
'wsrep_connected','wsrep_local_state_comment');Confirme se cada nó está conectado e pronto, pertence ao componente primário, reporta o tamanho de cluster esperado e atingiu um estado sincronizado. O MariaDB explica esses indicadores em seu guia de monitoramento Galera .
Crie o banco de dados com o conjunto de caracteres e a ordenação exigidos pelo guia de instalação atual do Nextcloud. Crie um usuário de banco de dados dedicado, restrito à rede do aplicativo, e conceda apenas os privilégios necessários para a configuração e operação normal do Nextcloud. Use TLS para conexões entre hosts ou segmentos de rede não confiáveis e valide os certificados onde sua implantação suportar. Não insira credenciais de root no arquivo config.php.
Instale a mesma versão do código Nextcloud, extensões PHP, aplicativos habilitados e configuração de servidor em cada nó web. Configure um endpoint de banco de dados compartilhado, e não hosts de banco de dados diferentes em arquivos por nó. Todos os nós devem usar o mesmo ID de instância, segredo, salts, política de domínio confiável e outras configurações globais da instância. Armazene a configuração em um processo de implantação compartilhado e controlado ou distribua-a de forma segura para que as atualizações permaneçam idênticas.
A camada de dados de arquivos do usuário também precisa ser comum aos nós da aplicação. Utilize um sistema de arquivos compartilhado ou um design de armazenamento de objetos primário compatível com a sua versão do Nextcloud e com os requisitos operacionais. Dados de usuário somente locais em um único host web comprometem o failover: uma requisição roteada para outro host não veria os mesmos arquivos. Mantenha o código da aplicação e os caminhos de dados graváveis distintos e valide o bloqueio de arquivos e a semântica de armazenamento antes da produção.
O Nextcloud normalmente cria suas configurações de banco de dados durante a instalação. Assim que o endpoint do banco de dados e o armazenamento compartilhado estiverem prontos, verifique se cada nó resolve os mesmos valores. Um fragmento de configuração típico se parece com isto; mantenha as credenciais reais em um fluxo de trabalho protegido por gerenciamento de segredos e não copie este fragmento para uma configuração de produção 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',
],Adapte o backend de cache e a escolha do diretório de dados às opções suportadas pela sua versão do Nextcloud. Instale e configure as extensões PHP necessárias, quando aplicável.
Use o APCu para cache local por host, se apropriado, e um serviço compartilhado compatível com Redis, como o Redis ou o Valkey, para cache distribuído e bloqueio transacional de arquivos. Todos os nós da web devem se referir ao mesmo serviço de cache ou cluster de cache compatível, e não ao localhost. A documentação do Nextcloud descreve a configuração do cluster Redis para ambientes em cluster e observa que o bloqueio transacional de arquivos depende do banco de dados por padrão. Proteja o cache com restrições de rede, autenticação e TLS, quando apropriado; a disponibilidade do cache e o comportamento de failover exigem um projeto específico.
Direcione o Nextcloud para um ponto de extremidade estável fornecido por um proxy de banco de dados ou outra camada de roteamento compatível. O proxy deve interromper o envio de novas conexões para nós que não estejam no componente Primário, não estejam sincronizados ou não estejam prontos. Uma verificação básica de porta TCP apenas comprova que um socket aceita conexões; não comprova que o Galera possa servir a aplicação com segurança. Analise o comportamento de verificação de integridade e os modos de falha do proxy escolhido. Se você usar um balanceador de carga TCP simples, combine-o com uma verificação de prontidão do Galera confiável e regras de roteamento conservadoras.
Não adicione divisão de leitura/gravação ou roteamento round-robin de forma leviana. O manual do desenvolvedor do Nextcloud descreve o suporte a conexões primárias/réplicas e alerta que o roteamento de leituras em um cluster pode criar problemas de consistência se os dados não tiverem sido propagados ou se um proxy não conseguir manter as leituras transacionais no nó correto. Comece com um endpoint estável com capacidade de gravação, meça seu desempenho e introduza roteamento especializado somente quando compreender as implicações de consistência e suporte.
Coloque pelo menos dois nós web atrás de um balanceador de carga e utilize um mecanismo de disponibilidade separado para o próprio balanceador, como um serviço gerenciado, um par redundante ou um design de IP virtual testado. Configure a terminação TLS, o tamanho da requisição, o comportamento de tempo limite e os requisitos de sessão persistente de acordo com a sua implementação. Consulte a documentação do proxy reverso do Nextcloud e defina trusted_proxiesos endereços de proxy reais; confiar em intervalos de IPs de clientes arbitrários enfraquece o gerenciamento de IPs de clientes.
Teste as atualizações primeiro em uma cópia de teste com a mesma topologia. Coloque o Nextcloud em modo de manutenção quando necessário para o procedimento de atualização, aplique a mesma versão do aplicativo a todos os nós e coloque os nós de volta em serviço somente após a aprovação nas verificações de integridade. Para manutenção de rotina do host, descarregue um nó web por vez e confirme se a capacidade restante é suficiente. Aplique as atualizações do banco de dados usando o processo de atualização contínua (rolling-upgrade) do MariaDB/Galera para as versões específicas envolvidas; não crie uma ordem a partir de um tutorial genérico.
Faça backup do banco de dados e da camada de dados de arquivos do usuário usando um procedimento documentado e consistente com o aplicativo. Mantenha a configuração, o material de criptografia e os segredos disponíveis para operadores de recuperação autorizados. Uma réplica do Galera não é um backup: exclusões acidentais e corrupção lógica podem se replicar para todos os membros. Armazene os backups fora do domínio de falha do cluster e realize ensaios de restauração regularmente. O Galera documenta as considerações sobre transferência de estado e backup em seu guia de backup de cluster ; verifique se qualquer procedimento adotado é compatível com a sua versão do MariaDB.
Galera é uma escolha prática quando você precisa de redundância de nós de banco de dados, possui múltiplos domínios de falha e pode monitorar o quorum e praticar recuperação controlada. Pode não ser a melhor opção quando o objetivo principal são operações mais simples, quando a carga de trabalho do banco de dados é dominada por gravações conflitantes ou quando a equipe não consegue responder com segurança à perda de quorum. Nesses casos, uma implementação de banco de dados mais simples e com suporte, com backups robustos, ou um serviço de banco de dados gerenciado, pode oferecer melhor confiabilidade operacional.
Para um serviço autohospedado de menor porte, primeiro torne os nós da aplicação intercambiáveis, mova os arquivos do usuário para um armazenamento compartilhado durável, configure o bloqueio compartilhado do Redis e teste os backups. Adicione o Galera somente depois que as medições demonstrarem que a falha de um único nó do banco de dados ou a janela de manutenção representa um risco inaceitável e que a organização pode manter a camada extra. O teste de sucesso significativo não é "todos os três servidores de banco de dados estão funcionando"; é que a URL do Nextcloud permaneça utilizável durante uma perda planejada de um nó, que os uploads e downloads funcionem entre os nós da web, que o banco de dados mantenha o quorum e que a equipe consiga restaurar os dados do banco de dados e os arquivos a partir do backup.
Compare 10 ferramentas de varredura de ping para descoberta rápida de LAN, varredura multiplataforma e gerenciamento de endereços IP. Saiba o que uma varredura pode — e não pode — revelar.
Compare seis ferramentas de gerenciamento de rede para monitoramento de desempenho, incluindo cobertura SNMP, mapeamento, alertas, modelos de implantação e custo-benefício.
Compare as melhores opções de analisadores de Wi-Fi para Windows, iPhone e Android, incluindo ferramentas para congestionamento de canais, cobertura de sinal, mapas de calor e solução de problemas de rede.
Compare sete monitores de ping gratuitos e de código aberto, desde suítes completas de rede até sondas de latência específicas, e escolha a opção mais adequada para disponibilidade, perda de pacotes e histórico.
Veja como a taxa de transferência de rede difere da largura de banda, o que causa desempenho lento ou instável e quais ferramentas podem testar um caminho ou monitorar o tráfego.
Compare softwares de servidor SFTP confiáveis para Windows e Linux, incluindo OpenSSH, Bitvise, SolarWinds e SFTPGo. Encontre a solução ideal para suas necessidades de segurança e transferência de arquivos.
Crie um monitoramento de rede prático com cobertura clara de dispositivos, métricas de desempenho úteis, alertas acionáveis e uma comparação entre SolarWinds NPM, PRTG e OpManager.
Compare sete ferramentas de gerenciamento de endereços IP para descoberta de sub-redes, coordenação de DNS e DHCP, inventário de rede e IPAM de código aberto.
Compare ferramentas de varredura de rede para descoberta rápida de dispositivos, varreduras de IP multiplataforma e IPAM corporativo, com orientações sobre como escolher a opção mais adequada para sua rede.
Compare seis ferramentas de monitoramento de rede Linux para descoberta de dispositivos SNMP, gráficos de interface, métricas de host, verificação de serviços e fluxos de tráfego.
