长时间运行操作的最佳实践

在 Azure Analysis Services 中，节点表示运行服务器资源的主机虚拟机。如果服务器资源移动到其他节点，某些操作（例如长时间运行的查询、刷新操作和查询横向扩展的同步）可能会失败。此场景中的常见错误消息包括：

“尝试查找长时间运行的 XMLA 请求时出错。该请求可能已被服务升级或服务器重启中断。”
ID 为<guid>的< 'database'> 模型的作业因服务错误（不活动）而被取消，消息为“取消刷新请求，因为它停滞而没有任何更新。” 这是一个内部服务问题。如果此问题重复发生，请重新提交作业或提交票证以获取帮助。”

导致长时间运行操作中断的原因有很多。例如，Azure 中的下述更新：

操作系统修补
安全更新
Azure Analysis Services 服务更新
Service Fabric 更新 Service Fabric 是由许多 Microsoft 云服务（包括 Azure Analysis Services）使用的平台组件。

除了服务中发生的更新外，由于需要进行负载均衡，服务还会在各个节点之间自然移动。云服务需要进行节点移动。 Azure Analysis Services 会尝试最大程度地降低节点移动影响，但无法完全消除它们。

除了节点移动之外，还可能发生其他故障。例如，数据源数据库系统可能处于脱机状态或网络连接丢失。如果在刷新期间，分区有 1000 万行，并且第 900 万行发生故障，则无法重启故障点的刷新。服务必须从头开始重新启动。

刷新 REST API

对于长时间运行的操作（如数据刷新）来说，服务中断可能具有挑战性。 Azure Analysis Services 包括一个 REST API，可帮助缓解服务中断带来的负面影响。若要了解详细信息，请参阅使用 REST API 进行异步刷新。

除了 REST API，你还可以使用其他方法在长时间运行的刷新操作期间尽量减少潜在问题。目标是避免不得不从头开始重启刷新操作，而是在能够分阶段提交的较小批次中执行刷新。

REST API 允许进行此类重启，但不允许完全灵活地创建和删除分区。如果方案需要复杂的数据管理作，解决方案应在其逻辑中包含某种形式的批处理。例如，通过使用事务以多批次且分开的方式处理数据，允许在失败时不必从头开始重启，而是从中间的检查点重新启动。

无论是使用 REST 还是自定义逻辑，客户端应用程序查询在处理批处理时仍可返回不一致或中间结果。如果在处理发生时需要客户端应用程序查询返回的一致数据，并且模型数据处于中间状态，请对只读查询副本使用横向扩展。

通过使用只读查询副本，在批量执行刷新时，客户端应用程序用户可以继续查询只读副本上的旧数据快照。刷新完成后，可以执行同步操作，使只读副本更新至最新状态。