Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-07-09. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Adiar a propagação do banco de dados

Você pode acelerar o processo de adição de um novo nó de réplica MySQL a seu cluster optando por adiar a propagação do banco de dados.

Quem pode usar esse recurso?

A GitHub determina a qualificação para clustering e deve habilitar a configuração para a licença da instância. O clustering requer um planejamento cuidadoso e sobrecarga administrativa adicional. Para obter mais informações, confira "Sobre clustering".

Sobre adiar a propagação do banco de dados de um nó de réplica do MySQL

Note

A capacidade de adiar a propagação do banco de dados foi adicionada na versão do patch 3.9.13 e está disponível como uma versão beta pública.

Adicionar um novo nó de réplica do MySQL a seu cluster quando o nó primário tiver mais de sete dias de dados normalmente disparará a propagação do banco de dados, o que pode levar várias horas, dependendo da quantidade de dados. Você pode optar por adiar a propagação do banco de dados, permitindo que a execução de aplicativo de configuração seja concluída mais cedo, resultando na capacidade de abrir seu dispositivo ao tráfego mais cedo.

Você só deverá adiar a propagação do banco de dados se já tiver configurado pelo menos uma réplica do MySQL e estiver adicionando uma réplica do MySQL adicional. Caso contrário, não haverá redundância do MySQL até que a propagação seja concluída.

Quando você adiar a propagação do banco de dados, a nova réplica do MySQL não será configurada para replicação nem terá uma cópia dos dados no nó primário do MySQL até que a propagação seja concluída manualmente mais tarde.

Configurar o adiamento da propagação do MySQL ao adicionar um novo nó MySQL

  1. Provisione e instale GitHub Enterprise Server com um nome de host exclusivo no nó de substituição.

  2. Usando o shell administrativo ou o DHCP, configure apenas o endereço IP do nó de substituição. Não altere nenhuma outra configuração.

  3. Crie a entrada cluster.conf para o novo nó MySQL e inclua o campo skip-data-setup = true. O exemplo abaixo adiciona um novo nó com o nome do host ghe-data-node-3 e a função mysql-server.

     ...
     [cluster "ghe-data-node-3"]
       hostname = ghe-data-node-3
       ipv4 = 192.168.0.9
       # ipv6 = fd12:3456:789a:1::7
       mysql-server = true
       skip-data-setup = true
     ...
     
  4. Para inicializar o novo nó no cluster, no shell administrativo do nó com o modificado cluster.conf, execute ghe-cluster-config-init.

  5. Para validar o arquivo de configuração e também copiar e configurar cada nó de acordo com o arquivo cluster.conf modificado, execute ghe-cluster-config-apply.

Propagar manualmente os dados

Após executar o ghe-cluster-config-apply, o serviço MySQL estará em execução em seu novo nó, mas não será configurado como uma réplica nem será propagado com dados do nó primário do MySQL. Para propagar dados do nó primário do MySQL, você precisará configurar a replicação manualmente.

  1. No novo nó, para iniciar a replicação manual dos dados do nó primário do MySQL, execute o comando a seguir, substituindo PRIMARY_IP pelo endereço IP do nó que executa o primário do MySQL.

    /usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP
    

O tempo necessário para a propagação do banco de dados depende do tamanho dos dados. Para grandes conjuntos de dados, recomendamos executar o comando acima em uma sessão screen para garantir que ele sobreviva às desconexões SSH.