MSSQL 트랜잭션 로그 잘라내기

Symptoms

MSSQL은 GitHub Enterprise Server 인스턴스이 활성화된 경우에만 GitHub Actions에서 실행됩니다. 트랜잭션 로그가 너무 커지면 다음 중 하나 이상이 표시될 수 있습니다.

데이터 디스크 사용량이 꾸준히 증가하고 감소하지 않습니다.
MSSQL은 데이터베이스의 트랜잭션 로그가 가득 찼다는 오류를 기록합니다.
자체 호스팅 실행기가 등록되지 않습니다. 단일 트랜잭션 로그는 2TB를 초과할 수 없으며 해당 제한에 도달하면 해당 데이터베이스에 대한 쓰기가 실패합니다.
MSSQL 복제가 실패하거나 완료하는 데 예상보다 훨씬 오래 걸립니다.

원인

각 MSSQL 데이터베이스에는 데이터 파일은 .mdf로 끝나고 트랜잭션 로그는 _log.ldf로 끝납니다. 모든 변경 내용은 먼저 트랜잭션 로그에 기록됩니다.

고가용성 구성에서 데이터베이스는 복제에 필요하므로 FULL 복구 모델로 실행됩니다. 해당 모델에서 로그 공간은 백업이 실행될 때만 다시 사용할 수 있습니다. 백업이 충분히 자주 실행되지 않거나 실패하는 경우 로그 파일은 새 레코드를 보관하기 위해 계속 확장됩니다. 데이터 디스크를 채우거나 파일당 2TB 제한에 도달할 때까지, 둘 중 먼저 도달하는 시점까지 증가합니다.

문제 확인 중

관리 셸에 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배 이상이며 이는 정상적인 성장을 훨씬 뛰어넘습니다. 이 예제에서 첫 번째 로그 파일은 72MB 데이터 파일에 비해 156GB이므로 디스크를 채우는 파일입니다.

문제 해결

아래 절차에서는 임시로 데이터베이스를 SIMPLE 복구 모델로 전환하여 트랜잭션 로그를 잘라낼 수 있게 한 다음 FULL 복구 모델을 복원합니다.

따라와 환경에 맞는 절차를 따르십시오. 복제는 FULL 복구 모델을 사용하므로 고가용성 구성에서는 로그를 자르기 전에 복제를 사용하지 않도록 설정해야 하기 때문에 두 가지가 다릅니다.

고가용성 환경

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 복제를 다시 사용하도록 설정합니다. 그러면 가용성 그룹이 다시 생성되고 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 지원에 데이터 제공을(를) 참조하세요.

추가 읽기

스토리지 용량 늘리기

이 기사에서