Truncar los registros de transacciones de MSSQL

Síntomas

MSSQL solo se ejecuta en tu instancia de GitHub Enterprise Server cuando GitHub Actions está habilitado. Cuando sus registros de transacciones crecen demasiado grandes, puede ver cualquiera de las siguientes opciones.

El uso del disco de datos aumenta constantemente y no se reduce.
MSSQL registra errores que indican que el registro de transacciones de una base de datos está lleno.
Los runners autohospedados no se pueden registrar. Un único registro de transacciones no puede crecer más allá de 2 TB y, una vez alcanzado ese límite, fallan las operaciones de escritura en esa base de datos.
La replicación de MSSQL falla o tarda mucho más de lo esperado en completarse.

Causas

Cada base de datos MSSQL tiene un archivo de datos que termina en .mdf y un registro de transacciones que termina en _log.ldf. Cada cambio se escribe primero en el registro de transacciones.

En una configuración de alta disponibilidad, las bases de datos se ejecutan en el modelo de recuperación completa, que requiere la replicación. En ese modelo, el espacio de registro solo se hace reutilizable cuando se ejecuta una copia de seguridad. Si las copias de seguridad no se ejecutan con frecuencia o están fallando, el registro sigue extendiendo el archivo para contener nuevos registros. Aumentará hasta que rellene el disco de datos o hasta que alcance el límite de 2 TB por archivo, lo que ocurra primero.

Confirmando el problema

Acceda por SSH al shell administrativo. Para obtener más información, vea Acceder al shell administrativo (SSH).
Enumere el directorio de datos MSSQL.
```
sudo ls -lth /data/user/mssql/data
```
Compare cada .mdf archivo de datos con su correspondiente _log.ldf registro de transacciones e identifique qué archivos usan más espacio.

Un archivo grande _log.ldf no es prueba por sí solo de que la truncación está fallando. El truncamiento hace que el espacio dentro del archivo sea reutilizable, no reduce el archivo, por lo que un registro que se ha truncado correctamente puede seguir siendo grande. Lo que indica el listado es qué archivos consumen espacio en 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 archivo de registro aquí es más de cinco veces el tamaño de su archivo de datos, lo que supera con creces el crecimiento normal. En este ejemplo, el primer archivo de registro es de 156 GB frente a un archivo de datos de 72 MB, por lo que es el que rellena el disco.

Resolución del problema

Los procedimientos siguientes cambian temporalmente las bases de datos al modelo de recuperación SIMPLE, lo que permite truncar los registros de transacciones y, a continuación, restaura el modelo de recuperación FULL.

Siga el procedimiento que coincida con su entorno. Los dos difieren porque la replicación se basa en el modelo de recuperación completa, por lo que, en una configuración de alta disponibilidad, la replicación debe deshabilitarse antes de que los registros se puedan truncar.

Entornos de alta disponibilidad

Use este procedimiento si tu instancia de GitHub Enterprise Server tiene una o varias réplicas. Ejecute todos los comandos en el primario.

Advertencia

Este procedimiento quita el grupo de disponibilidad y elimina los archivos de base de datos MSSQL en cada réplica, que luego se vuelven a crear mediante la siembra. La inicialización de una base de datos grande tarda tiempo y las réplicas no le protegen hasta que finalice.

Realice una copia de seguridad manual mediante la solución de copia de seguridad configurada.
```
ghe-backup
```
Si no hay ninguna solución de copia de seguridad configurada, exporte las bases de datos MSSQL en su lugar.
```
ghe-export-mssql --compress --stats 1
```
Registre los tamaños de archivo actuales, para poder confirmar la reducción después.
```
sudo du --all --human-readable /data/user/mssql/data
```
Truncar los registros de transacciones. Esto deshabilita la replicación de MSSQL en cada réplica, elimina el grupo de disponibilidad, cambia las bases de datos al modelo de recuperación SIMPLE y reduce los archivos de registro.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --disable-mssql-replication --set-simple-recovery-model
```

Confirme que los archivos son más pequeños.

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

Compruebe que los contenedores de MSSQL están en buen estado.
```
ghe-actions-check -s mssql
```
Vuelva a habilitar la replicación de MSSQL. Esto vuelve a crear el grupo de disponibilidad y restaura el modelo de recuperación completa.
```
ghe-cluster-each --serial --exclude --role mssql -- /usr/local/share/enterprise/ghe-repl-start-mssql
```
Supervise la propagación hasta que las réplicas estén sincronizadas. Hasta que finalice la propagación, las réplicas no contienen datos MSSQL.

A diferencia de los pasos anteriores, ejecútelo en cada réplica en lugar de en la principal.
```
ghe-repl-status
```

Entornos independientes

Use este procedimiento si tu instancia de GitHub Enterprise Server no tiene réplicas.

Realice una copia de seguridad manual mediante la solución de copia de seguridad configurada.
```
ghe-backup
```
Si no hay ninguna solución de copia de seguridad configurada, exporte las bases de datos MSSQL en su lugar.
```
ghe-export-mssql --compress --stats 1
```

Registre los tamaños de archivo actuales.

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

Truncar los registros de transacciones. Esto cambia las bases de datos al modelo de recuperación SIMPLE y reduce los archivos de registro.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --set-simple-recovery-model
```

Confirme que los archivos sean más pequeños.

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

Compruebe que los contenedores de MSSQL están en buen estado.
```
ghe-actions-check -s mssql
```
Realice una copia de seguridad nueva. Esto restaura el modelo de recuperación completa.
```
ghe-export-mssql --compress --stats 1
```
Advertencia

En una instancia independiente, el modelo de recuperación FULL no se restaura automáticamente. Debe realizar esta copia de seguridad. Si las bases de datos permanecen en el modelo de recuperación SIMPLE, los registros de transacciones se truncan en cada punto de control y se producirá un error en la replicación si agrega una réplica más adelante.

Prevenir la recurrencia

Las copias de seguridad borran los registros de transacciones, por lo que los registros permanecen en un tamaño razonable solo mientras las copias de seguridad se ejecutan de forma confiable.

Ejecute copias de seguridad según una programación y compruebe que se están completando. Para obtener más información, vea Configuración del servicio de copia de seguridad.
Supervise el uso del disco de datos para que vea que los registros crecen antes de que se llene el disco. Para obtener más información, vea Límites de alerta recomendados.
Después de cualquier período en el que las copias de seguridad estuvieran fallando, compruebe de nuevo los tamaños de archivo, ya que los registros habrán crecido mientras tanto.

Contactar con Soporte de GitHub

Si estos pasos no resuelven el problema o no está seguro de ninguno de ellos, póngase en contacto Soporte de GitHub en lugar de continuar. Para obtener más información, vea Crear un ticket de soporte.

Si ya ha abierto una incidencia, adjuntar un paquete de soporte técnico ayuda a Soporte de GitHub diagnosticar el problema más rápido. Para obtener más información, vea Proporcionar datos al soporte técnico de GitHub.

Lectura adicional

Aumentar la capacidad de almacenamiento

En este artículo