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 principal; ele é atualizado automaticamente para apontar para o novo banco de dados principal, possibilitando uma transição contínua entre os principais.
  • Alternância controlada de banco de dados principal ao encerrar ou reinicializar o dispositivo - Durante qualquer encerramento ou reinicialização iniciado pelo convidado do banco de dados principal atual, a função principal é 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 principal para uma falha inesperada do dispositivo do tenant - As falhas principais 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/
  • As conexões com postgres usando o comando psql agora passam por padrão pelo pgbouncer, e isso o conecta ao banco de dados principal, independentemente do dispositivo que você está usando. Para se conectar a uma instância específica de banco de dados, use os sinalizadores -h e -p com o psql. Você também deve especificar a porta 6432 para se conectar diretamente ao postgres. Por exemplo:
    psql -U admin -h ‹Appliance_IP› -p 6432 fdb
  • Você pode verificar a configuração do pgbouncer em /etc/pgbouncer/pgbouncer.ini para verificar se ela está apontando para os dispositivos corretos. As cadeias de conexão no topo do arquivo devem estar apontando para o principal do slony atual. Se não estiverem, na maioria dos casos, uma reinicialização do dispositivo corrigirá o problema.
Dbmonitor Serviço de monitoramento que faz o seguinte:
  • Detecta falhas principais e inicia o novo processo de failover.
  • Detecta as alterações do nó principal do slony causadas por alternância controlada ou reinscreve e atualiza o pgbouncer com o novo endereço principal apropriadamente.
 /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.
  1. 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.
  2. 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
  3. Recarregue o serviço pgbouncer: 
    service pgbouncer reload
  4. Confirme o status principal e a replicação executando slony-status:
    /usr/local/desktone/scripts# slony-status <org #>