MSSQL トランザクションログの切り捨て

Symptoms

MSSQL は、お使いの GitHub Enterprise Server インスタンスが有効になっている場合にのみ、GitHub Actions で実行されます。トランザクションログが大きすぎると、次のいずれかが表示されることがあります。

データディスクの使用量は着実に増加し、減少しません。
MSSQL は、データベースのトランザクションログがいっぱいであることを示すエラーをログに記録します。
セルフホステッドランナーは登録に失敗します。 1 つのトランザクションログを 2 TB を超えて拡張することはできません。その制限に達すると、そのデータベースへの書き込みが失敗します。
MSSQL レプリケーションが失敗するか、予想以上に長い時間がかかります。

原因

各 MSSQL データベースには、 .mdf で終わるデータファイルと、 _log.ldfで終わるトランザクションログがあります。すべての変更は、最初にトランザクションログに書き込まれます。

高可用性構成では、データベースはレプリケーションで必要とされる FULL 復旧モデルで実行されます。このモデルでは、ログ領域はバックアップの実行時にのみ再利用可能になります。バックアップが十分に頻繁に実行されていない場合、または失敗している場合、ログファイルが新しいレコードを保持するために拡張され続けます。データディスクがいっぱいになるまで、またはファイルあたり 2 TB の上限に達するまで、どちらか早い方に増加します。

問題を確認しています

管理シェルに 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
```
ここにあるすべてのログは、対応するデータファイルの5倍以上で、通常の増加を大きく超えています。この例では、最初のログファイルは 72 MB のデータファイルに対して 156 GB であるため、ディスクをいっぱいにしているのはそのログファイルです。

問題の解決

以下の手順では、データベースを一時的に SIMPLE 復旧モデルに切り替えてトランザクションログを切り捨て可能にし、その後 FULL 復旧モデルに戻します。

ご使用の環境にあった手順に従ってください。両者が異なるのは、レプリケーションが FULL 復旧モデルに依存しているためです。そのため、高可用性構成では、ログを切り捨てる前に、レプリケーションを無効にする必要があります。

高可用性環境

お使いの GitHub Enterprise Server インスタンスに 1 つ以上のレプリカがある場合は、この手順を使用します。プライマリで各コマンドを実行してください。

警告

この手順では、可用性グループを削除し、各レプリカの 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 レプリケーションを再度有効にします。これにより、可用性グループが再作成され、FULL 復旧モデルが復元されます。
```
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
```
新しいバックアップを作成してください。これにより、FULL 復旧モデルが復元されます。
```
ghe-export-mssql --compress --stats 1
```
警告

スタンドアロンインスタンスでは、FULL 復旧モデルには自動的に戻りません。このバックアップを取得する必要があります。データベースが SIMPLE 復旧モデルに残っている場合、トランザクションログはすべてのチェックポイントで切り捨てられ、後でレプリカを追加した場合、レプリケーションは失敗します。

再発防止

トランザクションログはバックアップによってクリアされるため、バックアップが確実に実行されている間だけ、ログのサイズは妥当なままです。

スケジュールに従ってバックアップを実行し、完了していることを確認します。詳細については、「バックアップサービスの構成」を参照してください。
データディスクの使用状況を監視して、ディスクがいっぱいになる前にログが増加していることを把握できるようにします。詳細については、「アラートの推奨閾値」を参照してください。
バックアップが失敗していた期間の後は、その時点までにログが増えているため、ファイルサイズをもう一度確認します。

連絡する GitHub のサポート

これらの手順で問題が解決しない場合、またはいずれかの手順に確信が持てない場合は、続行するのではなく、GitHub のサポートにお問い合わせください。詳細については、「サポートチケットの作成」を参照してください。

既にチケットを開いている場合は、サポートバンドルをアタッチすると、問題をより迅速に診断するのに役立ちますGitHub のサポート詳細については、「GitHub サポートにデータを提供する」を参照してください。

詳細については、次を参照してください。

ストレージ容量の増加

この記事で