무엇이 복구입니까?

elasticsearch에서 recovery는 한 인덱스의 조각을 다른 노드에 분배하는 과정을 가리킨다. 일반적으로 스냅샷 복구, 인덱스 복제 조각의 변경, 노드 고장 또는 재부팅할 때 발생한다. 마스터 노드는 전체 집단과 관련된 상태 정보를 저장하기 때문에 어떤 조각을 재분배하고 어느 노드에 분배해야 하는지 판단할 수 있다. 예를 들어

만약에 어떤 주분할이 있고 복제분할이 있는 노드가 끊어진다면master는 사용 가능한 노드를 따로 선택하여 이 주분할의 복제분할을 사용 가능한 노드에 분배한 다음에 주분할의 데이터 복제를 해야 한다

만약에 어떤 메인 필름이 있는 노드가 끊어지고 복제 필름이 남아 있다면master는 복제 필름을 메인 필름으로 업그레이드한 다음에 메인 필름에서 데이터 복제를 주도할 것이다

만약에 어떤 분할의 주부분할이 모두 끊어진다면 당분간 복구할 수 없고 관련 데이터를 보유한 노드가 다시 집단에 가입한 후에master가 데이터 복구 관련 조작을 진행할 수 있다..

그러나 복구 과정은 CPU, 메모리, 노드 간의 네트워크 대역폭 등 추가 자원을 소모해야 한다.집단의 서비스 성능이 떨어지고 심지어 일부 기능이 일시적으로 사용할 수 없기 때문에 복구 과정과 관련된 설정을 파악하여 불필요한 소모와 문제를 줄일 필요가 있다.

집단fullrestart로 인한 데이터 왕복 복사 감소

때때로 es 집단이 전체적으로 재개되는 상황을 만날 수 있다. 예를 들어 하드웨어 업그레이드, 불가항력의 의외 등이다. 그러면 다시 집단을 재개하는 것은 문제를 가져올 수 있다. 일부 노드가 우선화되고 주 노드가 우선적으로 선출되며 주 노드가 있으면 이 주 노드는 즉시recovery의 과정을 주재한다.
그러나 이때 이 집단 데이터는 아직 완전하지 않다. (다른 노드가 일어나지 않았다.) 예를 들어 A 노드의 주 분할에 대응하는 복제 분할이 있는 B 노드가 일어나지 않았지만, 주 노드는 A 노드의 복제 분할이 없는 몇 개의 주 분할을 사용할 수 있는 C 노드에 다시 복사할 것이다.그러나 B 노드가 성공하고 자체 검사를 할 때 자신의 노드에 저장된 A 노드의 메인 블록에 대응하는 복제 블록이 C 노드에 이미 나타났다는 것을 발견하면 자신의 노드에서'실효'된 데이터(A 노드의 몇 개의 복제 블록)를 직접 삭제한다. 이런 상황은 여러 노드의 집단에 빈번하게 나타날 가능성이 높다.
그러나 전체 집단이 회복된 후에 그 각 노드의 데이터 분포는 분명히 불균형적이다. (먼저 시작한 노드가 데이터를 복구했고 나중에 일어난 노드에서 무효한 데이터를 삭제했다.) 이때master는 Rebalance의 과정을 촉발하여 데이터를 각 노드 사이로 옮기는데 이 과정은 대량의 네트워크 데이터를 소모한다.따라서 우리는 복구 관련 파라미터를 합리적으로 설정하여 복구 과정을 최적화해야 한다.

집단 시작 과정에서 몇 개의 노드가 성공적으로 시작되면 복구 프로세스를 실행합니다. 이 명령은 마스터 노드(마스터 자격이 있는 노드)와 데이터 노드를 모두 포함합니다

gateway.expected_nodes: 3

몇 개의 마스터 노드가 시작되면 복구 과정을 수행합니다.

gateway.expected_master_nodes: 3

몇 개의 데이터 노드가 시작되면 복구 과정을 수행합니다..

gateway.expected_data_nodes: 3
집단이 기대하는 노드 수 조건이 충족되기 전에recovery 과정이 기다립니다gateway.recover_after_time 지정된 시간, 대기 시간이 초과되면 다음과 같은 조건에 따라 복구 프로세스를 실행할지 여부를 판단합니다.

gateway.recover_after_nodes: 3    # 3 （master data ） 
gateway.recover_after_master_nodes: 3  # 3 master 
gateway.recover_after_data_nodes: 3   # 3 data 

위의 세 가지 설정이 하나를 충족시키면 복구 과정을 실행할 수 있습니다.다음과 같이 구성된 클러스터가 있는 경우

gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8

이때 집단은 5분 안에 10개의 데이터 노드가 집단에 가입하거나 5분 후에 8개 이상의 데이터 노드가 집단에 가입하면 복구 과정을 시작합니다.

운영 복제본 간 데이터 복제 감소

만약fullrestart가 아니라 하나의 노드를 다시 시작하면 서로 다른 노드 사이를 복제할 수 있습니다. 이 문제를 피하기 위해 다시 시작하기 전에 그룹을 닫을 수 있습니다shard allocation .

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"none"
  }
}

노드가 재부팅되면 다시 엽니다.

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"all"
  }
}

이렇게 하면 노드가 다시 시작된 후에 가능한 한 이 노드에서 직접 데이터를 복구할 수 있다.그러나es1.6 버전 이전에 상기 조치를 취했음에도 불구하고 대량의 주부분편 간의 데이터 복사가 나타날 수 있다는 점은 이해하기 어렵다. 주부분편 데이터는 완전히 일치한다. 노드가 재부팅된 후에 본 노드의 사본에서 직접 수증을 다시 복원하면 된다. 왜 다시 주부분편에서 복제해야 하는가?복구는 주 부분편의 segment 파일(분단 파일)을 간단하게 비교하여 어떤 데이터가 일치하는지 로컬 복구가 가능한지, 어떤 일치하지 않으면 다시 복사해야 하는지 판단하기 때문이다.한편, 서로 다른 노드의segment 파일은 완전히 독립적으로 실행된다. 이것은 주 부본merge의 깊이가 완전히 일치하지 않아 제때에 문서 집합이 똑같아지고segment 파일은 완전히 같지 않을 수 있다.
이 문제를 해결하기 위해 es1.6 버전 이후에syncedflush(동기화 리셋)의 새로운 기능을 추가했습니다. 5분 동안 업데이트되지 않은shard에 대해syncedflush를 자동으로 추가합니다. 사실은 대응하는shard에 대한syncedflushid를 추가합니다. 이렇게 노드가 리셋된 후에 주부shard의syncedflushid를 비교하면 두 shard가 완전히 같은지 알 수 있고 불필요한 segment 파일 복사를 피할 수 있습니다.
주의해야 할 것은syncedflush는 콜드 인덱스에만 유효하고, 핫 인덱스 (5분 안에 업데이트된 인덱스) 에는 무효이며, 다시 시작하는 노드에 핫 인덱스가 포함되어 있다면, 대량의 복사를 피할 수 없습니다.대량의 열 인덱스를 포함하는 노드를 재부팅하려면 다음 절차에 따라 재부팅 프로세스를 실행하여 복구 프로세스를 순식간에 완성할 수 있습니다.

데이터 쓰기를 일시 중지합니다

집단의shardallocation을 닫습니다

수동 POST 수행/_flush/synced

노드를 다시 시작합니다

집단의shardallocation을 다시 시작합니다

복구가 완료되기를 기다립니다. 집단의healthstatus가 그린 후입니다

데이터 쓰기 다시 시작

특대열 인덱스가 왜 느리게 회복됩니까

콜드 인덱스에 대해 데이터가 더 이상 업데이트되지 않기 때문에(elasticsearch에 대해 5분, 오래되었습니다)syncedflush를 이용하여 로컬에서 데이터를 신속하게 복구할 수 있습니다. 핫 인덱스, 특히shard의 큰 열 인덱스는syncedflush파가 쓸모가 없기 때문에segmentfile를 대량으로 복사해야 하는 것을 제외하고translogrecovery가 느린 더 중요한 원인이 될 수 있습니다.
이translog recovery가 뭔지 연구해 봅시다!노드가 재부팅되면 운영 슬라이스에서 데이터를 복구하고 슬라이스를 복제하는 데 3단계가 걸립니다.

첫 번째 단계는 메인 슬라이드에 있는segment 파일에 스냅샷을 만들어서 복제 슬라이드가 있는 노드로 복사합니다. 데이터 복사 기간에 색인 요청을 막지 않고 새로운 색인 작업은translog에 기록됩니다(임시 파일로 이해됩니다)

두 번째 단계는translog에 대한 스냅샷을 만듭니다. 이 스냅샷은 첫 번째 단계에 추가된 인덱스 요청을 포함하고 스냅샷에 있는 인덱스 작업을 다시 만듭니다. 이 단계는 인덱스 요청을 막지 않고 인덱스 작업을translog에 기록합니다

3단계, 주부분편의 완전한 동기화를 위해 새로운 인덱스 요청을 막은 다음 1단계에 추가된translog 작업을 다시 시작합니다..

이를 통해 알 수 있듯이 복구 과정이 끝나기 전에translog는 제거될 수 없습니다.만약shard가 비교적 크다면 첫 번째 단계는 시간이 오래 걸리고 이 단계에서 발생하는translog가 매우 크다. 간단한 파일 복사보다 translog를 다시 넣는 데 시간이 더 걸리기 때문에 두 번째 단계의translog 소모 시간도 현저히 증가했다.3단계가 되면 다시 넣어야 하는translog가 2단계보다 더 많을 수 있습니다.중요한 것은 3단계는 새로운 인덱스 (쓰기) 요청을 막을 수 있기 때문에 쓰기에 대한 실시간 요구가 높은 상황에서 성능 저하를 초래하고 사용자 체험에 매우 영향을 미친다.따라서 특대 열 인덱스 복구 속도를 높이려면 이전 섹션의 방식을 참조하는 것이 좋습니다.

데이터 쓰기 일시 중지..

수동 synced flush..

데이터 복구 완료 후..

데이터 쓰기 재개..

이렇게 하면 데이터 지연의 영향을 최소화할 수 있다.