InfoGrab DocsInfoGrab Docs

일반 Geo 오류 문제 해결

요약

Rake 태스크가 `OpenSSH configured to use AuthorizedKeysCommand` 검사를 건너뛰면 다음 출력이 표시됩니다: OpenSSH configured to use AuthorizedKeysCommand ...

| --- | --- | | NTP_HOST | NTP 호스트. | pool.ntp.org | | NTP_PORT | 호스트가 수신 대기하는 NTP 포트. | 123 | | NTP_TIMEOUT | NTP 타임아웃(초). | net-ntp Ruby 라이브러리에 정의된 값(60초). |

Rake 태스크가 `OpenSSH configured to use AuthorizedKeysCommand` 검사를 건너뛰면 다음 출력이 표시됩니다:

#

OpenSSH configured to use AuthorizedKeysCommand ... skipped

Reason: Cannot access OpenSSH configuration file Try fixing it: This is expected if you are using SELinux. You may want to check configuration manually For more information see:
doc/administration/operations/fast_ssh_key_lookup.md#

이 문제는 다음과 같은 경우에 발생할 수 있습니다:

  • [SELinux](/19.2/administration/operations/fast_ssh_key_lookup/#selinux-support)를 사용하는 경우.
  • 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(Puma, Sidekiq, 또는 Geo Log Cursor)를 실행하는 모든 노드에서 이 Rake 태스크를 실행하여 수동으로 확인할 수 있습니다.

GitLab은 오브젝트 스토리지에 저장된 오브젝트를 검증하지 않습니다. 오브젝트 스토리지를 사용하는 경우, "verified" 검사가 모두 성공 횟수 0으로 표시됩니다. 이는 정상적인 동작이며 문제가 아닙니다.

#
sudo gitlab-rake gitlab:geo:status#

출력 내용에는 다음이 포함됩니다:

  • 실패가 발생한 경우 "failed" 항목의 수
  • "total" 대비 "succeeded" 항목의 비율
예시:
#

Geo Site Information#

Name: example-us-east-2 URL: https://gitlab.example.com Geo Role: Secondary Health Status: Healthy This Node's GitLab Version: 17.7.0-ee

Replication Information#

Sync Settings: Full Database replication lag: 0 seconds Last event ID seen from primary: 12345 (about 2 minutes ago) Last event ID processed: 12345 (about 2 minutes ago) Last status report was: 1 minute ago

Replication Status#

Lfs Objects replicated: succeeded 111 / total 111 (100%) Merge Request Diffs replicated: succeeded 28 / total 28 (100%) Package Files replicated: succeeded 90 / total 90 (100%) Terraform State Versions replicated: succeeded 65 / total 65 (100%) Snippet Repositories replicated: succeeded 63 / total 63 (100%) Group Wiki Repositories replicated: succeeded 14 / total 14 (100%) Pipeline Artifacts replicated: succeeded 112 / total 112 (100%) Pages Deployments replicated: succeeded 55 / total 55 (100%) Uploads replicated: succeeded 2 / total 2 (100%) Job Artifacts replicated: succeeded 32 / total 32 (100%) Ci Secure Files replicated: succeeded 44 / total 44 (100%) Dependency Proxy Blobs replicated: succeeded 15 / total 15 (100%) Dependency Proxy Manifests replicated: succeeded 2 / total 2 (100%) Project Wiki Repositories replicated: succeeded 2 / total 2 (100%) Design Management Repositories replicated: succeeded 1 / total 1 (100%) Project Repositories replicated: succeeded 2 / total 2 (100%)

Verification Status#

Lfs Objects verified: succeeded 111 / total 111 (100%) Merge Request Diffs verified: succeeded 28 / total 28 (100%) Package Files verified: succeeded 90 / total 90 (100%) Terraform State Versions verified: succeeded 65 / total 65 (100%) Snippet Repositories verified: succeeded 63 / total 63 (100%) Group Wiki Repositories verified: succeeded 14 / total 14 (100%) Pipeline Artifacts verified: succeeded 112 / total 112 (100%) Pages Deployments verified: succeeded 55 / total 55 (100%) Uploads verified: succeeded 2 / total 2 (100%) Job Artifacts verified: succeeded 32 / total 32 (100%) Ci Secure Files verified: succeeded 44 / total 44 (100%) Dependency Proxy Blobs verified: succeeded 15 / total 15 (100%) Dependency Proxy Manifests verified: succeeded 2 / total 2 (100%) Project Wiki Repositories verified: succeeded 2 / total 2 (100%) Design Management Repositories verified: succeeded 1 / total 1 (100%)
Project Repositories verified: succeeded 2 / total 2 (100%)#

모든 오브젝트가 복제 및 검증됩니다. 이는 [Geo 용어집](/19.2/administration/geo/glossary/)에 정의되어 있습니다. 각 데이터 유형의 복제 및 검증 방법에 대한 자세한 내용은 [지원되는 Geo 데이터 유형](/19.2/administration/geo/replication/datatypes/#data-types)을 참조하세요.

실패한 항목에 대한 자세한 정보를 확인하려면

[`gitlab-rails/geo.log` 파일](/19.2/administration/logs/log_parsing/#find-most-common-geo-sync-errors)을 확인하세요.

복제 또는 검증 실패가 발견되면 [해결 방법](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/)을 시도할 수 있습니다.

##### Geo 검사 Rake 태스크 실행 시 발견된 오류 수정

이 Rake 태스크를 실행할 때 노드가 올바르게 구성되지 않은 경우 오류 메시지가 표시될 수 있습니다:

#
sudo gitlab-rake gitlab:geo:check#

-

Rails가 데이터베이스에 연결할 때 비밀번호를 제공하지 않았습니다.

#

Checking Geo ...

GitLab Geo is available ... Exception: fe_sendauth: no password supplied

GitLab Geo is enabled ... Exception: fe_sendauth: no password supplied

...
Checking Geo ... Finished#

`postgresql['sql_user_password']`에 대한 해시를 생성할 때 사용한 일반 텍스트 비밀번호로 `gitlab_rails['db_password']`가 설정되어 있는지 확인하세요.

-

Rails가 데이터베이스에 연결할 수 없습니다.

#

Checking Geo ...

GitLab Geo is available ... 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 is enabled ... 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

...
Checking Geo ... Finished#

Rails 노드의 IP 주소가 `postgresql['md5_auth_cidr_addresses']`에 포함되어 있는지 확인하세요.

또한 IP 주소에 서브넷 마스크가 포함되어 있는지 확인하세요: `postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']`.

-

Rails가 잘못된 비밀번호를 제공했습니다.

#

Checking Geo ...

GitLab Geo is available ... Exception: FATAL: password authentication failed for user "gitlab"

FATAL: password authentication failed for user "gitlab"

GitLab Geo is enabled ... Exception: FATAL: password authentication failed for user "gitlab"

FATAL: password authentication failed for user "gitlab"

...
Checking Geo ... Finished#

`gitlab-ctl pg-password-md5 gitlab`을 실행하고 비밀번호를 입력하여 `postgresql['sql_user_password']`의 해시를 생성할 때 사용한 `gitlab_rails['db_password']`에 올바른 비밀번호가 설정되어 있는지 확인하세요.

-

검사 결과 `not a secondary node`가 반환됩니다.

#

Checking Geo ...

GitLab Geo is available ... yes

GitLab Geo is enabled ... yes

GitLab Geo tracking database is correctly configured ... not a secondary node

Database replication enabled? ... not a secondary node

...
Checking Geo ... Finished#

기본 사이트의 웹 인터페이스에서 관리자 영역의 Geo > 사이트에서 보조 사이트를 추가했는지 확인하세요.

또한 기본 사이트의 관리자 영역에서 보조 사이트를 추가할 때 `gitlab_rails['geo_node_name']`을 입력했는지 확인하세요.

-

검사 결과 `Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist`가 반환됩니다.

#

Checking Geo ...

GitLab Geo is available ... no

Try fixing it: Add a new license that includes the GitLab Geo feature For more information see: https://about.gitlab.com/features/gitlab-geo/

GitLab Geo is enabled ... Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist

LINE 8: WHERE a.attrelid = '"geo_nodes"'::regclass

^

: SELECT a.attname, format_type(a.atttypid, a.atttypmod),

pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod, c.collname, col_description(a.attrelid, a.attnum) AS comment FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum LEFT JOIN pg_type t ON a.atttypid = t.oid LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation WHERE a.attrelid = '"geo_nodes"'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum ...
Checking Geo ... Finished#

PostgreSQL 메이저 버전 업그레이드(9 > 10) 시 이는 예상된 동작입니다. [복제 프로세스 시작](/19.2/administration/geo/setup/database/#step-3-initiate-the-replication-process)을 따르세요.

-

Rails에 Geo 추적 데이터베이스에 연결하는 데 필요한 구성이 없는 것으로 보입니다.

#

Checking Geo ...

GitLab Geo is available ... yes

GitLab Geo is enabled ... yes

GitLab Geo tracking database is correctly configured ... no

Try fixing it:

Rails does not appear to have the configuration necessary to connect to the Geo tracking database. If the tracking database is running on a node other than this one, then you may need to add configuration.

...
Checking Geo ... Finished#
  • 모든 서비스를 단일 노드에서 실행 중인 보조 사이트의 경우, [Geo 데이터베이스 복제 - 보조 서버 구성](/19.2/administration/geo/setup/database/#step-2-configure-the-secondary-server)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 별도 노드에서 실행 중인 경우, [다중 서버를 위한 Geo - Geo 보조 사이트에서 Geo 추적 데이터베이스 구성](/19.2/administration/geo/replication/multiple_servers/#step-2-configure-the-geo-tracking-database-on-the-geo-secondary-site)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 Patroni 클러스터에서 실행 중인 경우, [Geo 데이터베이스 복제 - 추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성](/19.2/administration/geo/setup/database/#configuring-patroni-cluster-for-the-tracking-postgresql-database)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 외부 데이터베이스에서 실행 중인 경우, [외부 PostgreSQL 인스턴스를 사용하는 Geo](/19.2/administration/geo/setup/external_database/#configure-the-tracking-database)를 따르세요.
  • GitLab Rails 앱(Puma, Sidekiq, 또는 Geo Log Cursor)을 실행하는 서비스가 없는 노드에서 Geo 검사 태스크를 실행한 경우, 이 오류는 무시할 수 있습니다. 해당 노드에는 Rails 구성이 필요하지 않습니다.
##### 메시지: Container Registry Geo events … none found

`Container Registry Geo events ... none found`가 표시되고 컨테이너 레지스트리 복제 이벤트가 있을 것으로 예상되는 경우, 기본 사이트의 레지스트리 알림 구성이 [컨테이너 레지스트리 복제 구성 가이드](/19.2/administration/geo/replication/container_registry/#configure-primary-site)에 따라 설정되어 있는지 확인하세요.

##### 메시지: Machine clock is synchronized … Exception

Rake 태스크는 서버 시계가 NTP와 동기화되어 있는지 확인하려고 합니다. Geo가 올바르게 작동하려면 동기화된 시계가 필요합니다. 예를 들어, 보안상의 이유로 기본 사이트와 보조 사이트의 서버 시간이 약 1분 이상 차이가 나면 Geo 사이트 간 요청이 실패합니다. 이 검사 태스크가 시간 불일치 이외의 이유로 완료에 실패하더라도, 반드시 Geo가 작동하지 않는다는 의미는 아닙니다.

검사를 수행하는 Ruby gem은 참조 시간 소스로 `pool.ntp.org`가 하드 코딩되어 있습니다.

-

예외 메시지 `Machine clock is synchronized ... Exception: Timeout::Error`

이 문제는 서버가 호스트 `pool.ntp.org`에 접근할 수 없을 때 발생합니다.

-

예외 메시지 `Machine clock is synchronized ... Exception: No route to host - recvfrom(2)`

이 문제는 호스트명 `pool.ntp.org`가 시간 서비스를 제공하지 않는 서버로 해석될 때 발생합니다.

이 경우, GitLab 15.7 이상에서는 [환경 변수를 사용하여 사용자 정의 NTP 서버를 지정](/19.2/administration/geo/replication/troubleshooting/common/#health-check-rake-task)하세요.

GitLab 15.6 이하에서는 다음 중 하나의 임시 해결 방법을 사용하세요:

  • `/etc/hosts`에 `pool.ntp.org`에 대한 항목을 추가하여 요청을 유효한 로컬 타임 서버로 전달하세요.
이렇게 하면 긴 타임아웃과 타임아웃 오류가 해결됩니다.
  • 임의의 유효한 IP 주소로 검사를 전달하세요. 이렇게 하면 타임아웃 문제는 해결되지만, 앞서 언급한 대로 `No route to host` 오류와 함께 검사가 실패합니다.
Cloud Native GitLab 배포는 쿠버네티스의 컨테이너가 호스트 시계에 접근할 수 없기 때문에 오류가 발생합니다:
#
Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype#

##### 메시지: cannot execute INSERT in a read-only transaction

보조 사이트에서 이 오류가 발생하면 `gitlab-rails` 또는 `gitlab-rake` 명령어와 같은 GitLab Rails의 모든 사용 및 Puma, Sidekiq, Geo Log Cursor 서비스에 영향을 미칩니다.

#

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 `'

/opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `'

/opt/gitlab/embedded/bin/bundle:23:in `load'

/opt/gitlab/embedded/bin/bundle:23:in `
'#

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"#

이 상황은 다음과 같은 경우에 발생할 수 있습니다:

-

보조 사이트가 아직 자신이 보조 사이트임을 인식하지 못하는 초기 구성 단계에서 발생합니다. 오류를 해결하려면 [3단계. 보조 사이트 추가](/19.2/administration/geo/replication/configuration/#step-3-add-the-secondary-site)를 따르세요.

-

Geo 보조 사이트 업그레이드 중에 발생합니다. `gitlab_rails['auto_migrate']`가 `true`로 설정되어 있어 GitLab이 복제본 데이터베이스에서 데이터베이스 마이그레이션을 시도할 수 있는데, 이는 필요하지 않습니다. 오류를 해결하려면:

보조 사이트의 GitLab Rails 노드에 root로 SSH 접속하세요.

-

`/etc/gitlab/gitlab.rb`를 편집하고 이 설정을 주석 처리하거나 false로 설정하세요:

#
gitlab_rails['auto_migrate'] = false#

-

GitLab을 재구성하세요:

#
sudo gitlab-ctl reconfigure#

### PostgreSQL 복제가 작동하는지 확인

PostgreSQL 복제가 작동하는지 확인하려면 다음을 점검하세요:

  • [사이트가 올바른 데이터베이스 노드를 가리키는지](/19.2/administration/geo/replication/troubleshooting/common/#are-sites-pointing-to-the-correct-database-node) 확인.
  • [Geo가 현재 사이트를 올바르게 감지할 수 있는지](/19.2/administration/geo/replication/troubleshooting/common/#can-geo-detect-the-current-site-correctly) 확인.
여전히 문제가 있는 경우, [고급 복제 문제 해결](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/)을 참조하세요.

#### 사이트가 올바른 데이터베이스 노드를 가리키고 있나요?

기본 Geo [사이트](/19.2/administration/geo/glossary/)가 쓰기 권한을 가진 데이터베이스 노드를 가리키는지 확인하세요.

보조 사이트는 읽기 전용 데이터베이스 노드만 가리켜야 합니다.

#### Geo가 현재 사이트를 올바르게 감지할 수 있나요?

Geo는 다음 로직으로 `/etc/gitlab/gitlab.rb`에서 현재 Puma 또는 Sidekiq 노드의 Geo [사이트](/19.2/administration/geo/glossary/) 이름을 찾습니다:

Linux 패키지: `gitlab_rails['geo_node_name']` 설정을 가져옵니다.
  • GitLab Helm 차트: `global.geo.nodeName` 설정을 가져옵니다(Charts와 GitLab Geo 참조).
  • 정의되지 않은 경우, `external_url` 설정을 가져옵니다.
이 이름은 Geo 사이트 대시보드에서 동일한 이름을 가진 Geo 사이트를 조회하는 데 사용됩니다.

현재 머신의 사이트 이름이 데이터베이스의 사이트와 일치하는지 확인하려면 검사 태스크를 실행하세요:

#
sudo gitlab-rake gitlab:geo:check#

현재 머신의 사이트 이름과 일치하는 데이터베이스 레코드가 기본 사이트인지 보조 사이트인지를 표시합니다.

#
This machine's Geo node name matches a database record ... yes, found a secondary node named "Shanghai"#
#

This machine's Geo node name matches a database record ... no

Try fixing it: You could add or update a Geo node database record, setting the name to "https://example.com/". Or you could set this machine's Geo node name to match the name of an existing database record: "London", "Shanghai" For more information see:
doc/administration/geo/replication/troubleshooting/_index.md#can-geo-detect-the-current-node-correctly#

이름 필드 설명에서 권장되는 사이트 이름에 대한 자세한 내용은

[Geo 관리자 영역 공통 설정](/19.2/administration/geo_sites/#common-settings)을 참조하세요.

### OS 로케일 데이터 호환성 확인

가능하면 모든 사이트의 모든 Geo 노드는 [Geo 실행 요구 사항](/19.2/administration/geo/#requirements-for-running-geo)에 정의된 것과 동일한 방법 및 운영 체제로 배포되어야 합니다.

Geo 사이트에 서로 다른 운영 체제 또는 다른 운영 체제 버전이 배포된 경우, Geo를 설정하기 전에 로케일 데이터 호환성 검사를 반드시 수행해야 합니다. GitLab 배포 방법을 혼합하여 사용하는 경우에는 `glibc`도 확인해야 합니다. Linux 패키지 설치, GitLab Docker 컨테이너, Helm 차트 배포 또는 외부 데이터베이스 서비스 간에 로케일이 다를 수 있습니다. `glibc` 버전 호환성 확인 방법을 포함한 [PostgreSQL 운영 체제 업그레이드 문서](/19.2/administration/postgresql/upgrading_os/)를 참조하세요.

Geo는 PostgreSQL과 스트리밍 복제를 사용하여 Geo 사이트 간에 데이터를 복제합니다. PostgreSQL은 텍스트 정렬을 위해 운영 체제의 C 라이브러리가 제공하는 로케일 데이터를 사용합니다. C 라이브러리의 로케일 데이터가 Geo 사이트 간에 호환되지 않으면 보조 사이트에서 잘못된 동작을 유발하는 잘못된 쿼리 결과가 발생합니다.

예를 들어, Ubuntu 18.04(이하)와 RHEL/CentOS 7(이하)은 이후 릴리즈와 호환되지 않습니다.

자세한 내용은 PostgreSQL 위키를 참조하세요.

## 일반적인 오류 수정

이 섹션에서는 웹 인터페이스의 관리자 영역에 보고되는 일반적인 오류 메시지와 수정 방법을 설명합니다.

### 기존 추적 데이터베이스를 재사용할 수 없음

Geo는 기존 추적 데이터베이스를 재사용할 수 없습니다.

새 보조 사이트를 사용하거나, [Geo 보조 사이트 복제 재설정](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/#resetting-geo-secondary-site-replication)을 따라 전체 보조 사이트를 재설정하는 것이 가장 안전합니다.

보조 사이트를 재설정하지 않고 재사용하면 보조 사이트가 일부 Geo 이벤트를 놓쳤을 수 있어 위험합니다. 예를 들어, 누락된 삭제 이벤트는 보조 사이트에 삭제되어야 할 데이터가 영구적으로 남아 있게 합니다. 마찬가지로, 데이터의 물리적 위치를 이동하는 이벤트를 잃으면 한 위치에 데이터가 영구적으로 고아 상태가 되고 다른 위치에서는 재검증될 때까지 누락됩니다. 이것이 GitLab이 데이터 이동을 불필요하게 만드는 해시 스토리지로 전환한 이유입니다. 손실된 이벤트로 인한 다른 알 수 없는 문제가 있을 수 있습니다.

테스트 환경과 같이 이러한 위험이 적용되지 않는 경우, 또는 Geo 사이트가 추가된 이후로 메인 Postgres 데이터베이스에 모든 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)#

이 명령은 마지막으로 생성된 보조 사이트가 영향을 받는 사이트라고 가정합니다.

-

관리자 > Geo > 사이트에서 보조 사이트의 상태를 업데이트하세요. 보조 사이트의 Rails 콘솔에서 다음을 실행하세요:

#
Geo::MetricsUpdateWorker.new.perform#

-

보조 사이트가 정상으로 표시되어야 합니다. 그렇지 않으면 보조 사이트에서 `gitlab-rake gitlab:geo:check`를 실행하거나, 보조 사이트를 다시 추가한 이후 Rails를 아직 재시작하지 않았다면 재시작해 보세요.

-

누락되거나 오래된 데이터를 다시 동기화하려면 관리자 > Geo > 사이트로 이동하세요.

-

보조 사이트 아래에서 복제 세부 정보를 선택하세요.

-

모든 데이터 유형에 대해 모두 재검증을 선택하세요.

### Geo 사이트에 쓰기 가능한 데이터베이스가 있음

이 오류 메시지는 Geo가 접근할 것으로 예상하는 보조 사이트의 데이터베이스 복제본 문제를 나타냅니다. 쓰기 가능한 보조 사이트 데이터베이스는 데이터베이스가 기본 사이트와의 복제를 위해 구성되지 않았음을 나타냅니다. 일반적으로 다음 중 하나를 의미합니다:

  • 지원되지 않는 복제 방법이 사용되었습니다(예: 논리 복제).
  • [Geo 데이터베이스 복제](/19.2/administration/geo/setup/database/) 설정 지침을 올바르게 따르지 않았습니다.
  • `/etc/gitlab/gitlab.rb` 파일에서 잘못된 사용자를 지정하는 등 데이터베이스 연결 정보가 올바르지 않습니다.
Geo 보조 사이트에는 두 개의 별도 PostgreSQL 인스턴스가 필요합니다:
  • 기본 사이트의 읽기 전용 복제본.
  • 복제 메타데이터를 보관하는 일반적인 쓰기 가능 인스턴스. 즉, Geo 추적 데이터베이스.
이 오류 메시지는 보조 사이트의 복제본 데이터베이스가 잘못 구성되어 복제가 중단되었음을 나타냅니다.

데이터베이스를 복원하고 복제를 재개하려면 다음 중 하나를 수행할 수 있습니다:

  • [Geo 보조 사이트 복제 재설정](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/#resetting-geo-secondary-site-replication).
  • [Linux 패키지를 사용하여 새 Geo 보조 사이트 설정](/19.2/administration/geo/setup/#using-linux-package-installations).
새 보조 사이트를 처음부터 설정하는 경우, [Geo 클러스터에서 이전 사이트를 제거](/19.2/administration/geo/replication/remove_geo_site/)해야 합니다.

### Geo 사이트가 기본 사이트에서 데이터베이스를 복제하지 않는 것으로 보임

데이터베이스가 올바르게 복제되지 않는 가장 일반적인 문제는 다음과 같습니다:

  • 보조 사이트가 기본 사이트에 도달할 수 없습니다. 자격 증명과
[방화벽 규칙](/19.2/administration/geo/#firewall-rules)을 확인하세요.
  • SSL 인증서 문제. 기본 사이트에서 `/etc/gitlab/gitlab-secrets.json`을 복사했는지 확인하세요.
  • 데이터베이스 스토리지 디스크가 가득 찼습니다.
  • 데이터베이스 복제 슬롯이 잘못 구성되었습니다.
  • 데이터베이스가 복제 슬롯이나 다른 대안을 사용하지 않아 WAL 파일이 삭제되어 따라잡을 수 없습니다.
지원되는 구성에 대해 [Geo 데이터베이스 복제](/19.2/administration/geo/setup/database/) 지침을 따르세요.

### Geo 데이터베이스 버전(…)이 최신 마이그레이션(…)과 일치하지 않음

Linux 패키지 설치를 사용하는 경우, 업그레이드 중에 문제가 발생했을 수 있습니다. 다음을 수행할 수 있습니다:

  • `sudo gitlab-ctl reconfigure`를 실행하세요.
  • 보조 사이트에서 root로 `sudo gitlab-rake db:migrate:geo`를 실행하여 데이터베이스 마이그레이션을 수동으로 트리거하세요.
### GitLab이 100%를 초과하는 리포지터리가 동기화되었다고 표시함

이는 프로젝트 레지스트리의 고아 레코드로 인해 발생할 수 있습니다. 레지스트리 워커를 사용하여 주기적으로 정리되므로, 자동으로 수정될 때까지 잠시 기다리세요.

### 기본 사이트의 체크섬 실패

Geo 기본 검증 정보 화면에서 식별된 체크섬 실패는 파일 누락이나 체크섬 불일치로 인해 발생할 수 있습니다. `gitlab-rails/geo.log` 파일에서 `"Repository cannot be checksummed because it does not exist"` 또는 `"File is not checksummable - file does not exist at: "`와 같은 오류 메시지를 찾을 수 있습니다. 오류 메시지에는 누락된 파일을 식별하는 데 도움이 되는 파일 경로가 포함되어 있습니다.

실패한 항목에 대한 추가 정보를 얻으려면 [무결성 검사 Rake 태스크](/19.2/administration/raketasks/check/#uploaded-files-integrity)를 실행하세요:

#

sudo gitlab-rake gitlab:artifacts:check

sudo gitlab-rake gitlab:ci_secure_files:check

sudo gitlab-rake gitlab:lfs:check

sudo gitlab-rake gitlab:uploads:check#

개별 오류에 대한 자세한 정보를 보려면 `VERBOSE=1` 변수를 사용하세요.

### 보조 사이트가 UI에서 비정상으로 표시됨

기본 사이트의 `/etc/gitlab/gitlab.rb`에서 `external_url` 값을 업데이트하거나 프로토콜을 `http`에서 `https`로 변경한 경우, 보조 사이트가 비정상으로 표시될 수 있습니다. `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 :80 (Connection refused - connect(2) for \"\" port 80)"#

이 경우, 모든 사이트에서 변경된 URL을 업데이트하세요:

  • 오른쪽 상단 모서리에서 관리자를 선택하세요.
  • 왼쪽 사이드바에서 Geo > 사이트를 선택하세요.
  • URL을 변경하고 저장하세요.
### 메시지: ERROR: canceling statement due to conflict with recovery during backup

Geo 보조 사이트에서 백업을 실행하는 것은 지원되지 않습니다.

보조 사이트에서 백업을 실행하면 다음 오류 메시지가 발생할 수 있습니다:

#

Dumping PostgreSQL database gitlabhq_production ...

pg_dump: error: Dumping the contents of table "notes" failed: PQgetResult() failed.

pg_dump: error: Error message from server: 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: The command was: COPY public.notes (id, note, [...], last_edited_at) TO stdout;#

Geo 보조 사이트에서 GitLab 업그레이드 중 데이터베이스 백업이 자동으로 실행되는 것을 방지하려면 다음 빈 파일을 생성하세요:

#
sudo touch /etc/gitlab/skip-auto-backup#

### 오브젝트 검증 중 기본 사이트의 높은 CPU 사용량

GitLab 16.11부터 GitLab 17.2까지, 누락된 PostgreSQL 인덱스로 인해 높은 CPU 사용량과 느린 아티팩트 검증 진행이 발생합니다. 또한 Geo 보조 사이트가 비정상으로 보고될 수 있습니다. 이슈 471727에서 이 동작을 자세히 설명합니다.

이 문제가 발생하는지 확인하려면 영향 여부 확인 단계를 따르세요.

영향을 받는 경우, 임시 해결 방법의 단계에 따라 수동으로 인덱스를 생성하세요. 인덱스를 생성하면 완료될 때까지 PostgreSQL이 리소스를 약간 더 소비합니다. 이후 검증이 계속되는 동안 CPU 사용량이 높게 유지될 수 있지만, 쿼리는 훨씬 빠르게 완료되고 보조 사이트 상태가 올바르게 업데이트되어야 합니다.

### 검증 실패: Verification timed out after (...)

GitLab 16.11부터 Geo는 동일한 `artifact_id`에 대해 중복 `JobArtifactRegistry` 항목을 생성할 수 있으며, 이는 기본 사이트와 보조 사이트 간의 동기화 실패로 이어질 수 있습니다. 이 문제는 `UploadRegistry` 및 `PackageFileRegistry` 항목에도 영향을 미칠 수 있습니다.

이 문제가 발생하는지 확인하고 중복 항목을 제거하려면:

-

보조 사이트에서 [Rails 콘솔](/19.2/administration/operations/rails_console/)을 여세요.

-

중복이 있는 모델 레코드 ID의 수를 가져오세요:

#

artifact_ids = Geo::JobArtifactRegistry.group(:artifact_id).having('COUNT(*) > 1').pluck(:artifact_id); artifact_ids.size

upload_ids = Geo::UploadRegistry.group(:file_id).having('COUNT(*) > 1').pluck(:file_id); upload_ids.size

package_file_ids = Geo::PackageFileRegistry.group(:package_file_id).having('COUNT(*) > 1').pluck(:package_file_id); package_file_ids.size#

-

ID를 출력하세요:

#

puts 'BEGIN Artifact IDs', artifact_ids, 'END Artifact IDs'

puts 'BEGIN Upload IDs', upload_ids, 'END Upload IDs'

puts 'BEGIN Package File IDs', package_file_ids, 'END Package File IDs'#

출력이 비어 있으면 영향을 받지 않은 것입니다. 그렇지 않으면 나중에 연결이 끊어질 경우를 대비하여 터미널 출력을 텍스트 파일에 저장하세요.

-

모든 중복을 삭제하세요:

#

Geo::JobArtifactRegistry.where(artifact_id: artifact_ids).delete_all

Geo::UploadRegistry.where(file_id: upload_ids).delete_all

Geo::PackageFileRegistry.where(package_file_id: package_file_ids).delete_all#

-

백그라운드 job이 레지스트리 행을 다시 생성하고 재동기화할 때까지 기다리세요.

수정에 대한 피드백을 얻으려면 이슈 479852를 팔로우하세요.

### 보조 사이트에서 Geo Rake 검사 태스크 실행 시 end of file reached 오류

보조 사이트에서 [상태 확인 Rake 태스크](/19.2/administration/geo/replication/troubleshooting/common/#health-check-rake-task)를 실행할 때 다음 오류가 발생할 수 있습니다:

#

Can connect to the primary node ... no

Reason:

end of file reached#

설정에서 기본 사이트에 대한 잘못된 URL이 지정된 경우 이 오류가 발생할 수 있습니다. 문제를 해결하려면 [Rails 콘솔](/19.2/administration/operations/rails_console/)에서 다음 명령을 실행하세요:

#

primary = Gitlab::Geo.primary_node

primary.internal_uri

Gitlab::HTTP.get(primary.internal_uri, allow_local_requests: true, limit: 10)#

이전 출력에서 `internal_uri`의 값이 올바른지 확인하세요.

기본 사이트의 URL이 올바르지 않은 경우, `/etc/gitlab/gitlab.rb`와 관리자 > Geo > 사이트에서 다시 확인하세요.

### Geo 메트릭 수집로 인한 과도한 데이터베이스 IO

빈번한 Geo 메트릭 수집으로 인해 데이터베이스 부하가 높은 경우, `geo_metrics_update_worker` job의 실행 빈도를 줄일 수 있습니다. 이 조정은 메트릭 수집이 데이터베이스 성능에 큰 영향을 미치는 대규모 GitLab 인스턴스에서 데이터베이스 부담을 완화하는 데 도움이 됩니다.

간격을 늘리면 Geo 메트릭이 덜 자주 업데이트됩니다. 이로 인해 메트릭이 더 오랫동안 최신 상태가 아닐 수 있으며, 실시간으로 Geo 복제를 모니터링하는 능력에 영향을 줄 수 있습니다. 메트릭이 10분 이상 오래된 경우, 해당 사이트는 관리자 영역에서 임의로 "비정상"으로 표시됩니다.

다음 예시는 job을 30분마다 실행하도록 설정합니다. 필요에 따라 cron 스케줄을 조정하세요.

Linux package (Omnibus)

-

`/etc/gitlab/gitlab.rb`에서 다음 설정을 추가하거나 수정하세요:

#
gitlab_rails['geo_metrics_update_worker_cron'] = "/30 *"#

-

GitLab을 재구성하세요:

#
sudo gitlab-ctl reconfigure#
Self-compiled (source)

-

`/home/git/gitlab/config/gitlab.yml`을 편집하세요:

#

production: &base

ee_cron_jobs: geo_metrics_update_worker:
cron: "/30 *"#

-

파일을 저장하고 GitLab을 재시작하세요:

#

# For systems running systemd

sudo systemctl restart gitlab.target

# For systems running SysV init

sudo service gitlab restart#

#### 사전 계산된 검증 요약 사용

History

  • 도입됨 GitLab 19.0에서 `geo_job_artifact_verification_summaries`라는 [플래그](/19.2/administration/feature_flags/)와 함께. 기본적으로 비활성화됨.
이 기능의 가용성은 기능 플래그로 제어됩니다.

자세한 내용은 히스토리를 참조하세요.

이 기능은 테스트용으로 사용 가능하지만, 프로덕션 환경에서는 아직 준비되지 않았습니다.

메트릭 수집 빈도를 줄이는 대신, CI job 아티팩트에 대한 사전 계산된 검증 요약을 활성화할 수 있습니다. 이렇게 하면 전체 테이블 스캔이 증분 업데이트로 대체되어 변경된 데이터만 다시 집계됩니다.

활성화되면 백그라운드 워커가 전용 테이블에서 요약 카운트를 유지합니다. 검증 상태가 변경되면 데이터베이스 트리거가 영향을 받는 버킷을 더티(dirty)로 표시하고, 워커는 해당 버킷만 재계산합니다. 이렇게 하면 대규모 인스턴스에서 메트릭 수집로 인한 데이터베이스 부하가 대폭 감소합니다.

활성화하려면:

#
sudo gitlab-rails runner 'Feature.enable(:geo_job_artifact_verification_summaries)'#

비활성화하려면:

#
sudo gitlab-rails runner 'Feature.disable(:geo_job_artifact_verification_summaries)'#

일반 Geo 오류 문제 해결

GitLab v19.2
원문 보기
요약

Rake 태스크가 `OpenSSH configured to use AuthorizedKeysCommand` 검사를 건너뛰면 다음 출력이 표시됩니다: OpenSSH configured to use AuthorizedKeysCommand ...

| --- | --- | | NTP_HOST | NTP 호스트. | pool.ntp.org | | NTP_PORT | 호스트가 수신 대기하는 NTP 포트. | 123 | | NTP_TIMEOUT | NTP 타임아웃(초). | net-ntp Ruby 라이브러리에 정의된 값(60초). |

Rake 태스크가 `OpenSSH configured to use AuthorizedKeysCommand` 검사를 건너뛰면 다음 출력이 표시됩니다:

#

OpenSSH configured to use AuthorizedKeysCommand ... skipped

Reason: Cannot access OpenSSH configuration file Try fixing it: This is expected if you are using SELinux. You may want to check configuration manually For more information see:
doc/administration/operations/fast_ssh_key_lookup.md#

이 문제는 다음과 같은 경우에 발생할 수 있습니다:

  • [SELinux](/19.2/administration/operations/fast_ssh_key_lookup/#selinux-support)를 사용하는 경우.
  • 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(Puma, Sidekiq, 또는 Geo Log Cursor)를 실행하는 모든 노드에서 이 Rake 태스크를 실행하여 수동으로 확인할 수 있습니다.

GitLab은 오브젝트 스토리지에 저장된 오브젝트를 검증하지 않습니다. 오브젝트 스토리지를 사용하는 경우, "verified" 검사가 모두 성공 횟수 0으로 표시됩니다. 이는 정상적인 동작이며 문제가 아닙니다.

#
sudo gitlab-rake gitlab:geo:status#

출력 내용에는 다음이 포함됩니다:

  • 실패가 발생한 경우 "failed" 항목의 수
  • "total" 대비 "succeeded" 항목의 비율
예시:
#

Geo Site Information#

Name: example-us-east-2 URL: https://gitlab.example.com Geo Role: Secondary Health Status: Healthy This Node's GitLab Version: 17.7.0-ee

Replication Information#

Sync Settings: Full Database replication lag: 0 seconds Last event ID seen from primary: 12345 (about 2 minutes ago) Last event ID processed: 12345 (about 2 minutes ago) Last status report was: 1 minute ago

Replication Status#

Lfs Objects replicated: succeeded 111 / total 111 (100%) Merge Request Diffs replicated: succeeded 28 / total 28 (100%) Package Files replicated: succeeded 90 / total 90 (100%) Terraform State Versions replicated: succeeded 65 / total 65 (100%) Snippet Repositories replicated: succeeded 63 / total 63 (100%) Group Wiki Repositories replicated: succeeded 14 / total 14 (100%) Pipeline Artifacts replicated: succeeded 112 / total 112 (100%) Pages Deployments replicated: succeeded 55 / total 55 (100%) Uploads replicated: succeeded 2 / total 2 (100%) Job Artifacts replicated: succeeded 32 / total 32 (100%) Ci Secure Files replicated: succeeded 44 / total 44 (100%) Dependency Proxy Blobs replicated: succeeded 15 / total 15 (100%) Dependency Proxy Manifests replicated: succeeded 2 / total 2 (100%) Project Wiki Repositories replicated: succeeded 2 / total 2 (100%) Design Management Repositories replicated: succeeded 1 / total 1 (100%) Project Repositories replicated: succeeded 2 / total 2 (100%)

Verification Status#

Lfs Objects verified: succeeded 111 / total 111 (100%) Merge Request Diffs verified: succeeded 28 / total 28 (100%) Package Files verified: succeeded 90 / total 90 (100%) Terraform State Versions verified: succeeded 65 / total 65 (100%) Snippet Repositories verified: succeeded 63 / total 63 (100%) Group Wiki Repositories verified: succeeded 14 / total 14 (100%) Pipeline Artifacts verified: succeeded 112 / total 112 (100%) Pages Deployments verified: succeeded 55 / total 55 (100%) Uploads verified: succeeded 2 / total 2 (100%) Job Artifacts verified: succeeded 32 / total 32 (100%) Ci Secure Files verified: succeeded 44 / total 44 (100%) Dependency Proxy Blobs verified: succeeded 15 / total 15 (100%) Dependency Proxy Manifests verified: succeeded 2 / total 2 (100%) Project Wiki Repositories verified: succeeded 2 / total 2 (100%) Design Management Repositories verified: succeeded 1 / total 1 (100%)
Project Repositories verified: succeeded 2 / total 2 (100%)#

모든 오브젝트가 복제 및 검증됩니다. 이는 [Geo 용어집](/19.2/administration/geo/glossary/)에 정의되어 있습니다. 각 데이터 유형의 복제 및 검증 방법에 대한 자세한 내용은 [지원되는 Geo 데이터 유형](/19.2/administration/geo/replication/datatypes/#data-types)을 참조하세요.

실패한 항목에 대한 자세한 정보를 확인하려면

[`gitlab-rails/geo.log` 파일](/19.2/administration/logs/log_parsing/#find-most-common-geo-sync-errors)을 확인하세요.

복제 또는 검증 실패가 발견되면 [해결 방법](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/)을 시도할 수 있습니다.

##### Geo 검사 Rake 태스크 실행 시 발견된 오류 수정

이 Rake 태스크를 실행할 때 노드가 올바르게 구성되지 않은 경우 오류 메시지가 표시될 수 있습니다:

#
sudo gitlab-rake gitlab:geo:check#

-

Rails가 데이터베이스에 연결할 때 비밀번호를 제공하지 않았습니다.

#

Checking Geo ...

GitLab Geo is available ... Exception: fe_sendauth: no password supplied

GitLab Geo is enabled ... Exception: fe_sendauth: no password supplied

...
Checking Geo ... Finished#

`postgresql['sql_user_password']`에 대한 해시를 생성할 때 사용한 일반 텍스트 비밀번호로 `gitlab_rails['db_password']`가 설정되어 있는지 확인하세요.

-

Rails가 데이터베이스에 연결할 수 없습니다.

#

Checking Geo ...

GitLab Geo is available ... 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 is enabled ... 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

...
Checking Geo ... Finished#

Rails 노드의 IP 주소가 `postgresql['md5_auth_cidr_addresses']`에 포함되어 있는지 확인하세요.

또한 IP 주소에 서브넷 마스크가 포함되어 있는지 확인하세요: `postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']`.

-

Rails가 잘못된 비밀번호를 제공했습니다.

#

Checking Geo ...

GitLab Geo is available ... Exception: FATAL: password authentication failed for user "gitlab"

FATAL: password authentication failed for user "gitlab"

GitLab Geo is enabled ... Exception: FATAL: password authentication failed for user "gitlab"

FATAL: password authentication failed for user "gitlab"

...
Checking Geo ... Finished#

`gitlab-ctl pg-password-md5 gitlab`을 실행하고 비밀번호를 입력하여 `postgresql['sql_user_password']`의 해시를 생성할 때 사용한 `gitlab_rails['db_password']`에 올바른 비밀번호가 설정되어 있는지 확인하세요.

-

검사 결과 `not a secondary node`가 반환됩니다.

#

Checking Geo ...

GitLab Geo is available ... yes

GitLab Geo is enabled ... yes

GitLab Geo tracking database is correctly configured ... not a secondary node

Database replication enabled? ... not a secondary node

...
Checking Geo ... Finished#

기본 사이트의 웹 인터페이스에서 관리자 영역의 Geo > 사이트에서 보조 사이트를 추가했는지 확인하세요.

또한 기본 사이트의 관리자 영역에서 보조 사이트를 추가할 때 `gitlab_rails['geo_node_name']`을 입력했는지 확인하세요.

-

검사 결과 `Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist`가 반환됩니다.

#

Checking Geo ...

GitLab Geo is available ... no

Try fixing it: Add a new license that includes the GitLab Geo feature For more information see: https://about.gitlab.com/features/gitlab-geo/

GitLab Geo is enabled ... Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist

LINE 8: WHERE a.attrelid = '"geo_nodes"'::regclass

^

: SELECT a.attname, format_type(a.atttypid, a.atttypmod),

pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod, c.collname, col_description(a.attrelid, a.attnum) AS comment FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum LEFT JOIN pg_type t ON a.atttypid = t.oid LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation WHERE a.attrelid = '"geo_nodes"'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum ...
Checking Geo ... Finished#

PostgreSQL 메이저 버전 업그레이드(9 > 10) 시 이는 예상된 동작입니다. [복제 프로세스 시작](/19.2/administration/geo/setup/database/#step-3-initiate-the-replication-process)을 따르세요.

-

Rails에 Geo 추적 데이터베이스에 연결하는 데 필요한 구성이 없는 것으로 보입니다.

#

Checking Geo ...

GitLab Geo is available ... yes

GitLab Geo is enabled ... yes

GitLab Geo tracking database is correctly configured ... no

Try fixing it:

Rails does not appear to have the configuration necessary to connect to the Geo tracking database. If the tracking database is running on a node other than this one, then you may need to add configuration.

...
Checking Geo ... Finished#
  • 모든 서비스를 단일 노드에서 실행 중인 보조 사이트의 경우, [Geo 데이터베이스 복제 - 보조 서버 구성](/19.2/administration/geo/setup/database/#step-2-configure-the-secondary-server)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 별도 노드에서 실행 중인 경우, [다중 서버를 위한 Geo - Geo 보조 사이트에서 Geo 추적 데이터베이스 구성](/19.2/administration/geo/replication/multiple_servers/#step-2-configure-the-geo-tracking-database-on-the-geo-secondary-site)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 Patroni 클러스터에서 실행 중인 경우, [Geo 데이터베이스 복제 - 추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성](/19.2/administration/geo/setup/database/#configuring-patroni-cluster-for-the-tracking-postgresql-database)을 따르세요.
  • 보조 사이트의 추적 데이터베이스를 외부 데이터베이스에서 실행 중인 경우, [외부 PostgreSQL 인스턴스를 사용하는 Geo](/19.2/administration/geo/setup/external_database/#configure-the-tracking-database)를 따르세요.
  • GitLab Rails 앱(Puma, Sidekiq, 또는 Geo Log Cursor)을 실행하는 서비스가 없는 노드에서 Geo 검사 태스크를 실행한 경우, 이 오류는 무시할 수 있습니다. 해당 노드에는 Rails 구성이 필요하지 않습니다.
##### 메시지: Container Registry Geo events … none found

`Container Registry Geo events ... none found`가 표시되고 컨테이너 레지스트리 복제 이벤트가 있을 것으로 예상되는 경우, 기본 사이트의 레지스트리 알림 구성이 [컨테이너 레지스트리 복제 구성 가이드](/19.2/administration/geo/replication/container_registry/#configure-primary-site)에 따라 설정되어 있는지 확인하세요.

##### 메시지: Machine clock is synchronized … Exception

Rake 태스크는 서버 시계가 NTP와 동기화되어 있는지 확인하려고 합니다. Geo가 올바르게 작동하려면 동기화된 시계가 필요합니다. 예를 들어, 보안상의 이유로 기본 사이트와 보조 사이트의 서버 시간이 약 1분 이상 차이가 나면 Geo 사이트 간 요청이 실패합니다. 이 검사 태스크가 시간 불일치 이외의 이유로 완료에 실패하더라도, 반드시 Geo가 작동하지 않는다는 의미는 아닙니다.

검사를 수행하는 Ruby gem은 참조 시간 소스로 `pool.ntp.org`가 하드 코딩되어 있습니다.

-

예외 메시지 `Machine clock is synchronized ... Exception: Timeout::Error`

이 문제는 서버가 호스트 `pool.ntp.org`에 접근할 수 없을 때 발생합니다.

-

예외 메시지 `Machine clock is synchronized ... Exception: No route to host - recvfrom(2)`

이 문제는 호스트명 `pool.ntp.org`가 시간 서비스를 제공하지 않는 서버로 해석될 때 발생합니다.

이 경우, GitLab 15.7 이상에서는 [환경 변수를 사용하여 사용자 정의 NTP 서버를 지정](/19.2/administration/geo/replication/troubleshooting/common/#health-check-rake-task)하세요.

GitLab 15.6 이하에서는 다음 중 하나의 임시 해결 방법을 사용하세요:

  • `/etc/hosts`에 `pool.ntp.org`에 대한 항목을 추가하여 요청을 유효한 로컬 타임 서버로 전달하세요.
이렇게 하면 긴 타임아웃과 타임아웃 오류가 해결됩니다.
  • 임의의 유효한 IP 주소로 검사를 전달하세요. 이렇게 하면 타임아웃 문제는 해결되지만, 앞서 언급한 대로 `No route to host` 오류와 함께 검사가 실패합니다.
Cloud Native GitLab 배포는 쿠버네티스의 컨테이너가 호스트 시계에 접근할 수 없기 때문에 오류가 발생합니다:
#
Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype#

##### 메시지: cannot execute INSERT in a read-only transaction

보조 사이트에서 이 오류가 발생하면 `gitlab-rails` 또는 `gitlab-rake` 명령어와 같은 GitLab Rails의 모든 사용 및 Puma, Sidekiq, Geo Log Cursor 서비스에 영향을 미칩니다.

#

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 `'

/opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `'

/opt/gitlab/embedded/bin/bundle:23:in `load'

/opt/gitlab/embedded/bin/bundle:23:in `
'#

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"#

이 상황은 다음과 같은 경우에 발생할 수 있습니다:

-

보조 사이트가 아직 자신이 보조 사이트임을 인식하지 못하는 초기 구성 단계에서 발생합니다. 오류를 해결하려면 [3단계. 보조 사이트 추가](/19.2/administration/geo/replication/configuration/#step-3-add-the-secondary-site)를 따르세요.

-

Geo 보조 사이트 업그레이드 중에 발생합니다. `gitlab_rails['auto_migrate']`가 `true`로 설정되어 있어 GitLab이 복제본 데이터베이스에서 데이터베이스 마이그레이션을 시도할 수 있는데, 이는 필요하지 않습니다. 오류를 해결하려면:

보조 사이트의 GitLab Rails 노드에 root로 SSH 접속하세요.

-

`/etc/gitlab/gitlab.rb`를 편집하고 이 설정을 주석 처리하거나 false로 설정하세요:

#
gitlab_rails['auto_migrate'] = false#

-

GitLab을 재구성하세요:

#
sudo gitlab-ctl reconfigure#

### PostgreSQL 복제가 작동하는지 확인

PostgreSQL 복제가 작동하는지 확인하려면 다음을 점검하세요:

  • [사이트가 올바른 데이터베이스 노드를 가리키는지](/19.2/administration/geo/replication/troubleshooting/common/#are-sites-pointing-to-the-correct-database-node) 확인.
  • [Geo가 현재 사이트를 올바르게 감지할 수 있는지](/19.2/administration/geo/replication/troubleshooting/common/#can-geo-detect-the-current-site-correctly) 확인.
여전히 문제가 있는 경우, [고급 복제 문제 해결](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/)을 참조하세요.

#### 사이트가 올바른 데이터베이스 노드를 가리키고 있나요?

기본 Geo [사이트](/19.2/administration/geo/glossary/)가 쓰기 권한을 가진 데이터베이스 노드를 가리키는지 확인하세요.

보조 사이트는 읽기 전용 데이터베이스 노드만 가리켜야 합니다.

#### Geo가 현재 사이트를 올바르게 감지할 수 있나요?

Geo는 다음 로직으로 `/etc/gitlab/gitlab.rb`에서 현재 Puma 또는 Sidekiq 노드의 Geo [사이트](/19.2/administration/geo/glossary/) 이름을 찾습니다:

Linux 패키지: `gitlab_rails['geo_node_name']` 설정을 가져옵니다.
  • GitLab Helm 차트: `global.geo.nodeName` 설정을 가져옵니다(Charts와 GitLab Geo 참조).
  • 정의되지 않은 경우, `external_url` 설정을 가져옵니다.
이 이름은 Geo 사이트 대시보드에서 동일한 이름을 가진 Geo 사이트를 조회하는 데 사용됩니다.

현재 머신의 사이트 이름이 데이터베이스의 사이트와 일치하는지 확인하려면 검사 태스크를 실행하세요:

#
sudo gitlab-rake gitlab:geo:check#

현재 머신의 사이트 이름과 일치하는 데이터베이스 레코드가 기본 사이트인지 보조 사이트인지를 표시합니다.

#
This machine's Geo node name matches a database record ... yes, found a secondary node named "Shanghai"#
#

This machine's Geo node name matches a database record ... no

Try fixing it: You could add or update a Geo node database record, setting the name to "https://example.com/". Or you could set this machine's Geo node name to match the name of an existing database record: "London", "Shanghai" For more information see:
doc/administration/geo/replication/troubleshooting/_index.md#can-geo-detect-the-current-node-correctly#

이름 필드 설명에서 권장되는 사이트 이름에 대한 자세한 내용은

[Geo 관리자 영역 공통 설정](/19.2/administration/geo_sites/#common-settings)을 참조하세요.

### OS 로케일 데이터 호환성 확인

가능하면 모든 사이트의 모든 Geo 노드는 [Geo 실행 요구 사항](/19.2/administration/geo/#requirements-for-running-geo)에 정의된 것과 동일한 방법 및 운영 체제로 배포되어야 합니다.

Geo 사이트에 서로 다른 운영 체제 또는 다른 운영 체제 버전이 배포된 경우, Geo를 설정하기 전에 로케일 데이터 호환성 검사를 반드시 수행해야 합니다. GitLab 배포 방법을 혼합하여 사용하는 경우에는 `glibc`도 확인해야 합니다. Linux 패키지 설치, GitLab Docker 컨테이너, Helm 차트 배포 또는 외부 데이터베이스 서비스 간에 로케일이 다를 수 있습니다. `glibc` 버전 호환성 확인 방법을 포함한 [PostgreSQL 운영 체제 업그레이드 문서](/19.2/administration/postgresql/upgrading_os/)를 참조하세요.

Geo는 PostgreSQL과 스트리밍 복제를 사용하여 Geo 사이트 간에 데이터를 복제합니다. PostgreSQL은 텍스트 정렬을 위해 운영 체제의 C 라이브러리가 제공하는 로케일 데이터를 사용합니다. C 라이브러리의 로케일 데이터가 Geo 사이트 간에 호환되지 않으면 보조 사이트에서 잘못된 동작을 유발하는 잘못된 쿼리 결과가 발생합니다.

예를 들어, Ubuntu 18.04(이하)와 RHEL/CentOS 7(이하)은 이후 릴리즈와 호환되지 않습니다.

자세한 내용은 PostgreSQL 위키를 참조하세요.

## 일반적인 오류 수정

이 섹션에서는 웹 인터페이스의 관리자 영역에 보고되는 일반적인 오류 메시지와 수정 방법을 설명합니다.

### 기존 추적 데이터베이스를 재사용할 수 없음

Geo는 기존 추적 데이터베이스를 재사용할 수 없습니다.

새 보조 사이트를 사용하거나, [Geo 보조 사이트 복제 재설정](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/#resetting-geo-secondary-site-replication)을 따라 전체 보조 사이트를 재설정하는 것이 가장 안전합니다.

보조 사이트를 재설정하지 않고 재사용하면 보조 사이트가 일부 Geo 이벤트를 놓쳤을 수 있어 위험합니다. 예를 들어, 누락된 삭제 이벤트는 보조 사이트에 삭제되어야 할 데이터가 영구적으로 남아 있게 합니다. 마찬가지로, 데이터의 물리적 위치를 이동하는 이벤트를 잃으면 한 위치에 데이터가 영구적으로 고아 상태가 되고 다른 위치에서는 재검증될 때까지 누락됩니다. 이것이 GitLab이 데이터 이동을 불필요하게 만드는 해시 스토리지로 전환한 이유입니다. 손실된 이벤트로 인한 다른 알 수 없는 문제가 있을 수 있습니다.

테스트 환경과 같이 이러한 위험이 적용되지 않는 경우, 또는 Geo 사이트가 추가된 이후로 메인 Postgres 데이터베이스에 모든 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)#

이 명령은 마지막으로 생성된 보조 사이트가 영향을 받는 사이트라고 가정합니다.

-

관리자 > Geo > 사이트에서 보조 사이트의 상태를 업데이트하세요. 보조 사이트의 Rails 콘솔에서 다음을 실행하세요:

#
Geo::MetricsUpdateWorker.new.perform#

-

보조 사이트가 정상으로 표시되어야 합니다. 그렇지 않으면 보조 사이트에서 `gitlab-rake gitlab:geo:check`를 실행하거나, 보조 사이트를 다시 추가한 이후 Rails를 아직 재시작하지 않았다면 재시작해 보세요.

-

누락되거나 오래된 데이터를 다시 동기화하려면 관리자 > Geo > 사이트로 이동하세요.

-

보조 사이트 아래에서 복제 세부 정보를 선택하세요.

-

모든 데이터 유형에 대해 모두 재검증을 선택하세요.

### Geo 사이트에 쓰기 가능한 데이터베이스가 있음

이 오류 메시지는 Geo가 접근할 것으로 예상하는 보조 사이트의 데이터베이스 복제본 문제를 나타냅니다. 쓰기 가능한 보조 사이트 데이터베이스는 데이터베이스가 기본 사이트와의 복제를 위해 구성되지 않았음을 나타냅니다. 일반적으로 다음 중 하나를 의미합니다:

  • 지원되지 않는 복제 방법이 사용되었습니다(예: 논리 복제).
  • [Geo 데이터베이스 복제](/19.2/administration/geo/setup/database/) 설정 지침을 올바르게 따르지 않았습니다.
  • `/etc/gitlab/gitlab.rb` 파일에서 잘못된 사용자를 지정하는 등 데이터베이스 연결 정보가 올바르지 않습니다.
Geo 보조 사이트에는 두 개의 별도 PostgreSQL 인스턴스가 필요합니다:
  • 기본 사이트의 읽기 전용 복제본.
  • 복제 메타데이터를 보관하는 일반적인 쓰기 가능 인스턴스. 즉, Geo 추적 데이터베이스.
이 오류 메시지는 보조 사이트의 복제본 데이터베이스가 잘못 구성되어 복제가 중단되었음을 나타냅니다.

데이터베이스를 복원하고 복제를 재개하려면 다음 중 하나를 수행할 수 있습니다:

  • [Geo 보조 사이트 복제 재설정](/19.2/administration/geo/replication/troubleshooting/synchronization_verification/#resetting-geo-secondary-site-replication).
  • [Linux 패키지를 사용하여 새 Geo 보조 사이트 설정](/19.2/administration/geo/setup/#using-linux-package-installations).
새 보조 사이트를 처음부터 설정하는 경우, [Geo 클러스터에서 이전 사이트를 제거](/19.2/administration/geo/replication/remove_geo_site/)해야 합니다.

### Geo 사이트가 기본 사이트에서 데이터베이스를 복제하지 않는 것으로 보임

데이터베이스가 올바르게 복제되지 않는 가장 일반적인 문제는 다음과 같습니다:

  • 보조 사이트가 기본 사이트에 도달할 수 없습니다. 자격 증명과
[방화벽 규칙](/19.2/administration/geo/#firewall-rules)을 확인하세요.
  • SSL 인증서 문제. 기본 사이트에서 `/etc/gitlab/gitlab-secrets.json`을 복사했는지 확인하세요.
  • 데이터베이스 스토리지 디스크가 가득 찼습니다.
  • 데이터베이스 복제 슬롯이 잘못 구성되었습니다.
  • 데이터베이스가 복제 슬롯이나 다른 대안을 사용하지 않아 WAL 파일이 삭제되어 따라잡을 수 없습니다.
지원되는 구성에 대해 [Geo 데이터베이스 복제](/19.2/administration/geo/setup/database/) 지침을 따르세요.

### Geo 데이터베이스 버전(…)이 최신 마이그레이션(…)과 일치하지 않음

Linux 패키지 설치를 사용하는 경우, 업그레이드 중에 문제가 발생했을 수 있습니다. 다음을 수행할 수 있습니다:

  • `sudo gitlab-ctl reconfigure`를 실행하세요.
  • 보조 사이트에서 root로 `sudo gitlab-rake db:migrate:geo`를 실행하여 데이터베이스 마이그레이션을 수동으로 트리거하세요.
### GitLab이 100%를 초과하는 리포지터리가 동기화되었다고 표시함

이는 프로젝트 레지스트리의 고아 레코드로 인해 발생할 수 있습니다. 레지스트리 워커를 사용하여 주기적으로 정리되므로, 자동으로 수정될 때까지 잠시 기다리세요.

### 기본 사이트의 체크섬 실패

Geo 기본 검증 정보 화면에서 식별된 체크섬 실패는 파일 누락이나 체크섬 불일치로 인해 발생할 수 있습니다. `gitlab-rails/geo.log` 파일에서 `"Repository cannot be checksummed because it does not exist"` 또는 `"File is not checksummable - file does not exist at: "`와 같은 오류 메시지를 찾을 수 있습니다. 오류 메시지에는 누락된 파일을 식별하는 데 도움이 되는 파일 경로가 포함되어 있습니다.

실패한 항목에 대한 추가 정보를 얻으려면 [무결성 검사 Rake 태스크](/19.2/administration/raketasks/check/#uploaded-files-integrity)를 실행하세요:

#

sudo gitlab-rake gitlab:artifacts:check

sudo gitlab-rake gitlab:ci_secure_files:check

sudo gitlab-rake gitlab:lfs:check

sudo gitlab-rake gitlab:uploads:check#

개별 오류에 대한 자세한 정보를 보려면 `VERBOSE=1` 변수를 사용하세요.

### 보조 사이트가 UI에서 비정상으로 표시됨

기본 사이트의 `/etc/gitlab/gitlab.rb`에서 `external_url` 값을 업데이트하거나 프로토콜을 `http`에서 `https`로 변경한 경우, 보조 사이트가 비정상으로 표시될 수 있습니다. `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 :80 (Connection refused - connect(2) for \"\" port 80)"#

이 경우, 모든 사이트에서 변경된 URL을 업데이트하세요:

  • 오른쪽 상단 모서리에서 관리자를 선택하세요.
  • 왼쪽 사이드바에서 Geo > 사이트를 선택하세요.
  • URL을 변경하고 저장하세요.
### 메시지: ERROR: canceling statement due to conflict with recovery during backup

Geo 보조 사이트에서 백업을 실행하는 것은 지원되지 않습니다.

보조 사이트에서 백업을 실행하면 다음 오류 메시지가 발생할 수 있습니다:

#

Dumping PostgreSQL database gitlabhq_production ...

pg_dump: error: Dumping the contents of table "notes" failed: PQgetResult() failed.

pg_dump: error: Error message from server: 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: The command was: COPY public.notes (id, note, [...], last_edited_at) TO stdout;#

Geo 보조 사이트에서 GitLab 업그레이드 중 데이터베이스 백업이 자동으로 실행되는 것을 방지하려면 다음 빈 파일을 생성하세요:

#
sudo touch /etc/gitlab/skip-auto-backup#

### 오브젝트 검증 중 기본 사이트의 높은 CPU 사용량

GitLab 16.11부터 GitLab 17.2까지, 누락된 PostgreSQL 인덱스로 인해 높은 CPU 사용량과 느린 아티팩트 검증 진행이 발생합니다. 또한 Geo 보조 사이트가 비정상으로 보고될 수 있습니다. 이슈 471727에서 이 동작을 자세히 설명합니다.

이 문제가 발생하는지 확인하려면 영향 여부 확인 단계를 따르세요.

영향을 받는 경우, 임시 해결 방법의 단계에 따라 수동으로 인덱스를 생성하세요. 인덱스를 생성하면 완료될 때까지 PostgreSQL이 리소스를 약간 더 소비합니다. 이후 검증이 계속되는 동안 CPU 사용량이 높게 유지될 수 있지만, 쿼리는 훨씬 빠르게 완료되고 보조 사이트 상태가 올바르게 업데이트되어야 합니다.

### 검증 실패: Verification timed out after (...)

GitLab 16.11부터 Geo는 동일한 `artifact_id`에 대해 중복 `JobArtifactRegistry` 항목을 생성할 수 있으며, 이는 기본 사이트와 보조 사이트 간의 동기화 실패로 이어질 수 있습니다. 이 문제는 `UploadRegistry` 및 `PackageFileRegistry` 항목에도 영향을 미칠 수 있습니다.

이 문제가 발생하는지 확인하고 중복 항목을 제거하려면:

-

보조 사이트에서 [Rails 콘솔](/19.2/administration/operations/rails_console/)을 여세요.

-

중복이 있는 모델 레코드 ID의 수를 가져오세요:

#

artifact_ids = Geo::JobArtifactRegistry.group(:artifact_id).having('COUNT(*) > 1').pluck(:artifact_id); artifact_ids.size

upload_ids = Geo::UploadRegistry.group(:file_id).having('COUNT(*) > 1').pluck(:file_id); upload_ids.size

package_file_ids = Geo::PackageFileRegistry.group(:package_file_id).having('COUNT(*) > 1').pluck(:package_file_id); package_file_ids.size#

-

ID를 출력하세요:

#

puts 'BEGIN Artifact IDs', artifact_ids, 'END Artifact IDs'

puts 'BEGIN Upload IDs', upload_ids, 'END Upload IDs'

puts 'BEGIN Package File IDs', package_file_ids, 'END Package File IDs'#

출력이 비어 있으면 영향을 받지 않은 것입니다. 그렇지 않으면 나중에 연결이 끊어질 경우를 대비하여 터미널 출력을 텍스트 파일에 저장하세요.

-

모든 중복을 삭제하세요:

#

Geo::JobArtifactRegistry.where(artifact_id: artifact_ids).delete_all

Geo::UploadRegistry.where(file_id: upload_ids).delete_all

Geo::PackageFileRegistry.where(package_file_id: package_file_ids).delete_all#

-

백그라운드 job이 레지스트리 행을 다시 생성하고 재동기화할 때까지 기다리세요.

수정에 대한 피드백을 얻으려면 이슈 479852를 팔로우하세요.

### 보조 사이트에서 Geo Rake 검사 태스크 실행 시 end of file reached 오류

보조 사이트에서 [상태 확인 Rake 태스크](/19.2/administration/geo/replication/troubleshooting/common/#health-check-rake-task)를 실행할 때 다음 오류가 발생할 수 있습니다:

#

Can connect to the primary node ... no

Reason:

end of file reached#

설정에서 기본 사이트에 대한 잘못된 URL이 지정된 경우 이 오류가 발생할 수 있습니다. 문제를 해결하려면 [Rails 콘솔](/19.2/administration/operations/rails_console/)에서 다음 명령을 실행하세요:

#

primary = Gitlab::Geo.primary_node

primary.internal_uri

Gitlab::HTTP.get(primary.internal_uri, allow_local_requests: true, limit: 10)#

이전 출력에서 `internal_uri`의 값이 올바른지 확인하세요.

기본 사이트의 URL이 올바르지 않은 경우, `/etc/gitlab/gitlab.rb`와 관리자 > Geo > 사이트에서 다시 확인하세요.

### Geo 메트릭 수집로 인한 과도한 데이터베이스 IO

빈번한 Geo 메트릭 수집으로 인해 데이터베이스 부하가 높은 경우, `geo_metrics_update_worker` job의 실행 빈도를 줄일 수 있습니다. 이 조정은 메트릭 수집이 데이터베이스 성능에 큰 영향을 미치는 대규모 GitLab 인스턴스에서 데이터베이스 부담을 완화하는 데 도움이 됩니다.

간격을 늘리면 Geo 메트릭이 덜 자주 업데이트됩니다. 이로 인해 메트릭이 더 오랫동안 최신 상태가 아닐 수 있으며, 실시간으로 Geo 복제를 모니터링하는 능력에 영향을 줄 수 있습니다. 메트릭이 10분 이상 오래된 경우, 해당 사이트는 관리자 영역에서 임의로 "비정상"으로 표시됩니다.

다음 예시는 job을 30분마다 실행하도록 설정합니다. 필요에 따라 cron 스케줄을 조정하세요.

Linux package (Omnibus)

-

`/etc/gitlab/gitlab.rb`에서 다음 설정을 추가하거나 수정하세요:

#
gitlab_rails['geo_metrics_update_worker_cron'] = "/30 *"#

-

GitLab을 재구성하세요:

#
sudo gitlab-ctl reconfigure#
Self-compiled (source)

-

`/home/git/gitlab/config/gitlab.yml`을 편집하세요:

#

production: &base

ee_cron_jobs: geo_metrics_update_worker:
cron: "/30 *"#

-

파일을 저장하고 GitLab을 재시작하세요:

#

# For systems running systemd

sudo systemctl restart gitlab.target

# For systems running SysV init

sudo service gitlab restart#

#### 사전 계산된 검증 요약 사용

History

  • 도입됨 GitLab 19.0에서 `geo_job_artifact_verification_summaries`라는 [플래그](/19.2/administration/feature_flags/)와 함께. 기본적으로 비활성화됨.
이 기능의 가용성은 기능 플래그로 제어됩니다.

자세한 내용은 히스토리를 참조하세요.

이 기능은 테스트용으로 사용 가능하지만, 프로덕션 환경에서는 아직 준비되지 않았습니다.

메트릭 수집 빈도를 줄이는 대신, CI job 아티팩트에 대한 사전 계산된 검증 요약을 활성화할 수 있습니다. 이렇게 하면 전체 테이블 스캔이 증분 업데이트로 대체되어 변경된 데이터만 다시 집계됩니다.

활성화되면 백그라운드 워커가 전용 테이블에서 요약 카운트를 유지합니다. 검증 상태가 변경되면 데이터베이스 트리거가 영향을 받는 버킷을 더티(dirty)로 표시하고, 워커는 해당 버킷만 재계산합니다. 이렇게 하면 대규모 인스턴스에서 메트릭 수집로 인한 데이터베이스 부하가 대폭 감소합니다.

활성화하려면:

#
sudo gitlab-rails runner 'Feature.enable(:geo_job_artifact_verification_summaries)'#

비활성화하려면:

#
sudo gitlab-rails runner 'Feature.disable(:geo_job_artifact_verification_summaries)'#