- 기본 문제 해결
-
일반 오류 해결
- Geo 데이터베이스 구성 파일이 없음
- 기존 추적 데이터베이스를 재사용할 수 없음
- Geo 사이트에는 쓰기 가능한 데이터베이스가 있으며, 이는 주 사이트와의 복제가 구성되지 않았음을 나타냅니다.
- Geo 사이트에서 주 사이트로부터 데이터베이스를 복제하지 않는 것으로 나타납니다.
- Geo 데이터베이스 버전 (…)이(가) 최신 마이그레이션 (…)과(와) 일치하지 않습니다.
- GitLab에서 리포지터리의 100% 이상이 동기화되었다는 메시지
external_url값 변경 후 UI에서 Unhealthy로 표시된 Secondary 사이트- 백업 중에 메시지:
ERROR: canceling statement due to conflict with recovery표시
Geo 일반 오류 해결
기본 문제 해결
더 고급화된 문제 해결을 시도하기 전에:
Geo 사이트의 상태 확인
주 사이트에서:
- 왼쪽 사이드바에서 아래쪽에서 관리 영역을 선택합니다.
- Geo > 사이트를 선택합니다.
우리는 다음과 같은 상태 확인을 부 사이트마다 수행하여 문제가 있는지를 확인합니다:
- 사이트가 작동 중인가요?
- 부 사이트의 데이터베이스가 스트리밍 복제로 구성되어 있나요?
- 이 부 사이트의 추적 데이터베이스가 구성되어 있나요?
- 이 부 사이트의 추적 데이터베이스가 연결되어 있나요?
- 이 부 사이트의 추적 데이터베이스가 최신 상태인가요?
- 이 부 사이트의 상태가 10분 이내인가요?
사이트의 상태가 10분 이상 오래된 경우 “비정상”으로 표시됩니다. 이 경우, 영향 받는 부 사이트의 Rails 콘솔에서 다음을 실행해 보세요.
Geo::MetricsUpdateWorker.new.perform
이 작업이 오류를 발생시키면, 문제가 작업이 완료되는 것도 막을 수 있습니다. 10분 이상 걸린다면 성능 문제가 있을 수 있으며, 상태가 최종적으로 업데이트되더라도 UI에 항상 “비정상”이 표시됩니다.
상태가 성공적으로 업데이트되면 Sidekiq에 문제가 있을 수 있습니다. 작동 중인가요? 로그에 오류가 표시되나요? 이 작업은 매분마다 큐에 들어가며 작업 중복성 이덤포턴시 키가 제대로 지워지지 않으면 실행되지 않을 수 있습니다. 이는 Redis에서 배타적 레이스를 취해 한 번에 하나의 작업만 실행되도록 합니다. 주 사이트는 PostgreSQL 데이터베이스에서 상태를 직접 업데이트합니다. 부 사이트는 상태 데이터를 주 사이트에 HTTP Post 요청으로 보냅니다.
어떤 특정 상태 확인에서도 사이트가 “비정상”으로 표시됩니다. 영향을 받는 부 사이트의 Rails 콘솔에서 다음을 실행하여 실패 사항을 확인할 수 있습니다.
Gitlab::Geo::HealthCheck.new.perform_checks
""(빈 문자열) 또는 "Healthy"가 반환되면, 확인이 성공했음을 나타냅니다. 다른 값을 반환하면, 해당 메시지에서 실패 사유를 설명하거나 예외 메시지를 표시해야 합니다.
사용자 인터페이스에서 보고되는 일반 오류 메시지를 해결하는 방법에 대한 정보는 일반 오류 해결을 참조해 주세요.
사용자 인터페이스가 작동하지 않거나 로그인할 수 없는 경우, Geo 상태 확인을 매뉴얼으로 실행하여 이 정보와 몇 가지 추가 정보를 얻을 수 있습니다.
상태 확인 Rake 작업
- GitLab 15.7에서 사용자 지정 NTP 서버를 사용하는 것이 도입되었습니다.
이 Rake 작업은 주 또는 부 Geo 사이트의 Rails 노드에서 실행할 수 있습니다.
sudo gitlab-rake gitlab:geo:check
예시 출력:
Geo 확인 중...
GitLab Geo를 사용할 수 있음... 예
GitLab Geo가 활성화됨... 예
이 머신의 Geo 노드 이름이 데이터베이스 레코드와 일치함... "Shanghai"이라는 이름의 부 노드를 찾음
GitLab Geo 추적 데이터베이스가 올바르게 구성됨... 예
데이터베이스 복제 활성화됨? ... 예
데이터베이스 복제가 작동 중인가요? ... 예
GitLab Geo HTTP(S) 연결...
* 주 노드에 연결할 수 있음... 예
HTTP/HTTPS 리포지터리 복제가 활성화됨... 예
머신 시계가 동기화됨... 예
Git 사용자가 기본 SSH 구성을 갖고 있나요? ... 예
OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨... 예
GitLab이 authorized_keys 파일에 쓰는 것을 비활성화하도록 구성됨? ... 예
새로운 프로젝트를 해시 리포지터리에 저장하도록 GitLab이 구성됨? ... 예
모든 프로젝트가 해시 리포지터리에 있나요? ... 예
Geo 확인 중... 완료
환경 변수를 사용하여 사용자 지정 NTP 서버를 지정할 수도 있습니다. 예시:
sudo gitlab-rake gitlab:geo:check NTP_HOST="ntp.ubuntu.com" NTP_TIMEOUT="30"
다음과 같은 환경 변수를 지원합니다.
| 변수 | 설명 | 기본값 |
|---|---|---|
NTP_HOST
| NTP 호스트 | pool.ntp.org
|
NTP_PORT
| 호스트가 수신 대기하는 NTP 포트 | ntp
|
NTP_TIMEOUT
| NTP 제한 시간(초) |
net-ntp Ruby 라이브러리에 정의된 값 (60초).
|
Rake 작업이 OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨 확인을 건너뛸 경우, 다음과 같은 출력이 표시됩니다.
OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨 ... 건너뛰었음
이유:
OpenSSH 구성 파일에 액세스할 수 없음
이 문제를 해결하려면:
이 문제는 SELinux를 사용하는 경우에 예상됩니다. 매뉴얼으로 구성을 확인할 수 있습니다
자세한 내용은 다음을 참조하세요:
doc/administration/operations/fast_ssh_key_lookup.md
이 문제는 발생할 수 있습니다:
- SELinux를 사용하는 경우.
- SELinux를 사용하지 않고 ‘git’ 사용자가 제한된 파일 권한으로 인해 OpenSSH 구성 파일에 액세스할 수 없는 경우.
후자의 경우, 다음 출력에서 ‘root’ 사용자만이 이 파일을 읽을 수 있다는 것을 보여줍니다:
sudo stat -c '%G:%U %A %a %n' /etc/ssh/sshd_config
root:root -rw------- 600 /etc/ssh/sshd_config
파일 소유자나 권한을 변경하지 않고도 ‘git’ 사용자가 OpenSSH 구성 파일을 읽을 수 있도록 하려면 acl을 사용합니다:
sudo setfacl -m u:git:r /etc/ssh/sshd_config
동기화 상태 Rake 작업
현재 동기화 정보는 Geo 부 사이트의 Rails(푸마, Sidekiq, 또는 Geo 로그 커서) 노드에서 이 Rake 작업을 매뉴얼으로 실행하여 확인할 수 있습니다.
Object Storage에 저장된 객체를 확인하지 않습니다. Object Storage를 사용하는 경우 “verified” 체크에 성공한 0개만 표시됩니다. 이것은 예상되는 동작이며 걱정할 필요가 없습니다.
sudo gitlab-rake geo:status
출력에는 다음이 포함됩니다:
- 실패한 항목 수 (오류가 발생한 경우)
- “성공” 항목의 비율, “전체”에 대해
예시:
http://secondary.example.com/
-----------------------------------------------------
GitLab Version: 14.9.2-ee
Geo Role: Secondary
Health Status: Healthy
Project Repositories: succeeded 12345 / total 12345 (100%)
Project Wiki Repositories: succeeded 6789 / total 6789 (100%)
Attachments: succeeded 4 / total 4 (100%)
CI job artifacts: succeeded 0 / total 0 (0%)
Design management repositories: succeeded 1 / total 1 (100%)
LFS Objects: failed 1 / succeeded 2 / total 3 (67%)
Merge Request Diffs: succeeded 0 / total 0 (0%)
Package Files: failed 1 / succeeded 2 / total 3 (67%)
Terraform State Versions: failed 1 / succeeded 2 / total 3 (67%)
Snippet Repositories: failed 1 / succeeded 2 / total 3 (67%)
Group Wiki Repositories: succeeded 4 / total 4 (100%)
Pipeline Artifacts: failed 3 / succeeded 0 / total 3 (0%)
Pages Deployments: succeeded 0 / total 0 (0%)
Repositories Checked: failed 5 / succeeded 0 / total 5 (0%)
Package Files Verified: succeeded 0 / total 10 (0%)
Terraform State Versions Verified: succeeded 0 / total 10 (0%)
Snippet Repositories Verified: succeeded 99 / total 100 (99%)
Pipeline Artifacts Verified: succeeded 0 / total 10 (0%)
Project Repositories Verified: succeeded 12345 / total 12345 (100%)
Project Wiki Repositories Verified: succeeded 6789 / total 6789 (100%)
Sync Settings: Full
Database replication lag: 0 seconds
Last event ID seen from primary: 12345 (약 2분 전)
Last event ID processed: 12345 (약 2분 전)
Last status report was: 1 minute ago
각 항목을 세 가지 상태가 가질 수 있습니다. 예를 들어, 프로젝트 리포지터리의 경우 다음과 같은 정보가 표시됩니다:
Project Repositories: succeeded 12345 / total 12345 (100%)
Project Repositories Verified: succeeded 12345 / total 12345 (100%)
Repositories Checked: failed 5 / succeeded 0 / total 5 (0%)
3개 상태 항목은 다음과 같이 정의됩니다:
-
Project Repositories출력은 주 사이트에서 부 사이트로 동기화된 프로젝트 리포지터리의 수를 보여줍니다. -
Project Verified Repositories출력은 부 사이트에서 기본 사이트와 일치하는 리포지터리 체크섬을 가진 프로젝트 리포지터리의 수를 보여줍니다. -
Repositories Checked출력은 부 사이트에서 지역 Git 리포지터리 체크(git fsck)를 통과한 프로젝트 리포지터리의 수를 보여줍니다.
실패한 항목에 대한 자세한 정보를 찾으려면 gitlab-rails/geo.log 파일을 확인하세요.
복제 또는 확인 실패 사항을 발견하면 해결을 시도해 볼 수 있습니다.
리포지터리 확인 실패 사항이 있는 경우 해결을 시도할 수도 있습니다.
Geo check Rake 작업 실행 중 발견된 오류 수정
이 Rake 작업을 실행하는 동안 노드가 제대로 구성되지 않은 경우 오류 메시지가 표시될 수 있습니다:
sudo gitlab-rake gitlab:geo:check
-
Rails가 데이터베이스에 연결할 때 암호를 제공하지 않았습니다.
Geo 확인 중 ... GitLab Geo 사용 가능... Exception: fe_sendauth: no password supplied GitLab Geo 활성화... Exception: fe_sendauth: no password supplied ... Geo 확인 완료gitlab_rails['db_password']가postgresql['sql_user_password']의 해시를 생성할 때 사용된 평문 암호로 설정되어 있는지 확인하십시오. -
Rails가 데이터베이스에 연결할 수 없습니다.
Geo 확인 중 ... GitLab Geo 사용 가능... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off GitLab Geo 활성화... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off ... Geo 확인 완료Rails 노드의 IP 주소가
postgresql['md5_auth_cidr_addresses']에 포함되어 있는지 확인하고, IP 주소에 서브넷 마스크가 포함되었는지 확인하십시오:postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']. -
Rails가 올바르지 않은 암호를 제공했습니다.
Geo 확인 중... GitLab Geo 사용 가능... Exception: FATAL: password authentication failed for user "gitlab" FATAL: password authentication failed for user "gitlab" GitLab Geo 활성화... Exception: FATAL: password authentication failed for user "gitlab" FATAL: password authentication failed for user "gitlab" ... Geo 확인 완료gitlab_rails['db_password']에 올바른 암호가 설정되었는지postgresql['sql_user_password']의 해시를 생성할 때 사용된 암호를 확인하려면gitlab-ctl pg-password-md5 gitlab을 실행하고 암호를 입력하십시오. -
확인 결과
secondary node가 아님이 반환됩니다.Geo 확인 중 ... GitLab Geo 사용 가능... 예 GitLab Geo 활성화... 예 GitLab Geo 추적 데이터베이스가 올바르게 구성됨... secondary node가 아님 데이터베이스 복제가 활성화되었습니까?... secondary node가 아님 ... Geo 확인 완료관리 영역의 Geo > Sites에서 primary 사이트용으로 웹 인터페이스에 secondary 사이트를 추가하고, primary 사이트의 관리 영역에서 secondary 사이트를 추가할 때
gitlab_rails['geo_node_name']을 입력했는지 확인하십시오. -
Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist가 반환됩니다.Geo 확인 중 ... GitLab Geo 사용 가능... 아니요 해결 방법: GitLab Geo 기능이 포함된 새 라이선스 추가 자세한 정보는 다음을 참조: https://about.gitlab.com/features/gitlab-geo/ GitLab Geo 활성화... Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist ... Geo 확인 완료PostgreSQL 주 버전(9 > 10) 업그레이드를 수행할 때 이 문제가 발생합니다. 복제 프로세스를 시작하라를 따르십시오.
-
Rails가 Geo 추적 데이터베이스에 연결하기 위해 필요한 구성을 보유하지 않는 것으로 보입니다.
Geo 확인 중 ... GitLab Geo 사용 가능... 예 GitLab Geo 활성화... 예 GitLab Geo 추적 데이터베이스가 올바르게 구성됨... 아니오 해결 방법: Rails가 이 노드 이외의 노드에서 실행 중인 추적 데이터베이스에 연결할 필요가 있으면 설정을 추가해야 합니다. ... Geo 확인 완료- 보조 사이트의 모든 서비스를 단일 노드에서 실행 중인 경우, 보조 서버의 Geo 데이터베이스 복제 - 보조 서버 구성를 따르십시오.
- 보조 사이트의 추적 데이터베이스를 별도의 노드에서 실행 중인 경우, 다중 서버용 Geo - 보조 Geo 사이트에서 추적 데이터베이스 구성를 따르십시오.
- 보조 사이트의 추적 데이터베이스를 Patroni 클러스터에서 실행 중인 경우, Geo 데이터베이스 복제 - 추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성를 따르십시오.
- 보조 사이트의 추적 데이터베이스를 외부 데이터베이스에서 실행 중인 경우, 외부 PostgreSQL 인스턴스와 함께 Geo를 따르십시오.
- Geo 확인 작업이 GitLab Rails 앱(Puma, Sidekiq 또는 Geo Log Cursor)을 실행하지 않는 노드에서 실행 중인 경우이 오류를 무시할 수 있습니다. 이 노드는 Rails의 구성이 필요하지 않습니다.
메시지: 기계 클럭이 동기화되었습니다… Exception
Rake 작업은 서버 클럭이 NTP(Network Time Protocol)와 동기화되었는지 확인을 시도합니다. 동기화된 클럭은 Geo가 올바르게 작동하는 데 필요합니다. 예를 들어, 보안을 위해 기본 사이트와 보조 사이트의 서버 시간이 약간 이라도 차이가 나면 Geo 사이트 간의 요청이 실패합니다. 이 확인 작업이 시간 불일치 외의 이유로 완료되지 않는다고 하더라도 Geo가 작동하지 않는다는 것은 아닙니다.
이 확인을 수행하는 Ruby gem은 참조 시간원으로 pool.ntp.org를 하드 코딩하여 사용합니다.
-
예외 메시지
기계 클럭이 동기화되었습니다... Exception: Timeout::Error이 문제는 서버가
pool.ntp.org호스트에 액세스할 수 없을 때 발생합니다. -
예외 메시지
기계 클럭이 동기화되었습니다... Exception: No route to host - recvfrom(2)이 문제는 호스트명
pool.ntp.org가 시간 서비스를 제공하지 않는 서버로 해석되었을 때 발생합니다.
이 경우 GitLab 15.7 이상에서는 환경 변수를 사용하여 사용자 정의 NTP 서버를 지정할 수 있습니다.
GitLab 15.6 이전에서는 다음 중 하나의 해결책을 사용하십시오:
-
/etc/hosts에pool.ntp.org항목을 추가하여 유효한 로컬 시간 서버로 요청을 전달하십시오. 이렇게 하면 대기 시간이 긴 문제와 시간 초과 오류가 해결됩니다. - 확인을 유효한 IP 주소로 직접 지정하십시오. 이렇게 하면 시간 초과 문제는 해결되지만,
위에서 언급한대로
No route to host오류로 인해 확인이 실패합니다.
클라우드 네이티브 GitLab 배포는 쿠버네티스 컨테이너에서 호스트 클록에 액세스할 수 없기 때문에 오류가 발생합니다:
기계 클럭이 동기화되었습니다... Exception: getaddrinfo: Servname not supported for ai_socktype
메시지: ActiveRecord::StatementInvalid: PG::ReadOnlySqlTransaction: ERROR: cannot execute INSERT in a read-only transaction
이 오류가 보조 사이트에서 발생하는 경우, gitlab-rails 또는 gitlab-rake 명령과 함께 Puma, Sidekiq 및 Geo Log Cursor 서비스 등 GitLab Rails의 모든 사용에 영향을 미칠 수 있습니다.
ActiveRecord::StatementInvalid: PG::ReadOnlySqlTransaction: ERROR: cannot execute INSERT in a read-only transaction
/opt/gitlab/embedded/service/gitlab-rails/app/models/application_record.rb:86:in `block in safe_find_or_create_by'
/opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/cross_database_modification.rb:92:in `block in transaction'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database.rb:332:in `block in transaction'
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database.rb:331:in `transaction'
/opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/cross_database_modification.rb:83:in `transaction'
/opt/gitlab/embedded/service/gitlab-rails/app/models/application_record.rb:86:in `safe_find_or_create_by'
/opt/gitlab/embedded/service/gitlab-rails/app/models/shard.rb:21:in `by_name'
/opt/gitlab/embedded/service/gitlab-rails/app/models/shard.rb:17:in `block in populate!'
/opt/gitlab/embedded/service/gitlab-rails/app/models/shard.rb:17:in `map'
/opt/gitlab/embedded/service/gitlab-rails/app/models/shard.rb:17:in `populate!'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/fill_shards.rb:9:in `<top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `<top (required)>'
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `<main>'
PostgreSQL 읽기 복제 데이터베이스에서 이러한 오류가 발생할 수 있습니다.
2023-01-17_17:44:54.64268 ERROR: cannot execute INSERT in a read-only transaction
2023-01-17_17:44:54.64271 STATEMENT: /*application:web,db_config_name:main*/ INSERT INTO "shards" ("name") VALUES ('storage1') RETURNING "id"
이 상황은 보조 사이트가 아직 자신이 보조 사이트임을 인식하지 못한 초기 구성 중에 발생할 수 있습니다.
해당 오류를 해결하려면 Step 3. Add the secondary site를 따르십시오.
PostgreSQL 복제가 작동하는지 확인
PostgreSQL 복제가 작동하는지 확인하려면 다음 사항을 확인하십시오:
문제가 계속되는 경우 고급 복제 문제 해결을 참조하십시오.
사이트가 올바른 데이터베이스 노드를 가리키고 있는지 확인
Primary Geo site가 쓰기 권한이 있는 데이터베이스 노드를 가리키고 있는지 확인해야 합니다.
어떤 Secondary 사이트는 읽기 전용 데이터베이스 노드만 가리켜야 합니다.
Geo가 현재 사이트를 올바르게 감지하는지 확인
Geo는 다음 로직을 사용하여 /etc/gitlab/gitlab.rb에서 Puma 또는 Sidekiq 노드의 Geo site 이름을 찾습니다:
- “Geo 노드 이름”을 가져옵니다 (이름을 “Geo 사이트 이름”으로 바꾸는 것에 대한 이슈가 있습니다):
- Linux 패키지:
gitlab_rails['geo_node_name']설정 가져오기 - GitLab Helm 차트:
global.geo.nodeName설정 가져오기 (참조: GitLab Geo와 차트)
- Linux 패키지:
- 그것이 정의되지 않았다면
external_url설정을 가져옵니다.
이 이름은 Geo Sites 대시보드에서 Name과 동일한 이름의 Geo 사이트를 찾기 위해 사용됩니다.
현재 머신이 데이터베이스에 존재하는 사이트 이름과 일치하는지 확인하려면 다음 작업을 실행합니다:
sudo gitlab-rake gitlab:geo:check
이 명령은 현재 머신의 사이트 이름과 일치하는 데이터베이스 레코드가 Primary 또는 Secondary 사이트인지 여부를 표시합니다.
이 머신의 Geo 노드 이름과 데이터베이스 레코드 일치 ... yes, "Shanghai"라는 이름의 보조 노드를 찾았습니다
이 머신의 Geo 노드 이름과 데이터베이스 레코드 일치 ... no
수정하는 방법:
"https://example.com/"로 이름을 설정한 Geo 노드 데이터베이스 레코드를 추가하거나 업데이트할 수 있습니다.
또는 이 머신의 Geo 노드 이름을 "London", "Shanghai"와 같은 기존 데이터베이스 레코드의 이름과 일치하도록 설정할 수 있습니다
자세한 정보는 다음을 참조하십시오:
doc/administration/geo/replication/troubleshooting/index.md#can-geo-detect-the-current-node-correctly
이름 필드의 권장 사이트 이름에 관한 자세한 내용은 Geo 관리 영역 공통 설정을 참조하십시오.
OS 로캘 데이터 호환성 확인
가능한 경우 모든 사이트의 모든 Geo 노드는 Geo를 실행하는 데 필요한 요구 사항에 정의된대로 동일한 방법과 운영 체제로 배포되어야 합니다.
다른 운영 체제나 다른 운영 체제 버전이 Geo 사이트 전체에 배포되는 경우, Geo를 설정하기 전에 반드시 로캘 데이터 호환성을 확인해야 합니다. 또한 GitLab 설치 방법의 혼합 사용 시 glibc를 확인해야 합니다. 로캘은 Linux 패키지 설치, GitLab Docker 컨테이너, Helm 차트 배포 또는 외부 데이터베이스 서비스를 사용할 때 각각 다를 수 있습니다. PostgreSQL의 운영 체제를 업그레이드하는 방법에 대한 문서를 참조하십시오. 이 문서에는 glibc 버전 호환성을 확인하는 방법도 설명되어 있습니다.
Geo는 PostgreSQL 및 스트리밍 복제를 사용하여 데이터를 Geo 사이트 전체에 복제합니다. PostgreSQL은 텍스트를 정렬하는 데 운영 체제의 C 라이브러리에서 제공하는 로캘 데이터를 사용합니다. C 라이브러리의 로캘 데이터가 Geo 사이트 전체에 대해 호환되지 않으면 오동작으로 이어지는 잘못된 쿼리 결과를 초래합니다 (보조 사이트에서 잘못된 동작을 초래하는 잘못된 쿼리 결과).
예를 들어, Ubuntu 18.04(이전 버전) 및 RHEL/CentOS 7(이전 버전)은 각각 나중 버전과 호환되지 않습니다. 자세한 내용은 PostgreSQL 위키를 참조하십시오.
일반 오류 해결
이 섹션에는 웹 인터페이스의 관리 영역에서 보고된 일반 오류 메시지와 그 해결 방법에 대해 문서화되어 있습니다.
Geo 데이터베이스 구성 파일이 없음
GitLab이 database_geo.yml 구성 파일을 찾지 못하거나 액세스할 수 있는 권한이 없습니다.
Linux 패키지 설치에서 파일은 /var/opt/gitlab/gitlab-rails/etc에 있어야 합니다.
해당 경로에 파일이 없거나 실수로 변경되었다면 sudo gitlab-ctl reconfigure를 실행하여 올바른 상태로 복원하십시오.
이 경로가 원격 볼륨에 마운트된 경우 볼륨 구성이 올바른 권한을 가지고 있는지 확인하십시오.
기존 추적 데이터베이스를 재사용할 수 없음
Geo는 기존 추적 데이터베이스를 재사용할 수 없습니다.
가장 안전한 방법은 새로운 보조를 사용하거나 복제를 재설정하는 것입니다.
Geo 이벤트를 놓치고 보조 사이트에서 데이터가 삭제되어야 하는 경우 등 리스크를 극복하려면 보조 사이트를 재설정하는 것이 가장 좋습니다. 이러한 이유로 GitLab은 데이터 이동이 필요하지 않도록 해시 리포지터리로 전환했습니다. 보조 사이트에는 이래 하지 않은 여러 문제가 있을 수 있습니다. 이러한 리스크가 해당되지 않는 경우, 예를 들어 테스트 환경이나 Geo 사이트 추가 이후에 모든 Geo 이벤트가 여전히 주 데이터베이스에 있는지 알고 있는 경우에는 해당 건강 검사를 우회할 수 있습니다.
-
마지막 처리된 이벤트 시간을 얻습니다. 보조 사이트의 Rails 콘솔에서 다음을 실행하십시오:
Geo::EventLogState.last.created_at.utc - 출력된 값을 복사하십시오. 예를 들어
2024-02-21 23:50:50.676918 UTC입니다. -
보조 사이트의 생성된 시간을 오래된 것처럼 보이도록 업데이트하십시오. 기본 사이트의 Rails 콘솔에서 다음을 실행하십시오:
GeoNode.secondary_nodes.last.update_column(:created_at, DateTime.parse('2024-02-21 23:50:50.676918 UTC') - 1.second)이 명령은 영향 받는 보조 사이트가 마지막으로 생성된 사이트라고 가정합니다.
-
Admin > Geo > Sites으로 이동하여 보조 사이트의 상태를 업데이트하십시오. 보조 사이트의 Rails 콘솔에서 다음을 실행하십시오:
Geo::MetricsUpdateWorker.new.perform - 보조 사이트는 정상적으로 표시되어야 합니다. 그렇지 않은 경우에는 보조 사이트에서
gitlab-rake gitlab:geo:check를 실행하거나 보조 사이트를 다시 시작해 보십시오. - 누락된 또는 오래된 데이터를 다시 동기화하려면 Admin > Geo > Sites으로 이동하십시오.
- 보조 사이트 아래에서 Replication Details를 선택하십시오.
- 각 데이터 유형에 대해 Reverify all을 선택하십시오.
Geo 사이트에는 쓰기 가능한 데이터베이스가 있으며, 이는 주 사이트와의 복제가 구성되지 않았음을 나타냅니다.
이 오류 메시지는 secondary 사이트의 데이터베이스 복제에 문제가 있다는 것을 가리키며, Geo가 액세스해야 하는 것으로 예상됩니다. 일반적으로 다음 사항을 의미합니다.
- 지원되지 않는 복제 방법이 사용되었습니다(예: 논리적 복제).
- Geo 데이터베이스 복제 설정 지침이 올바르게 따라지지 않았습니다.
- 데이터베이스 연결 세부 정보가 잘못되었습니다. 즉,
/etc/gitlab/gitlab.rb파일에서 잘못된 사용자를 지정했습니다.
Geo secondary 사이트에는 다음이 필요합니다.
- 주 사이트의 읽기 전용 레플리카.
- 복제 메타데이터를 보유하는 일반적이며 쓰기 가능한 인스턴스. 즉, Geo 추적 데이터벤이스입니다.
이 오류 메시지는 secondary 사이트의 레플리카 데이터베이스가 잘못 구성되어 있고, 복제가 중단되었음을 나타냅니다.
데이터베이스를 복원하고 복제를 재개하려면 다음 중 하나를 수행할 수 있습니다.
- Geo secondary 사이트 복제 재설정.
- Linux 패키지를 사용하여 새로운 Geo secondary 설정](../../setup/index.md#using-linux-package-installations).
새로운 secondary를 처음부터 설정한다면, Geo 클러스터에서 이전 사이트를 제거해야 합니다.
Geo 사이트에서 주 사이트로부터 데이터베이스를 복제하지 않는 것으로 나타납니다.
데이터베이스가 올바르게 복제되지 못하는 가장 흔한 문제점은 다음과 같습니다.
- Secondary 사이트가 주 사이트에 연결할 수 없습니다. 자격 증명 및 방화벽 규칙을 확인하세요.
- SSL 인증서 문제.
/etc/gitlab/gitlab-secrets.json을 주 사이트에서 복사했는지 확인하세요. - 데이터베이스 저장 디스크가 가득 찼습니다.
- 데이터베이스 복제 슬롯이 잘못 구성되었습니다.
- 데이터베이스가 복제 슬롯을 사용하고 있지 않거나 다른 대체 방법을 사용하며 WAL 파일이 정리되어 따라잡을 수 없습니다.
지원되는 구성을 위한 Geo 데이터베이스 복제 지침을 준수해야 합니다.
Geo 데이터베이스 버전 (…)이(가) 최신 마이그레이션 (…)과(와) 일치하지 않습니다.
Linux 패키지 설치를 사용하는 경우, 업그레이드 중에 실패한 것일 수 있습니다. 다음을 수행할 수 있습니다.
-
sudo gitlab-ctl reconfigure실행. - 루트로
sudo gitlab-rake db:migrate:geo를 실행하여 secondary 사이트에서 데이터베이스 마이그레이션을 수동으로 트리거합니다.
GitLab에서 리포지터리의 100% 이상이 동기화되었다는 메시지
이는 프로젝트 레지스트리에 고아 레코드가 있는 경우에 발생할 수 있습니다. 주기적으로 레지스트리 워커를 사용하여 정리되므로 자체적으로 문제를 해결할 시간을 주세요.
external_url 값 변경 후 UI에서 Unhealthy로 표시된 Secondary 사이트
/etc/gitlab/gitlab.rb의 external_url 값을 업데이트했거나 프로토콜을 http에서 https로 변경한 경우, Secondary 사이트가 Unhealthy로 표시됩니다. 또한 geo.log에 다음과 같은 오류가 표시될 수 있습니다.
"class": "Geo::NodeStatusRequestService",
...
"message": "Failed to Net::HTTP::Post to primary url: http://primary-site.gitlab.tld/api/v4/geo/status",
"error": "Failed to open TCP connection to <PRIMARY_IP_ADDRESS>:80 (Connection refused - connect(2) for \"<PRIMARY_ID_ADDRESS>\" port 80)"
이 경우, 변경된 URL을 모든 사이트에서 업데이트하는 것을 확인하세요.
- 왼쪽 사이드바에서 가장 아래에서 관리자 영역을 선택합니다.
- Geo > 사이트를 선택합니다.
- URL을 변경하고 변경 내용을 저장합니다.
백업 중에 메시지: ERROR: canceling statement due to conflict with recovery 표시
Geo secondary에서 백업을 실행하는 것은 지원되지 않습니다.
Secondary에서 백업을 실행하는 경우, 다음과 같은 오류 메시지가 표시될 수 있습니다.
PostgreSQL 데이터베이스 gitlabhq_production을 덤프하는 중...
pg_dump: error: 테이블 "notes"의 내용을 덤프하는 데 실패했습니다: PQgetResult()가 실패했습니다.
pg_dump: error: 서버로부터의 오류 메시지: ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
pg_dump: error: 명령은 다음과 같습니다.: COPY public.notes (id, note, [...], last_edited_at) TO stdout;
GitLab 업그레이드 중에 Geo secondary에서 자동으로 데이터베이스 백업이 이루어지지 않도록 하려면 다음 빈 파일을 생성하세요.
sudo touch /etc/gitlab/skip-auto-backup
도움말