단일 세컨더리 구성에서 세컨더리 Geo 사이트 프로모션
다중 보조 구성에서 보조 Geo 레플리카 프로모션
- 단계 1. 새 기본 사이트를 설치하여 하나 이상의 보조 사이트 제공할 준비
- 단계 2. 복제 프로세스 시작
GitLab Helm 차트에서 보조 Geo 클러스터 프로모션
문제 해결

재해 복구 (지오)

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

Geo는 데이터베이스, Git 저장소 및 일부 기타 에셋을 복제하지만, 제한 사항이 있습니다.

경고: 멀티 세컨더리 구성은 모든 비 프로모션된 세컨더리를 완전히 재동기화하고 재구성해야 하며, 다운 타임을 유발합니다.

단일 세컨더리 구성에서 세컨더리 Geo 사이트 프로모션

자동으로 Geo 레플리카를 프로모션하고 장애 조치를 수행할 수 없지만, 머신에 root 액세스가 있다면 수동으로 프로모션할 수 있습니다.

이 프로세스는 세컨더리 Geo 사이트를 프라이머리 사이트로 프로모션합니다. 지리적 재해 복구를 최대한 빨리 수행하려면이 지침을 따른 후 즉시 새 세컨더리 사이트를 추가해야 합니다.

단계 1. 가능한 경우 복제가 완료되기를 기다리십시오

세컨더리 사이트가 아직 프라이머리 사이트에서 데이터를 복제하고 있는 경우, 계획된 장애 조치 문서를 가능한 한 정확히 따라서 불필요한 데이터 손실을 피하도록 해야 합니다.

단계 2. 프라이머리 사이트 영구적으로 비활성화

경고: 프라이머리 사이트가 오프라인 상태가 되면, 프라이머리 사이트에 저장된 데이터가 세컨더리 사이트로 복제되지 않은 경우가 있을 수 있습니다. 이 경우 계속 진행한다면 이러한 데이터는 손실로 간주해야 합니다.

프라이머리 사이트에서 정전이 발생한 경우, GitLab 인스턴스에서 두 개 이상의 다른 위치에 쓰기가 발생하여 복구 작업이 복잡해지는 분산 뇌전 상황을 피하기 위해 가능한 모든 것을 수행해야 합니다. 그러므로 장애 조치를 위해 프라이머리 사이트를 비활성화해야 합니다.

SSH 액세스 권한이 있는 경우:
1. 프라이머리 사이트에 SSH하여 GitLab을 중지하고 비활성화합니다:
```
sudo gitlab-ctl stop
```
2. 서버가 예기치 않게 다시 부팅되면 GitLab이 다시 시작되지 않도록 합니다:
```
sudo systemctl disable gitlab-runsvdir
```
프라이머리 사이트에 SSH 액세스 권한이 없는 경우, 서버를 오프라인 상태로 만들고 재부팅을 방지합니다. 다음과 같은 수단을 통해 이를 수행해야 할 수 있습니다.
- 로드 밸런서 재구성.
- DNS 레코드 변경 (예: 프라이머리 DNS 레코드를 세컨더리 사이트로 지정하여 프라이머리 사이트의 사용을 중지).
- 가상 서버 중지.
- 방화벽을 통한 트래픽 차단.
- 프라이머리 사이트에서 객체 저장 권한 취소.
- 머신의 물리적 분리.
프라이머리 도메인 DNS 레코드를 업데이트할 계획이 있다면, DNS 변경이 빠르게 전파되도록 TTL을 낮게 유지하는 것이 좋습니다.
참고: 본 프로세스 중에는 프라이머리 사이트의 /etc/gitlab/gitlab.rb 파일이 자동으로 세컨더리 사이트에 복사되지 않습니다. 그러므로 나중에 필요한 값들을 복원할 수 있도록 프라이머리의 /etc/gitlab/gitlab.rb 파일을 백업해 두어야 합니다.

단계 3. 세컨더리 사이트 프로모션

세컨더리를 프로모션할 때 다음 사항을 주목하십시오:

세컨더리 사이트가 일시 중지되었을 때, 프로모션을 수행하면 이전 상태로의 시점 복원이 이루어집니다. 세컨더리가 일시 중지된 동안 프라이머리에서 생성된 데이터는 손실됩니다.
이 시점에 새 세컨더리를 추가해서는 안 됩니다. 새 세컨더리를 추가하려면 세컨더리를 프라이머리로 프로모션하는 전체 프로세스를 완료한 후 수행해야 합니다.
이 프로세스 중에 ActiveRecord::RecordInvalid: Validation failed: Name has already been taken 오류 메시지가 발생하면 더 많은 정보를 원하시면 문제 해결 팁을 참조하십시오.
별도의 URL을 사용하는 경우 프라이머리 도메인 DNS를 새로운 프라이머리 사이트로 지정해야 합니다. 그렇지 않으면 Runner는 새로 프로모션된 사이트에 다시 등록해야 하며, Git 리모트, 북마크 및 외부 통합을 모두 업데이트해야 합니다.
위치 인식 DNS를 사용하는 경우, 이전 프라이머리가 DNS 항목에서 제거된 후 러너가 자동으로 새 프라이머리에 연결해야 합니다.
이전 프라이머리에 연결된 러너가 다시 연결되지 않을 것으로 예상된다면 다음을 수행해야 합니다:
- UI를 통해:
  1. 왼쪽 사이드바에서 Admin을 선택합니다.
  2. CI/CD > Runners를 선택하여 그들을 제거합니다.
- Runners API를 사용합니다.

단일 노드에서 실행 중인 세컨더리 사이트 프로모션

세컨더리 사이트에 SSH로 연결하여 다음을 실행합니다:
- 세컨더리 사이트를 프라이머리로 프로모션:
```
sudo gitlab-ctl geo promote
```
- 추가 확인없이 세컨더리 사이트를 프라이머리로 프로모션:
```
sudo gitlab-ctl geo promote --force
```
이전에 세컨더리 사이트에 사용되었던 URL을 사용하여 새로 프로모션된 프라이머리 사이트에 연결할 수 있는지 확인합니다.
성공적으로 프로모션된 세컨더리 사이트는 이제 프라이머리 사이트로 프로모션되었습니다.

다중 노드에서 실행 중인 세컨더리 사이트 프로모션

세컨더리 사이트의 모든 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을 사용하여 새로 프로모션된 프라이머리 사이트에 연결할 수 있는지 확인합니다.
성공적으로 프로모션된 세컨더리 사이트는 이제 프라이머리 사이트로 프로모션되었습니다.

Patroni Standby Cluster를 사용한 복제 사이트 프로모션

Secondary 사이트의 모든 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 연결한 후 다음 명령 중 하나를 실행합니다.
- Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
Secondary 사이트의 각 레일 노드에 SSH로 연결한 후 다음 명령 중 하나를 실행합니다.
- Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 Secondary 사이트에 사용한 URL을 사용하여 새로 승격된 프라이머리 사이트에 연결할 수 있는지 확인합니다.
성공하면, Secondary 사이트가 이제 프라이머리 사이트로 승격되었습니다.

외부 PostgreSQL 데이터베이스를 사용한 Secondary 사이트 프로모션

gitlab-ctl geo promote 명령은 외부 PostgreSQL 데이터베이스와 함께 사용할 수 있습니다. 이 경우 Secondary 사이트와 관련된 레플리카 데이터베이스를 수동으로 먼저 프로모션해야 합니다.

Secondary 사이트와 관련된 레플리카 데이터베이스를 프로모션합니다. 이렇게 하면 데이터베이스가 읽기-쓰기로 설정됩니다. 데이터베이스가 호스팅된 위치에 따라 절차가 다릅니다:

Amazon RDS
Azure PostgreSQL
Google Cloud SQL

기타 외부 PostgreSQL 데이터베이스의 경우, 예를 들어 /tmp/geo_promote.sh와 같이 Secondary 사이트에 다음 스크립트를 저장하고 환경과 일치하도록 연결 매개변수를 수정한 후 레플리카를 프로모션하도록 실행합니다:

#!/bin/bash

PG_SUPERUSER=postgres

# pg_ctl 바이너리의 경로입니다. PostgreSQL 설치에 맞게 이 경로를 조정해야 할 수 있습니다.
PG_CTL_BINARY=/usr/lib/postgresql/10/bin/pg_ctl

# PostgreSQL 데이터 디렉토리의 경로입니다. PostgreSQL 설치에 맞게 이 경로를 조정해야 할 수 있습니다. PostgreSQL에서 데이터 디렉토리를 찾으려면 `SHOW data_directory;`를 실행할 수 있습니다.
PG_DATA_DIRECTORY=/etc/postgresql/10/main

# PostgreSQL 데이터베이스를 프로모션하고 읽기/쓰기 작업을 허용합니다.
sudo -u $PG_SUPERUSER $PG_CTL_BINARY -D $PG_DATA_DIRECTORY promote

Secondary 사이트의 각 Sidekiq, PostgreSQL 및 Gitaly 노드에 SSH로 연결한 후 다음 명령 중 하나를 실행합니다.
- Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
Secondary 사이트의 각 레일 노드에 SSH로 연결한 후 다음 명령 중 하나를 실행합니다.
- Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote
```
- 추가 확인 없이 Secondary 사이트를 프라이머리로 승격하려면:
```
sudo gitlab-ctl geo promote --force
```
이전에 Secondary 사이트에 사용한 URL을 사용하여 새로 승격된 프라이머리 사이트에 연결할 수 있는지 확인합니다.
성공하면, Secondary 사이트가 이제 프라이머리 사이트로 승격되었습니다.

Step 4. (선택 사항) 프라이머리 도메인 DNS 레코드 업데이트

프라이머리 도메인의 DNS 레코드를 Secondary 사이트로 지정합니다. 이를 통해 프라이머리 도메인에 대한 모든 참조를 업데이트할 필요가 없어집니다. 예를 들어 Git 리모트 및 API URL 변경 등이 있습니다.

Secondary 사이트에 SSH로 연결하고 root로 로그인합니다.
```
sudo -i
```
프라이머리 도메인의 DNS 레코드를 업데이트합니다. 프라이머리 도메인의 DNS 레코드를 Secondary 사이트로 업데이트한 후, /etc/gitlab/gitlab.rb에서 새 URL을 반영하도록 Secondary 사이트의 설정을 편집합니다:
```
# 기존 external_url 구성 변경
external_url 'https://<new_external_url>'
```
참고: external_url을 변경해도, 이전 Secondary URL의 DNS 레코드가 여전히 유지되는 한, 여전히 이전 Secondary URL을 통한 액세스를 방지하지 않습니다.
Secondary의 SSL 인증서를 업데이트합니다.
- 만약 Let’s Encrypt 통합을 사용한다면, 인증서는 자동으로 업데이트됩니다.
- 수동으로 설정했다면(https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-https-manually), Secondary의 인증서를 Primary에서 Secondary로 복사합니다. Primary에 액세스할 수 없다면, 새 인증서를 발급하고 이 Primary 및 Secondary 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
```
변경사항이 적용되도록 Secondary 사이트를 다시 구성합니다:
```
gitlab-ctl reconfigure
```
아래 명령을 실행하여 새롭게 승격된 프라이머리 사이트의 URL을 업데이트합니다:
```
gitlab-rake geo:update_primary_node_url
```
이 명령은 /etc/gitlab/gitlab.rb에서 정의된 변경된 external_url 구성을 사용합니다.
변경된 DNS 레코드가 아직 이전 DNS 레코드 TTL에 따라 전파되지 않았을 수 있으므로 이 명령을 실행하여 새로 승격된 프라이머리에 연결할 수 있는지 확인합니다.

단계 5. (선택 사항) 보조 Geo 사이트를 프로모션된 기본 사이트에 추가하기

위의 절차를 사용하여 보조 사이트를 기본 사이트로 프로모션하는 것은 새로운 기본 사이트에서 Geo를 활성화하지 않습니다.

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

단계 6. 이전 보조 추적 데이터베이스 제거

모든 보조에는 기본에서 모든 항목의 동기화 상태를 저장하는 특수 추적 데이터베이스가 있습니다. 보조가 이미 프로모션되었기 때문에 추적 데이터베이스의 데이터는 더 이상 필요하지 않습니다.

다음 명령을 사용하여 데이터를 제거할 수 있습니다.

sudo rm -rf /var/opt/gitlab/geo-postgresql

gitlab.rb 파일에서 geo_secondary[] 구성 옵션이 활성화되어 있다면 주석 처리하거나 제거한 후 GitLab 재구성을 위해 변경 사항이 적용되도록 하세요.

다중 보조 구성에서 보조 Geo 레플리카 프로모션

여러 개의 보조 사이트가 있는 경우 하나를 프로모션해야 하는 경우, 단일 보조 구성에서 보조 Geo 사이트 프로모션을 따른 후 두 가지 추가 단계가 필요합니다.

단계 1. 새 기본 사이트를 설치하여 하나 이상의 보조 사이트 제공할 준비

새로운 기본 사이트에 SSH로 로그인하세요. root로 로그인하세요:
```
sudo -i
```

/etc/gitlab/gitlab.rb 파일을 편집하세요:

## Geo Primary 역할을 활성화하세요 (아직 활성화하지 않은 경우)
roles ['geo_primary_role']

##
# 기본 및 보조 IP에서의 PostgreSQL 클라이언트 인증을 허용하세요. 이러한 IP는
# 예를 들어 CIDR 형식의 공용 또는 VPC 주소일 수 있습니다. ['198.51.100.1/32', '198.51.100.2/32']와 같이
##
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

# 각 보조 사이트에는 자체 슬롯이 있어야 하므로 보조 사이트의 수를 지정하세요
# postgresql['max_replication_slots'] = 1 # 보조 노드가 하나 이상인 경우 Geo 보조 노드의 수로 설정해야 합니다.

##
## 자동 데이터베이스 마이그레이션 일시적으로 비활성화하세요
## (PostgreSQL이 재시작되고 개인 주소에서 수신 대기 중일 때까지).
##
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. 복제 프로세스 시작

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

GitLab Helm 차트에서 보조 Geo 클러스터 프로모션

클라우드 네이티브 Geo 배포를 업데이트할 때, 보조 쿠버네티스 클러스터 외부의 모든 노드를 업데이트하는 프로세스는 클라우드 네이티브 방법과 다르지 않습니다. 따라서 자세한 내용은 항상 단일 보조 구성에서 보조 Geo 사이트 프로모션을 참고하세요.

아래 섹션에서는 gitlab 네임스페이스를 사용한다고 가정합니다. 클러스터 설정 시 다른 네임스페이스를 사용한 경우 --namespace gitlab을 해당 네임스페이스로 교체해야 합니다.

단계 1. 기본 클러스터를 영구적으로 비활성화

경고: 기본 사이트가 오프라인 상태가 되면 기본 사이트에 저장된 데이터 중 보조 사이트에 동기화되지 않은 데이터가 있을 수 있습니다. 이 경우 진행하면 해당 데이터는 손실된 것으로 취급되어야 합니다.

기본 사이트에 장애가 발생하는 경우, 두 개의 다른 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. 클러스터 외부의 모든 보조 사이트 노드 프로모션

경고: 보조 사이트가 일시 중지된 상태라면, 이는 마지막 알려진 상태로의 시점 복원을 수행합니다. 보조가 일시 중지된 동안 기본에서 생성된 데이터는 손실됩니다.

클러스터 외의 각 노드 (예: PostgreSQL 또는 Gitaly)에 대해, Linux 패키지를 사용하여 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 geo:set_secondary_as_primary

환경 변수를 제공하여 작업의 동작을 수정할 수 있습니다. 사용 가능한 변수는 다음과 같습니다:

이름	기본값	설명
`ENABLE_SILENT_MODE`	`false`	(GitLab 16.4 이후) 프로모션 전 Silent Mode를 활성화하는지 여부

단계 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로 업데이트합니다.
클러스터가 기본 사이트로 유지되는 경우 전체 psql 섹션을 제거할 수 있으며, 이는 추적 데이터베이스를 참조하며 클러스터가 기본 사이트로 활동하는 동안 무시됩니다.
새 구성으로 클러스터를 업데이트합니다.
```
helm upgrade --install --version <current Chart version> gitlab-geo gitlab/gitlab --namespace gitlab -f gitlab.yaml
```
이전에 보조로 사용했던 URL을 사용하여 새로 홍보된 기본에 연결할 수 있는지 확인합니다.
성공! 보조 클러스터가 이제 기본으로 홍보되었습니다.

문제 해결

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

재해 복구 (지오)

단일 세컨더리 구성에서 세컨더리 Geo 사이트 프로모션

단계 1. 가능한 경우 복제가 완료되기를 기다리십시오

단계 2. 프라이머리 사이트 영구적으로 비활성화

단계 3. 세컨더리 사이트 프로모션

단일 노드에서 실행 중인 세컨더리 사이트 프로모션

다중 노드에서 실행 중인 세컨더리 사이트 프로모션

Patroni Standby Cluster를 사용한 복제 사이트 프로모션

외부 PostgreSQL 데이터베이스를 사용한 Secondary 사이트 프로모션

Step 4. (선택 사항) 프라이머리 도메인 DNS 레코드 업데이트

단계 5. (선택 사항) 보조 Geo 사이트를 프로모션된 기본 사이트에 추가하기

단계 6. 이전 보조 추적 데이터베이스 제거

다중 보조 구성에서 보조 Geo 레플리카 프로모션

단계 1. 새 기본 사이트를 설치하여 하나 이상의 보조 사이트 제공할 준비

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

GitLab Helm 차트에서 보조 Geo 클러스터 프로모션

단계 1. 기본 클러스터를 영구적으로 비활성화

단계 2. 클러스터 외부의 모든 보조 사이트 노드 프로모션

단계 3. 보조 클러스터 홍보하기

문제 해결

도움말

기능 사용 가능성과 제품 평가판

도움받기