-
PostgreSQL 데이터베이스 복제 오류 수정
- 비활성 복제 슬롯 제거
- 메시지:
WARNING: oldest xmin is far in the past
및pg_wal
사이즈가 증가함 - 메시지:
ERROR: replication slots can only be used if max_replication_slots > 0
? - 메시지:
FATAL: could not start WAL streaming: ERROR: replication slot "geo_secondary_my_domain_com" does not exist
? - 메시지: “명령이 허용된 실행 시간을 초과했습니다” 복제 설정 중?
- 메시지: “PANIC: could not write to file
pg_xlog/xlogtemp.123
: No space left on device” - 메시지: “ERROR: canceling statement due to conflict with recovery”
- 메시지:
FATAL: could not connect to the primary server: server certificate for "PostgreSQL" does not match host name
- 메시지:
LOG: invalid CIDR mask in address
- 메시지:
LOG: invalid IP mask "md5": Name or service not known
- 메시지:
gitlab-ctl replicate-geo-database
를 실행할 때gitlabhq_production
데이터베이스에서 데이터를 찾았습니다! - 메시지:
FATAL: could not map anonymous shared memory: Cannot allocate memory
- PostgreSQL 복제 실패 수정
- 데이터베이스 복제 지연의 원인 조사
- Geo secondary 사이트 복제 재설정
Geo 복제 문제 해결
PostgreSQL 데이터베이스 복제 오류 수정
다음 섹션에서는 복제 오류 메시지를 해결하는 문제 해결 단계를 설명합니다(데이터베이스 복제 작동 여부를 나타내는 Database replication working? ... no
가 geo:check
출력에 표시됨).
비활성 복제 슬롯 제거
복제 슬롯은 복제 클라이언트(보조 사이트)가 해당 슬롯과의 연결을 해제할 때 ‘비활성’으로 표시됩니다. 비활성 복제 슬롯으로 인해 WAL 파일이 유지되므로, 클라이언트가 다시 연결되고 슬롯이 다시 활성 상태가 되면 해당 파일이 클라이언트로 전송됩니다. 보조 사이트가 다시 연결할 수 없는 경우 해당 비활성 복제 슬롯을 제거하기 위해 다음 단계를 수행합니다:
-
PostgreSQL 콘솔 세션을 시작합니다. 이는 Geo 기본 사이트의 데이터베이스 노드에서 수행됩니다:
sudo gitlab-psql -d gitlabhq_production
복제 슬롯을 관리하기 위해서는 슈퍼유저 권한이 필요하므로gitlab-rails dbconsole
을 사용할 수 없습니다. -
복제 슬롯을 보고 비활성 상태인 경우 제거합니다:
SELECT * FROM pg_replication_slots;
active
가f
인 슬롯은 비활성 상태입니다.- 이 슬롯이 활성 상태여아 하는 경우 슬롯을 사용하여 보조 사이트를 구성했기 때문에, 보조 사이트의 PostgreSQL 로그를 확인하여 복제가 실행되지 않는 이유를 확인합니다.
-
이 슬롯을 더 이상 사용하지 않는 경우(예: 더 이상 Geo를 사용하지 않음) 또는 보조 사이트가 다시 연결할 수 없는 경우, PostgreSQL 콘솔 세션을 사용하여 해당 슬롯을 제거합니다:
SELECT pg_drop_replication_slot('<name_of_inactive_slot>');
-
해당 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에서 복제 실패를 발견하면 다음과 같은 일반적인 단계로 문제를 해결할 수 있습니다:
- Geo는 실패를 자동으로 재시도합니다. 실패가 새로운 것이고 수가 적거나 원인이 이미 해결되었다고 의심되는 경우, 실패가 사라지는지 기다릴 수 있습니다.
- 실패가 오래동안 존재했다면, 이미 많은 재시도가 발생했고 자동 재시도 간격이 실패 유형에 따라 최대 4시간까지 증가했습니다. 원인이 이미 해결되었다고 의심된다면, 복제 또는 검증을 매뉴얼으로 재시도할 수 있습니다.
- 실패가 지속되는 경우, 다음 섹션을 사용하여 해결하세요.
복제 또는 검증 매뉴얼으로 재시도
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 콘솔을 사용하여 수행할 수 있습니다. 다음 섹션에서는 개별 레코드에 대한 복제 또는 검증을 동기적 또는 비동기적으로 일으키기 위해 내부 응용 프로그램 명령을 사용하는 방법을 설명합니다.
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
-
여러 컴포넌트 재동기화 및 다시 확인
다음 섹션에서는 내부 응용 프로그램 명령을 Rails 콘솔에서 사용하여 대량 복제 또는 확인하는 방법에 대해 설명합니다.
모든 컴포넌트(또는 검증을 지원하는 모든 SSF 데이터 유형) 다시 확인
GitLab 16.4 및 이전 버전의 경우:
- 기본 Geo 사이트의 GitLab Rails 노드에 SSH로 로그인합니다.
- Rails 콘솔을 엽니다.
-
모든 업로드를
대기 중인 확인
으로 표시합니다:Upload.verification_state_table_class.each_batch do |relation| relation.update_all(verification_state: 0) end
- 이렇게 하면 기본이 모든 업로드에 대해 체크섬을 시작합니다.
- 기본이 레코드의 체크섬을 성공적으로 체크섬하는 경우에는 모든 보조 노드도 체크섬을 다시 계산하고 값을 비교합니다.
다른 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 사이트가 손상된 상태로되어 있으며 복제 상태를 재설정하고 다시 처음부터 시작하려는 경우 일부 단계를 따라야 합니다:
-
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
-
리포지터리 스토리지 폴더 이름 변경 및 새로 만들기. 가능한 고아 디렉터리 및 파일에 대해 걱정할 필요가 없다면 이 단계는 건너 뛸 수 있습니다.
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
더 이상 필요하지 않다고 확인하면 나중에/var/opt/gitlab/git-data/repositories.old
를 제거해 디스크 공간을 저장할 수 있습니다. -
선택 사항. 다른 데이터 폴더 이름 변경 및 새로 만들기.
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
-
추적 데이터베이스 재설정.
선택적인 단계 3을 건너 뛴 경우geo-postgresql
및postgresql
서비스가 실행 중임을 확인하세요.gitlab-rake db:drop:geo DISABLE_DATABASE_ENVIRONMENT_CHECK=1 # 보조 앱 노드에서 gitlab-ctl reconfigure # 추적 데이터베이스 노드에서 gitlab-rake db:migrate:geo # 보조 앱 노드에서
-
이전에 중지한 서비스 다시 시작.
gitlab-ctl start