Truncando logs de transações do MSSQL

Symptoms

O MSSQL é executado em sua instância do GitHub Enterprise Server somente quando GitHub Actions está habilitado. Quando seus logs de transações crescerem muito, você poderá ver qualquer um dos seguintes.

O uso do disco de dados sobe constantemente e não diminui.
O MSSQL registra erros informando que o log de transações de um banco de dados está cheio.
Os runners auto-hospedados não conseguem se registrar. Um único log de transações não pode crescer além de 2 TB e, depois de atingir esse limite, as gravações nesse banco de dados falharão.
A replicação do MSSQL falha ou leva muito mais tempo do que o esperado para ser concluída.

Causas

Cada banco de dados MSSQL tem um arquivo de dados terminando .mdf e um log de transações terminando em _log.ldf. Cada alteração é gravada primeiro no log de transações.

Em uma configuração de alta disponibilidade, os bancos de dados operam no modelo de recuperação FULL, que é exigido pela replicação. Nesse modelo, o espaço de log só é reutilizável quando um backup é executado. Se os backups não estiverem sendo executados com frequência suficiente ou estiverem falhando, o log continua estendendo o arquivo para acomodar novos registros. Ele crescerá até preencher o disco de dados ou até atingir o limite de 2 TB por arquivo, o que ocorrer primeiro.

Confirmando o problema

Acesse o shell administrativo via SSH. Para obter mais informações, consulte Acessar o shell administrativo (SSH).
Liste o diretório de dados MSSQL.
```
sudo ls -lth /data/user/mssql/data
```
Compare cada arquivo de dados .mdf com o _log.ldf log de transações correspondente e identifique quais arquivos estão usando mais espaço.

Um arquivo grande _log.ldf não é uma prova por si só de que a truncação está falhando. O truncamento torna o espaço dentro do arquivo reutilizável, ele não reduz o arquivo, portanto, um log truncado com êxito ainda pode ser grande. O que a listagem informa é quais arquivos estão consumindo o disco.
```
-rw-r----- 1 mssql mssql 156G Apr 17 02:52 Mps_cf856db1-88f0-412a-b35d-8df36a8350ac_log.ldf
-rw-r----- 1 mssql mssql  72M Apr 17 02:52 Mps_cf856db1-88f0-412a-b35d-8df36a8350ac.mdf
-rw-r----- 1 mssql mssql 836M Apr 17 02:52 Pipelines_45f96584-c933-460c-8706-5d8928261202_log.ldf
-rw-r----- 1 mssql mssql  72M Apr 17 02:52 Pipelines_45f96584-c933-460c-8706-5d8928261202.mdf
-rw-r----- 1 mssql mssql 3.4G Apr 17 02:58 Mps_Configuration_log.ldf
-rw-r----- 1 mssql mssql 136M Apr 17 02:58 Mps_Configuration.mdf
```
Cada log aqui tem mais de cinco vezes o tamanho do arquivo de dados, o que está muito acima do crescimento normal. Neste exemplo, o primeiro arquivo de log tem 156 GB em relação a um arquivo de dados de 72 MB, portanto, é aquele que está ocupando o disco.

Resolvendo o problema

Os procedimentos abaixo alternam temporariamente os bancos de dados para o modelo de recuperação SIMPLE, que permite que os logs de transações sejam truncados e depois restaura o modelo de recuperação FULL.

Siga o procedimento que corresponda ao seu ambiente. Os dois diferem porque a replicação depende do modelo de recuperação FULL, portanto, em uma configuração de alta disponibilidade, a replicação deve ser desabilitada antes que os logs possam ser truncados.

Ambientes de alta disponibilidade

Use este procedimento se sua instância do GitHub Enterprise Server tiver uma ou mais réplicas. Execute todos os comandos no nó primário.

Aviso

Esse procedimento descarta o grupo de disponibilidade e exclui os arquivos de banco de dados MSSQL em cada réplica, que são recriados por semeadura. A inicialização de um banco de dados grande leva tempo, e suas réplicas não oferecem proteção até que ela seja concluída.

Faça um backup manual usando sua solução de backup configurada.
```
ghe-backup
```
Se nenhuma solução de backup estiver configurada, exporte os bancos de dados MSSQL.
```
ghe-export-mssql --compress --stats 1
```
Registre os tamanhos de arquivo atuais, para que você possa confirmar a redução posteriormente.
```
sudo du --all --human-readable /data/user/mssql/data
```
Truncar os logs de transação. Isso desabilita a replicação do MSSQL em cada réplica, descarta o grupo de disponibilidade, alterna os bancos de dados para o modelo de recuperação SIMPLE e reduz os logs.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --disable-mssql-replication --set-simple-recovery-model
```

Confirme se os arquivos são menores.

sudo du --all --human-readable /data/user/mssql/data

Verifique se os contêineres MSSQL estão saudáveis.
```
ghe-actions-check -s mssql
```
Habilite novamente a replicação do MSSQL. Isso recria o grupo de disponibilidade e restaura o modelo de recuperação FULL.
```
ghe-cluster-each --serial --exclude --role mssql -- /usr/local/share/enterprise/ghe-repl-start-mssql
```
Monitore a propagação até que as réplicas estejam em sincronia. Até que a propagação seja concluída, as réplicas não contêm dados MSSQL.

Ao contrário das etapas acima, execute isso em cada réplica, e não na primária.
```
ghe-repl-status
```

Ambientes autônomos

Use este procedimento se sua instância do GitHub Enterprise Server não tiver réplicas.

Faça um backup manual usando sua solução de backup configurada.
```
ghe-backup
```
Se nenhuma solução de backup estiver configurada, exporte os bancos de dados MSSQL.
```
ghe-export-mssql --compress --stats 1
```

Registre os tamanhos de arquivo atuais.

sudo du --all --human-readable /data/user/mssql/data

Trunque os logs de transação. Isso alterna os bancos de dados para o modelo de recuperação SIMPLE e reduz os logs.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --set-simple-recovery-model
```

Confirme se os arquivos são menores.

sudo du --all --human-readable /data/user/mssql/data

Verifique se os contêineres MSSQL estão saudáveis.
```
ghe-actions-check -s mssql
```
Faça um novo backup. Isso restaura o modelo de recuperação FULL.
```
ghe-export-mssql --compress --stats 1
```
Aviso

Em uma instância autônoma, o modelo de recuperação FULL não é restaurado automaticamente. Você deve fazer esse backup. Se os bancos de dados permanecerem no modelo de recuperação SIMPLE, os logs de transações serão truncados em cada ponto de verificação e a replicação falhará se você adicionar uma réplica mais tarde.

Prevenção de recorrência

Os logs de transações são limpos por backups, portanto, os logs permanecem em um tamanho razoável apenas enquanto os backups funcionam de forma confiável.

Execute backups de forma agendada e verifique se estão sendo concluídos. Para obter mais informações, consulte Configurando o serviço de backup.
Monitore o uso do disco de dados para que você veja os logs crescendo antes que o disco fique cheio. Para obter mais informações, consulte Limites de alerta recomendados.
Após qualquer período em que os backups estavam falhando, verifique os tamanhos de arquivo novamente, pois os logs terão crescido enquanto isso.

Entrar em contato com Suporte do GitHub

Se essas etapas não resolverem o problema ou você não tiver certeza sobre nenhum deles, entre em contato Suporte do GitHub em vez de continuar. Para obter mais informações, consulte Criando um tíquete de suporte.

Se você já abriu um tíquete, anexar um pacote de suporte ajuda a Suporte do GitHub diagnosticar o problema mais rapidamente. Para obter mais informações, consulte Fornecendo dados para GitHub suporte.

Leitura adicional

Aumentar a capacidade de armazenamento

Neste artigo