Kürzen von MSSQL-Transaktionsprotokollen

Symptome

MSSQL wird nur auf Ihre GitHub Enterprise Server-Instance ausgeführt, wenn GitHub Actions aktiviert ist. Wenn Ihre Transaktionsprotokolle zu groß werden, sehen Sie möglicherweise eines der folgenden Probleme.

Die Datenträgernutzung steigt stetig und wird nicht wieder abnehmen.
MSSQL protokolliert Fehler, die angeben, dass das Transaktionsprotokoll für eine Datenbank voll ist.
Selbst gehostete Runner können sich nicht registrieren. Ein einzelnes Transaktionsprotokoll kann nicht mehr als 2 TB wachsen, und sobald dieser Grenzwert erreicht ist, schlagen Schreibvorgänge in diese Datenbank fehl.
MSSQL-Replikation schlägt fehl oder dauert viel länger als erwartet.

Ursachen

Jede MSSQL-Datenbank enthält eine Datendatei mit der Endung .mdf und ein Transaktionsprotokoll mit der Endung _log.ldf. Jede Änderung wird zuerst in das Transaktionsprotokoll geschrieben.

In einer Hochverfügbarkeitskonfiguration werden die Datenbanken im vollständigen Wiederherstellungsmodell ausgeführt, das von der Replikation vorausgesetzt wird. In diesem Modell wird der Transaktionsprotokollspeicher nur wiederverwendbar gemacht, wenn eine Sicherung ausgeführt wird. Wenn Sicherungen nicht häufig genug ausgeführt werden oder fehlschlagen, erweitert das Transaktionsprotokoll die Datei, um neue Einträge aufzunehmen. Sie wächst, bis sie den Datenträger ausfüllt, oder bis sie den Grenzwert von 2 TB pro Datei erreicht, je nachdem, was zuerst eintritt.

Problem bestätigen

Melden Sie sich per SSH bei der administrativen Shell an. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
Auflisten des MSSQL-Datenverzeichnisses.
```
sudo ls -lth /data/user/mssql/data
```
Vergleichen Sie jede .mdf Datendatei mit dem übereinstimmenden _log.ldf Transaktionsprotokoll, und identifizieren Sie, welche Dateien den meisten Speicherplatz verwenden.

Eine große _log.ldf Datei ist selbst kein Beweis dafür, dass das Abschneiden fehlschlägt. Durch Kürzen wird Speicherplatz innerhalb der Datei wiederverwendbar, die Datei wird nicht verkleinert, sodass eine Protokolldatei, die erfolgreich gekürzt wurde, weiterhin groß sein kann. Die Auflistung zeigt Ihnen, welche Dateien den Datenträger verbrauchen.
```
-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
```
Jedes Protokoll hier ist mehr als fünfmal so groß wie seine Datendatei, was weit über dem normalen Wachstum liegt. In diesem Beispiel ist die erste Protokolldatei 156 GB groß, gegenüber einer Datendatei von 72 MB, sodass sie den Datenträger ausfüllt.

Beheben des Problems

Die folgenden Verfahren wechseln die Datenbanken vorübergehend in das SIMPLE-Wiederherstellungsmodell, wodurch die Transaktionsprotokolle abgeschnitten werden können, und stellen dann das VOLLSTÄNDIGE Wiederherstellungsmodell wieder her.

Nutzen Sie das Verfahren, das Ihrer Umgebung entspricht. Die beiden unterscheiden sich, da die Replikation auf das VOLLSTÄNDIGE Wiederherstellungsmodell basiert. Daher muss in einer Hochverfügbarkeitskonfiguration die Replikation deaktiviert werden, bevor die Protokolle abgeschnitten werden können.

Hochverfügbarkeitsumgebungen

Verwenden Sie dieses Verfahren, wenn bei Ihre GitHub Enterprise Server-Instance ein oder mehrere Replikate vorhanden sind. Führen Sie jeden Befehl auf dem primären System aus.

Warnung

Dieses Verfahren löscht die Verfügbarkeitsgruppe und löscht die MSSQL-Datenbankdateien für jedes Replikat, die dann durch Seeding neu erstellt werden. Das Seeding einer großen Datenbank dauert Zeit, und Ihre Replikate schützen Sie erst, bis dieser Vorgang abgeschlossen ist.

Erstellen Sie eine manuelle Sicherung mithilfe Ihrer konfigurierten Sicherungslösung.
```
ghe-backup
```
Wenn keine Sicherungslösung konfiguriert ist, exportieren Sie stattdessen die MSSQL-Datenbanken.
```
ghe-export-mssql --compress --stats 1
```
Notieren Sie die aktuellen Dateigrößen, damit Sie die Reduzierung anschließend bestätigen können.
```
sudo du --all --human-readable /data/user/mssql/data
```
Kürzen Sie die Transaktionsprotokolle. Dadurch wird die MSSQL-Replikation für jedes Replikat deaktiviert, die Verfügbarkeitsgruppe gelöscht, die Datenbanken in das SIMPLE-Wiederherstellungsmodell umgeschaltet und die Protokolle verkleinert.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --disable-mssql-replication --set-simple-recovery-model
```
Vergewissern Sie sich, dass die Dateien verkleinert werden.
```
sudo du --all --human-readable /data/user/mssql/data
```
Überprüfen Sie, ob die MSSQL-Container fehlerfrei sind.
```
ghe-actions-check -s mssql
```
Aktivieren Sie die MSSQL-Replikation erneut. Dadurch wird die Verfügbarkeitsgruppe neu erstellt und das VOLLSTÄNDIGE Wiederherstellungsmodell wiederhergestellt.
```
ghe-cluster-each --serial --exclude --role mssql -- /usr/local/share/enterprise/ghe-repl-start-mssql
```
Überwachen Sie das Seeding, bis die Replikate synchronisiert sind. Bis das Seeding abgeschlossen ist, enthalten die Replikate keine MSSQL-Daten.

Führen Sie dies im Gegensatz zu den vorstehenden Schritten für jedes Replikat und nicht auf dem primären aus.
```
ghe-repl-status
```

Eigenständige Umgebungen

Verwenden Sie dieses Verfahren, wenn Ihre GitHub Enterprise Server-Instance keine Replikate hat.

Erstellen Sie eine manuelle Sicherung mithilfe Ihrer konfigurierten Sicherungslösung.
```
ghe-backup
```
Wenn keine Sicherungslösung konfiguriert ist, exportieren Sie stattdessen die MSSQL-Datenbanken.
```
ghe-export-mssql --compress --stats 1
```

Notieren Sie die aktuellen Dateigrößen.

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

Schneiden Sie die Transaktionsprotokolle ab. Dadurch werden die Datenbanken in das EINFACHE Wiederherstellungsmodell umgeschaltet und die Protokolle werden verkleinert.
```
sudo /usr/local/share/enterprise/ghe-mssql-shrinkfile --set-simple-recovery-model
```

Bestätigen Sie, dass die Dateien kleiner sind.

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

Überprüfen Sie, ob die MSSQL-Container fehlerfrei sind.
```
ghe-actions-check -s mssql
```
Erstellen Sie eine neue Sicherung. Dadurch wird das vollständige Wiederherstellungsmodell wiederhergestellt.
```
ghe-export-mssql --compress --stats 1
```
Warnung

In einer eigenständigen Instanz wird das vollständige Wiederherstellungsmodell nicht automatisch wiederhergestellt. Sie müssen diese Sicherung erstellen. Wenn die Datenbanken im einfachen Wiederherstellungsmodell verbleiben, werden Transaktionsprotokolle bei jedem Checkpoint gekürzt, und die Replikation schlägt fehl, wenn Sie später ein Replikat hinzufügen.

Erneutes Auftreten verhindern

Transaktionsprotokolle werden durch Sicherungen geleert, sodass die Protokolle nur dann eine angemessene Größe aufweisen, wenn Sicherungen zuverlässig ausgeführt werden.

Führen Sie Sicherungen nach einem Zeitplan aus, und überprüfen Sie, ob sie abgeschlossen sind. Weitere Informationen findest du unter Konfigurieren des Sicherungsdiensts.
Überwachen Sie die Datenträgernutzung, sodass Sie sehen, wie die Protokolle wachsen, bevor der Datenträger voll ist. Weitere Informationen findest du unter Empfohlene Schwellenwerte für Meldungen.
Überprüfen Sie nach jedem Zeitraum, in dem Sicherungen fehlgeschlagen sind, die Dateigrößen erneut, da die Protokolle in der Zwischenzeit gewachsen sind.

Kontaktieren GitHub-Support

Wenn das Problem durch diese Schritte nicht behoben wird oder Sie sich bei einem dieser Schritte nicht sicher sind, wenden Sie sich an GitHub-Support, anstatt fortzufahren. Weitere Informationen findest du unter Erstellen eines Supporttickets.

Wenn Sie bereits ein Ticket geöffnet haben, hilft GitHub-Support das Anfügen eines Support-Bundles, das Problem schneller zu diagnostizieren. Weitere Informationen findest du unter Bereitstellen von Daten für GitHub Support.

Weiterführende Lektüre

Speicherkapazität erhöhen

In diesem Artikel