태스크 관리

많은 데이터에 대한 새 인덱스를 작성하거나 대규모 데이터베이스를 복제하는 작업에는 많은 시간이 소요될 수 있습니다.

태스크가 진행 중인지 또는 완료되었는지 여부를 판별하려면 어떻게 해야 합니까? _active_tasks 엔드포인트는 모든 진행 중인 태스크에 대한 정보를 제공합니다. 그러나 다수의 태스크를 시작하는 경우, 일부 태스크는 나중에 실행되도록 스케줄되고 시작할 때까지 다음의 아래에 표시되지 않을 수 있습니다. _active_tasks

다음 SDK 및 컬 코드 예시를 참조하세요:

curl "$SERVICE_URL/_active_tasks"

import com.ibm.cloud.cloudant.v1.Cloudant;
import com.ibm.cloud.cloudant.v1.model.ActiveTask;
Cloudant service = Cloudant.newInstance();
List<ActiveTask> response =
    service.getActiveTasks().execute().getResult();
System.out.println(response);

const { CloudantV1 } = require('@ibm-cloud/cloudant');
const service = CloudantV1.newInstance({});
service.getActiveTasks().then(response => {
  console.log(response.result);
});

from ibmcloudant.cloudant_v1 import CloudantV1
service = CloudantV1.new_instance()
response = service.get_active_tasks().get_result()
print(response)

getActiveTasksOptions := service.NewGetActiveTasksOptions()
activeTask, response, err := service.GetActiveTasks(getActiveTasksOptions)
if err != nil {
  panic(err)
}
b, _ := json.MarshalIndent(activeTask, "", "  ")
fmt.Println(string(b))

이전 Go 예제에서는 다음 가져오기 블록이 필요합니다.

import (
    "encoding/json"
    "fmt"
    "github.com/IBM/cloudant-go-sdk/cloudantv1"
)

모든 Go 예제에서는 service 오브젝트가 초기화되어야 합니다. 자세한 정보는 API 문서 인증 섹션 예제를 참조하십시오.

이제 _active_tasks 엔드포인트를 사용하여 장기 실행 태스크를 모니터링하는 방법을 확인할 수 있습니다. curl 명령은 엔드포인트에 액세스하는 데 사용됩니다. jq 명령행 JSON 프로세서는 JSON 응답을 처리하기 위해 사용됩니다.

이 태스크 중심 튜토리얼은 이 태스크를 수행하는 데 필수적인 내용만을 다루고 있습니다. 자세한 정보는 IBM® Cloudant® for IBM Cloud® 사용에서 사용 가능한 옵션에 대한 전체 안내서를 참조하십시오.

`curl` 및 `jq` 기본 사항

모든 활성 태스크를 가져와 출력을 보기 좋게 형식화하려면 curl을 사용하여 계정을 호출하고 출력을 jq에 전달하십시오.

jq를 사용하면 필드 값에 따라 문서의 목록을 필터링할 수 있습니다. 이 필터는 모든 복제 문서를 가져오거나, 하나의 특정 뷰 인덱싱 태스크의 세부사항을 가져오기 쉽게 해 줍니다. 이 옵션에 대한 자세한 정보는 API 참조에 있습니다.

다음과 같이 활성 태스크의 목록을 얻고 형식화하는 예제를 참조하십시오.

curl "$SERVICE_URL/_active_tasks" | jq

뷰 빌드 및 검색 인덱스 모니터링

뷰 인덱스는 디자인 문서가 업데이트되면 다시 빌드됩니다. 뷰 중 하나가 업데이트되면 문서에 있는 모든 뷰가 다시 빌드됩니다.

검색 인덱스는 해당 인덱스 함수가 변경되는 경우에만 다시 빌드됩니다. 빌드되는 각 검색 인덱스와 변경된 뷰가 있는 각 디자인 문서마다, 클러스터에 있는 각 복제본 및 각 샤드에 대해 새 태스크가 작성됩니다.

예를 들어 각각 세 개의 복제본이 있는 24개의 샤드가 존재하며 두 개의 검색 인덱스를 업데이트하는 경우 24 x 3 x 2 = 144개의 태스크가 실행됩니다.

모든 뷰 인덱싱 태스크를 찾으려면 curl 출력을 jq에 전달하고, 여기에서 유형 필드에 따라 문서를 배열에 필터링하도록 하십시오. 해당 명령은 검색 인덱싱 태스크에 대해 작동합니다.

각 경우에 인덱싱 태스크 목록을 검색한 결과는 JSON 오브젝트의 목록입니다. 각 활성 태스크에 대해 하나씩 표시됩니다.

다음과 같이 indexer 유형에 대해 필터링하여 모든 보기 인덱싱 태스크를 찾는 예제를 참조하십시오.

curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="indexer")'

다음과 같이 search_indexer 유형에 대해 필터링하여 모든 검색 인덱싱 태스크를 찾는 예제를 참조하십시오.

curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="search_indexer")'

다음과 같이 보기 인덱싱 태스크를 검색한 이후의 결과 예제를 참조하십시오.

{
    "total_changes": 6435,
    "started_on": 1371118332,
    "user": "username",
    "updated_on": 1371118334,
    "type": "indexer",
    "node": "dbcore@db6.meritage.cloudant.net",
    "pid": "<0.16366.6103>",
    "changes_done": 364,
    "database": "shards/40000000-7fffffff/username/database",
    "design_document": "_design/ngrams"
}

태스크 완료 시간 예상

인덱싱 태스크가 완료되는 데 필요한 시간을 예상하려면 changes_done의 수를 모니터링하고 이 값을 total_changes와 비교하십시오. 예를 들어, changes_done이 초당 250씩 늘어나고 total_changes가 1,000,000인 경우 해당 태스크는 완료되는 데 1,000,000 / 250 = 4,000초 또는 66분이 소요될 것으로 예상됩니다.

인덱싱 태스크 완료 시간 예상이 100% 정확하지는 않습니다. 태스크를 완료하는 데 소요되는 실제 시간은 다음과 같은 요소에 따라 달라집니다.

각 문서를 처리하는 데 소요되는 시간. 예를 들면 다음과 같습니다. 어떤 뷰에서는 먼저 문서의 유형을 확인할 수도 있고, 그리고 단 하나의 유형에 대해서만 새로운 인덱스 항목을 생성합니다.
문서의 크기
클러스터의 현재 워크로드

이러한 요소가 결합되어 예상 시간에 상당한 오차가 발생할 수 있다는 것을 예상해야 합니다.

다음과 같이 changes_done를 사용하여 jq 필드를 추출하는 예제를 참조하십시오.

curl ... | jq '.[] | select(.type=="search_indexer") | .changes_done'

복제 모니터링

모든 복제 태스크를 찾으려면 curl 출력을 jq에 전달하고, 유형 필드에 따라 문서를 배열에 필터링하십시오.

다음 단계를 수행하여 활성 태스크의 목록에서 복제 프로세스에 대한 정보를 더 쉽게 선택할 수 있습니다.

_replicator 데이터베이스에 문서를 작성하여 복제 프로세스를 시작하십시오.
_id 필드를 알려진 값으로 설정하십시오.

다음과 같이 replication 유형에 대해 필터링하여 모든 복제 태스크를 찾는 예제를 참조하십시오.

curl -s "$SERVICE_URL/_active_tasks" | jq '.[] | select(.type=="replication")'

다음과 같이 알려진 문서 ID에 대해 필터링하여 특정 복제 태스크를 찾는 예제를 참조하십시오.

curl ... | jq '.[] | select(.doc_id=="ID")'

다음과 같이 알려진 replication_id에 대해 필터링하여 특정 복제 태스크를 찾는 예제를 참조하십시오.

curl ... | jq '.[] | select(.replication_id=="ID")'

다음과 같이 복제 태스크를 검색한 이후의 결과 예제를 참조하십시오.

{
    "started_on": 1371094220,
    "source_seq": "62960-sakdjflksdfjsdlkafjalskdfjlsakfjlasdkjksald",
    "source": "",
    "revisions_checked": 12,
    "continuous": true,
    "doc_id": null,
    "doc_write_failures": 0,
    "docs_read": 12,
    "target": "",
    "type": "replication",
    "updated_on": 1371118477,
    "user": "username",
    "checkpointed_source_seq": "61764-dskfjalsfjsalkfjssadjfhasdfkjhsdkfhsdkf",
    "changes_pending": 1196,
    "pid": "<0.9955.4120>",
    "node": "dbcore@db7.meritage.cloudant.net",
    "docs_written": 12,
    "missing_revisions_found": 12,
    "replication_id": "asfksdlfkjsadkfjsdalkfjas+continuous+create_target"
}

고착된 태스크 문제점 해결

태스크의 정지 여부

소스 데이터베이스가 복제 중에 크게 업데이트되지 않는 일회성 비연속 복제에서, changes_pending 값은 처리할 남은 문서의 수를 알려줍니다. 따라서 changes_pending 값은 복제 완료 시점에 대한 좋은 지표입니다.

연속 복제의 경우에는 시간 경과에 따른 처리 문서 수와 changes_pending 값의 증가 여부에 더 관심을 가져야 합니다. changes_pending이 증가하지만 revisions_checked가 변경되지 않는 상태로 유지되면 복제 작업이 정지되었을 가능성이 높습니다. changes_pending이 증가하며 revisions_checked도 증가하는 경우, 이러한 증가는 복제 속도가 데이터베이스에서 데이터가 추가되거나 업데이트되는 속도를 따라가지 못하고 있음을 나타낼 수 있습니다.

정지 태스크의 해결 방법

중단된 복제를 해결하려면, 복제 프로세스를 취소한 후 다시 시작해야 할 수도 있습니다.

이렇게 해도 해결되지 않는 경우에는 소스 또는 대상 데이터베이스에 액세스 중인 사용자에게 쓰기 권한이 없어 복제가 정지되었을 수 있습니다.

복제는 체크포인트를 사용하며, 이는 복제가 다시 시작되는 경우 이미 복제되었으며 변경되지 않은 컨텐츠는 다시 복제할 필요가 없음을 의미합니다.

_replicator 데이터베이스에 문서를 작성하여 복제 프로세스를 작성한 경우에는 여기에서 복제의 상태를 확인할 수도 있습니다.

태스크 관리

태스크 관리

curl 및 jq 기본 사항

뷰 빌드 및 검색 인덱스 모니터링

태스크 완료 시간 예상

복제 모니터링

고착된 태스크 문제점 해결

태스크의 정지 여부

정지 태스크의 해결 방법

`curl` 및 `jq` 기본 사항