通过负载均衡器使用 mlGradle 进行部署时出错
Error deploying with mlGradle via load balancer
我们在 AWS 中有一个 3 节点集群设置，前面有一个负载均衡器。通过负载均衡器可以访问管理 UI、查询控制台和 REST api。但是当通过 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 的粘性，但这似乎没有帮助。
有没有其他人以前见过这个问题？
回到基础：绕过负载均衡器，然后在受控测试中分别命中每个节点。确保其余的每个节点都像您期望的那样工作。然后，如果每个节点看起来都正常，则转移到负载均衡器上 - 粘性与否，看起来你没有访问 XDBC 服务器。
错误与 AWS 负载均衡器的配置有关。所有端点都列为 HTTP 端点，因此我创建了负载均衡器以将请求代理为 HTTP。在我的特定部署中，使用 XDBC 将文件加载到模块的根目录。 HTTP 端点也启用了 XDBC，但负载均衡器只接受 HTTP，这就是我收到错误请求的原因。将所有端口的负载平衡器切换到 TCP 工作正常。
问题既不是负载平衡器也不是 Xdbc vs http。 xdbc 是 HTTP 兼容的，如果不是，则没有请求将起作用，您可以通过使用来验证这一点。具有原始配置的 1 节点集群。它会起作用。 “问题”是由 mlgradle 执行的管理操作的要求与负载平衡的概念之间的错误连接。由于多种原因，如果它们命中不同的 ML 服务器，排序的管理操作可能无法工作，其中一个是计时和等待条件休息调用，它们仅在联系的服务器中有效，（例如，等待主机重启完成，更新节点特定顺序以适应故障转移、事务、会话状态等）。
您对负载均衡器所做的是将其从 cookie affinity 更改为不同的算法。这确实会改变行为，但不会从根本上解决它，您还导致了 ELB 刷新，据观察这会导致 ELB 不为第一组连接加载 balencem。这会导致测试出现误报，因为没有实际分布目标服务器。您可以通过启动一个新的 ELB 并测试背对背连接以查看哪些服务器被命中来进行验证。请注意，无论命中什么服务器，大多数事情通常都能正常工作，您不能简单地通过不注意使用黑盒测试的错误来验证“它有效”——它可能很难——或经常——命中 th% 产生意外的事件的确切顺序（虽然并不总是错误的）行为......你可以通过使用 xdmp:host() .. 运行 几次在 qconsole 中看到这个，等一下，重复。你能指望什么 ？那件事发生了吗？它是否始终可重现？什么样的应用程序 behvious 会受到影响？是错的吗？如果你事先没有答案，我建议不要在应用程序代码和 marklogic 之间使用负载平衡器。如果您的应用程序是完全无状态的，请在应用程序和 internet/browser 用户之间使用它们。如果不是，那么负载平衡器不是解决方案。
我们在 AWS 中有一个 3 节点集群设置，前面有一个负载均衡器。通过负载均衡器可以访问管理 UI、查询控制台和 REST api。但是当通过 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 的粘性，但这似乎没有帮助。
有没有其他人以前见过这个问题？
回到基础：绕过负载均衡器，然后在受控测试中分别命中每个节点。确保其余的每个节点都像您期望的那样工作。然后，如果每个节点看起来都正常，则转移到负载均衡器上 - 粘性与否，看起来你没有访问 XDBC 服务器。
错误与 AWS 负载均衡器的配置有关。所有端点都列为 HTTP 端点，因此我创建了负载均衡器以将请求代理为 HTTP。在我的特定部署中，使用 XDBC 将文件加载到模块的根目录。 HTTP 端点也启用了 XDBC，但负载均衡器只接受 HTTP，这就是我收到错误请求的原因。将所有端口的负载平衡器切换到 TCP 工作正常。
问题既不是负载平衡器也不是 Xdbc vs http。 xdbc 是 HTTP 兼容的，如果不是，则没有请求将起作用，您可以通过使用来验证这一点。具有原始配置的 1 节点集群。它会起作用。 “问题”是由 mlgradle 执行的管理操作的要求与负载平衡的概念之间的错误连接。由于多种原因，如果它们命中不同的 ML 服务器，排序的管理操作可能无法工作，其中一个是计时和等待条件休息调用，它们仅在联系的服务器中有效，（例如，等待主机重启完成，更新节点特定顺序以适应故障转移、事务、会话状态等）。
您对负载均衡器所做的是将其从 cookie affinity 更改为不同的算法。这确实会改变行为，但不会从根本上解决它，您还导致了 ELB 刷新，据观察这会导致 ELB 不为第一组连接加载 balencem。这会导致测试出现误报，因为没有实际分布目标服务器。您可以通过启动一个新的 ELB 并测试背对背连接以查看哪些服务器被命中来进行验证。请注意，无论命中什么服务器，大多数事情通常都能正常工作，您不能简单地通过不注意使用黑盒测试的错误来验证“它有效”——它可能很难——或经常——命中 th% 产生意外的事件的确切顺序（虽然并不总是错误的）行为......你可以通过使用 xdmp:host() .. 运行 几次在 qconsole 中看到这个，等一下，重复。你能指望什么 ？那件事发生了吗？它是否始终可重现？什么样的应用程序 behvious 会受到影响？是错的吗？如果你事先没有答案，我建议不要在应用程序代码和 marklogic 之间使用负载平衡器。如果您的应用程序是完全无状态的，请在应用程序和 internet/browser 用户之间使用它们。如果不是，那么负载平衡器不是解决方案。