Problemas conhecidos com atualizações de instância

Sobre os problemas conhecidos com as atualizações do GitHub Enterprise Server

A GitHub está ciente dos problemas a seguir que podem afetar as atualizações para novas versões do GitHub Enterprise Server. Para saber mais, confira "Problemas conhecidos" nas Notas sobre a versão do GitHub Enterprise Server.

A GitHub recomenda enfaticamente que você realize backups regulares da configuração e dos dados da instância. Antes de prosseguir com qualquer atualização, faça o backup da instância e valide-o em um ambiente de preparo. Para saber mais, confira Como configurar backups em sua instância e Configurar uma instância de preparo.

Mais horas trabalhadas de E/S da atualização do MySQL 8 em GitHub Enterprise Server 3.9 ou posterior

Se você atualizar do GitHub Enterprise Server 3.7 ou 3.8 para a versão 3.9 ou versões posteriores, uma atualização do software de banco de dados na instância aumentará a utilização de E/S. Em alguns casos, isso pode afetar o desempenho da instância.

O GitHub Enterprise Server inclui um servidor de banco de dados MySQL compatível com o mecanismo de armazenamento InnoDB. O GitHub Enterprise Server 3.8 e as versões anteriores usam o MySQL 5.7. Em outubro de 2023, a Oracle encerrará o suporte estendido para o MySQL 5.7. Para saber mais, confira Política de suporte vitalício da Oracle no site de suporte da Oracle.

Para preparar o GitHub Enterprise Server para o futuro e fornecer as atualizações de segurança, as correções de bugs e as melhorias de desempenho mais recentes, o GitHub Enterprise Server 3.9 e as versões posteriores usam o MySQL 8.0. O MySQL 8.0 atinge um número maior de QPS (consultas por segundo) devido a um log REDO reprojetado. Para saber mais, confira Desempenho do MySQL: log REDO reprojetado na versão 8.0 e escalabilidade de cargas de trabalho readWrite no blog (dim) da DimitriK.

Após a atualização para o GitHub Enterprise Server 3.9, se você sofrer uma degradação inaceitável de desempenho da instância, colete dados no painel do monitor da instância a fim de confirmar o impacto. É possível tentar atenuar o problema e fornecer os dados ao Suporte do GitHub para ajudar na criação de um perfil e na comunicação do impacto real da alteração.

Coletar dados de utilização de E/S de linha de base antes da atualização do MySQL

Colete os dados de linha de base antes de atualizar para o GitHub Enterprise Server 3.9 ou para versões posteriores. Para coletar dados de linha de base, a GitHub recomenda configurar uma instância de preparo do GitHub Enterprise Server que executa a versão 3.7 ou 3.8 e restaurar os dados da instância de produção usando o GitHub Enterprise Server Backup Utilities. Para saber mais, confira Configurar uma instância de preparo e Como configurar backups em sua instância.

Pode não ser possível simular a carga da instância em um ambiente de produção. No entanto, é útil coletar dados de linha de base ao simular padrões de uso do ambiente de produção na instância de preparo.

1. Acesse o painel do monitor da instância. Para saber mais, confira Sobre o painel do monitor.

2. No painel do monitor, monitore os gráficos relevantes.

   • Em "Processos", monitore os gráficos de "Operações de E/S (IOPS de leitura)" e "Operações de E/S (IOPS de gravação)", filtrando por mysqld. Esses gráficos exibem operações de E/S para todos os serviços do nó.
   • Em "Armazenamento", monitore o gráfico de "Utilização do disco (DEVICE-ID do dispositivo de dados)". Esse gráfico exibe a quantidade de tempo gasto em todas as operações de E/S do nó.

Rever os dados de utilização de E/S após a atualização do MySQL

Após a atualização para o GitHub Enterprise Server 3.9, revise a utilização de E/S da instância. A GitHub recomenda atualizar uma instância de preparo do GitHub Enterprise Server que executa a versão 3.7 ou 3.8 e inclui dados restaurados da instância de produção ou restaurar os dados da instância de produção em uma nova instância de preparo que executa a 3.9. Para saber mais, confira Configurar uma instância de preparo e Como configurar backups em sua instância.

1. Acesse o painel do monitor da instância. Para saber mais, confira Sobre o painel do monitor.

2. No painel do monitor, monitore os gráficos relevantes.

   • Em "Processos", monitore os gráficos de "Operações de E/S (IOPS de leitura)" e "Operações de E/S (IOPS de gravação)", filtrando por mysqld. Esses gráficos exibem operações de E/S para todos os serviços do nó.
   • Em "Armazenamento", monitore os gráficos de "Utilização de disco (DEVICE-ID do dispositivo de dados)" e "Latência de disco (DEVICE-ID do dispositivo de dados)". Esses gráficos exibem a quantidade de tempo gasto em todas as operações de E/S do nó, bem como a latência geral do disco.
     • Aumentos significativos na latência do disco podem indicar que a instância está forçando o IOPS do disco a aguardar a conclusão.
     • É possível confirmar uma observação de aumento de latência examinando o gráfico de "Operações de disco pendentes (DEVICE-ID do dispositivo de dados)", que pode indicar que o disco não é capaz de lidar suficientemente com todas as operações.

Reduzir o impacto da atualização do MySQL

Para lidar com a degradação inaceitável do desempenho, a GitHub recomenda as soluções a seguir.

Antes de testar qualquer procedimento de mitigação em um ambiente de produção, faça backup da instância, valide esse backup e teste o procedimento em um ambiente de preparo. Para saber mais, confira Como configurar backups em sua instância e Configurar uma instância de preparo.

• Ajustar o método de liberação do InnoDB
• Atualizar o armazenamento da instância

Ajustar o método de liberação do InnoDB

Para tentar reduzir o impacto no desempenho, ajuste o método de liberação do InnoDB a fim de ignorar a chamada de sistema fsync() após cada operação de gravação. Para saber mais, confira innodb_flush_method no manual de referência do MySQL 8.0.

As instruções a seguir destinam-se apenas ao GitHub Enterprise Server 3.9 e a versões posteriores.

1. Conecte-se via SSH ao sua instância do GitHub Enterprise Server. Se sua instância for composta por vários nós, por exemplo, se a alta disponibilidade ou a replicação geográfica estiver configurada, efetue SSH no nó primário. Se você usar um cluster, poderá efetuar SSH em qualquer nó. Substitua HOSTNAME pelo nome do host da instância ou pelo nome do host ou endereço IP de um nó. Para obter mais informações, confira "Acesar o shell administrativo (SSH)".

   Shell

   ssh -p 122 admin@HOSTNAME
   

2. Para validar o método de liberação atual do InnoDB, execute o comando a seguir.

   Shell

   ghe-config mysql.innodb-flush-no-fsync
   

   Por padrão, o comando retorna false, que indica que a instância executa uma chamada de sistema fsync() após cada operação de gravação.

3. Para configurar o InnoDB a fim de ignorar a chamada de sistema fsync() após cada operação de gravação, execute o comando a seguir.

   Shell

   ghe-config mysql.innodb-flush-no-fsync true
   

4. Para aplicar a configuração, execute o comando a seguir.

   Note

   Durante uma execução de configuração, os serviços do sua instância do GitHub Enterprise Server podem ser reiniciados, o que pode causar um breve tempo de inatividade para os usuários.

   Shell

   ghe-config-apply
   

5. Aguarde a conclusão da execução de suas configurações.

Atualizar o armazenamento da instância

É possível reduzir as operações pendentes, aumentar o IOPS e melhorar o desempenho provisionando um armazenamento mais rápido para os nós da instância. Para atualizar o armazenamento da instância, faça backup dela e restaure o backup em uma nova instância substituta. Para saber mais, confira Como configurar backups em sua instância.

Compartilhar dados com a GitHub

Por fim, se você estiver disposto a ajudar a GitHub a entender o impacto real da atualização para o MySQL 8, forneça os dados coletados ao Suporte do GitHub. Forneça as observações de linha de base e pós-atualização do painel do monitor, além de um pacote de suporte que abranja o período em que você coletou os dados. Para saber mais, confira Sobre o suporte do GitHub e Fornecer dados para o GitHub Support.

Os dados que você envia ajudam a GitHub a continuar fornecendo um produto de alto desempenho, mas a GitHub não garante nenhuma etapa de mitigação adicional ou alterações no produto como resultado dos dados fornecidos.

O MySQL não é iniciado após a atualização para GitHub Enterprise Server 3.9 ou 3.10

Durante uma atualização para GitHub Enterprise Server 3.9 (a partir da 3.7 ou 3.8) ou 3.10 (somente a partir da 3.8), se o MySQL não tiver sido desligado normalmente durante o desligamento da instância do GitHub Enterprise Server 3.7 ou 3.8, o MySQL tentará passar pela recuperação de pane quando a instância do GitHub Enterprise Server 3.9 ou 3.10 for iniciada. Como o GitHub Enterprise Server 3.7 e 3.8 usa o MySQL 5.7 e as versões 3.9 e 3.10 do GitHub Enterprise Server foram atualizados para o MySQL 8.0, o MySQL não poderá concluir a recuperação de pane.

Se você estiver atualizando de GitHub Enterprise Server 3.9 para 3.10, então você não será afetado por esse problema, pois o MySQL já foi atualizado de 5.7 para 8.0 em sua instância.

Se você enfrentar esse problema, o seguinte erro estará no log de erros do mysql (/var/log/mysql/mysql.err):

[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

Evitando esse problema

É altamente recomendável atualizar sua instância do GitHub Enterprise Server para a versão mais recente do patch (3.7.14 ou superior ou 3.8.7 ou superior) antes de atualizar para 3.9 ou 3.10. Essas versões contêm uma correção para o problema de atualização.

Se você não puder atualizar sua instância do GitHub Enterprise Server, poderá evitar o problema atualizando o tempo limite nomad para MySQL antes de iniciar uma atualização para GitHub Enterprise Server 3.9 (a partir da 3.7 ou 3.8) ou 3.10 (somente a partir da 3.8).

1. Coloque sua instância no modo de manutenção:

   Shell

   ghe-maintenance -s
   

2. Atualize o modelo do consul para nomad:

   Shell

   sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl
   

3. Renderize o modelo do consul para nomad:

   Shell

   sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl
   

4. Verifique as configurações atuais de kill_timeout:

   Shell

   nomad job inspect mysql | grep KillTimeout
   

   Resposta esperada:

   Shell

   "KillTimeout": 5000000000
   

5. Pare o MySQL:

   Shell

   nomad job stop mysql
   

6. Execute o novo trabalho do MySQL:

   Shell

   nomad job run /etc/nomad-jobs/mysql/mysql.hcl
   

7. Verifique se kill_timeout foi atualizado:

   Shell

   nomad job inspect mysql | grep KillTimeout
   

   Resposta esperada:

   Shell

   "KillTimeout": 600000000000,
   

8. Tire a instância do modo de manutenção:

   Shell

   ghe-maintenance -u
   

Agora que o tempo limite nomad do MySQL foi atualizado, você pode atualizar sua instância do GitHub Enterprise Server para 3.9.

Mitigação de uma reinicialização com falha do MySQL

Se você for afetado por esse problema, restaure sua instância do GitHub Enterprise Server para o estado em que estava antes da tentativa de atualização e siga as etapas da seção anterior.

Para obter mais informações sobre como restaurar de uma atualização com falha, confira Restaurar após uma atualização com falha.