Geo 복제 문제 해결

Tier: Premium, Ultimate Offering: Self-Managed형

PostgreSQL 데이터베이스 복제 오류 수정

다음 섹션에서는 복제 오류 메시지를 해결하는 문제 해결 단계를 설명합니다(데이터베이스 복제 작동 여부를 나타내는 Database replication working? ... no가 geo:check 출력에 표시됨).

비활성 복제 슬롯 제거

복제 슬롯은 복제 클라이언트(보조 사이트)가 해당 슬롯과의 연결을 해제할 때 ‘비활성’으로 표시됩니다. 비활성 복제 슬롯으로 인해 WAL 파일이 유지되므로, 클라이언트가 다시 연결되고 슬롯이 다시 활성 상태가 되면 해당 파일이 클라이언트로 전송됩니다. 보조 사이트가 다시 연결할 수 없는 경우 해당 비활성 복제 슬롯을 제거하기 위해 다음 단계를 수행합니다:

  1. PostgreSQL 콘솔 세션을 시작합니다. 이는 Geo 기본 사이트의 데이터베이스 노드에서 수행됩니다: 

    sudo gitlab-psql -d gitlabhq_production
    note
    복제 슬롯을 관리하기 위해서는 슈퍼유저 권한이 필요하므로 gitlab-rails dbconsole을 사용할 수 없습니다.

  2. 복제 슬롯을 보고 비활성 상태인 경우 제거합니다: 

    SELECT * FROM pg_replication_slots;

    active가 f인 슬롯은 비활성 상태입니다.

    • 이 슬롯이 활성 상태여아 하는 경우 슬롯을 사용하여 보조 사이트를 구성했기 때문에, 보조 사이트의 PostgreSQL 로그를 확인하여 복제가 실행되지 않는 이유를 확인합니다.

    • 이 슬롯을 더 이상 사용하지 않는 경우(예: 더 이상 Geo를 사용하지 않음) 또는 보조 사이트가 다시 연결할 수 없는 경우, PostgreSQL 콘솔 세션을 사용하여 해당 슬롯을 제거합니다: 

      SELECT pg_drop_replication_slot('<name_of_inactive_slot>');

  3. 해당 Geo 사이트가 더 이상 필요하지 않은 경우 해당 Geo 사이트 제거 또는 복제 슬롯을 올바르게 다시 생성하는 복제 프로세스 재개 단계를 따릅니다.

메시지: WARNING: oldest xmin is far in the past 및 pg_wal 사이즈가 증가함

복제 슬롯이 비활성 상태인 경우 해당 슬롯에 해당하는 pg_wal 로그는 영원히 예약됩니다(또는 슬롯이 다시 활성화 될 때까지). 이로 인해 지속적인 디스크 사용량이 증가하고 다음 메시지가 PostgreSQL 로그에 반복적으로 표시됩니다: 

WARNING: oldest xmin is far in the past
HINT: Close open transactions soon to avoid wraparound problems.
You might also need to commit or roll back old prepared transactions, or drop stale replication slots.

이 문제를 해결하려면 비활성 복제 슬롯을 제거하고 복제를 다시 시작해야 합니다.

메시지: ERROR: replication slots can only be used if max_replication_slots > 0?

이는 max_replication_slots PostgreSQL 변수가 기본 데이터베이스에서 설정되어야 함을 의미합니다. 이 설정은 기본적으로 1로 설정됩니다. 보조 사이트가 더 많은 경우이 값을 늘려야 할 수 있습니다.

이 값이 적용되려면 PostgreSQL을 다시 시작해야 합니다. 자세한 내용은 PostgreSQL 복제 설정 가이드를 참조하세요.

메시지: FATAL: could not start WAL streaming: ERROR: replication slot "geo_secondary_my_domain_com" does not exist?

이 메시지는 PostgreSQL에 해당 이름을 가진 보조 사이트의 복제 슬롯이 없을 때 발생합니다.

보조 사이트에서 복제 프로세스를 다시 실행할 수 있습니다.

메시지: “명령이 허용된 실행 시간을 초과했습니다” 복제 설정 중?

이는 보조 사이트에서 복제 프로세스 시작 중에 발생할 수 있으며, 기본 시간 제한(30분) 내로 초기 데이터 세트가 복제되지 않는 경우 발생할 수 있습니다.

--backup-timeout에 더 긴 값(예: --backup-timeout=21600)을 포함하여 gitlab-ctl replicate-geo-database를 다시 실행합니다: 

sudo gitlab-ctl \
   replicate-geo-database \
   --host=<primary_node_hostname> \
   --slot-name=<secondary_slot_name> \
   --backup-timeout=21600

이렇게 하면 초기 복제가 기본 30분이 아니라 최대 6시간까지 완료됩니다. 설치 환경에 따라 필요에 맞게 조정합니다.

메시지: “PANIC: could not write to file pg_xlog/xlogtemp.123: No space left on device”

기본 데이터베이스에 사용되지 않는 복제 슬롯이 있는지 확인합니다. 이로 인해 pg_xlog에 대량의 로그 데이터가 생성될 수 있습니다.

비활성 슬롯을 제거하여 pg_xlog에서 사용되는 공간을 줄일 수 있습니다.

메시지: “ERROR: canceling statement due to conflict with recovery”

이 오류 메시지는 일반적인 사용에서는 드물게 발생하며, 시스템은 복구하기에 충분히 견고합니다.

그러나 특정 조건에서는 보조 데이터베이스에서 일부 쿼리가 지나치게 오래 실행될 수 있으며, 이로 인해 이 오류 메시지가 빈번하게 발생할 수 있습니다. 이는 일부 쿼리가 모든 복제에서 취소되어 결국 완료되지 않을 수도 있는 상황으로 이어질 수 있습니다.

이러한 장기 실행 쿼리는 나중에 제거될 예정입니다만, 해결책으로는 hot_standby_feedback를 활성화하는 것을 권장합니다. 이는 VACUUM이 최근에 만료된 행을 제거하는 것을 방지하여 기본 사이트에서 부풀어 오르는 가능성을 높일 수 있습니다. 그러나 이것은 실제로 GitLab.com에서 제품으로 성공적으로 사용되었습니다.

hot_standby_feedback를 활성화하려면 보조 사이트의 /etc/gitlab/gitlab.rb에 다음을 추가하십시오: 

postgresql['hot_standby_feedback'] = 'on'

그런 다음 GitLab을 다시 구성합니다: 

sudo gitlab-ctl reconfigure

이 문제를 해결하기 위해 이 문제에 댓글을 작성하여 당사로 하여금 도움을 요청해주십시오.

메시지: FATAL: could not connect to the primary server: server certificate for "PostgreSQL" does not match host name

이는 Linux 패키지가 자동으로 생성하는 PostgreSQL 인증서에 공통 이름 PostgreSQL이 포함되어 있지만, 복제가 다른 호스트에 연결되어 있고 GitLab이 기본적으로 verify-full SSL 모드를 사용하려고 시도할 때 발생합니다.

이 문제를 해결하려면 다음 중 하나를 선택할 수 있습니다:

  • replicate-geo-database 명령에 --sslmode=verify-ca 인수를 사용합니다.
  • 이미 복제된 데이터베이스의 경우 /var/opt/gitlab/postgresql/data/gitlab-geo.conf에서 sslmode=verify-full을 sslmode=verify-ca로 변경하고 gitlab-ctl restart postgresql을 실행합니다.
  • 자동으로 생성된 인증서 대신 /etc/gitlab/gitlab.rb의 CN 또는 SAN에 데이터베이스에 연결에 사용되는 호스트 이름을 포함하는 사용자 정의 인증서로 PostgreSQL에 SSL을 구성합니다.

메시지: LOG: invalid CIDR mask in address

이는 postgresql['md5_auth_cidr_addresses']에서 올바르게 형식을 맞추지 못한 주소로 발생합니다. 

2020-03-20_23:59:57.60499 LOG:  invalid CIDR mask in address "***"
2020-03-20_23:59:57.60501 CONTEXT:  configuration file "/var/opt/gitlab/postgresql/data/pg_hba.conf"의 74행

이 문제를 해결하려면 /etc/gitlab/gitlab.rb에서 postgresql['md5_auth_cidr_addresses']에서 IP 주소를 CIDR 형식에 맞추도록 업데이트합니다(예: 10.0.0.1/32).

참고: 모든 주어진 문제 해결 방법에 대해 더 자세한 내용을 확인하려면 원본 문서를 참조하십시오.

메시지: LOG: invalid IP mask "md5": Name or service not known

이는 postgresql['md5_auth_cidr_addresses']에 서브넷 마스크 없이 IP 주소를 추가한 경우 발생합니다. 

2020-03-21_00:23:01.97353 LOG:  invalid IP mask "md5": Name or service not known
2020-03-21_00:23:01.97354 CONTEXT:  line 75 of configuration file "/var/opt/gitlab/postgresql/data/pg_hba.conf"

이를 해결하려면, /etc/gitlab/gitlab.rb에 postgresql['md5_auth_cidr_addresses'] 아래에 CIDR 형식을 준수하는 서브넷 마스크를 추가하십시오(예: 10.0.0.1/32).

메시지: gitlab-ctl replicate-geo-database를 실행할 때 gitlabhq_production 데이터베이스에서 데이터를 찾았습니다!

이는 projects 테이블에서 데이터가 감지된 경우 발생합니다. 하나 이상의 프로젝트가 감지되면, 우연한 데이터 손실을 방지하기 위해 작업이 중단됩니다. 이 메시지를 우회하려면 명령에 --force 옵션을 전달하십시오.

메시지: FATAL: could not map anonymous shared memory: Cannot allocate memory

이 메시지가 표시되면, 이는 보조 사이트의 PostgreSQL이 사용 가능한 메모리보다 높은 메모리를 요청하려고 시도하는 경우입니다. 이 문제를 추적하는 이슈가 있습니다.

Linux 패키지 설치의 경우 Patroni 로그(위치: /var/log/gitlab/patroni/current)에 예상되는 오류 메시지: 

2023-11-21_23:55:18.63727 FATAL:  could not map anonymous shared memory: Cannot allocate memory
2023-11-21_23:55:18.63729 HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 17035526144 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

해결책은 보조 사이트의 PostgreSQL 노드에서 사용 가능한 메모리를 증가시켜 주요 사이트의 PostgreSQL 노드의 메모리 요구 사항에 맞추는 것입니다.

PostgreSQL 복제 실패 수정

Admin > Geo > Sites 또는 Sync status Rake task에서 복제 실패를 발견하면 다음과 같은 일반적인 단계로 문제를 해결할 수 있습니다:

  1. Geo는 실패를 자동으로 재시도합니다. 실패가 새로운 것이고 수가 적거나 원인이 이미 해결되었다고 의심되는 경우, 실패가 사라지는지 기다릴 수 있습니다.
  2. 실패가 오래동안 존재했다면, 이미 많은 재시도가 발생했고 자동 재시도 간격이 실패 유형에 따라 최대 4시간까지 증가했습니다. 원인이 이미 해결되었다고 의심된다면, 복제 또는 검증을 매뉴얼으로 재시도할 수 있습니다.
  3. 실패가 지속되는 경우, 다음 섹션을 사용하여 해결하세요.

복제 또는 검증 매뉴얼으로 재시도

Geo 데이터 형식은 하나 이상의 GitLab 기능에서 필요한 특정 데이터 클래스이며 Geo에서 보조 사이트로 복제됩니다.

다음과 같은 Geo 데이터 형식이 있습니다:

  • Blob 유형:
    • Ci::JobArtifact
    • Ci::PipelineArtifact
    • Ci::SecureFile
    • LfsObject
    • MergeRequestDiff
    • Packages::PackageFile
    • PagesDeployment
    • Terraform::StateVersion
    • Upload
    • DependencyProxy::Manifest
    • DependencyProxy::Blob
  • Repository 유형:
    • ContainerRepositoryRegistry
    • DesignManagement::Repository
    • ProjectRepository
    • ProjectWikiRepository
    • SnippetRepository
    • GroupWikiRepository

주요 클래스는 Registry, Model 및 Replicator입니다. 이러한 클래스의 인스턴스가 있는 경우 다른 인스턴스를 가져올 수 있습니다. Registry 및 Model은 대부분 PostgreSQL DB 상태를 관리합니다. Replicator는 복제/검증 방법을 알고 있거나 (또는 서비스를 호출하여) 호출할 수 있습니다: 

model_record = Packages::PackageFile.last
model_record.replicator.registry.replicator.model_record # 이 메서드들이 존재하는 것을 보여주기만 함

이 모든 정보를 사용하여 다음을 수행할 수 있습니다:

개별 구성요소 매뉴얼으로 동기화 및 다시 검증

UI를 사용하여 [자체 서비스 프레임워크](../../../../development/geo/framework.md)에서 관리하는 모든 구성요소 유형에 대한 개별 항목을 강제로 동기화 및 다시 검증할 수 있습니다. 보조 사이트에서 Admin > Geo > Replication으로 이동하십시오.

그러나 이 방법이 작동하지 않는 경우, 동일한 작업을 Rails 콘솔을 사용하여 수행할 수 있습니다. 다음 섹션에서는 개별 레코드에 대한 복제 또는 검증을 동기적 또는 비동기적으로 일으키기 위해 내부 응용 프로그램 명령을 사용하는 방법을 설명합니다.

caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건 하에 실행되지 않으면 피해를 줄 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 수 있는 백업 인스턴스를 준비하세요.

Rails 콘솔 세션을 시작하여 다음 기본 문제 해결 단계를 수행할 수 있습니다:

  • Blob 유형을 위한 경우 (Packages::PackageFile 구성요소를 예로 들어)

    • 동기화에 실패한 레지스트리 레코드 찾기: 

      Geo::PackageFileRegistry.failed

    • 주요 사이트에서 누락된 레지스트리 레코드 찾기: 

      Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Geo primary site')

    • ID를 지정하여 패키지 파일을 동기적으로 다시 동기화: 

      model_record = Packages::PackageFile.find(id)
model_record.replicator.send(:download)

    • 레지스트리 ID를 지정하여 패키지 파일을 동기적으로 다시 동기화: 

      registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.send(:download)

    • 레지스트리 ID를 지정하여 패키지 파일을 비동기적으로 다시 동기화. GitLab 16.2부터, 구성요소는 다음과 같이 비동기적으로 복제할 수 있습니다: 

      registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.enqueue_sync

    • 레지스트리 ID를 지정하여 패키지 파일을 비동기적으로 다시 검증. GitLab 16.2부터, 구성요소는 다음과 같이 비동기적으로 검증할 수 있습니다: 

      registry = Geo::PackageFileRegistry.find(registry_id)
registry.replicator.verify_async

  • 리포지터리 유형의 경우 (SnippetRepository 구성요소를 예로 들어)

    • ID를 지정하여 스니펫 리포지터리를 동기적으로 다시 동기화: 

      model_record = Geo::SnippetRepositoryRegistry.find(id)
model_record.replicator.sync_repository

    • 레지스트리 ID를 지정하여 스니펫 리포지터리를 동기적으로 다시 동기화: 

      registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.sync_repository

    • 레지스트리 ID를 지정하여 스니펫 리포지터리를 비동기적으로 다시 동기화. GitLab 16.2부터, 구성요소는 다음과 같이 비동기적으로 복제할 수 있습니다: 

      registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.enqueue_sync

    • 레지스트리 ID를 지정하여 스니펫 리포지터리를 비동기적으로 다시 검증. GitLab 16.2부터, 구성요소는 다음과 같이 비동기적으로 검증할 수 있습니다: 

      registry = Geo::SnippetRepositoryRegistry.find(registry_id)
registry.replicator.verify_async

여러 컴포넌트 재동기화 및 다시 확인

note
관리자 영역 UI에 이 기능을 구현하는 데 관한 문제가 있습니다. (문제 참조)
caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건 하에서 실행되지 않을 경우 손상을 일으킬 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복구할 수 있는 백업 인스턴스가 준비되어 있는지 확인하세요.

다음 섹션에서는 내부 응용 프로그램 명령을 Rails 콘솔에서 사용하여 대량 복제 또는 확인하는 방법에 대해 설명합니다.

모든 컴포넌트(또는 검증을 지원하는 모든 SSF 데이터 유형) 다시 확인

GitLab 16.4 및 이전 버전의 경우:

  1. 기본 Geo 사이트의 GitLab Rails 노드에 SSH로 로그인합니다.
  2. Rails 콘솔을 엽니다.

  3. 모든 업로드를 대기 중인 확인으로 표시합니다: 

    Upload.verification_state_table_class.each_batch do |relation|
  relation.update_all(verification_state: 0)
end
  4. 이렇게 하면 기본이 모든 업로드에 대해 체크섬을 시작합니다.
  5. 기본이 레코드의 체크섬을 성공적으로 체크섬하는 경우에는 모든 보조 노드도 체크섬을 다시 계산하고 값을 비교합니다.

다른 SSF 데이터 유형의 경우 위의 명령에서 Upload를 원하는 모델 클래스로 대체합니다.

보조에서 블롭 파일 매뉴얼으로 확인

보조에서 모든 패키지 파일을 반복하여 데이터베이스에 저장된 verification_checksum (기본값)을 확인한 다음, 해당 값을 확인하기 위해 보조에서 계산합니다. 이렇게 하면 UI에서는 아무것도 변경되지 않습니다. 

# 보조에서 실행
status = {}

Packages::PackageFile.find_each do |package_file|
  primary_checksum = package_file.verification_checksum
  secondary_checksum = Packages::PackageFile.sha256_hexdigest(package_file.file.path)
  verification_status = (primary_checksum == secondary_checksum)
  
  status[verification_status.to_s] ||= []
  status[verification_status.to_s] << package_file.id
end

# 각 값이 몇 번씩 나왔는지 계산
status.keys.each {|key| puts "#{key} 수: #{status[key].count}"}

# 전체 출력 확인
status

기본 Geo 사이트에서 업로드의 확인 실패

기본 Geo 사이트에서 업로드의 확인이 verification_checksum = nil 및 verification_failure = Error during verification: undefined method underscore’ for NilClass:Class`로 실패하는 경우, 이는 고아 업로드 때문일 수 있습니다. 업로드를 소유하는 상위 레코드(업로드 모델)가 어떤 이유로 삭제되었지만 업로드 레코드는 여전히 남아 있는 경우입니다. 이러한 확인 실패는 잘못된 것입니다.

이러한 오류는 기본 Geo 사이트의 geo.log 파일에서 찾을 수 있습니다.

모델 레코드가 누락되었는지 확인하기 위해 기본 Geo 사이트에서 rake 작업을 실행할 수 있습니다: 

sudo gitlab-rake gitlab:uploads:check

이러한 실패를 제거하려면 Rails 콘솔에서 다음 스크립트를 실행하여 기본 Geo 사이트에서 이러한 업로드 레코드를 삭제할 수 있습니다: 

# 확인 오류가 있는 업로드 찾기
# 또는 영향을 받는 ID로 수정
uploads = Geo::UploadState.where(
  verification_checksum: nil,
  verification_state: 3,
  verification_failure: "Error during verification: undefined method  `underscore' for NilClass:Class"
).pluck(:upload_id)

uploads_deleted = 0
begin
    uploads.each do |upload|
    u = Upload.find upload
    rescue => e
        puts "업로드 확인 실패: #{u.id}, 에러: #{e.message}"
      else
        uploads_deleted = uploads_deleted + 1
        p u                            ### 삭제하기 전에 확인
        # p u.destroy!                 ### 실제로 삭제하려면 주석 해제
  end
end
p "#{uploads_deleted} 원격 객체가 파괴되었습니다."

데이터베이스 복제 지연의 원인 조사

sudo gitlab-rake geo:status의 결과가 시간이 지남에 따라 Database replication lag가 여전히 상당히 높게 나타나면 데이터베이스 복제의 여러 부분에 대한 지연 상태를 확인할 수 있습니다. 이러한 값은 write_lag, flush_lag, 및 replay_lag로 알려져 있습니다. 자세한 정보는 공식 PostgreSQL 문서를 참조하세요.

주요 Geo 노드의 데이터베이스에서 다음 명령을 실행하여 관련 출력을 제공하세요: 

gitlab-psql -xc 'SELECT write_lag,flush_lag,replay_lag FROM pg_stat_replication;'
-[ 레코드 1 ]---------------
write_lag  | 00:00:00.072392
flush_lag  | 00:00:00.108168
replay_lag | 00:00:00.108283

이러한 값 중 하나 이상이 상당히 높은 경우 문제가 있을 수 있으므로 조사해야합니다. 원인을 확인할 때 write_lag는 기본이 보낸 WAL 바이트가 보조로 전송되었지만 아직 플러시되지 않은 시간을 나타냅니다. 높은 write_lag 값은 기본과 보조 노드 사이의 네트워크 성능이 저하되었거나 네트워크 속도가 충분하지 않을 수 있음을 나타낼 수 있습니다. 높은 flush_lag 값은 보조 노드의 저장 장치에 대한 성능이 저하되거나 부적절할 수 있음을 나타낼 수 있습니다. 높은 replay_lag 값은 PostgreSQL에서 긴 수행 트랜잭션 또는 CPU와 같은 필요한 리소스의 포화를 나타낼 수 있습니다. write_lag와 flush_lag 간의 시간 차이는 WAL 바이트가 기본의 하부 저장 시스템에 전송되었지만 플러시되지 않았음을 나타냅니다. 이 데이터는 아마도 영구 리포지터리에 완전히 기록되지 않았으며 어떤 종류의 휘발성 기록 캐시에 보관되었을 가능성이 높습니다. flush_lag와 replay_lag 간의 차이는 저장에 성공적으로 기록된 WAL 바이트가 데이터베이스 시스템에 재생되지 않은 것을 나타냅니다.

Geo secondary 사이트 복제 재설정

Secondary 사이트가 손상된 상태로되어 있으며 복제 상태를 재설정하고 다시 처음부터 시작하려는 경우 일부 단계를 따라야 합니다:

  1. Sidekiq와 Geo LogCursor 중지.

    Sidekiq를 정상적으로 중지할 수 있지만 새로운 작업을 가져 오지 않고 현재 작업이 처리되기를 기다리는 상태로 만들 수 있습니다. 또는 gitlab-ctl stop 명령을 사용하세요. 

    gitlab-ctl status sidekiq
# 실행 중인: sidekiq: (pid 10180) <- 이 PID를 사용합니다
kill -TSTP 10180 # 올바른 PID로 변경
   
gitlab-ctl stop sidekiq
gitlab-ctl stop geo-logcursor

    작업 처리 상태를 확인하기 위해 Sidekiq 로그를 확인할 수 있습니다. 

    gitlab-ctl tail sidekiq

  2. 리포지터리 스토리지 폴더 이름 변경 및 새로 만들기. 가능한 고아 디렉터리 및 파일에 대해 걱정할 필요가 없다면 이 단계는 건너 뛸 수 있습니다. 

    mv /var/opt/gitlab/git-data/repositories /var/opt/gitlab/git-data/repositories.old
mkdir -p /var/opt/gitlab/git-data/repositories
chown git:git /var/opt/gitlab/git-data/repositories
    note
    더 이상 필요하지 않다고 확인하면 나중에 /var/opt/gitlab/git-data/repositories.old를 제거해 디스크 공간을 저장할 수 있습니다.

  3. 선택 사항. 다른 데이터 폴더 이름 변경 및 새로 만들기.

    caution
    Secondary 사이트에는 여전히 primary 사이트에서 제거된 파일이지만 이 제거가 반영되지 않은 경우가 있을 수 있습니다. 이 단계를 건너 뛰면 이러한 파일이 Geo secondary 사이트에서 제거되지 않습니다.

    업로드된 내용(예: 파일 첨부, 아바타 또는 LFS 객체와 같은)은 다음 경로의 하위 폴더에 저장됩니다:

  • /var/opt/gitlab/gitlab-rails/shared
  • /var/opt/gitlab/gitlab-rails/uploads

모두 이름을 바꾸려면: 

  gitlab-ctl stop
  
  mv /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared.old
  mkdir -p /var/opt/gitlab/gitlab-rails/shared
  
  mv /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/uploads.old
  mkdir -p /var/opt/gitlab/gitlab-rails/uploads
  
  gitlab-ctl start postgresql
  gitlab-ctl start geo-postgresql

폴더를 다시 만들고 권한과 소유권이 올바른지 확인하려면 재구성하세요: 

  gitlab-ctl reconfigure

  1. 추적 데이터베이스 재설정.

    caution
    선택적인 단계 3을 건너 뛴 경우 geo-postgresql 및 postgresql 서비스가 실행 중임을 확인하세요.
    gitlab-rake db:drop:geo DISABLE_DATABASE_ENVIRONMENT_CHECK=1   # 보조 앱 노드에서
gitlab-ctl reconfigure     # 추적 데이터베이스 노드에서
gitlab-rake db:migrate:geo # 보조 앱 노드에서

  2. 이전에 중지한 서비스 다시 시작. 

    gitlab-ctl start