如何修复使用 JavaScript 驱动程序时遇到的 Cannot Connect to proxy at port; 错误？

- 对于 CE 和 BE 发行版，请在手动启动代理时提供 user.security 文件。例如：
java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port>
-store <storename> -username admin -security <path>/user.security
- EE 发行版使用钱夹，因此，除了在类路径中设置 oraclepki.jar 之外，请指定在手动启动代理时指定 user.security
文件。例如：
java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port>
-store <storename> -username admin -security <path>/user.security

可以使用哪些 JVM 运行 Oracle NoSQL Database？

Oracle NoSQL Database 服务器与 Java SE 8（64 位）及更高版本兼容，客户端与 Java SE 6 及更高版本兼容。两者都经过 Oracle Java SE 8 Update 73 的测试和认证。我们鼓励您升级到 Java 新版本，以利用新的错误修复和性能改进。试图用早于所需版本的 Java 版本使用此版本会产生类似以下内容的错误消息：Exception in thread "main" java.lang.UnsupportedClassVersionError: oracle/kv/impl/util/KVStoreMain :Unsupported major.minor version 52.0

为什么我会看到 UnsupportedClassVersionError 异常？

Oracle NoSQL Database 第 1 版和第 2 版要求 Java SE 6 或更高版本的 Java 运行时。第 3 版需要 Java SE 7 或更高版本。Oracle NoSQL Datatabase 第 4 版需要 Java SE 8 或更高版本。如果看到类似下面的错误消息，您可能试图使用早期版本的 Java 运行它。

Exception in thread "main" java.lang.UnsupportedClassVersionError:Bad version number in .class file

Exception in thread "main" java.lang.UnsupportedClassVersionError:
oracle/kv/impl/util/KVStoreMain :Unsupported major.minor version 51.0

在管理计划运行时获取反馈

可通过以下几种方式跟踪管理命令的进度。

show plan -id <id> 将显示命令的新状态。

show topology 命令将显示存储的当前布局以及当前存在的 NoSQL DB 服务。

NoSQL DB 服务创建并联机后，将刷新 Admin Console 的 Topology 选项卡（4.3 之前的版本）。

在计划执行时，您可以同时通过 Topology 选项卡（4.3 之前的版本）或 Admin CLI 发出 verify 命令。服务启动时，verify 将提供服务的状态信息。

您可以通过 Admin Console 的 Logs 选项卡（4.3 之前的版本）或 CLI 的 logtail 命令跟踪存储级日志。

在哪里可以找到错误信息

随着管理计划的执行和完成，会提供管理计划的错误信息。每次尝试运行计划失败时，都会在计划历史记录中报告错误。可通过命令行界面 KVAdmin（也称为“java -jar kvstore.jar runadmin”或简称“CLI”）的 show plan -id <id> 命令或 Admin Console 中的 Plans And Configuration 选项卡（4.3 之前的版本）查看计划历史记录。使用 -verbose 标志将添加更多详细信息。

还可能异步发生其他问题。通过 Admin Console 的 Logs 选项卡（4.3 之前的版本）中显示的关键事件或通过 CLI 的 show events 命令，您可以了解意外故障、服务停机和性能问题。事件带有时间戳，其描述可能包含足够的信息来诊断问题。在其他情况下，可能需要更多上下文，并且管理员可能希望查看该时刻前后还发生了什么。

存储级日志整合了所有服务的日志记录输出。浏览此文件可以让管理员更全面地了解问题期间的活动。该视图可通过 Admin Console 的 Logs 选项卡（4.3 之前的版本）或 CLI 的 logtail 命令查看，也可以通过直接查看 <KVHOME>/<storename>/log 目录中的 <storename>_N.log 文件进行查看。还可以使用 Admin Console 的 Logs 选项卡下载存储级日志文件。

.log 文件采用什么格式？

KVROOT/<store_name>?log 目录中的 .log 文件包含来自每个 NoSQL DB 组件的跟踪消息。每行开头部分是消息的日期、严重性以及发出消息的组件的名称。例如：

10-01-11 08:39:43:548 UTC INFO [admin1] Initializing Admin for store: kvstore

行格式为 MM-dd-yy HH:mm:ss:SSS <java.util.logging.Level> [组件名] 消息。查找给定时刻事件的更多上下文时，请使用时间戳和组件名缩小要浏览的日志部分范围。严重异常使用 SEVERE 日志级别记录，并通过 Admin Console 和 CLI (java -jar kvstore.jar runadmin) show events 命令提供。

.perf 文件采用什么格式？

管理服务以每个复制节点为单位收集服务器端吞吐量和延迟统计信息。可以通过 Admin Console 的 topology 选项卡（4.3 之前的版本）、命令行界面 (CLI) show perf 命令和主管理服务的 KVROOT log 目录中提供的 <storename>.perf 文件查看这些统计信息。还可以通过 Admin Console 找到并下载 .perf 文件。

按 statsInterval 复制节点参数确定的时间间隔（默认为 60 秒）计算吞吐量和延迟。.perf 文件的每一行代表一个复制节点的一个统计时间间隔。每行还适用于一个 optype 类别。

Single 和 Multi 这两个 optype 用于了解不同数据操作的性能特征。有些客户端 API 数据操作与单一数据记录有关，有些则与一条或多条记录有关。例如，KVStore.get() 方法提取一条数据记录，而 KVStore.multiGet() 提取一条或多条记录。所有单记录操作聚合和记录为 optype Single，而所有多记录操作以 optype Multi 形式报告。

从 NoSQL 2.0.25 开始，按请求计算延迟信息。由于多记录操作可以由许多记录分摊每条记录的开销，其效率可能明显高于单记录操作。统计信息可以按 optype 保存，有助于说明这种差异。

例如，如果应用在一个时间间隔内发出 KVStore.get()、KVStore.put()、KVStore.putIfVersion() 和 KVStore.multiGet() 操作，所有 multiGet 记录成一个 Multi 统计行，所有其他操作一起记录成一个 Single 统计行。

每行显示以下列：

Resource ：复制节点的名称
Time ：统计时间间隔的起始时间，格式为 MM/HH/YY hh:mm:ss
OpType ：Single 或 Multi

时间间隔性能统计信息：

Total Ops ：统计时间间隔内执行的该 optype 操作的数据记录数
PerSec ：该时间间隔内每秒数据记录数
Total Req ：对于 Single optype，每个时间间隔的操作数和请求数相同。对于 Multi optype，操作数可能大于或等于请求数，因为每个请求可能返回多条记录。
Min ：该时间间隔的最小请求延迟（以毫秒为单位）
Max ：该时间间隔的最大请求延迟（以毫秒为单位）
Avg ：该时间间隔的平均请求延迟（以毫秒为单位）
95th ：该时间间隔内第 95 百分位的请求的延迟
99th ：该时间间隔内第 99 百分位的请求的延迟

累计性能统计信息：

Total Ops ：复制节点进程生命周期内执行的该 optype 的操作数。每次复制节点重新启动时，都会重置累计值
PerSec ：RN 进程生命周期内的每秒操作数
Total Req ：对于 Single optype，操作数和请求数相同。对于 Multi optype，操作数可能大于或等于请求数，因为每个请求可能返回多条记录。
Min ：RN 进程生命周期内的最小延迟（以毫秒为单位）
Max ：RN 进程生命周期内的最大延迟（以毫秒为单位）
Avg ：RN 进程生命周期内的平均延迟（以毫秒为单位）
95th ：RN 进程生命周期内第 95 百分位的操作延迟
99th ：RN 进程生命周期内第 99 百分位的操作延迟

NoSQL DB 服务有哪些状态？

NoSQL DB 服务分为三种类型：管理、存储节点和复制节点。每个服务都有状态，可通过 Admin Console 中的 Topology 选项卡（4.3 之前的版本）、CLI (java -jar kvstore.jar runadmin) 中的 show topology 命令或 java -jar kvstore.jar ping 查看。

状态值包括：

正常运行的服务从 STARTING 开始。在转到 RUNNING 之前，它可能短暂切换到 WAITING_FOR_DEPLOY。ERROR_RESTARTING 和 ERROR_NO_RESTART 表示存在应该调查的问题。UNREACHABLE 服务只能临时处于该状态，但如果该状态持续的话，服务可能真的变成 ERROR_RESTARTING 或 ERROR_NO_RESTART 状态。

注意，Topology 选项卡只显示异常的服务状态。处于 RUNNING 状态的正常运行的组件的服务状态为空白。

为什么我的计划在报告错误后仍然运行？

管理计划可能调用异步执行的远程服务。每个计划步骤（即任务）可以运行的最长时间由 task_timeout 参数配置，默认为 5 分钟。一旦确定了成功或错误结果，或者超过超时时段，任务结束。

异步远程服务可能遇到错误，错误直接回报到 Admin Console，并显示在错误对话框中，然后由任务确定结果。因此，用户可能已经获悉错误，而管理服务仍然认为计划处于 RUNNING 和活动状态。计划最终将看到错误，并转换到 ERROR 状态。

我的存储节点注册端口配置不正确

如果您为存储节点 (SN) 注册端口指定了无效值，存储节点代理将无法正常启动。您将无法通过 jps -m 命令查看 SNA，它不会响应 java -jar kvstore.jar ping 命令。SN 根目录中的 snaboot_0.log 文件将显示错误信息。例如，如果注册端口已在使用，日志可能显示：

10-03-11 22:47:59:525 EDT SEVERE [snaService] Failed to start SNA:
Port already in use:1000; nested exception is:
java.net.BindException:Permission denied

您应删除 KVROOT 目录并重复 makebootconfig 安装步骤

我的存储节点 HA 端口范围配置不正确

如果您为 HA 端口范围（如常见问题解答中前面所述）指定了无效值，将无法在此 SN 上部署复制节点 (RN) 或辅助管理进程 (Admin)。当您首次尝试在该故障 SN 上部署存储或管理副本时，将会发现此问题。您将看到这些指示，表明 RN 未在此存储节点上启动：

Admin Console（4.3 之前的版本）将显示一个错误对话框，警告此 RN 处于 ERROR_RESTARTING 状态。Topology 选项卡也将以红色显示此状态，并且在数次重试后，将指示 RN 处于 ERROR_NO_RESTART 状态。

计划将转入 ERROR 状态，可通过在 Admin Console 的 Plans and Configuration 选项卡（4.3 之前的版本）中单击计划或通过 java -jar kvstore.jar runadmin "show plan <planId>" 命令查看其详细的历史记录，其中将显示如下的错误消息：

Attempt 1
state:ERROR
start time:10-03-11 22:06:12
end time:10-03-11 22:08:12
DeployOneRepNode of rg1-rn3 on sn3/farley:5200 [RUNNING] failed.
....  Failed to attach to RepNodeService for rg1-rn3, see log,
/KVRT3/<storename>/log/rg1-rn3*.log, on host farley for more
information.

关键事件机制（可通过 Admin Console（4.3 之前的版本）或 CLI 访问）将显示一条警报，其中包含与计划历史记录中相同的错误信息。

检查指定的 .log 文件或 Admin Console 的 Log 选项卡（4.3 之前的版本）中显示的存储级日志将显示特定的错误消息，例如：

[rg1-rn3] Process exiting
java.lang.IllegalArgumentException:Port number 1 is invalid because the
port must be outside the range of "well known" ports

可以通过这些步骤解决配置错误。有些步骤必须在托管 NoSQL DB 存储节点的物理节点上执行，而其他步骤可以在能够访问 Admin Console 或 Admin CLI 的任何节点上完成。

使用 Admin Console 或 Admin CLI 取消因配置错误而运行出错的 deploy-store 或 deploy-admin 计划。

在 SN 节点上，终止现有的配置错误的 StorageNodeAgentImpl 进程及其所有 ManagedProcesses。您可以通过参数“-root <KVROOT>”将它们与其他进程区分开来。

在 SN 节点上，删除 KVROOT 目录中的所有文件。

在 SN 节点上，使用 java -jar kvstore.jar makebootconfig 命令在 KVROOT 目录中重新创建存储节点引导配置文件。

在 SN 节点上，使用 java -jar kvstore.jar start 重新启动存储节点。

通过 Admin Console 或 Admin CLI 使用 deploy-sn 计划重新部署存储节点。

现在，您已经返回之前遇到错误的位置，您可以使用与初始尝试相同的参数创建和执行 deploy-store 或 deploy-admin 计划。

配置过程中抛出了 java.net.NoRouteToHostException

有些用户在配置过程中看到 java.net.NoRouteToHostException 。即使可以 ping （使用 Unix 或 Windows CLI ping 命令，而非 Oracle NoSQL Database 的“ping”命令）和 ssh 目标计算机，但配置 Oracle NoSQL Database 仍可能失败。典型异常可能如下所示：

[nosql@nosql0 kv-1.2.123]$ java -jar ./lib/kvstore-1.2.123.jar ping -port 5000
-host nosql1.example.com
Exception in thread "main" java.rmi.ConnectIOException:Exception creating
connection to: nosql1.example.com; nested exception is:
java.net.NoRouteToHostException:No route to host
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:632)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
at sun.rmi.registry.RegistryImpl_Stub.list(Unknown Source)
at oracle.kv.util.Ping.getTopology(Ping.java:332)
at oracle.kv.util.Ping.main(Ping.java:104)
at oracle.kv.impl.util.KVStoreMain$8.run(KVStoreMain.java:218)
at oracle.kv.impl.util.KVStoreMain.main(KVStoreMain.java:319)
Caused by: java.net.NoRouteToHostException:No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:327)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:193)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:180)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
at java.net.Socket.connect(Socket.java:546)
at java.net.Socket.connect(Socket.java:495)
at java.net.Socket.(Socket.java:392)
at java.net.Socket.(Socket.java:206)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket
(RMIDirectSocketFactory.java:40)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket
(RMIMasterSocketFactory.java:146)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
...8 more
[nosql@nosql0 kv-1.2.123]$

通常，这是因为在一台或多台正在使用的计算机上运行 iptables 。要检查 iptables 设置，可以执行 iptables -L -n 。这可能产生如下输出：

[root@nosql1 init.d]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,
ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp
dpt:22
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
[root@nosql1 init.d]#

要解决此问题，您应该创建规则，允许通过您为 Oracle NoSQL Database 配置的端口通信。要测试是否是因为 iptables，一个简单的解决办法是临时关闭 iptables（但请注意，这将禁用防火墙规则，导致潜在的安全问题）。