通过负载均衡器使用mlGradle部署时出错

Question

我们在AWS中有一个3节点集群设置，由负载均衡器提供支持。通过负载均衡器访问管理UI，查询控制台和REST apis都很好。但是当通过mlGradle部署模块内容时，我们会收到以下错误。

:mlLoadModules FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':mlLoadModules'.
> Unable to insert content at URI: /config/context.xml; cause: Query evaluation request rejected (400, BAD_REQUEST). Is this an XDBC server?

针对单个节点时，此错误很正常。我的猜测是它可能会击中不同的主机，导致失败。我有AWS负载平衡器设置用于粘贴cookie，但这似乎没有帮助。

之前有其他人见过这个问题吗？

Answer 1

回到基础：绕过负载均衡器，然后在受控测试中单独点击每个节点。确保其余部分的工作方式与预期的每个节点一样。然后移动到负载均衡器上，如果每个节点都自己看起来没问题 - 粘性与否，看起来你没有碰到XDBC服务器。

Answer 2

错误与AWS负载均衡器的配置有关。所有端点都列为HTTP端点，因此我创建了负载均衡器以将请求代理为HTTP。在我的特定部署中，使用XDBC将​​文件加载到模块的根目录。 HTTP端点也启用了XDBC，但负载均衡器只接受HTTP，这就是我收到错误请求的原因。将负载均衡器切换为所有端口的TCP都可以正常工作。

Answer 3

问题既不是负载均衡器，也不是Xdbc vs http。 xdbc是HTTP兼容的，如果不是，那么没有请求可以工作，你可以通过使用来验证它。具有原始配置的1节点群集。它会工作。 “问题”是由mlgradle执行的管理操作的要求与负载终止的概念之间的错误连接。排序的管理操作如果由于多种原因而命中不同的ML服务器可能不起作用，一个是定时和等待条件休息调用，这些调用仅在联系的服务器中有效（例如，等待主机重新启动完成，更新节点中的节点）特定顺序以适应故障转移，事务，会话状态等）。

您对负载均衡器所做的是将其从cookie亲和性更改为其他算法。这确实会改变行为，但不会从根本上修复它，你还会导致ELB刷新，这已经被观察到导致ELB没有为第一组连接加载balencem。这会导致测试出现误报结果，因为不会发生目标服务器的实际分发。您可以通过启动新ELB并测试背靠背连接来查看哪些服务器被命中。请注意，无论什么服务器被击中，MOST的东西通常都能正常工作，你不能仅仅通过使用黑盒测试来注意错误就无法验证“它是否正常工作” - 可能很难 - 或者不变 - 来确定产生意外的事件的确切顺序（行为......你可以通过使用xdmp：host（）在qconsole中看到这个...运行几次，等待一段时间，重复一遍。你能指望什么 ？那会发生吗？它是否始终可重复？什么样的应用会受到影响？是不是错了？如果你没有预先得到答案，我建议不要在应用程序代码和marklogic之间使用load balencers。如果您的应用程序完全无状态，请在applidation和Internet /浏览器用户之间使用它们。如果没有，那么加载压延机不是解决方案。