재해 복구 (Geo)

요약

Geo는 데이터베이스, Git 저장소 및 기타 자산을 복제합니다. 선택적 동기화가 활성화된 보조 사이트를 승격하면 해당 보조 사이트에 복제되지 않은 모든 데이터에 대해 영구적인 데이터 손실이 발생합니다. 자세한 내용은 선택적 동기화가 활성화된 보조 사이트 승격을 참조하세요.

Geo는 데이터베이스, Git 저장소 및 기타 자산을 복제합니다. 일부 알려진 이슈가 있습니다.

Warning

다중 보조 구성은 승격되지 않은 모든 보조 사이트의 완전한 재동기화 및 재구성이 필요하고 다운타임을 발생시킵니다.
보조 사이트가 승격된 후 기본 사이트는 완전히 분리됩니다. 기본 사이트를 복원하려면 새 보조 사이트로 추가해야 합니다.

선택적 동기화가 활성화된 보조 사이트#

선택적 동기화가 활성화된 보조 사이트를 승격하면 해당 보조 사이트에 복제되지 않은 모든 데이터에 대해 영구적인 데이터 손실이 발생합니다.

자세한 내용은 선택적 동기화가 활성화된 보조 사이트 승격을 참조하세요.

`gitlab-cluster.json` 파일#

gitlab-ctl geo promote로 보조 사이트를 기본 사이트로 승격하면, 해당 명령이 실행되는 각 노드에 /etc/gitlab/gitlab-cluster.json 파일이 자동으로 생성됩니다. 대부분의 경우 이 파일을 수동으로 편집할 필요가 없습니다.

gitlab-cluster.json 파일을 통해 승격 명령이 /etc/gitlab/gitlab.rb를 직접 수정하지 않고 구성 변경을 자동화할 수 있습니다. gitlab.rb를 프로그래밍 방식으로 편집하면 오류가 발생하기 쉬우므로 gitlab-cluster.json은 머신 관리 재정의 레이어 역할을 합니다.

두 파일이 모두 존재하는 경우 gitlab-ctl reconfigure가 실행될 때 gitlab-cluster.json의 값이 gitlab.rb의 해당 값보다 우선합니다. 이 명령을 실행하면 다음과 유사한 경고가 표시됩니다:

The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb
The 'geo_secondary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'false' and overrides the setting in the /etc/gitlab/gitlab.rb

이 경고는 승격 후 예상되는 동작입니다.

파일 구조#

일반적인 gitlab-cluster.json 파일은 다음과 같습니다:

{
  "primary": true,
  "secondary": false,
  "geo_secondary": {
    "enable": false
  }
}

키	설명
`primary`	`true`이면 `geo_primary_role`을 활성화하여 노드를 Geo 기본으로 구성합니다.
`secondary`	`true`이면 `geo_secondary_role`을 활성화하여 노드를 Geo 보조로 구성합니다.
`geo_secondary`	추적 데이터베이스와 같은 Geo 보조 구성과 관련된 설정을 포함합니다. `"enable": false`는 보조 전용 서비스를 비활성화합니다.

primary 및 secondary 키는 각각 geo_primary_role 및 geo_secondary_role에 매핑됩니다. 이러한 역할은 단일 노드 설정의 편의를 위한 것으로 gitlab.rb에서 개별 서비스 역할이 명시적으로 구성된 다중 노드 구성에서는 사용하지 않아야 합니다.

파일 제거#

승격이 성공하면 gitlab-cluster.json을 그대로 유지할 수 있습니다. 그러나 다음 상황에서는 제거해야 합니다:

강등된 기본 사이트를 새 보조 사이트로 복구하는 경우 모든 Sidekiq, PostgreSQL, Gitaly 및 Rails 노드에서 gitlab-cluster.json을 삭제해야 합니다.
gitlab.rb를 업데이트하여 Geo 역할(예: roles(['geo_primary_role']))을 설정하고 gitlab.rb를 유일한 구성 소스로 사용하려는 경우.
부분 페일오버에서 복구한 후.

파일이 복구 중에 수동으로 생성되는 시기에 대한 자세한 내용은 부분 페일오버에서 복구를 참조하세요.

파일을 제거하려면:

다음 명령을 실행합니다:
```
sudo rm /etc/gitlab/gitlab-cluster.json
sudo gitlab-ctl reconfigure
```
다중 노드 설정의 경우 사이트의 모든 노드에서 이 명령을 반복합니다.

gitlab-cluster.json이 재구성 프로세스와 상호 작용하는 방법에 대한 기술적 세부 정보는 Omnibus 재구성 문서를 참조하세요.

단일 보조 구성에서 보조 Geo 사이트 승격#

Geo 복제본을 자동으로 승격하고 페일오버를 수행할 수는 없지만, 머신에 대한 root 액세스 권한이 있으면 수동으로 승격할 수 있습니다.

이 프로세스는 보조 Geo 사이트를 기본 사이트로 승격합니다. 지리적 이중화를 최대한 빨리 회복하려면 이 지침을 따른 후 즉시 새 보조 사이트를 추가해야 합니다.

가능하면 복제가 완료될 때까지 기다리기#

보조 사이트가 기본 사이트에서 데이터를 아직 복제 중인 경우 불필요한 데이터 손실을 방지하기 위해 계획된 페일오버 문서를 최대한 따르세요.

1단계. 기본 사이트 영구 비활성화#

Warning

기본 사이트가 오프라인 상태가 되면 보조 사이트에 복제되지 않은 기본 사이트에 저장된 데이터가 있을 수 있습니다. 진행하면 이 데이터는 손실된 것으로 처리해야 합니다.

기본 사이트에 장애가 발생하면 두 개의 서로 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인 상황을 피하기 위해 모든 것을 다해야 합니다. 이는 복구 노력을 복잡하게 만듭니다. 따라서 페일오버를 준비하기 위해 기본 사이트를 비활성화해야 합니다.

SSH 액세스가 있는 경우:
1. 기본 사이트에 SSH로 접속하여 GitLab을 중지하고 비활성화합니다:
```
sudo gitlab-ctl stop
```
2. 서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 합니다:
```
sudo systemctl disable gitlab-runsvdir
```
기본 사이트에 SSH 액세스가 없는 경우 머신을 오프라인 상태로 전환하고 사용 가능한 모든 수단을 통해 재부팅을 방지합니다. 다음을 수행해야 할 수 있습니다:
- 로드 밸런서 재구성.
- DNS 레코드 변경(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 기본 사이트에서 오브젝트 스토리지 권한 취소.
- 머신 물리적 연결 해제.
기본 도메인 DNS 레코드 업데이트를 계획하는 경우 DNS 변경의 빠른 전파를 위해 낮은 TTL을 유지하는 것이 좋습니다.

[!note] 기본 사이트의 /etc/gitlab/gitlab.rb 파일은 이 과정에서 보조 사이트로 자동 복사되지 않습니다. 나중에 보조 사이트에서 필요한 값을 복원할 수 있도록 기본 사이트의 /etc/gitlab/gitlab.rb 파일을 백업하세요.

2단계. 보조 사이트 승격#

보조 사이트를 승격할 때 다음 사항에 유의하세요:

보조 사이트가 일시 중지된 경우, 승격은 마지막으로 알려진 상태로 특정 시점 복구를 수행합니다. 보조 사이트가 일시 중지된 동안 기본 사이트에서 생성된 데이터는 손실됩니다.
보조 사이트가 일시 중지된 경우 이 프로세스 중에 ActiveRecord::StatementInvalid: PG::ReadOnlySqlTransaction: ERROR: cannot execute DELETE in a read-only transaction 오류 메시지가 발생하면 다음 기술 자료 문서를 참조하세요: Geo 승격이 예기치 않은 기본 종료 후 읽기 전용 트랜잭션 오류 또는 타임아웃으로 실패함.
이 시점에 새 보조 사이트를 추가하면 안 됩니다. 새 보조를 추가하려면 보조에서 기본으로 승격하는 전체 프로세스를 완료한 후에 수행하세요.
이 과정에서 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하면 이 문제 해결 조언을 참조하세요.
별도의 URL을 사용하는 경우 기본 도메인 DNS를 새로 승격된 사이트로 지정해야 합니다. 그렇지 않으면 러너를 새로 승격된 사이트에 다시 등록하고 모든 Git 원격, 북마크 및 외부 통합을 업데이트해야 합니다.
위치 인식 DNS를 사용하는 경우 이전 기본 사이트가 DNS 항목에서 제거된 후 러너가 자동으로 새 기본 사이트에 연결됩니다.
기본 사이트가 다운된 후 보조 사이트에서 gitlab-ctl promotion-preflight-checks를 실행하여 Geo 동기화 상태를 확인하고 최종 검증 점검을 수행합니다.
이전 기본 사이트에 연결된 러너가 돌아오지 않을 것으로 예상되면 제거해야 합니다:
- UI를 통해:
  1. 오른쪽 상단에서 관리자를 선택합니다.
  2. CI/CD > 러너를 선택하고 제거합니다.
- 러너 API 사용.

단일 노드에서 실행 중인 보조 사이트 승격#

보조 사이트에 SSH로 접속하여 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

gitlab-ctl geo promote를 실행하면 노드에 gitlab-cluster.json 파일이 생성됩니다. 이 파일은 재구성 시 gitlab.rb의 Geo 역할 설정을 재정의합니다.

3단계. 이전 보조의 추적 데이터베이스 제거#

/etc/gitlab/gitlab.rb 파일에 활성화된 geo_secondary[] 구성 옵션이 있으면 주석 처리하거나 제거한 다음 변경 사항을 적용하기 위해 GitLab 재구성을 수행합니다.

이 시점에서 승격된 사이트는 새 기본 GitLab 사이트입니다. 선택적으로 Geo를 새 보조 사이트로 다시 설정하려면 이전 사이트를 보조로 복구할 수 있습니다.

여러 노드와 단일 보조 사이트가 있는 보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트의 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

gitlab-ctl geo promote를 실행하면 노드에 gitlab-cluster.json 파일이 생성됩니다. 이 파일은 재구성 시 gitlab.rb의 Geo 역할 설정을 재정의합니다.

Patroni 대기 클러스터가 있는 보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격#

gitlab-ctl geo promote 명령은 외부 PostgreSQL 데이터베이스와 함께 사용할 수 있습니다. 이 경우 보조 사이트와 연결된 복제본 데이터베이스를 먼저 수동으로 승격해야 합니다:

보조 사이트와 연결된 복제본 데이터베이스를 승격합니다. 이는 데이터베이스를 읽기/쓰기로 설정합니다. 지침은 데이터베이스 호스팅 위치에 따라 다릅니다:

Amazon RDS
Azure PostgreSQL
Google Cloud SQL

다른 외부 PostgreSQL 데이터베이스의 경우 보조 사이트에 다음 스크립트를 저장하고(예: /tmp/geo_promote.sh), 환경에 맞게 연결 매개변수를 수정한 다음 복제본을 승격하기 위해 실행합니다:

#!/bin/bash

PG_SUPERUSER=postgres

# The path to your pg_ctl binary. You may need to adjust this path to match
# your PostgreSQL installation
PG_CTL_BINARY=/usr/lib/postgresql/16/bin/pg_ctl

# The path to your PostgreSQL data directory. You may need to adjust this
# path to match your PostgreSQL installation. You can also run
# `SHOW data_directory;` from PostgreSQL to find your data directory
PG_DATA_DIRECTORY=/etc/postgresql/16/main

# Promote the PostgreSQL database and allow read/write operations
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

(선택사항) 기본 도메인 DNS 레코드 업데이트#

기본 도메인의 DNS 레코드를 업데이트하여 보조 사이트를 지정합니다. 이렇게 하면 Git 원격 및 API URL 변경과 같이 기본 도메인에 대한 모든 참조를 업데이트할 필요가 없습니다.

보조 사이트에 SSH로 접속하고 루트로 로그인합니다:
```
sudo -i
```
기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드를 보조 사이트로 업데이트한 후 보조 사이트의 /etc/gitlab/gitlab.rb를 편집하여 새 URL을 반영합니다:
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
[!note] external_url 변경은 보조 DNS 레코드가 여전히 유지되는 한 이전 보조 URL을 통한 액세스를 방지하지 않습니다.
보조의 SSL 인증서 업데이트:
- Let's Encrypt 통합을 사용하는 경우 인증서가 자동으로 업데이트됩니다.
- 보조의 인증서를 수동으로 설정한 경우 기본에서 보조로 인증서를 복사합니다. 기본에 액세스할 수 없는 경우 새 인증서를 발급하고 기본 및 보조 URL이 모두 주체 대체 이름에 포함되어 있는지 확인합니다. 다음으로 확인할 수 있습니다:
```
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
변경 사항을 적용하기 위해 보조 사이트를 재구성합니다:
```
gitlab-ctl reconfigure
```
새로 승격된 기본 사이트 URL을 업데이트하기 위해 다음 명령을 실행합니다:
```
gitlab-rake gitlab:geo:update_primary_node_url
```
이 명령은 /etc/gitlab/gitlab.rb에 정의된 변경된 external_url 구성을 사용합니다.
새로 승격된 기본에 해당 URL을 사용하여 연결할 수 있는지 확인합니다. 기본 도메인의 DNS 레코드를 업데이트했다면 이전 DNS 레코드의 TTL에 따라 이 변경이 아직 전파되지 않았을 수 있습니다.

(선택사항) 승격된 기본 사이트에 보조 Geo 사이트 추가#

새 보조 사이트를 온라인으로 가져오려면 Geo 설정 지침을 따르세요.

다중 보조 구성에서 보조 Geo 복제본 승격#

보조 사이트가 두 개 이상 있고 그 중 하나를 승격해야 하는 경우 단일 보조 구성에서 보조 Geo 사이트 승격을 따른 후 두 가지 추가 단계가 필요합니다.

1단계. 하나 이상의 보조 사이트를 제공하도록 새 기본 사이트 준비#

새 기본 사이트에 SSH로 접속하고 루트로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집합니다:

## Enable a Geo Primary role (if you haven't yet)
roles ['geo_primary_role']

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

# Every secondary site needs to have its own slot so specify the number of secondary sites you're going to have
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one

##
## Disable automatic database migrations temporarily
## (until PostgreSQL is restarted and listening on the private address).
##
gitlab_rails['auto_migrate'] = false

(이 설정에 대한 자세한 내용은 기본 서버 구성을 참조하세요)

파일을 저장하고 데이터베이스 수신 변경 및 복제 슬롯 변경이 적용되도록 GitLab을 재구성합니다:
```
gitlab-ctl reconfigure
```
PostgreSQL 변경 사항을 적용하기 위해 재시작합니다:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 재시작되고 개인 주소에서 수신 대기 중이므로 마이그레이션을 다시 활성화합니다.

/etc/gitlab/gitlab.rb를 편집하고 구성을 true로 변경합니다:
```
gitlab_rails['auto_migrate'] = true
```
파일을 저장하고 GitLab을 재구성합니다:
```
gitlab-ctl reconfigure
```

2단계. 복제 프로세스 시작#

이제 각 보조 사이트가 새 기본 사이트의 변경 사항을 수신하도록 해야 합니다. 이를 위해 복제 프로세스를 시작해야 하지만 이번에는 다른 기본 사이트에 대해 수행합니다. 모든 이전 복제 설정이 덮어씌워집니다.

기존 보조 사이트의 데이터베이스에 데이터가 채워져 있으므로 다음과 같은 메시지가 표시될 수 있습니다:

Found data inside the gitlabhq_production database! If you are sure you are in the secondary server, override with --force

적절한 보조 사이트에 있는지 확인한 후 --force로 복제를 시작합니다.

Warning

--force를 사용하면 해당 보조 서버의 데이터베이스에 있는 모든 기존 데이터가 삭제됩니다.

GitLab Helm 차트에서 보조 Geo 클러스터 승격#

클라우드 네이티브 Geo 배포를 업데이트할 때 보조 Kubernetes 클러스터 외부의 노드를 업데이트하는 프로세스는 클라우드 비네이티브 접근 방식과 다르지 않습니다. 따라서 자세한 내용은 항상 단일 보조 구성에서 보조 Geo 사이트 승격을 참조할 수 있습니다.

다음 섹션은 gitlab 네임스페이스를 사용한다고 가정합니다. 클러스터 설정 시 다른 네임스페이스를 사용한 경우 --namespace gitlab도 해당 네임스페이스로 교체해야 합니다.

1단계. 기본 클러스터 영구 비활성화#

Warning

기본 사이트에 장애가 발생하면 두 개의 서로 다른 GitLab 인스턴스에서 쓰기가 발생할 수 있는 스플릿 브레인 상황을 피하기 위해 모든 것을 다해야 합니다. 따라서 페일오버를 준비하기 위해 기본 사이트를 비활성화해야 합니다:

기본 Kubernetes 클러스터에 액세스할 수 있는 경우 연결하여 GitLab webservice 및 Sidekiq 파드를 비활성화합니다:

kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0

기본 Kubernetes 클러스터에 액세스할 수 없는 경우 클러스터를 오프라인 상태로 전환하고 사용 가능한 모든 수단을 통해 재시작을 방지합니다. 다음을 수행해야 할 수 있습니다:
- 로드 밸런서 재구성.
- DNS 레코드 변경(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 기본 사이트에서 오브젝트 스토리지 권한 취소.
- 머신 물리적 연결 해제.

2단계. 클러스터 외부의 모든 보조 사이트 노드 승격#

Warning

보조 사이트가 일시 중지된 경우, 이는 마지막으로 알려진 상태로 특정 시점 복구를 수행합니다. 보조 사이트가 일시 중지된 동안 기본 사이트에서 생성된 데이터는 손실됩니다.

Linux 패키지를 사용하여 보조 Kubernetes 클러스터 외부의 각 노드(PostgreSQL 또는 Gitaly 등)에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```

toolbox 파드를 찾습니다:

kubectl --namespace gitlab get pods -lapp=toolbox

보조 사이트를 승격합니다:
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:set_secondary_as_primary
```
태스크의 동작을 수정하기 위해 환경 변수를 제공할 수 있습니다. 사용 가능한 변수는 다음과 같습니다:

이름 기본값 설명

ENABLE_SILENT_MODE false true이면 승격 전에 사일런트 모드를 활성화합니다(GitLab 16.4 이상)

이름	기본값	설명
`ENABLE_SILENT_MODE`	`false`	`true`이면 승격 전에 사일런트 모드를 활성화합니다(GitLab 16.4 이상)

3단계. 보조 클러스터 승격#

기존 클러스터 구성을 업데이트합니다.

Helm으로 기존 구성을 가져올 수 있습니다:
```
helm --namespace gitlab get values gitlab-geo > gitlab.yaml
```
기존 구성에는 다음과 유사한 Geo 섹션이 포함됩니다:
```
geo:
   enabled: true
   role: secondary
   nodeName: secondary.example.com
   psql:
      host: geo-2.db.example.com
      port: 5431
      password:
         secret: geo
         key: geo-postgresql-password
```
보조 클러스터를 기본 클러스터로 승격하려면 role: secondary를 role: primary로 업데이트합니다.

클러스터가 기본 사이트로 유지되면 geo 아래의 전체 psql 섹션을 반드시 제거해야 합니다. 이는 추적 데이터베이스를 참조하며, 그대로 두면 새 보조 사이트가 추가될 때 인증을 끊는 경로 등록 문제를 일으킬 수 있습니다.

새 구성으로 클러스터를 업데이트합니다:
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공! 보조 사이트가 이제 기본 사이트로 승격되었습니다.

4단계. (선택사항) OpenBao HA 클러스터 승격#

GitLab Secrets Manager가 활성화된 경우 Kubernetes 클러스터를 승격한 후 다음 단계에 따라 OpenBao 고가용성(HA) 클러스터를 승격합니다.

OpenBao 파드 재시작#

PostgreSQL 복제본이 기본으로 승격된 후 OpenBao 파드를 재시작하여 이제 쓰기 가능한 데이터베이스에 다시 연결되도록 합니다:

kubectl --namespace gitlab rollout restart deployment -l app=openbao

(선택사항) JWT 인증 구성#

기본 도메인의 DNS 레코드를 보조 사이트로 업데이트한 경우 이 단계를 건너뜁니다.

JWT 인증을 재구성하려면 루트 토큰이 필요합니다. 복구 키를 사용하여 루트 토큰을 생성합니다.

복구 키에서 루트 토큰 생성.

루트 토큰이 있으면 JWT 인증 마운트가 보조 도메인을 가리키도록 재구성합니다. 구성 세부 정보는 Geo 구성을 참조하세요.

필요한 경우 언실 시크릿 복원#

보조 클러스터의 언실 키는 기본 클러스터의 언실 키와 동일해야 합니다. 그렇지 않으면 OpenBao가 보조 사이트에서 볼트를 언실할 수 없습니다.

불일치가 있는 경우 시크릿 백업에서 보조 클러스터의 gitlab-openbao-unseal 시크릿을 복원한 후 OpenBao 파드를 재시작합니다:

kubectl --namespace gitlab rollout restart deployment -l app=openbao

OpenBao 정상 작동 확인#

모든 OpenBao 파드가 실행 중인지 확인합니다:
```
kubectl --namespace gitlab get pods -l app=openbao
```
Secrets Manager 변수를 사용하는 CI 파이프라인을 실행하여 OpenBao 통합을 테스트합니다.

문제 해결#

이 섹션은 다른 위치로 이동되었습니다.

재해 복구 (Geo)

Tier: Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-05-22

요약

Geo는 데이터베이스, Git 저장소 및 기타 자산을 복제합니다. 일부 알려진 이슈가 있습니다.

Warning

다중 보조 구성은 승격되지 않은 모든 보조 사이트의 완전한 재동기화 및 재구성이 필요하고 다운타임을 발생시킵니다.
보조 사이트가 승격된 후 기본 사이트는 완전히 분리됩니다. 기본 사이트를 복원하려면 새 보조 사이트로 추가해야 합니다.

선택적 동기화가 활성화된 보조 사이트#

선택적 동기화가 활성화된 보조 사이트를 승격하면 해당 보조 사이트에 복제되지 않은 모든 데이터에 대해 영구적인 데이터 손실이 발생합니다.

자세한 내용은 선택적 동기화가 활성화된 보조 사이트 승격을 참조하세요.

`gitlab-cluster.json` 파일#

The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb
The 'geo_secondary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'false' and overrides the setting in the /etc/gitlab/gitlab.rb

이 경고는 승격 후 예상되는 동작입니다.

파일 구조#

일반적인 gitlab-cluster.json 파일은 다음과 같습니다:

{
  "primary": true,
  "secondary": false,
  "geo_secondary": {
    "enable": false
  }
}

키	설명
`primary`	`true`이면 `geo_primary_role`을 활성화하여 노드를 Geo 기본으로 구성합니다.
`secondary`	`true`이면 `geo_secondary_role`을 활성화하여 노드를 Geo 보조로 구성합니다.
`geo_secondary`	추적 데이터베이스와 같은 Geo 보조 구성과 관련된 설정을 포함합니다. `"enable": false`는 보조 전용 서비스를 비활성화합니다.

파일 제거#

승격이 성공하면 gitlab-cluster.json을 그대로 유지할 수 있습니다. 그러나 다음 상황에서는 제거해야 합니다:

강등된 기본 사이트를 새 보조 사이트로 복구하는 경우 모든 Sidekiq, PostgreSQL, Gitaly 및 Rails 노드에서 gitlab-cluster.json을 삭제해야 합니다.
gitlab.rb를 업데이트하여 Geo 역할(예: roles(['geo_primary_role']))을 설정하고 gitlab.rb를 유일한 구성 소스로 사용하려는 경우.
부분 페일오버에서 복구한 후.

파일이 복구 중에 수동으로 생성되는 시기에 대한 자세한 내용은 부분 페일오버에서 복구를 참조하세요.

파일을 제거하려면:

다음 명령을 실행합니다:
```
sudo rm /etc/gitlab/gitlab-cluster.json
sudo gitlab-ctl reconfigure
```
다중 노드 설정의 경우 사이트의 모든 노드에서 이 명령을 반복합니다.

gitlab-cluster.json이 재구성 프로세스와 상호 작용하는 방법에 대한 기술적 세부 정보는 Omnibus 재구성 문서를 참조하세요.

단일 보조 구성에서 보조 Geo 사이트 승격#

Geo 복제본을 자동으로 승격하고 페일오버를 수행할 수는 없지만, 머신에 대한 root 액세스 권한이 있으면 수동으로 승격할 수 있습니다.

가능하면 복제가 완료될 때까지 기다리기#

보조 사이트가 기본 사이트에서 데이터를 아직 복제 중인 경우 불필요한 데이터 손실을 방지하기 위해 계획된 페일오버 문서를 최대한 따르세요.

1단계. 기본 사이트 영구 비활성화#

Warning

SSH 액세스가 있는 경우:
1. 기본 사이트에 SSH로 접속하여 GitLab을 중지하고 비활성화합니다:
```
sudo gitlab-ctl stop
```
2. 서버가 예기치 않게 재부팅될 경우 GitLab이 다시 시작되지 않도록 합니다:
```
sudo systemctl disable gitlab-runsvdir
```
기본 사이트에 SSH 액세스가 없는 경우 머신을 오프라인 상태로 전환하고 사용 가능한 모든 수단을 통해 재부팅을 방지합니다. 다음을 수행해야 할 수 있습니다:
- 로드 밸런서 재구성.
- DNS 레코드 변경(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 기본 사이트에서 오브젝트 스토리지 권한 취소.
- 머신 물리적 연결 해제.
기본 도메인 DNS 레코드 업데이트를 계획하는 경우 DNS 변경의 빠른 전파를 위해 낮은 TTL을 유지하는 것이 좋습니다.

[!note] 기본 사이트의 /etc/gitlab/gitlab.rb 파일은 이 과정에서 보조 사이트로 자동 복사되지 않습니다. 나중에 보조 사이트에서 필요한 값을 복원할 수 있도록 기본 사이트의 /etc/gitlab/gitlab.rb 파일을 백업하세요.

2단계. 보조 사이트 승격#

보조 사이트를 승격할 때 다음 사항에 유의하세요:

보조 사이트가 일시 중지된 경우, 승격은 마지막으로 알려진 상태로 특정 시점 복구를 수행합니다. 보조 사이트가 일시 중지된 동안 기본 사이트에서 생성된 데이터는 손실됩니다.
보조 사이트가 일시 중지된 경우 이 프로세스 중에 ActiveRecord::StatementInvalid: PG::ReadOnlySqlTransaction: ERROR: cannot execute DELETE in a read-only transaction 오류 메시지가 발생하면 다음 기술 자료 문서를 참조하세요: Geo 승격이 예기치 않은 기본 종료 후 읽기 전용 트랜잭션 오류 또는 타임아웃으로 실패함.
이 시점에 새 보조 사이트를 추가하면 안 됩니다. 새 보조를 추가하려면 보조에서 기본으로 승격하는 전체 프로세스를 완료한 후에 수행하세요.
이 과정에서 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하면 이 문제 해결 조언을 참조하세요.
별도의 URL을 사용하는 경우 기본 도메인 DNS를 새로 승격된 사이트로 지정해야 합니다. 그렇지 않으면 러너를 새로 승격된 사이트에 다시 등록하고 모든 Git 원격, 북마크 및 외부 통합을 업데이트해야 합니다.
위치 인식 DNS를 사용하는 경우 이전 기본 사이트가 DNS 항목에서 제거된 후 러너가 자동으로 새 기본 사이트에 연결됩니다.
기본 사이트가 다운된 후 보조 사이트에서 gitlab-ctl promotion-preflight-checks를 실행하여 Geo 동기화 상태를 확인하고 최종 검증 점검을 수행합니다.
이전 기본 사이트에 연결된 러너가 돌아오지 않을 것으로 예상되면 제거해야 합니다:
- UI를 통해:
  1. 오른쪽 상단에서 관리자를 선택합니다.
  2. CI/CD > 러너를 선택하고 제거합니다.
- 러너 API 사용.

단일 노드에서 실행 중인 보조 사이트 승격#

보조 사이트에 SSH로 접속하여 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

gitlab-ctl geo promote를 실행하면 노드에 gitlab-cluster.json 파일이 생성됩니다. 이 파일은 재구성 시 gitlab.rb의 Geo 역할 설정을 재정의합니다.

3단계. 이전 보조의 추적 데이터베이스 제거#

여러 노드와 단일 보조 사이트가 있는 보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트의 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

gitlab-ctl geo promote를 실행하면 노드에 gitlab-cluster.json 파일이 생성됩니다. 이 파일은 재구성 시 gitlab.rb의 Geo 역할 설정을 재정의합니다.

Patroni 대기 클러스터가 있는 보조 사이트 승격#

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격#

Amazon RDS
Azure PostgreSQL
Google Cloud SQL

#!/bin/bash

PG_SUPERUSER=postgres

# The path to your pg_ctl binary. You may need to adjust this path to match
# your PostgreSQL installation
PG_CTL_BINARY=/usr/lib/postgresql/16/bin/pg_ctl

# The path to your PostgreSQL data directory. You may need to adjust this
# path to match your PostgreSQL installation. You can also run
# `SHOW data_directory;` from PostgreSQL to find your data directory
PG_DATA_DIRECTORY=/etc/postgresql/16/main

# Promote the PostgreSQL database and allow read/write operations
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

보조 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
보조 사이트의 각 Rails 노드에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 보조 사이트를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공하면 보조 사이트가 이제 기본 사이트로 승격된 것입니다.

(선택사항) 기본 도메인 DNS 레코드 업데이트#

보조 사이트에 SSH로 접속하고 루트로 로그인합니다:
```
sudo -i
```
기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드를 보조 사이트로 업데이트한 후 보조 사이트의 /etc/gitlab/gitlab.rb를 편집하여 새 URL을 반영합니다:
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
[!note] external_url 변경은 보조 DNS 레코드가 여전히 유지되는 한 이전 보조 URL을 통한 액세스를 방지하지 않습니다.
보조의 SSL 인증서 업데이트:
- Let's Encrypt 통합을 사용하는 경우 인증서가 자동으로 업데이트됩니다.
- 보조의 인증서를 수동으로 설정한 경우 기본에서 보조로 인증서를 복사합니다. 기본에 액세스할 수 없는 경우 새 인증서를 발급하고 기본 및 보조 URL이 모두 주체 대체 이름에 포함되어 있는지 확인합니다. 다음으로 확인할 수 있습니다:
```
/opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
    -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
```
변경 사항을 적용하기 위해 보조 사이트를 재구성합니다:
```
gitlab-ctl reconfigure
```
새로 승격된 기본 사이트 URL을 업데이트하기 위해 다음 명령을 실행합니다:
```
gitlab-rake gitlab:geo:update_primary_node_url
```
이 명령은 /etc/gitlab/gitlab.rb에 정의된 변경된 external_url 구성을 사용합니다.
새로 승격된 기본에 해당 URL을 사용하여 연결할 수 있는지 확인합니다. 기본 도메인의 DNS 레코드를 업데이트했다면 이전 DNS 레코드의 TTL에 따라 이 변경이 아직 전파되지 않았을 수 있습니다.

(선택사항) 승격된 기본 사이트에 보조 Geo 사이트 추가#

새 보조 사이트를 온라인으로 가져오려면 Geo 설정 지침을 따르세요.

다중 보조 구성에서 보조 Geo 복제본 승격#

보조 사이트가 두 개 이상 있고 그 중 하나를 승격해야 하는 경우 단일 보조 구성에서 보조 Geo 사이트 승격을 따른 후 두 가지 추가 단계가 필요합니다.

1단계. 하나 이상의 보조 사이트를 제공하도록 새 기본 사이트 준비#

새 기본 사이트에 SSH로 접속하고 루트로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집합니다:

## Enable a Geo Primary role (if you haven't yet)
roles ['geo_primary_role']

##
# Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
# public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

# Every secondary site needs to have its own slot so specify the number of secondary sites you're going to have
# postgresql['max_replication_slots'] = 1 # Set this to be the number of Geo secondary nodes if you have more than one

##
## Disable automatic database migrations temporarily
## (until PostgreSQL is restarted and listening on the private address).
##
gitlab_rails['auto_migrate'] = false

(이 설정에 대한 자세한 내용은 기본 서버 구성을 참조하세요)

파일을 저장하고 데이터베이스 수신 변경 및 복제 슬롯 변경이 적용되도록 GitLab을 재구성합니다:
```
gitlab-ctl reconfigure
```
PostgreSQL 변경 사항을 적용하기 위해 재시작합니다:
```
gitlab-ctl restart postgresql
```
PostgreSQL이 재시작되고 개인 주소에서 수신 대기 중이므로 마이그레이션을 다시 활성화합니다.

/etc/gitlab/gitlab.rb를 편집하고 구성을 true로 변경합니다:
```
gitlab_rails['auto_migrate'] = true
```
파일을 저장하고 GitLab을 재구성합니다:
```
gitlab-ctl reconfigure
```

2단계. 복제 프로세스 시작#

기존 보조 사이트의 데이터베이스에 데이터가 채워져 있으므로 다음과 같은 메시지가 표시될 수 있습니다:

Found data inside the gitlabhq_production database! If you are sure you are in the secondary server, override with --force

적절한 보조 사이트에 있는지 확인한 후 --force로 복제를 시작합니다.

Warning

--force를 사용하면 해당 보조 서버의 데이터베이스에 있는 모든 기존 데이터가 삭제됩니다.

GitLab Helm 차트에서 보조 Geo 클러스터 승격#

1단계. 기본 클러스터 영구 비활성화#

Warning

기본 Kubernetes 클러스터에 액세스할 수 있는 경우 연결하여 GitLab webservice 및 Sidekiq 파드를 비활성화합니다:

kubectl --namespace gitlab scale deploy gitlab-geo-webservice-default --replicas=0
kubectl --namespace gitlab scale deploy gitlab-geo-sidekiq-all-in-1-v1 --replicas=0

기본 Kubernetes 클러스터에 액세스할 수 없는 경우 클러스터를 오프라인 상태로 전환하고 사용 가능한 모든 수단을 통해 재시작을 방지합니다. 다음을 수행해야 할 수 있습니다:
- 로드 밸런서 재구성.
- DNS 레코드 변경(예: 기본 DNS 레코드를 보조 사이트로 지정하여 기본 사이트 사용 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 기본 사이트에서 오브젝트 스토리지 권한 취소.
- 머신 물리적 연결 해제.

2단계. 클러스터 외부의 모든 보조 사이트 노드 승격#

Warning

Linux 패키지를 사용하여 보조 Kubernetes 클러스터 외부의 각 노드(PostgreSQL 또는 Gitaly 등)에 SSH로 접속하여 다음 명령 중 하나를 실행합니다:
- Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Kubernetes 클러스터 외부의 보조 사이트 노드를 기본으로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```

toolbox 파드를 찾습니다:

kubectl --namespace gitlab get pods -lapp=toolbox

보조 사이트를 승격합니다:
```
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:set_secondary_as_primary
```
태스크의 동작을 수정하기 위해 환경 변수를 제공할 수 있습니다. 사용 가능한 변수는 다음과 같습니다:

이름 기본값 설명

ENABLE_SILENT_MODE false true이면 승격 전에 사일런트 모드를 활성화합니다(GitLab 16.4 이상)

이름	기본값	설명
`ENABLE_SILENT_MODE`	`false`	`true`이면 승격 전에 사일런트 모드를 활성화합니다(GitLab 16.4 이상)

3단계. 보조 클러스터 승격#

기존 클러스터 구성을 업데이트합니다.

Helm으로 기존 구성을 가져올 수 있습니다:
```
helm --namespace gitlab get values gitlab-geo > gitlab.yaml
```
기존 구성에는 다음과 유사한 Geo 섹션이 포함됩니다:
```
geo:
   enabled: true
   role: secondary
   nodeName: secondary.example.com
   psql:
      host: geo-2.db.example.com
      port: 5431
      password:
         secret: geo
         key: geo-postgresql-password
```
보조 클러스터를 기본 클러스터로 승격하려면 role: secondary를 role: primary로 업데이트합니다.

클러스터가 기본 사이트로 유지되면 geo 아래의 전체 psql 섹션을 반드시 제거해야 합니다. 이는 추적 데이터베이스를 참조하며, 그대로 두면 새 보조 사이트가 추가될 때 인증을 끊는 경로 등록 문제를 일으킬 수 있습니다.

새 구성으로 클러스터를 업데이트합니다:
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 보조 사이트에 사용된 URL을 사용하여 새로 승격된 기본 사이트에 연결할 수 있는지 확인합니다.
성공! 보조 사이트가 이제 기본 사이트로 승격되었습니다.

4단계. (선택사항) OpenBao HA 클러스터 승격#

GitLab Secrets Manager가 활성화된 경우 Kubernetes 클러스터를 승격한 후 다음 단계에 따라 OpenBao 고가용성(HA) 클러스터를 승격합니다.

OpenBao 파드 재시작#

PostgreSQL 복제본이 기본으로 승격된 후 OpenBao 파드를 재시작하여 이제 쓰기 가능한 데이터베이스에 다시 연결되도록 합니다:

kubectl --namespace gitlab rollout restart deployment -l app=openbao

(선택사항) JWT 인증 구성#

기본 도메인의 DNS 레코드를 보조 사이트로 업데이트한 경우 이 단계를 건너뜁니다.

JWT 인증을 재구성하려면 루트 토큰이 필요합니다. 복구 키를 사용하여 루트 토큰을 생성합니다.

복구 키에서 루트 토큰 생성.

루트 토큰이 있으면 JWT 인증 마운트가 보조 도메인을 가리키도록 재구성합니다. 구성 세부 정보는 Geo 구성을 참조하세요.

필요한 경우 언실 시크릿 복원#

보조 클러스터의 언실 키는 기본 클러스터의 언실 키와 동일해야 합니다. 그렇지 않으면 OpenBao가 보조 사이트에서 볼트를 언실할 수 없습니다.

불일치가 있는 경우 시크릿 백업에서 보조 클러스터의 gitlab-openbao-unseal 시크릿을 복원한 후 OpenBao 파드를 재시작합니다:

kubectl --namespace gitlab rollout restart deployment -l app=openbao

OpenBao 정상 작동 확인#

모든 OpenBao 파드가 실행 중인지 확인합니다:
```
kubectl --namespace gitlab get pods -l app=openbao
```
Secrets Manager 변수를 사용하는 CI 파이프라인을 실행하여 OpenBao 통합을 테스트합니다.

문제 해결#

이 섹션은 다른 위치로 이동되었습니다.

재해 복구 (Geo)

선택적 동기화가 활성화된 보조 사이트#

gitlab-cluster.json 파일#

파일 구조#

파일 제거#

단일 보조 구성에서 보조 Geo 사이트 승격#

가능하면 복제가 완료될 때까지 기다리기#

1단계. 기본 사이트 영구 비활성화#

2단계. 보조 사이트 승격#

단일 노드에서 실행 중인 보조 사이트 승격#

3단계. 이전 보조의 추적 데이터베이스 제거#

여러 노드와 단일 보조 사이트가 있는 보조 사이트 승격#

Patroni 대기 클러스터가 있는 보조 사이트 승격#

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격#

(선택사항) 기본 도메인 DNS 레코드 업데이트#

(선택사항) 승격된 기본 사이트에 보조 Geo 사이트 추가#

다중 보조 구성에서 보조 Geo 복제본 승격#

1단계. 하나 이상의 보조 사이트를 제공하도록 새 기본 사이트 준비#

2단계. 복제 프로세스 시작#

GitLab Helm 차트에서 보조 Geo 클러스터 승격#

1단계. 기본 클러스터 영구 비활성화#

2단계. 클러스터 외부의 모든 보조 사이트 노드 승격#

3단계. 보조 클러스터 승격#

4단계. (선택사항) OpenBao HA 클러스터 승격#

OpenBao 파드 재시작#

(선택사항) JWT 인증 구성#

필요한 경우 언실 시크릿 복원#

OpenBao 정상 작동 확인#

문제 해결#

선택적 동기화가 활성화된 보조 사이트#

gitlab-cluster.json 파일#

파일 구조#

파일 제거#

단일 보조 구성에서 보조 Geo 사이트 승격#

가능하면 복제가 완료될 때까지 기다리기#

1단계. 기본 사이트 영구 비활성화#

2단계. 보조 사이트 승격#

단일 노드에서 실행 중인 보조 사이트 승격#

3단계. 이전 보조의 추적 데이터베이스 제거#

여러 노드와 단일 보조 사이트가 있는 보조 사이트 승격#

Patroni 대기 클러스터가 있는 보조 사이트 승격#

외부 PostgreSQL 데이터베이스가 있는 보조 사이트 승격#

(선택사항) 기본 도메인 DNS 레코드 업데이트#

(선택사항) 승격된 기본 사이트에 보조 Geo 사이트 추가#

다중 보조 구성에서 보조 Geo 복제본 승격#

1단계. 하나 이상의 보조 사이트를 제공하도록 새 기본 사이트 준비#

2단계. 복제 프로세스 시작#

GitLab Helm 차트에서 보조 Geo 클러스터 승격#

1단계. 기본 클러스터 영구 비활성화#

2단계. 클러스터 외부의 모든 보조 사이트 노드 승격#

3단계. 보조 클러스터 승격#

4단계. (선택사항) OpenBao HA 클러스터 승격#

OpenBao 파드 재시작#

(선택사항) JWT 인증 구성#

필요한 경우 언실 시크릿 복원#

OpenBao 정상 작동 확인#

문제 해결#

`gitlab-cluster.json` 파일#

`gitlab-cluster.json` 파일#