rippled 서버가 동기화되지 않음

이 페이지에서는 rippled 서버가 성공적으로 시작되었지만 네트워크에 완전히 연결되지 않고 "연결됨" 상태로 멈출 수 있는 이유를 설명합니다. (시작 중 또는 시작 직후 서버가 충돌하는 경우에는 서버가 시작되지 않음을 참조하세요.)

이 안내는 지원되는 플랫폼에 rippled를 설치했다고 가정합니다.

정상적인 동기화 동작

네트워크와의 동기화는 일반적으로 약 5분에서 15분 정도 소요됩니다. 이 시간 동안 서버는 여러 가지 작업을 수행합니다:

  • 권장 유효성 검사기 목록(일반적으로 vl.ripple.com에서)을 로드하여 어떤 유효성 검사기를 신뢰할지 결정합니다.

  • 피어 서버를 검색하고 피어 서버에 연결합니다.

  • 피어 서버에서 최신 ledger의 헤더와 전체 상태 정보를 다운로드하고, 이를 사용해 내부 ledger 데이터 데이터베이스를 구축합니다.

  • 신뢰할 수 있는 검증자를 수신하여 최근에 검증이 완료된 ledger 해시를 찾습니다.

  • 새로 브로드캐스트된 트랜잭션을 수집하여 진행 중인 ledger에 적용하려고 시도합니다.

이러한 작업을 수행하는 동안 서버가 네트워크를 따라잡을 수 없으면 서버는 네트워크에 동기화되지 않습니다.

첫 번째 단계: 재시작

대부분의 동기화 문제는 서버를 다시 시작하면 해결할 수 있습니다. 처음에 동기화하지 못한 이유와 상관없이 두 번째 시도에서는 동기화에 성공할 수 있습니다.

server_info 메소드에 제안 중 또는 가득 찼음 이외의 server_state가 표시되고 server_state_duration_us가 900000000(마이크로초 단위로 15분) 이상인 경우, rippled 서비스를 종료하고 몇 초 기다린 후 다시 시작해야 합니다. 선택 사항으로 전체 컴퓨터를 다시 시작하세요.

문제가 지속되면 이 페이지에 나열된 다른 가능성을 확인해 보세요. 이 중 어느 것도 해당되지 않는 것 같으면 rippled 저장에서 이슈를 열고 "동기화 이슈" 레이블을 추가하세요.

동기화 문제의 일반적인 원인

동기화 문제의 가장 일반적인 원인은 시스템 요구 사항을 충족하지 않는 것입니다. 가장 일반적인 세 가지 부족 사항은 다음과 같습니다:

  • 느린 디스크. 일관되게 빠른 SSD(솔리드 스테이트 디스크)가 필요합니다. AWS와 같은 클라우드 제공업체는 다른 고객과 공유하는 하드웨어에 따라 디스크 성능이 달라지기 때문에 일반적으로 디스크 성능을 보장하지 않습니다.

  • RAM이 부족. 메모리 요구사항은 네트워크 부하와 XRP Ledger를 사용하는 방식 등 예측하기 어려운 여러 요인에 따라 달라지므로 최소 시스템 요구사항보다 더 많은 메모리를 보유하는 것이 좋습니다.

  • 나쁜 네트워크 연결 상태. 네트워크 요구사항은 사람들이 XRP Ledger를 사용하는 방식에 따라 가장 크게 달라지지만, 연결이 느리거나 불안정하면 XRP Ledger에 추가된 새로운 트랜잭션과 데이터를 따라잡을 수 없을 수 있습니다.

동기화 상태를 유지하는 데 문제가 있다면 서버가 시스템 요구 사항을 충족하는지 다시 확인하세요. 서버 사용 방식에 따라 더 높은 "권장" 요구사항을 충족해야 할 수도 있습니다. "권장" 요구 사항을 충족하는데도 동기화가 되지 않는다면 이 페이지에 나와 있는 다른 방법을 시도해 보세요.

유효성 검증인 목록을 로드할 수 없음

기본 구성은 vl.ripple.com에서 검색된 권장 유효성 검증인 목록을 사용합니다. 이 목록은 rippled의 암호화 키 쌍으로 서명되며 만료 날짜가 내장되어 있습니다. 어떤 이유로 서버가 vl.ripple.com에서 목록을 다운로드할 수 없는 경우, 서버는 신뢰할 수 있는 검증자 집합을 선택하지 않으며 어떤 ledger을 유효한 것으로 선언할지 결정할 수 없습니다. (testnet이나 다른 병렬 네트워크에 연결되어 있는 경우 서버는 대신 해당 네트워크의 신뢰할 수 있는 검증인 목록을 사용합니다.)

server_info 메소드 응답의 validator_list 블록은 만료일을 포함한 검증인 목록의 상태를 보여줍니다. 목록이 있지만 만료된 경우 서버가 이전에 유효성 검증인 목록 사이트에 연결되었지만 최근에 연결할 수 없었기 때문에 서버가 최신 목록을 다운로드할 수 없는 동안 현재 목록이 만료되었을 수 있습니다.

validator_list_sites 메소드를 사용하여 더 자세한 정보를 얻을 수도 있습니다. 응답의 유효성 검증인 사이트 객체에서 last_refresh_status 및 last_refresh_time 필드가 누락된 경우 서버가 유효성 검증인 목록 사이트에 연결하는 데 문제가 있는 것일 수 있습니다. 방화벽 구성을 확인하여 포트 80(HTTP) 또는 443(HTTPS)에서 나가는 트래픽을 차단하고 있지 않은지 확인하세요. 또한 DNS가 유효성 검증인 목록 사이트의 도메인을 확인할 수 있는지 확인하세요.

피어 수가 충분하지 않음

서버가 충분한 수의 피어 서버에 연결되지 않은 경우, 네트워크가 새 트랜잭션을 계속 처리하는 동안 네트워크와 동기화된 상태를 유지하기에 충분한 데이터를 다운로드하지 못할 수 있습니다. 네트워크 연결이 불안정하거나 안정적인 고정 피어를 충분히 추가하지 않고 서버를 비공개 서버로 구성한 경우 이러한 문제가 발생할 수 있습니다.

피어 메소드를 사용하여 서버의 현재 피어에 대한 정보를 얻습니다. 정확히 10개 또는 11개의 피어가 있는 경우 방화벽이 들어오는 피어 연결을 차단하고 있다는 의미일 수 있습니다. 들어오는 연결을 더 많이 허용하도록 포트 포워딩을 설정하세요. 서버가 비공개 서버로 구성되어 있는 경우에는 구성 파일에서 [ips_fixed] 구문의 내용과 구문을 다시 확인하고 가능한 경우 프록시 또는 공용 허브를 더 추가하세요.

손상된 데이터베이스

드물지만 rippled 서버의 내부 데이터베이스에 저장된 데이터가 손상되어 동기화에 실패하는 경우가 있습니다. 서버가 실행 중이 아니라면 대부분의 상황에서 서버의 데이터베이스를 안전하게 삭제할 수 있습니다. 손상된 데이터는 디스크에 복사하거나 쓸 때 일시적인 하드웨어 오류, 더 심각한 디스크 오류, 다른 프로세스가 충돌하여 디스크의 잘못된 부분에 쓰거나 기타 문제로 인해 발생할 수 있습니다.

현재 ledger를 다시 다운로드하고 다른 설정을 저장할 수 있는 여유 공간이 충분하다면 테스트용으로 서버의 데이터베이스 경로를 일시적으로 변경할 수 있습니다.

Note:

데이터베이스 경로를 변경하면 서버의 현재 노드 키 쌍 및 피어 예약과 같은 일부 저장된 설정은 서버에서 로드되지 않습니다. 데이터베이스 경로를 변경하여 서버의 동기화 문제가 해결되면 이러한 설정 중 일부를 다시 생성할 수 있습니다.

  1. rippled 서버가 실행 중인 경우 중지합니다.

$ sudo systemctl stop rippled
  1. 새 데이터베이스를 저장할 빈 폴더를 새로 만듭니다.

$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
  1. 새 경로를 사용하도록 구성 파일을 편집합니다. [node_db] 구절의 경로 필드와 [database_path] 구절의 값을 변경해야 합니다.

[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb

[database_path]
 /var/lib/rippled/db_new

권장 설치는 기본적으로 구성 파일 /etc/opt/ripple/rippled.cfg를 사용합니다. 구성 파일을 저장할 수 있는 다른 위치로는 $HOME/.config/ripple/rippled.cfg(여기서 $HOME은 rippled를 실행하는 사용자의 홈 디렉터리), $HOME/.local/ripple/rippled.cfg 또는 rippled를 시작한 현재 작업 디렉터리 등이 있습니다.

  1. rippled 서버를 다시 시작합니다.

$ sudo systemctl start rippled

서버가 새 데이터베이스를 사용하여 성공적으로 동기화되면 이전 데이터베이스가 있는 폴더를 삭제할 수 있습니다. 특히 디스크와 RAM에 하드웨어 오류가 있는지 확인할 수도 있습니다.

Last updated