Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

노드 업그레이드

이 절차를 사용하여 노드별 구성 및 검증자 상태를 보존하면서 Stable 노드를 업그레이드합니다. 항상 네트워크의 기록 페이지에서 버전, 바이너리 및 활성화 높이를 가져오세요.

시작하기 전에

필요한 사항:

  • 노드에 대한 셸 액세스 권한과 서비스 관리 권한.
  • 활성 데이터 디렉터리 외부에 보호된 백업을 위한 충분한 디스크 공간.
  • 배포에 대한 노드 홈, 서비스 이름 및 설치된 바이너리 경로.
  • 메인넷 버전 기록 또는 테스트넷 버전 기록에서 릴리스 항목.

아래 예시는 다음 경로를 사용합니다. 배포에 맞게 변경하세요.

export STABLED_HOME="/var/lib/stabled"
export STABLED_SERVICE="stabled"
export STABLED_BIN="/usr/local/bin/stabled"
export STABLED_ARCH="amd64" # ARM 호스트에서는 arm64 사용.
출력 없음.

1. 실행 중인 노드 확인

노드를 변경하기 전에 현재 빌드 및 동기화 상태를 기록합니다.

"$STABLED_BIN" version --long
curl -fsS http://localhost:26657/status \
  | jq '{catching_up: .result.sync_info.catching_up, latest_block_height: .result.sync_info.latest_block_height}'
<현재 빌드 정보>
{
  "catching_up": false,
  "latest_block_height": "<현재 높이>"
}

catching_up이 false가 될 때까지 계속하지 마세요.

2. 신원 및 구성 백업

검증자 키와 서명 상태를 비공개로 유지하세요. 이 백업을 암호화된 스토리지에 저장하고 노드 운영자에게만 제한된 권한을 부여하세요.

export STABLED_BACKUP="/var/backups/stabled/pre-upgrade"
sudo install -d -m 0700 "$STABLED_BACKUP"
sudo cp -a "$STABLED_HOME/config" "$STABLED_BACKUP/config"
sudo cp -a "$STABLED_HOME/data/priv_validator_state.json" \
  "$STABLED_BACKUP/priv_validator_state.json"
sudo cp -a "$STABLED_BIN" "$STABLED_BACKUP/stabled"
printf 'Backup stored at %s\n' "$STABLED_BACKUP"
백업이 /var/backups/stabled/pre-upgrade에 저장되었습니다.

3. 릴리스 다운로드 및 검사

Stable 메인넷은 블록 36,976,000에서 v1.8.0을 활성화했습니다. 호스트 아키텍처용 아카이브를 다운로드하고 설치 전에 보고된 빌드를 검사하세요.

export STABLED_RELEASE="v1.8.0"
export STABLED_ARCHIVE="/tmp/stabled-1.8.0-linux-${STABLED_ARCH}-mainnet.tar.gz"
export STABLED_STAGE="/tmp/stabled-v1.8.0"
 
curl -fL \
  "https://stable-data-dist.s3.us-east-1.amazonaws.com/mainnet/binary/stabled-1.8.0-linux-${STABLED_ARCH}-mainnet.tar.gz" \
  -o "$STABLED_ARCHIVE"
mkdir -p "$STABLED_STAGE"
tar -xzf "$STABLED_ARCHIVE" -C "$STABLED_STAGE"
"$STABLED_STAGE/stabled" version --long
<v1.8.0 빌드 정보>

다른 릴리스 또는 테스트넷의 경우 해당 버전 기록 표에서 정확한 바이너리 URL을 복사하세요.

4. v1.8.0 구성 준비

v1.8.0은 config.toml 및 app.toml 모두에 필요한 설정을 추가합니다. 메인넷 템플릿을 스테이징 디렉터리로 다운로드하세요.

export STABLED_CONFIG_STAGE="/tmp/stable-v1.8.0-config"
mkdir -p "$STABLED_CONFIG_STAGE"
curl -fL \
  "https://stable-data-dist.s3.us-east-1.amazonaws.com/mainnet/configuration/v1.8.0/partners/config.toml" \
  -o "$STABLED_CONFIG_STAGE/config.toml"
curl -fL \
  "https://stable-data-dist.s3.us-east-1.amazonaws.com/mainnet/configuration/v1.8.0/partners/app.toml" \
  -o "$STABLED_CONFIG_STAGE/app.toml"
printf 'Configuration staged at %s\n' "$STABLED_CONFIG_STAGE"
/tmp/stable-v1.8.0-config에 구성이 스테이징되었습니다.

이 템플릿에서 시작한 다음 백업에서 노드별 값을 모두 복원합니다. 최소한 다음을 확인하세요.

  • moniker 및 external_address.
  • 영구 피어, 시드 및 비공개 피어 설정.
  • API, JSON-RPC, gRPC 및 메트릭 설정.
  • 조직별 타임아웃 및 리소스 제한.
  • 아카이브 노드용 가지치기 설정.

배포된 app.toml은 기본 가지치기를 사용합니다. 가지치기된 기록은 로컬 노드에서 재구성할 수 없습니다. v1.8.0은 또한 inter-block-cache를 강제로 끕니다.

5. 노드 중지 및 파일 설치

조정된 향후 업그레이드의 경우, 노드가 게시된 높이에서 중지될 때까지 기다립니다. v1.8.0 메인넷 높이는 과거에 발생했으므로 이 설치 전에 이전 메인넷 노드를 중지할 수 있습니다.

sudo systemctl stop "$STABLED_SERVICE"
systemctl is-active "$STABLED_SERVICE" || true
비활성

스테이징된 바이너리와 완료된 구성 파일을 설치합니다.

sudo install -m 0755 "$STABLED_STAGE/stabled" "$STABLED_BIN"
cp "$STABLED_CONFIG_STAGE/config.toml" "$STABLED_HOME/config/config.toml"
cp "$STABLED_CONFIG_STAGE/app.toml" "$STABLED_HOME/config/app.toml"
printf 'Installed %s\n' "$STABLED_RELEASE"
v1.8.0 설치됨

v1.8.0 메인넷 업그레이드는 상태 내보내기, 가져오기 또는 스냅샷 재설정을 요구하지 않았습니다.

6. 노드 시작 및 확인

서비스를 시작하고 설치된 빌드를 확인한 다음 노드가 동기화를 다시 시작하는지 확인합니다.

sudo systemctl start "$STABLED_SERVICE"
systemctl is-active "$STABLED_SERVICE"
"$STABLED_BIN" version --long
curl -fsS http://localhost:26657/status \
  | jq '{catching_up: .result.sync_info.catching_up, latest_block_height: .result.sync_info.latest_block_height}'
활성
<v1.8.0 빌드 정보>
{
  "catching_up": false,
  "latest_block_height": "<현재 높이>"
}

노드를 정상 작동으로 되돌리기 전에 서비스 로그에서 반복되는 패닉, 합의 실패 또는 구성 구문 분석 오류를 확인합니다.

Cosmovisor로 향후 업그레이드 자동화

Cosmovisor는 온체인 업그레이드 핸들러가 구성된 높이에 도달하면 바이너리를 전환할 수 있습니다. Cosmovisor 문서를 따르고 해당 거버넌스 제안의 업그레이드 이름을 사용하세요.

운영 정책이 구성된 소스를 명시적으로 신뢰하지 않는 한 자동 바이너리 다운로드를 비활성화된 상태로 유지하세요. 활성화 높이 전에 릴리스 바이너리를 스테이징하고 확인하세요.

릴리스별 지침이 있는 경우에만 롤백

새 프로세스가 업그레이드된 블록을 실행하기 전에 실패하면 서비스를 중지하고 오류를 검사하세요. 릴리스 노트에 롤백이 안전하다고 명시된 경우에만 이전 바이너리 및 구성을 복원하세요.

노드가 업그레이드된 블록을 실행했다면 네트워크 운영자와 복구를 조율하세요. 복구에는 릴리스별 바이너리 또는 합의된 높이의 신뢰할 수 있는 스냅샷이 필요할 수 있습니다.

다음으로 이동할 곳