Усечение журналов транзакций MSSQL

Симптомы

MSSQL выполняется ваш экземпляр GitHub Enterprise Server только в том случае, если GitHub Actions он включен. Когда журналы транзакций становятся слишком большими, вы можете увидеть любой из следующих элементов.

Использование диска данных постоянно увеличивается и не спустится.
MsSQL регистрирует ошибки, указывающие, что журнал транзакций для базы данных заполнен.
Не удалось зарегистрировать локальные средства выполнения. Один журнал транзакций не может увеличиться до 2 ТБ, и после достижения этого ограничения запись в базу данных завершается ошибкой.
Репликация MSSQL завершается сбоем или занимает гораздо больше времени, чем ожидалось.

Причины

Каждая база данных MSSQL имеет файл данных, заканчивающийся .mdf , и журнал транзакций заканчивается _log.ldf. Каждое изменение сначала записывается в журнал транзакций.

В конфигурации высокой доступности базы данных выполняются в модели полного восстановления, для которой требуется репликация. В этой модели пространство журнала используется повторно только при выполнении резервного копирования. Если резервные копии не выполняются достаточно часто или завершаются сбоем, журнал продолжает расширять файл для хранения новых записей. Он будет расти до тех пор, пока он не заполнит диск данных или пока не достигнет ограничения на 2 ТБ на файл, в зависимости от того, что происходит в первую очередь.

Подтверждение проблемы

SSH в административную оболочку. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).
Список каталога данных MSSQL.
```
sudo ls -lth /data/user/mssql/data
```
Сравните каждый .mdf файл данных с соответствующим журналом _log.ldf транзакций и определите, какие файлы используют больше всего места.

Большой _log.ldf файл не является доказательством того, что усечение завершается ошибкой. Усечение делает пространство внутри файла повторно используемым, он не сжимает файл, поэтому журнал, который был усечен успешно, все равно может быть большим. В описании рассказывается, какие файлы используют диск.
```
-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
```
Каждый журнал здесь превышает пять раз в его файл данных, что хорошо прошло нормально. В этом примере первый файл журнала составляет 156 ГБ для файла данных размером 72 МБ, поэтому он заполняет диск.

Устранение проблемы

Приведенные ниже процедуры временно переключят базы данных на модель ПРОСТОго восстановления, которая позволяет усеченным журналам транзакций, а затем восстанавливает модель полного восстановления.

Выполните процедуру, соответствующую вашей среде. Они отличаются, так как репликация зависит от модели полного восстановления, поэтому в репликации конфигурации высокой доступности необходимо отключить до усечения журналов.

Среды высокого уровня доступности

Используйте эту процедуру, если ваш экземпляр GitHub Enterprise Server имеет одну или несколько реплик. Выполните каждую команду на первичном сервере.

Предупреждение

Эта процедура удаляет группу доступности и удаляет файлы базы данных MSSQL на каждой реплике, которые затем повторно создаются путем заполнения. Время заполнения большой базы данных занимает некоторое время, и ваши реплики не защищают вас до завершения работы.

Создайте резервную копию вручную с помощью настроенного решения для резервного копирования.
```
ghe-backup
```
Если решение резервного копирования не настроено, экспортируйте базы данных MSSQL.
```
ghe-export-mssql --compress --stats 1
```
Запишите текущие размеры файлов, чтобы подтвердить сокращение после этого.
```
sudo du --all --human-readable /data/user/mssql/data
```
Усечьте журналы транзакций. Это отключает репликацию MSSQL на каждой реплике, удаляет группу доступности, переключает базы данных в модель восстановления SIMPLE и сжимает журналы.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --disable-mssql-replication --set-simple-recovery-model
```

Убедитесь, что файлы меньше.

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

Убедитесь, что контейнеры MSSQL работоспособны.
```
ghe-actions-check -s mssql
```
Повторно включите репликацию MSSQL. Это повторно создает группу доступности и восстанавливает модель полного восстановления.
```
ghe-cluster-each --serial --exclude --role mssql -- /usr/local/share/enterprise/ghe-repl-start-mssql
```
Отслеживайте начальные значения, пока реплики не будут синхронизированы. До завершения реплики не содержат данных MSSQL.

В отличие от описанных выше шагов, запустите его на каждой реплике, а не на первичной.
```
ghe-repl-status
```

Автономные среды

Используйте эту процедуру, если ваш экземпляр GitHub Enterprise Server нет реплик.

Создайте резервную копию вручную с помощью настроенного решения для резервного копирования.
```
ghe-backup
```
Если решение резервного копирования не настроено, экспортируйте базы данных MSSQL.
```
ghe-export-mssql --compress --stats 1
```
Запишите текущие размеры файлов.
```
sudo du --all --human-readable /data/user/mssql/data
```
Усечьте журналы транзакций. Это переключает базы данных на модель восстановления SIMPLE и сжимает журналы.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --set-simple-recovery-model
```

Убедитесь, что файлы меньше.

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

Убедитесь, что контейнеры MSSQL работоспособны.
```
ghe-actions-check -s mssql
```
Создайте новую резервную копию. Это восстанавливает модель полного восстановления.
```
ghe-export-mssql --compress --stats 1
```
Предупреждение

В автономном экземпляре модель полного восстановления не восстанавливается автоматически. Эту резервную копию необходимо выполнить. Если базы данных остаются в модели простого восстановления, журналы транзакций усечены на каждой контрольной точке, а репликация завершится ошибкой, если вы добавите реплику позже.

Предотвращение повторения

Журналы транзакций очищаются резервными копиями, поэтому журналы остаются разумным размером только в то время как резервные копии выполняются надежно.

Запустите резервные копии по расписанию и убедитесь, что они завершены. Дополнительные сведения см. в разделе Настройка службы резервного копирования.
Отслеживайте использование диска данных, чтобы вы видели журналы, растущие до заполнения диска. Дополнительные сведения см. в разделе Рекомендуемые пороговые значения оповещений.
После любого периода, когда резервные копии завершались сбоем, проверьте размеры файлов снова, так как журналы будут растут в то же время.

Связь Служба поддержки GitHub

Если эти действия не устраняют проблему, или вы не уверены в любом из них, обратитесь Служба поддержки GitHub , а не продолжайте. Дополнительные сведения см. в разделе Создание запроса в службу поддержки.

Если вы уже открыли запрос, присоединение пакета поддержки помогает Служба поддержки GitHub быстрее диагностировать проблему. Дополнительные сведения см. в разделе Предоставление данных в поддержку GitHub.

Дополнительные материалы

Увеличение емкости хранилища