4

我们在更新 Java SDK 版本后尝试连接到集群时遇到问题。

系统设置如下：

我们有一个使用 Java SDK 和 Couchbase 集群的 Web 应用程序。在两者之间，我们有一个 VIP（虚拟 IP 地址）。我们意识到这并不理想，但我们无法立即改变这一点，因为 VIP 是由 Tech Ops 授权的。VIP 基本上只是在应用程序启动时重新路由初始请求。这样我们就可以对集群进行修改，并确保当应用程序启动时，它可以找到集群，而不管集群中的实际节点及其 IP。

在此问题之前，我们使用 JAVA SDK 版本 1.4.4。我们的应用程序将启动，Java SDK 将在端口 8091 上向 VIP 发起请求。请注意，8091 端口是 VIP 上唯一开放的端口。VIP 会将请求重新路由到当前正在使用的节点集群之一，该集群将响应 Java SDK。那时，Java SDK 会发现集群中的所有节点，并且应用程序会运行良好。在正常运行期间，如果我们要从集群中添加、删除一个节点，Java SDK 将自动更新，并且一切都将运行而不会出现问题。

在上一个 sprint 中，我们将 Java SDK 更新到了 2.1.3 版。我们的应用程序将启动，Java SDK 将在端口 11210 上向 VIP 发起请求。由于此端口未打开，请求将失败，Java SDK 将抛出异常：

Caused by: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.couchbase.client.java.util.Blocking.blockForSingle(Blocking.java:93)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:108)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:99)
at com.couchbase.client.java.CouchbaseCluster.openBucket(CouchbaseCluster.java:89)

不会对任何港口提出进一步的要求。

似乎版本之间使用端口的顺序已更改。有人可以确认或质疑用于集群发现的端口顺序已在版本之间更改。也有人可以就我们如何解决这个问题提供一些建议。我们正在尝试了解客户端的行为，如果我们可以打开 VIP 上的所有这些端口，那么客户端是否仍能正常运行并发挥全部性能？

这个问题发生在我们的生产环境中，我们不能用它来测试潜在的解决方案，因为它会干扰我们的产品。

4

2 回答 2

2

在 Java SDK 的 v2.x 中，默认为 11210 以获取集群映射以引导应用程序。这实际上是一个巨大的改进，因为现在映射来自托管缓存而不是集群管理器 (8091)。如果 SDK无法在 11210 上获取地图，则应使用 8091 作为后备。不管怎样，你真的很想从 11210 得到那张地图，相信我。它清理了很多问题。

要解决这个长期问题并遵循 Couchbase 最佳实践，请升级到 Java 2.2.x SDK，完全摆脱 VIP 并改用 DNS SRV 记录。这为您提供了 SDK 连接对象的一个​​ DNS 条目，您只需管理 DNS 中的节点列表。它工作得很好。我说 SDK 2.2 作为 DNS SRV 记录解决方案在那里得到完全支持，在 2.1 中它是实验性的。这些天来，Couchbase 特别推荐 VIP。在旧版本的 SDK 中，这样做很好，它有助于限制从应用程序到 DB 节点的连接数量，但这不再是必要的，实际上可能是一件坏事。

于 2015-09-21T18:34:18.713 回答
1

除了Kirk 的长期答案（我也建议您遵循），短期解决方案可能是通过调用构建器来停用 11210 引导（运营商引导） 。CouchbaseEnvironmentbootstrapCarrierEnabled(false)

即使在那之后，我也不保证它会与 vIP 一起使用，但如果你赶时间的话，这可能值得一试。

于 2015-09-23T08:18:22.687 回答