Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
设置属性 schedule 以将索引器配置为按计划运行。 索引器计划在以下情况下非常有用:
- 源数据随时间变化,你希望索引器自动处理差异。
- 源数据非常大,你需要一个定期计划来为所有内容编制索引。
- 一个索引通过多个索引器从多个数据源填充数据,你希望将这些作业错峰执行以减少冲突。
如果无法在典型的 2 小时处理窗口内完成索引,请将索引器计划为每 2 小时运行一次,以逐步处理大量数据。 只要你的数据源支持更改检测逻辑,索引器就可以在每次运行时自动从中断的位置继续运行。
一旦将索引器设为按计划运行,它就会一直按照该计划运行,直到清除间隔设置或开始时间,或者将 disabled 设为 true。 如果计划索引器意外停止触发,请参阅 计划行为常见问题解答 了解恢复步骤。 在没有任何内容需要处理时,让索引器按计划运行不会影响系统性能。 检查更改的内容是一项相对较快的操作。
前提条件
使用数据源和索引配置的有效索引器。
数据源中的更改检测。 Azure 存储和SharePoint具有内置的更改检测。 对于其他数据源(如Azure SQL和Azure Cosmos DB),必须手动启用更改检测。
计划定义
计划是索引器定义的一部分。 如果省略该 schedule 属性,索引器仅按需运行。 属性包含两个部分。
| 属性 | 说明 |
|---|---|
| 间隔 | (必需)连续两次执行索引器之间的时间间隔。 允许的最小间隔为 5 分钟,最长为 1,440 分钟(24 小时)。 将其格式化为 XSD“dayTimeDuration”值( ISO 8601 持续时间 值的受限子集)。
此值的模式为: P(nD)(T(nH)(nM))。
示例: PT15M 为每隔 15 分钟,PT2H 为每隔 2 小时。 |
| 开始时间 | (可选)指定协调世界时(UTC)的开始时间。 如果省略此值,则使用当前时间。 此时间可以是过去的时间,在这种情况下,第一次执行将被安排得如同索引器自原始开始时间起一直在运行。 |
以下示例计划从 1 月 1 日午夜开始,每 2 小时运行一次。
{
"dataSourceName" : "hotels-ds",
"targetIndexName" : "hotels-idx",
"schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}
配置日程安排
在索引器定义中指定计划。 若要设置计划,请使用Azure门户、REST API 或Azure SDK。
- 在 Azure 门户中,转到你的搜索服务。
- 在左窗格中,选择 “索引器”。
- 打开索引器。
- 选择“设置”。
- 向下滚动到 “计划”,然后选择“ 每小时”、“ 每日”或“ 自定义 ”以设置特定的日期、时间或自定义间隔。
切换到索引顶部的“索引器定义(JSON)”选项卡,以 XSD 格式查看计划定义。
计划行为常见问题解答
是否可以并行运行多个索引器作业?
可以同时运行多个索引器,但每个索引器都是单个实例。 不能同时运行同一索引器的两个副本。
对于基于文本的索引,调度程序可以启动的索引器作业数量最多可达到搜索服务所支持的上限,而该数量由 搜索单位 的数量决定。 例如,如果该服务有三个副本和四个分区,那么你可能有 12 个索引器作业处于活动执行状态,无论是按需启动还是按计划启动。
对于基于技能的索引编制,索引器在特定的执行环境中运行。 因此,服务单元的数量不会影响可运行的基于技能的索引器作业数量。 多个基于技能的索引器可以并行运行,但这样做会依赖于执行环境中的内容处理器可用性。
计划作业是否始终在指定时间启动?
索引器进程可以排队,可能不会在发布时完全启动,具体取决于处理工作负荷和其他因素。 例如,如果索引器在下一次计划执行开始时恰好仍在运行,则此次待执行的任务会推迟到下一个计划执行时间,从而让当前作业得以完成。
若要使此行为更加具体,请考虑以下示例。 假设你配置索引器计划,间隔为每小时,开始时间为 2024 年 1 月 1 日上午 8:00:00 UTC。 下面是索引器运行时间超过一小时时可能出现的情况:
第一次索引器执行的开始时间为 2024 年 1 月 1 日上午 8:00 (UTC) 左右。 假设此执行需要 20 分钟(或不到 1 小时的任何时间)。
第二次执行的开始时间为 2024 年 1 月 1 日上午 9:00 (UTC) 左右。 假设此执行需要 70 分钟(超过一小时),直到 UTC 上午 10:10 才完成。
第三次执行的计划开始时间为上午 10:00 (UTC),但此时上一次执行仍在运行。 那么,将会跳过此计划的执行。 索引器的下一次执行直到 UTC 上午 11:00 才开始。
在极少数情况下,例如在维护期间或从暂时性状况中恢复时,系统会将多个索引器运行排入队列。 当出现这种情况时,索引器会在计划时间窗口内按顺序执行待处理的工作负载。 例如,如果某个索引器计划为每小时运行一次,而其中几次运行被延迟或按需触发,那么这些已排队的作业将连续执行,直到队列清空为止。 这些运行并非额外的运行,而是指先前已计划或已请求的执行任务。 尽管大多数情况下这种行为并不常见,但索引器旨在最终处理所有排队任务,以保持一致性和数据新鲜度。
注意
如果对时间敏感的索引器执行要求严格,请考虑使用 推送 API 模型 ,以便可以直接控制索引管道。
如果索引编制在同一文档上重复失败,会发生什么情况?
如果将索引器设置为按某个计划运行,但它每次都在同一文档上反复失败,则索引器会开始按较低频率运行(最长可延长到至少每 2 小时一次或每 24 小时一次,具体取决于不同的实现因素),直到它再次成功取得进展。 如果你认为你修复了基础问题, 请手动运行索引器。 如果索引成功,索引器将返回到其常规计划。 如果索引器在成功手动运行后未恢复其正常计划,请参阅下一个问题。
计划的索引器已停止触发。 如何重置其计划?
如果计划的索引器停止运行,请禁用并重新启用它以重置计划。 需要此恢复的标志:即使配置了计划并更改了数据源,执行历史记录中也不会显示新的运行。
将 disabled 设置为 true 将暂停该计划。 将它重新设置为 false (或省略属性)将恢复计划,使用当前时间作为配置间隔的新基线。
- 在 Azure 门户中,转到你的搜索服务。
- 选择 索引器。
- 选择索引器以将其打开。
- 选择“设置”。
- 将索引器设置为 “已禁用”。
- 选择“保存”。
- 将索引器设置回 “已启用”。
- 选择“保存”。
注意
重新启用索引器会相对于当前时间重置计划,而不是原始 startTime计划。 例如,如果间隔为 2 小时,并在下午 3:15 重新启用,则下一次计划的运行大约为下午 5:15。
后续步骤
对于按计划运行的索引器,可以通过从搜索服务检索状态来监视操作,或通过启用资源日志记录来获取详细信息。