Este tópico descreve a funcionalidade de failover de banco de dados para dispositivos que executam a versão 9.0.0 ou posterior. Para esses dispositivos, o failover é totalmente automatizado, exceto quando um dispositivo do provedor de serviços é encerrado inesperadamente, e nesse caso ainda há um processo manual.
Observação: Este tópico se aplica apenas a dispositivos que estejam executando a versão 9.0.0 ou posterior. Para obter informações pertinentes a dispositivos mais antigos, consulte
Failover de Banco de Dados - Dispositivos Legados.
Failover automatizado
A funcionalidade de failover automatizado inclui o seguinte.
- Conexão de fonte de dados única - Todos os dispositivos agora usam uma única conexão de fonte de dados que é feita por um proxy por meio do novo serviço pgbouncer. O pgbouncer é um pooler de conexões que mantém conexões com os bancos de dados postgres subjacentes, fornecendo um único ponto de conexão para os serviços do dispositivo usarem. Esse serviço também gerencia todas as migrações de failover e mestre; ele é atualizado automaticamente para apontar para o novo banco de dados mestre, possibilitando uma transição contínua entre os mestres.
- Alternância controlada de banco de dados mestre ao desligar ou reinicializar o dispositivo - Durante qualquer desligamento ou reinicialização iniciado pelo convidado, a função mestre é migrada para o outro dispositivo no par de alta disponibilidade de forma controlada. Isso causa apenas uma interrupção mínima no funcionamento dos dispositivos, afetando principalmente as conexões da área de trabalho por meio do portal do Blast (web). As conexões de área de trabalho feitas via Horizon Client não são afetadas. Há também um breve período de indisponibilidade do horizonadmin, e os usuários que solicitam uma conexão de área de trabalho durante a alternância podem receber um erro informando que nenhuma área de trabalho está disponível (mas a repetição logo depois deve permitir que eles se conectem a uma área de trabalho).
- O failover automático do banco de dados mestre para uma falha inesperada do dispositivo do tenant - As falhas mestre agora são detectadas automaticamente, seguidas de uma solicitação para os dispositivos do provedor de serviços para verificar se o dispositivo está realmente inoperante. Em seguida, o processo de failover é iniciado após um atraso de três minutos. Esse novo processo de failover é menos prejudicial do que os processos de failover passados e deixa o cluster do slony em um estado normal de replicação posteriormente – Nenhuma reinicialização do Slony é necessária após ocorrer um failover.
Esses recursos têm suporte pelos serviços descritos abaixo.
Serviço | Descrição | Localização do log | Notas |
---|---|---|---|
Pgbouncer | Pooler de conexões que as conexões de banco de dados de agentes entre os serviços de plataforma e postgres. | /var/log/pgbouncer/ |
|
Dbmonitor | Serviço de monitoramento que faz o seguinte:
|
/var/log/dbmonitor/ | |
Alternância | O script é executado no desligamento para executar a ação de alternância. | /var/log/desktone/slony-services | |
Reinscrição | O script é executado na inicialização para executar a ação de reinscrição. | /var/log/desktone/slony-services |
Failover manual do dispositivo do provedor de serviços
Se um dispositivo do provedor de serviços tiver um encerramento inesperado, você poderá realizar um failover manual executando as etapas abaixo no outro dispositivo do provedor de serviços.
- Execute o script failover-slony-master (localizado em /usr/local/desktone/scripts/) como raiz:
failover-slony-master <database type> '<database password>'
onde <tipo de banco de dados> é fdb, edb ou avdb. - Confirme que o arquivo pgbouncer.ini está apontando para o endereço IP front-end do dispositivo atual:
/usr/local/desktone/scripts# grep '<IP address>' /etc/pgbouncer/pgbouncer.ini
- Recarregue o serviço pgbouncer:
service pgbouncer reload
- Confirme o status mestre e a replicação executando slony-status:
/usr/local/desktone/scripts# slony-status <org #>