Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.
Português do Brasil
Nenhum resultado encontrado.

Explorar por produto

Enterprise administrators
  • Get started
  • Account and profile
  • Authentication
  • Repositories
  • GitHub
  • Enterprise administrators
  • Billing and payments
  • Organizations
  • Code security
  • GitHub Issues
  • GitHub Actions
  • GitHub Codespaces
  • GitHub Packages
  • Search on GitHub
  • Developers
  • REST API
  • GraphQL API
  • GitHub CLI
  • GitHub Discussions
  • GitHub Sponsors
  • Building communities
  • GitHub Pages
  • Education
  • GitHub Desktop
  • Atom
  • Electron
  • CodeQL
  • npm
    • Português do Brasil
  • English
  • 简体中文 (Simplified Chinese)
  • 日本語 (Japanese)
  • Español (Spanish)
  • Português do Brasil (Portuguese)

    • Esta versão do GitHub Enterprise foi descontinuada em 2021-09-23. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

    Versão do artigo

    Iniciar failover do appliance réplica

    É possível fazer failover de um appliance réplica do GitHub Enterprise Server usando a linha de comando para manutenção e teste ou em caso de falha do appliance primário.

    O tempo do failover dependerá do tempo necessário para promover manualmente a réplica e redirecionar o tráfego. Em média, o procedimento leva de dois a dez minutos.

    Promover uma réplica não configura automaticamente a replicação para appliances existentes. Depois de promover uma réplica, se desejar, você pode configurar a replicação do novo principal para os appliances existentes e o principal anterior.

    1. Para permitir que a replicação termine antes de você alternar os appliances, coloque o appliance principal no modo de manutenção:
    2. Quando o número de operações ativas do Git chegar a zero, aguarde 30 segundos.
    3. Para verificar todos os canais de replicação que reportarem OK, use o comando ghe-repl-status -vv. 
      $ ghe-repl-status -vv
    4. Para parar a replicação e promover o appliance réplica ao status de primário, use o comando ghe-repl-promote. A ação também colocará automaticamente o nó primário no nó de manutenção, se ele for acessível. 
      $ ghe-repl-promote
    5. Atualize o registro DNS para apontar para o endereço IP do appliance réplica. O tráfego é direcionado para o réplica após o término do período TTL. Se você estiver usando um balanceador de carga, verifique se ele está configurado para enviar tráfego para o réplica.
    6. Avise aos usuários que eles podem voltar a trabalhar normalmente.
    7. Se desejar, configure a replicação do novo primário para os appliances existentes e o primário anterior. Para obter mais informações, consulte "Sobre a configuração de alta disponibilidade".
    8. Appliances para os quais você não pretende configurar replicação faziam parte da configuração de alta disponibilidade antes da falha precisam ser removidos da configuração de alta disponibilidade por UUID.
      • Nos appliances anteriores, obtenha seu UUID via cat /data/user/common/uid. 
        $ cat /data/user/common/uuid
      • No novo primário, remova os UUIDs usando ghe-repl-teardown. Substitua UUID por um UUID que você recuperou na etapa anterior. 
        $ ghe-repl-teardown -u UUID

    Leia mais