추천 설정
- Redis 설정 요약
- Sentinel 설정 요약
Redis 구성
Example of a minimal configuration with 1 primary, 2 replicas and 3 Sentinels
- GitLab 애플리케이션의 예제 구성
고급 구성
문제 해결
더 읽어보기

Redis 복제 및 Linux 패키지와 장애 조치

Tier: Premium, Ultimate Offering: Self-Managed

이 설명서는 Linux 패키지를 위한 것입니다. 자체 묶지 않은 Redis를 사용하려면 자체 인스턴스 제공 복제 및 장애 조치을 참조하세요.

Redis 용어에서 primary는 master로 불립니다. 이 문서에서는 master가 필요한 설정을 제외하고 primary를 사용합니다.

확장 가능한 환경에서 Redis를 사용하여 Primary x Replica 위상 및 Redis Sentinel 서비스를 사용하여 자동 장애 조치 절차를 감시하고 자동으로 시작할 수 있습니다.

Redis는 Sentinel을 사용할 때 인증이 필요합니다. 자세한 내용은 Redis Security 문서를 참조하세요. Redis 서비스를 보호하기 위해 Redis 암호 및 엄격한 방화벽 규칙의 조합을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel 문서를 자세히 읽어 전체 위상 및 아키텍처를 완전히 이해하는 것이 좋습니다.

복제 위상에 대한 Redis 및 Redis Sentinel 설정의 세부 사항에 들어가기 전에 이 문서를 한 번 통째로 읽어 컴포넌트가 어떻게 연결되는지 더 잘 이해하세요.

최소 3 대의 독립적인 머신이 필요합니다. 물리적 머신이나 별도의 머신에서 실행되는 VM이어야 합니다. 기본적인 Redis 인스턴스와 복제가 다른 머신에서 실행되는 것이 중요합니다. 특정 방식으로 머신을 프로비저닝하지 않으면 공유 환경에 문제가 발생할 수 있습니다.

Primary 또는 Replica Redis 인스턴스 옆에 Sentinel을 실행해도 괜찮습니다. 그러나 동일한 머신에는 하나의 Sentinel만 있어야 합니다.

또한 Redis / Sentinel 및 GitLab 인스턴스 간에 백업 연결이 있음을 확인하고 네트워크의 단일 장애 지점이 되지 않도록 해야 합니다.

확장 가능한 환경에서 Redis를 실행하려면 다음이 필요합니다:

여러 개의 Redis 인스턴스
Primary x Replica 위상에서 Redis 실행
여러 개의 Sentinel 인스턴스
모든 Sentinel 및 Redis 인스턴스를 지원하고 볼 수 있는 응용프로그램

Redis Sentinel은 HA 환경에서 가장 중요한 작업을 수행하고 서버를 최소한 또는 없는 다운타임으로 유지하는 데 도움이 될 수 있습니다. Redis Sentinel:

Primary 및 Replica 인스턴스를 감시하여 사용 가능한지 확인합니다.
Primary이 실패하면 Replica를 Primary로 승격시킵니다.
실패한 Primary가 온라인 상태로 돌아올 때 Primary를 Replica로 강등합니다 (데이터 파티션 방지)
응용프로그램이 항상 현재 Primary 서버에 연결하도록 Sentinel에 쿼리할 수 있습니다.

Primary가 응답하지 않을 때, 응용프로그램(GitLab 등)은 타임아웃 및 재연결을 처리하기 위한 책임이 있습니다 (Sentinel에 새 Primary을 요청하는 쿼리 포함).

Sentinel을 올바르게 설정하는 방법에 대한 이해를 높이기 위해 Redis Sentinel 문서를 먼저 읽어야 합니다. 올바르게 구성하지 않으면 데이터 손실 또는 전체 클러스터 다운으로 이어질 수 있으므로 이 문서를 읽는 것이 좋습니다.

Redis 구성

새로운 Redis 인스턴스를 설치하고 설정하는 섹션입니다.

GitLab 및 모든 컴포넌트를 처음부터 설치했다고 가정합니다. 이미 Redis를 설치하고 실행한 경우 기존 단일 머신 설치에서 전환하는 방법을 읽으십시오.

Redis 노드(기본 및 복제본)는 redis['password']에서 정의된 동일한 암호가 필요합니다. 장애 조치(failover) 중에 언제든지 Sentinels가 노드를 다시 구성하고 기본 상태에서 복제본 상태로 변경하거나 그 반대로 변경할 수 있습니다.

요구 사항

Redis 설정에 대한 요구 사항은 다음과 같습니다:

권장 설정에 명시된대로 최소 필요한 인스턴스 수를 프로비저닝합니다.
GitLab 애플리케이션이 실행 중인 머신에 Redis 또는 Redis Sentinel을 설치하는 것을 권장하지 않습니다. 그러면 HA 구성이 약화됩니다. 그러나 Redis 및 Sentinel을 동일한 머신에 설치할 수 있습니다.
모든 Redis 노드는 서로 통신하고 Redis(6379) 및 Sentinel(26379) 포트에서 들어오는 연결을 수락해야 합니다(기본값을 변경하지 않는 한).
GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 액세스할 수 있어야 합니다.
외부 네트워크(Internet)에서 노드에 액세스하지 못하도록 방화벽으로 보호해야 합니다.

기존 단일 머신 설치에서 전환하는 경우

이미 단일 머신에 GitLab 설치가 실행 중인 경우 Redis 인스턴스를 비활성화하기 전에 먼저 이 머신에서 복제해야 합니다.

사용 중인 단일 머신 설치는 초기 기본이며, 3개의 다른 기기를 복제본으로 구성해야 합니다.

복제가 따라잡히면 단일 머신 설치의 서비스를 중지하고 새 노드 중 하나를 기본으로 변경해야 합니다.

구성 변경 사항을 적용하고 새 노드를 다시 시작합니다.

단일 설치의 Redis를 비활성화하려면 /etc/gitlab/gitlab.rb를 편집합니다:

redis['enable'] = false

먼저 복제하지 않으면 데이터(처리되지 않은 백그라운드 작업)가 손실될 수 있습니다.

단계 1. 기본 Redis 인스턴스 구성

기본 Redis 서버에 SSH로 로그인합니다.
Linux 패키지를 다운로드하고 설치합니다. GitLab 다운로드 페이지의 단계 1과 2를 사용합니다.
- 현재 설치된 버전 및 유형(Community, Enterprise Edition)과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
- 다운로드 페이지의 다른 단계를 완료하지 않습니다.

/etc/gitlab/gitlab.rb를 편집하고 내용을 추가합니다:

# 서버 역할을 'redis_master_role'로 지정
roles ['redis_master_role']
   
# 다른 머신이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
# 모든 인터페이스에서 수신 대기하기 위해 bind를 '0.0.0.0'으로 설정할 수도 있습니다.
# 외부 액세스 가능한 IP에 바인딩하는 경우 무단 액세스를 방지하도록 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.0.0.1'
   
# Redis가 TCP 요청을 수신하도록하는 포트를 정의하여 다른 머신이 연결할 수 있도록합니다.
redis['port'] = 6379
   
# Redis의 암호 인증 설정(모든 노드에서 동일한 암호 사용)
redis['password'] = '여기에-redis-암호-입력'

기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다. 업그레이드 시 데이터베이스 마이그레이션을 방지하려면 /etc/gitlab/gitlab.rb 파일에 다음 구성을 추가하세요:
```
gitlab_rails['auto_migrate'] = false
```
변경 사항이 적용되려면 GitLab을 다시 구성합니다.

roles ['redis_sentinel_role', 'redis_master_role']와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 더 알아보기.

단계 2. 복제본 Redis 인스턴스 구성

복제본 Redis 서버에 SSH로 로그인합니다.
Linux 패키지를 다운로드하고 설치합니다. GitLab 다운로드 페이지의 단계 1과 2를 사용합니다.
- 현재 설치된 버전 및 유형(Community, Enterprise Edition)과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다.
- 다운로드 페이지의 다른 단계를 완료하지 않습니다.

/etc/gitlab/gitlab.rb를 편집하고 내용을 추가합니다:

# 서버 역할을 'redis_replica_role'로 지정
roles ['redis_replica_role']
   
# 다른 머신이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
# 모든 인터페이스에서 수신 대기하기 위해 bind를 '0.0.0.0'으로 설정할 수도 있습니다.
# 외부 액세스 가능한 IP에 바인딩하는 경우 무단 액세스를 방지하도록 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.0.0.2'
   
# Redis가 TCP 요청을 수신하도록하는 포트를 정의하여 다른 머신이 연결할 수 있도록합니다.
redis['port'] = 6379
   
# 기본 노드에서 설정한 Redis 인증용 동일한 암호
redis['password'] = '여기에-redis-암호-입력'
   
# 기본 Redis 노드의 IP
redis['master_ip'] = '10.0.0.1'
   
# 기본 Redis 서버의 포트, 기본값 변경을 해제하려면 주석 처리합니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

업그레이드 시 자동으로 reconfigure가 실행되는 것을 방지하려면 다음을 실행합니다:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
모든 다른 복제본 노드에 대해 다시 한 번 단계를 수행하세요.

roles ['redis_sentinel_role', 'redis_master_role']와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 더 알아보기.

변경할 내용이 없다면 /etc/gitlab/gitlab.rb에서 다시 변경하지 않아도 됩니다. 노드는 Sentinels에 의해 관리되고 gitlab-ctl reconfigure 후에도 Sentinels에 의해 구성이 복원됩니다.

단계 3. Redis Sentinel 인스턴스 구성

참고: Sentinel 암호 인증 지원은 GitLab 16.1에서 소개되었습니다.

이제 Redis 서버가 모두 설정되었으므로 Sentinel 서버를 구성해봅시다.

Redis 서버가 올바르게 작동하고 복제되고 있는지 확실하지 않다면 복제 문제 해결을 읽고 진행하기 전에 문제를 해결하세요.

적어도 3개의 Redis Sentinel 서버가 있어야 하며 독립적인 기기에 각각 있어야 합니다. 다른 Redis 서버를 구성한 곳과 동일한 기기에 구성할 수 있습니다.

GitLab Enterprise Edition을 사용하면 Linux 패키지를 사용하여 Sentinel 데몬이 있는 여러 기기를 설정할 수 있습니다.

Redis Sentinel을 호스트하는 서버에 SSH로 로그인합니다.
다른 Redis 인스턴스가 호스트하는 노드와 Sentinels를 호스트하는 노드가 동일한 경우 이 단계를 생략할 수 있습니다.
Linux Enterprise Edition 패키지를 다운로드하고 설치합니다. GitLab 다운로드 페이지의 단계 1과 2를 사용합니다. - 현재 GitLab 애플리케이션이 실행 중인 버전과 동일한 올바른 Linux 패키지를 선택했는지 확인합니다. - 다운로드 페이지의 다른 단계를 완료하지 않습니다.

/etc/gitlab/gitlab.rb를 편집하고 다음 내용을 추가합니다(만약 Sentinels을 다른 Redis 인스턴스를 호스트하는 동일한 노드에 설치하는 경우 일부 값은 중복될 수 있습니다):

roles ['redis_sentinel_role']
   
# 모든 sentinel 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis'
   
# 기본 노드에서 설정한 Redis 인증용 동일한 암호
redis['master_password'] = '여기에-redis-암호-입력'
   
# 기본 Redis 노드의 IP
redis['master_ip'] = '10.0.0.1'
   
# Redis가 TCP 요청을 수신하도록하는 포트를 정의하여 다른 머신이 연결할 수 있도록합니다.
redis['port'] = 6379
   
# 기본적인 Redis 서버의 포트, 기본값 변경을 해제하려면 주석 처리합니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
## Sentinel 구성
sentinel['bind'] = '10.0.0.1'
   
## Sentinel 인증용 선택적 비밀번호. 기본 설정은 비밀번호가 필요하지 않음입니다.
# sentinel['password'] = '여기에-sentinel-암호-입력'
   
# Sentinel이 수신 대기하는 포트, 기본값 변경을 해제하려면 주석 처리합니다. 기본값은 `26379`입니다.
# sentinel['port'] = 26379
   
## 1. 투표 센티넬 수를 반영해야 합니다. 
## 값은 반드시 센티넬 수보다 클 수 없습니다.
## 
## 센티넬은 두 가지 방법으로 조정할 수 있습니다.
## 1. 다수의 센티넬에 비해 투표수가 작게 설정된 경우, 기본적으로 센티넬을 주요 실패에 민감하게 만들어 절반의 센티넬에서 더 이상 주요가 아닌 경우가
##    발생하면 장애 조치를 트리거합니다.
## 1. 다수의 센티넬에 비해 투표수가 크게 설정된 경우, 센티넬이 매우 많고 상당한 수(ALM)의 잘 연결된 센티넬의 가장자리 다운에 동의하는 경우에만 
##    동의하기 때문에 센티넬은 매우 많고 잘 연결된 센티넬의 대부분이 기본 서버가 중단된 것을 인시할 때에만 장애 조치할 수 있습니다.
sentinel['quorum'] = 2
   
## x밀리초 후 무응답 서버를 다운으로 간주
# sentinel['down_after_milliseconds'] = 10000
   
## 밀리초 단위의 장애 조치 제한 시간을 지정합니다. 여러 가지 방법으로 사용됩니다.
## - 이전 장애 작업을 이미 시도한 센티넬이 동일한 기본에 대해 장애 조치를 다시 시작하는 데 필요한 시간은 failover 제한시간의 두 배입니다.
## - 잘못된 기본에 대한 레플리카 복제시도에는 sentinel이 현재 구성에 따라 잘못된 기본과 복제되기까지 정확히 failover_timeout할 때까지 거릅니다.
## - 현재 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 승격된 복제본이 아닌 REPLICAOF NO ONE을 아직 인정받지 않았지만 이미 시도된 경우).
## - 현재 진행 중인 장애 조치가 새로운 기본의 모든 복제본이 새로운 기본의 복제본으로 다시 구성되기를 기다리는 최대 시간. 그러나 이 시간이 지나도
##   Sentinels에 의해 복제가 수행되지만 parallel-syncs 진행은 정확하지만 지정된 것과는 약간 다릅니다.
# sentinel['failover_timeout'] = 60000

업그레이드 시 데이터베이스 마이그레이션을 방지하려면 다음을 실행합니다:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
기본 GitLab 애플리케이션 서버만 마이그레이션을 처리해야 합니다.
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
모든 다른 Sentinel 노드에 대해 다시 한 번 단계를 수행하세요.

단계 4. GitLab 애플리케이션 구성

마지막으로, 주요 GitLab 애플리케이션 서버에 Redis Sentinel 서버 및 인증 자격 증명을 알리는 것입니다.

설치 바랍니다. redis[‘master_name’] = ‘gitlab-redis’

Example of a minimal configuration with 1 primary, 2 replicas and 3 Sentinels

실제 사용시, 외부로부터의 접근을 방지하기 위해 방화벽 규칙을 설정하고, 외부(인터넷)에서의 트래픽을 차단하기 위해서도 설정해야 합니다.

Redis 프라이머리 및 Sentinel 1에 대한 구성 예시

/etc/gitlab/gitlab.rb에서:

roles ['redis_sentinel_role', 'redis_master_role']
redis['bind'] = '10.0.0.1'
redis['port'] = 6379
redis['password'] = 'redis-password-goes-here'
redis['master_name'] = 'gitlab-redis' # 모든 sentinel 노드에서 동일해야 합니다.
redis['master_password'] = 'redis-password-goes-here' # 기본 인스턴스에서 정의된 동일한 값
redis['master_ip'] = '10.0.0.1' # 초기 프라이머리 redis 인스턴스의 IP
#redis['master_port'] = 6379 # 기본값이 아닌 다른 포트로 변경하려면 주석 처리를 해제합니다
sentinel['bind'] = '10.0.0.1'
# sentinel['password'] = 'sentinel-password-goes-here' # 모든 sentinel 노드에서 동일해야 하며, 암호를 설정하려면 주석 처리를 해제합니다
# sentinel['port'] = 26379 # 기본 포트를 변경하려면 주석 처리를 해제합니다
sentinel['quorum'] = 2
# sentinel['down_after_milliseconds'] = 10000
# sentinel['failover_timeout'] = 60000

GitLab 재구성하여 변경 사항이 적용되도록 합니다.

GitLab 애플리케이션의 예제 구성

/etc/gitlab/gitlab.rb에서:

redis['master_name'] = 'gitlab-redis'
redis['master_password'] = '여기에 레디스 비밀번호 입력'
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.0.0.1', 'port' => 26379},
  {'host' => '10.0.0.2', 'port' => 26379},
  {'host' => '10.0.0.3', 'port' => 26379}
]
# gitlab_rails['redis_sentinels_password'] = 'sentinel-비밀번호-입력-여기' # 주석 해제하고 sentinel['password']와 동일한 값으로 설정

변경 사항을 적용하려면 GitLab 재구성을 실행하세요.

고급 구성

이 섹션에서는 권장되는 최소 구성을 넘어선 구성 옵션을 다룹니다.

여러 개의 Redis 클러스터 실행

Linux 패키지는 다른 지속 클래스에 대해 별도의 Redis 및 Sentinel 인스턴스를 실행하는 것을 지원합니다.

클래스	용도
`cache`	캐시된 데이터 저장
`queues`	Sidekiq 백그라운드 작업 저장
`shared_state`	세션 관련 및 기타 지속 데이터 저장
`actioncable`	ActionCable의 Pub/Sub 큐 백엔드
`trace_chunks`	CI trace chunks 데이터 저장
`rate_limiting`	속도 제한 상태 저장
`sessions`	세션 저장
`repository_cache`	리포지터리에 특화된 캐시 데이터 저장

Sentinel과 함께 사용하려면:

귀하의 요구에 따라 다른 Redis/Sentinels를 구성하세요.

각 Rails 애플리케이션 인스턴스에 대해 /etc/gitlab/gitlab.rb 파일을 편집하세요:

gitlab_rails['redis_cache_instance'] = REDIS_CACHE_URL
gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
gitlab_rails['redis_actioncable_instance'] = REDIS_ACTIONCABLE_URL
gitlab_rails['redis_trace_chunks_instance'] = REDIS_TRACE_CHUNKS_URL
gitlab_rails['redis_rate_limiting_instance'] = REDIS_RATE_LIMITING_URL
gitlab_rails['redis_sessions_instance'] = REDIS_SESSIONS_URL
gitlab_rails['redis_repository_cache_instance'] = REDIS_REPOSITORY_CACHE_URL
   
# Sentinel 구성
gitlab_rails['redis_cache_sentinels'] = [
  { host: REDIS_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REDIS_CACHE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_queues_sentinels'] = [
  { host: REDIS_QUEUES_SENTINEL_HOST, port: 26379 },
  { host: REDIS_QUEUES_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_shared_state_sentinels'] = [
  { host: SHARED_STATE_SENTINEL_HOST, port: 26379 },
  { host: SHARED_STATE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_actioncable_sentinels'] = [
  { host: ACTIONCABLE_SENTINEL_HOST, port: 26379 },
  { host: ACTIONCABLE_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_trace_chunks_sentinels'] = [
  { host: TRACE_CHUNKS_SENTINEL_HOST, port: 26379 },
  { host: TRACE_CHUNKS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_rate_limiting_sentinels'] = [
  { host: RATE_LIMITING_SENTINEL_HOST, port: 26379 },
  { host: RATE_LIMITING_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_sessions_sentinels'] = [
  { host: SESSIONS_SENTINEL_HOST, port: 26379 },
  { host: SESSIONS_SENTINEL_HOST2, port: 26379 }
]
gitlab_rails['redis_repository_cache_sentinels'] = [
  { host: REPOSITORY_CACHE_SENTINEL_HOST, port: 26379 },
  { host: REPOSITORY_CACHE_SENTINEL_HOST2, port: 26379 }
]
   
# gitlab_rails['redis_cache_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_queues_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_shared_state_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_actioncable_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_trace_chunks_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_rate_limiting_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_sessions_sentinels_password'] = 'sentinel-비밀번호-입력-여기'
# gitlab_rails['redis_repository_cache_sentinels_password'] = 'sentinel-비밀번호-입력-여기'

Redis URL은 redis://:PASSWORD@SENTINEL_PRIMARY_NAME 형식이어야 하며:
- PASSWORD는 Redis 인스턴스의 평문 암호입니다.
- SENTINEL_PRIMARY_NAME은 redis['master_name']으로 설정한 Sentinel 주 이름입니다. 예: gitlab-redis-cache.

파일을 저장하고 변경 사항이 적용되도록 GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```

각 지속 클래스에 대해 GitLab은 변경된 설정에 대한 기본 구성을 사용하며, 이전에 설명한 설정에 의해 재정의되지 않는 한 기본적으로 gitlab_rails['redis_sentinels']을 사용합니다.

실행 중인 서비스 제어

이전 예에서는 redis_sentinel_role 및 redis_master_role을 사용하여 구성 변경의 양을 줄이는 데 사용했습니다.

더 많은 제어를 원한다면, 각 역할이 활성화되었을 때 자동으로 설정하는 내용은 다음과 같습니다:

## Redis Sentinel 역할
redis_sentinel_role['enable'] = true

# Sentinel 역할이 활성화되면 다음 서비스도 활성화됩니다
sentinel['enable'] = true

# 다음 서비스들은 비활성화됩니다
redis['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

-------

## Redis primary/replica 역할
redis_master_role['enable'] = true # 둘 중 하나만 활성화합니다
redis_replica_role['enable'] = true # 둘 중 하나만 활성화합니다

# Redis primary 또는 Replica 역할이 활성화되면 다음 서비스들이
# 활성화/비활성화됩니다. Redis 및 Sentinel 역할이 결합되면 두 서비스
# 모두 활성화됩니다.

# 다음 서비스들은 비활성화됩니다
sentinel['enable'] = false
bootstrap['enable'] = false
nginx['enable'] = false
postgresql['enable'] = false
gitlab_rails['enable'] = false
mailroom['enable'] = false

# Redis Replica 역할의 경우 이 설정도 기본값 'true'에서 'false'로 변경하세요:
redis['master'] = false

관련 속성은 gitlab_rails.rb에서 찾을 수 있습니다.

시작 시 동작 제어하기

GitLab 15.10에서 도입됨.

번들에 포함된 Redis 서비스가 부팅시 시작하지 않도록 하거나 구성을 변경한 후 재시작되지 않도록하려면:

/etc/gitlab/gitlab.rb 파일을 편집합니다:
```
redis['start_down'] = true
```
GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

새 복제 노드를 테스트해야하는 경우 start_down을 true로 설정하고 노드를 매뉴얼으로 시작할 수 있습니다. 새로운 복제 노드가 Redis 클러스터에서 작동하는 것이 확인되면 start_down을 false로 설정하고 GitLab을 다시 구성하여 노드가 작동 중에 예상대로 시작 및 재시작되도록 합니다.

복제 구성 제어하기

GitLab 15.10에서 도입됨.

Redis 구성 파일에 replicaof 라인을 렌더링하지 않도록하려면:

/etc/gitlab/gitlab.rb 파일을 편집합니다:
```
redis['set_replicaof'] = false
```
GitLab을 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

이 설정은 다른 Redis 설정과는 독립적으로 Redis 노드의 복제를 방지하는 데 사용할 수 있습니다.

문제 해결

Redis 문제 해결 가이드를 참조하십시오.

더 읽어보기

자세히 알아보기:

Redis 복제 및 Linux 패키지와 장애 조치

추천 설정

Redis 설정 요약

Sentinel 설정 요약

Redis 구성

요구 사항

기존 단일 머신 설치에서 전환하는 경우

단계 1. 기본 Redis 인스턴스 구성

단계 2. 복제본 Redis 인스턴스 구성

단계 3. Redis Sentinel 인스턴스 구성

단계 4. GitLab 애플리케이션 구성

Example of a minimal configuration with 1 primary, 2 replicas and 3 Sentinels

Redis 프라이머리 및 Sentinel 1에 대한 구성 예시

GitLab 애플리케이션의 예제 구성

고급 구성

여러 개의 Redis 클러스터 실행

실행 중인 서비스 제어

시작 시 동작 제어하기

복제 구성 제어하기

문제 해결

더 읽어보기

도움말

기능 사용 가능성과 제품 평가판

도움받기