재해 복구 (Geo)

요약

Geo는 데이터베이스와 Git 리포지터리, 그 외 자산을 복제합니다. 선택적 동기화가 활성화된 보조 사이트를 승격하면 해당 보조 사이트로 복제되지 않은 모든 데이터가 영구적으로 손실됩니다. gitlab-ctl geo promote로 보조 사이트를 기본 사이트로 승격하면, 이 명령은 실행되는 각 노드에 /etc/gitlab/gitlab-cluster.json 파일을 자동으로 만듭니다.

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이 reconfigure 프로세스와 상호작용하는 방식에 대한 기술적 상세는 Omnibus reconfigure 문서에서 확인할 수 있습니다.

단일 보조 구성에서 보조 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 promotion fails with read-only transaction error or timeout after unexpected primary shutdown.
이 시점에 새 보조 사이트를 추가하지 않아야 합니다. 새 보조 사이트를 추가하려면 보조 사이트를 기본 사이트로 승격하는 전체 절차를 모두 마친 뒤에 진행합니다.
이 절차 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 표시된다면 자세한 내용은 다음 문제 해결 안내를 참고합니다.
별도의 URL을 사용한다면 기본 도메인 DNS가 새로 승격된 사이트를 가리키도록 해야 합니다. 그렇지 않으면 러너를 새로 승격된 사이트에 다시 등록해야 하고, 모든 Git 원격과 북마크, 외부 통합을 업데이트해야 합니다.
위치 인식 DNS를 사용한다면 이전 기본 사이트가 DNS 항목에서 제거된 뒤 러너가 새 기본 사이트에 자동으로 연결됩니다.
기본 사이트가 중단된 뒤 보조 사이트에서 gitlab-ctl promotion-preflight-checks를 실행해 Geo 동기화 상태를 확인하고 최종 검증을 수행합니다.
이전 기본 사이트에 연결된 러너가 돌아오지 않을 것으로 예상된다면 해당 러너를 제거해야 합니다:
- UI에서 제거하는 방법:
  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. CI/CD > Runners를 선택하고 러너를 제거합니다.
- 러너 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로 접속해 root로 로그인합니다:
```
sudo -i
```
기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드가 보조 사이트를 가리키도록 업데이트한 뒤에는 보조 사이트의 /etc/gitlab/gitlab.rb를 편집해 새 URL을 반영합니다:
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
[!note] 보조 사이트의 DNS 레코드가 그대로 남아 있다면 external_url을 변경해도 기존 보조 URL을 통한 액세스가 차단되지는 않습니다.
보조 사이트의 SSL 인증서를 업데이트합니다:
- Let's Encrypt 통합을 사용한다면 인증서가 자동으로 업데이트됩니다.
- 보조 사이트의 인증서를 직접 설정했다면 기본 사이트의 인증서를 보조 사이트로 복사합니다. 기본 사이트에 액세스할 수 없다면 새 인증서를 발급하고, 주체 대체 이름에 기본 URL과 보조 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로 접속해 root로 로그인합니다:
```
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 Pod를 비활성화합니다:

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

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

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

toolbox Pod를 찾습니다:

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이면 승격 전에 사일런트 모드를 활성화합니다

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

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 섹션 전체를 제거해야 합니다. 이 섹션은 추적 데이터베이스를 가리킵니다. 그대로 두면 애플리케이션이 부팅 시 해당 노드를 보조로 인식하고, 통합 URL로 새 보조 사이트를 추가할 때 인증을 깨뜨리는 경로 등록 문제가 발생합니다.

새 구성으로 클러스터를 업데이트합니다:
```
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 Pod 재시작#

PostgreSQL 복제본이 기본으로 승격된 뒤에는 데이터베이스가 쓰기 가능해졌으므로 OpenBao Pod를 재시작해 데이터베이스에 다시 연결하도록 합니다:

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

JWT 인증 구성#

기본 도메인이 승격된 보조 사이트를 가리키도록 DNS 레코드를 업데이트합니다. OpenBao는 다른 도메인을 사용하는 보조 사이트로의 페일오버를 지원하지 않습니다. 자세한 내용은 Geo 배포를 참고합니다.

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

보조 클러스터의 언실 키는 기본 키의 언실 키와 같아야 하며, 그렇지 않으면 OpenBao가 보조 사이트에서 vault를 언실할 수 없습니다.

불일치가 있다면 시크릿 백업에서 보조 클러스터의 gitlab-openbao-unseal 시크릿을 복원한 다음 OpenBao Pod를 재시작합니다:

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

OpenBao 정상 작동 확인#

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

문제 해결#

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

재해 복구 (Geo)

GitLab v19.4

Tier: Premium, Ultimate
Offering: GitLab Self-Managed

원문 보기

번역일: 2026-09-18

요약

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이 reconfigure 프로세스와 상호작용하는 방식에 대한 기술적 상세는 Omnibus reconfigure 문서에서 확인할 수 있습니다.

단일 보조 구성에서 보조 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 promotion fails with read-only transaction error or timeout after unexpected primary shutdown.
이 시점에 새 보조 사이트를 추가하지 않아야 합니다. 새 보조 사이트를 추가하려면 보조 사이트를 기본 사이트로 승격하는 전체 절차를 모두 마친 뒤에 진행합니다.
이 절차 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 표시된다면 자세한 내용은 다음 문제 해결 안내를 참고합니다.
별도의 URL을 사용한다면 기본 도메인 DNS가 새로 승격된 사이트를 가리키도록 해야 합니다. 그렇지 않으면 러너를 새로 승격된 사이트에 다시 등록해야 하고, 모든 Git 원격과 북마크, 외부 통합을 업데이트해야 합니다.
위치 인식 DNS를 사용한다면 이전 기본 사이트가 DNS 항목에서 제거된 뒤 러너가 새 기본 사이트에 자동으로 연결됩니다.
기본 사이트가 중단된 뒤 보조 사이트에서 gitlab-ctl promotion-preflight-checks를 실행해 Geo 동기화 상태를 확인하고 최종 검증을 수행합니다.
이전 기본 사이트에 연결된 러너가 돌아오지 않을 것으로 예상된다면 해당 러너를 제거해야 합니다:
- UI에서 제거하는 방법:
  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. CI/CD > Runners를 선택하고 러너를 제거합니다.
- 러너 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을 재구성해 변경 사항을 적용합니다.

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

보조 사이트의 모든 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로 접속해 root로 로그인합니다:
```
sudo -i
```
기본 도메인의 DNS 레코드를 업데이트합니다. 기본 도메인의 DNS 레코드가 보조 사이트를 가리키도록 업데이트한 뒤에는 보조 사이트의 /etc/gitlab/gitlab.rb를 편집해 새 URL을 반영합니다:
```
# Change the existing external_url configuration
external_url 'https://<new_external_url>'
```
[!note] 보조 사이트의 DNS 레코드가 그대로 남아 있다면 external_url을 변경해도 기존 보조 URL을 통한 액세스가 차단되지는 않습니다.
보조 사이트의 SSL 인증서를 업데이트합니다:
- Let's Encrypt 통합을 사용한다면 인증서가 자동으로 업데이트됩니다.
- 보조 사이트의 인증서를 직접 설정했다면 기본 사이트의 인증서를 보조 사이트로 복사합니다. 기본 사이트에 액세스할 수 없다면 새 인증서를 발급하고, 주체 대체 이름에 기본 URL과 보조 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 복제본 승격#

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

새 기본 사이트에 SSH로 접속해 root로 로그인합니다:
```
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 Pod를 비활성화합니다:

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

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

toolbox Pod를 찾습니다:

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이면 승격 전에 사일런트 모드를 활성화합니다

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

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 섹션 전체를 제거해야 합니다. 이 섹션은 추적 데이터베이스를 가리킵니다. 그대로 두면 애플리케이션이 부팅 시 해당 노드를 보조로 인식하고, 통합 URL로 새 보조 사이트를 추가할 때 인증을 깨뜨리는 경로 등록 문제가 발생합니다.

새 구성으로 클러스터를 업데이트합니다:
```
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 Pod 재시작#

PostgreSQL 복제본이 기본으로 승격된 뒤에는 데이터베이스가 쓰기 가능해졌으므로 OpenBao Pod를 재시작해 데이터베이스에 다시 연결하도록 합니다:

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

JWT 인증 구성#

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

보조 클러스터의 언실 키는 기본 키의 언실 키와 같아야 하며, 그렇지 않으면 OpenBao가 보조 사이트에서 vault를 언실할 수 없습니다.

불일치가 있다면 시크릿 백업에서 보조 클러스터의 gitlab-openbao-unseal 시크릿을 복원한 다음 OpenBao Pod를 재시작합니다:

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

OpenBao 정상 작동 확인#

모든 OpenBao Pod가 실행 중인지 확인합니다:
```
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 Pod 재시작#

JWT 인증 구성#

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

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 Pod 재시작#

JWT 인증 구성#

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

OpenBao 정상 작동 확인#

문제 해결#

`gitlab-cluster.json` 파일#

`gitlab-cluster.json` 파일#