Geo에 강등된 사이트 재도입

장애 조치 후 강등된 기본 사이트를 새 보조 사이트로 되돌리거나 원래 기본 사이트를 복원하는 방법을 설명합니다.

강등된 사이트를 Geo에 다시 도입하기 # - Tier: Premium, Ultimate - Offering: GitLab Self-Managed 페일오버 이후, 강등된 기본 사이트(primary site)를 새로운 보조 사이트(secondary site)로 다시 가져오거나 원래의 기본 사이트를 복원할 수 있습니다. 이 과정은 두 단계로 구성됩니다: 이전 기본 사이트를 보조 사이트로 전환하기. 보조 사이트를 기본 사이트로 승격하기. 이 사이트의 데이터 일관성에 대한 의문이 있다면, 처음부터 다시 설정하는 것이 좋습니다. 강등된 기본 사이트는 더 이상 Geo와 동기화되지 않는 독립형 GitLab 서버로 간주됩니다. 이전 기본 사이트로서의 잔여 설정을 모두 제거한 후 새로운 보조 사이트로 다시 추가해야 합니다. 이전 기본 사이트를 보조 사이트로 구성하기 # 이전 기본 사이트는 현재 기본 사이트와 동기화가 맞지 않으므로, 첫 번째 단계는 이전 기본 사이트를 최신 상태로 만드는 것입니다. 리포지터리 및 업로드와 같이 디스크에 저장된 데이터의 삭제는 이전 기본 사이트를 다시 동기화할 때 재현되지 않으므로, 디스크 사용량이 증가할 수 있습니다. 이를 방지하려면 새 보조 GitLab 인스턴스를 설정 하는 방법을 사용할 수 있습니다. 이전 기본 사이트를 최신 상태로 만들려면: 뒤처진 이전 기본 사이트에 SSH로 접속합니다. /etc/gitlab/gitlab-cluster.json 파일이 존재한다면 삭제합니다. ( gitlab-cluster.json 파일이란? ) 보조 사이트로 다시 추가될 사이트가 gitlab-ctl geo promote 명령으로 승격된 경우, /etc/gitlab/gitlab-cluster.json 파일이 존재할 수 있습니다. 예를 들어 gitlab-ctl reconfigure 실행 시 다음과 같은 출력이 나타날 수 있습니다: The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb 이 경우, /etc/gitlab/gitlab.rb 가 다시 단일 진실 공급원(Single Source Of Truth, SSOT)이 되도록, 사이트 내 모든 Sidekiq, PostgreSQL, Gitaly, Rails 노드에서 /etc/gitlab/gitlab-cluster.json 을 삭제해야 합니다(멀티 노드 설정 사용 시). 모든 서비스가 실행 중인지 확인합니다: sudo gitlab-ctl start 기본 사이트를 영구적으로 비활성화 한 경우, 지금 해당 단계를 되돌려야 합니다. Debian/Ubuntu/CentOS7+ 등 systemd를 사용하는 배포판에서는 sudo systemctl enable gitlab-runsvdir 을 실행해야 합니다. CentOS 6처럼 systemd가 없는 배포판에서는 GitLab 인스턴스를 처음부터 설치하고 설정 지침 을 따라 보조