IBM Cloud Docs
管理任务

管理任务

对大量数据创建新索引或复制大型数据库可能需要较长的一段时间。

如何确定您的任务是正在进行还是已完成? _active_tasks 端点可提供有关所有进行中任务的信息。 但是,如果启动大量任务,那么其中一些任务可能会安排在稍后运行,并且不会显示在 _active_tasks 下 直到他们开始

请参阅以下 SDK 和 curl 代码示例:

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® 以获取可用选项的完整指南。

curljq 基础知识

要获取所有活动任务并以适当方式格式化输出,请使用 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% 正确。 完成任务所需实际时间取决于以下因素:

  • 处理每个文档所需的时间。 例如,视图可能首先检查文档类型,然后仅针对一种类型发出新的索引条目。
  • 文档的大小。
  • 集群上的当前工作负载。

您必须假定这些因子可能组合在一起,从而在估算中产生相当大的不准确性。

请参阅使用 jq抽取 changes_done 字段的示例:

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

监视复制

要查找所有复制任务,请将 curl 输出传送到 jq,然后按文档类型字段过滤数组中的文档。

通过执行以下步骤,可以更轻松地从活动任务列表中选择有关复制过程的信息:

  1. 通过在 _replicator 数据库中创建文档来启动复制过程。
  2. 将其 _id 字段设置为已知值。

请参阅通过过滤 replication 类型来查找所有复制任务的示例:

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

请参阅通过过滤已知文档身份来查找特定复制任务的示例:

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 数据库中创建文档而创建了复制过程,那么还可以在该数据库中检查复制的状态。