常见问题解答 — Oracle NoSQL Database


更新时间:2017 年 2 月 27 日

综合

API


故障排除

 

综合


BE/CE 和 EE 有何差异?


除了社区版/基础版提供的所有特性之外,Oracle NoSQL Database 企业版还包含其他特性:

  • 通过外部表与 Oracle Database 集成,使用 SQL 查询将 Oracle NoSQL 数据读取到 Oracle Database 中(注 — Oracle Big Data SQL 集成包括在所有版本中)
  • 与 Oracle Enterprise Manager (OEM) 集成:提供了一个图形界面来监视部署的 Oracle NoSQL Database 存储。
  • 使用 NoSQL 数据库包集成 Oracle Event Processing (OEP) 引擎:通过 CQL 查询访问数据
  • 与 Oracle Coherence 集成允许将 Oracle NoSQL Database 用作 Oracle Coherence 应用的缓存,并允许应用从 Oracle NoSQL Database 直接访问缓存的数据。
  • 与 Oracle Big data Spatial and Graph 集成:Oracle NoSQL Database 可用作属性图和空间矢量数据的信息库。
  • 企业版 (EE) 的企业级支持 (24x7)。使用社区论坛可获得社区版 (CE) 支持。
  • 支持 Kerberos 集成。

Oracle NoSQL Database 基础版 (BE) — Oracle NoSQL Database* 的全部功能现在包含在 Oracle Database 企业版中,无需额外付费即可获得软件和支持。

*与 Coherence、外部表、Oracle Streams 等集成需要 Oracle NoSQL Database 企业版获得上述许可。

Oracle NoSQL Database 企业版 (EE) — 这个版本是闭源的,可以从 Oracle 购买。基于永久许可(基于处理器)或指定用户的定价模式。此外,还可购买支持。

Oracle NoSQL Database 社区版 (CE) — 这个版本是开源的,只能通过社区论坛获得支持。CE 是免费的,可以从 Oracle OTN NoSQL Web 页面下载。

  
有关更多信息,请查看概述页面上提供的产品介绍
 

返回页首

 

都有哪些端口?何时使用各端口?


存储部署包含许多组件,每个组件运行在自己的进程中,进程间彼此通信。系统管理员必须在每个存储节点 (SN) 上为每种类型的进程定义以下 TCP/IP 端口。

  • 每个 SN 上的主端口是“注册端口”,该端口归存储节点代理 (SNA) 所有。该端口通过 java -jar kvstore.jar makebootconfig 命令的“-port”参数命名。该端口还用于配置过程中的 deploy-sn 计划。文件示例使用 5000 作为注册端口。此外,java -jar kvstore.jar kvlite 命令使用端口 5000 作为默认值。
  • 每个管理进程都必须指定一个端口(“Admin Console 端口”)用于监听 HTTP 连接(4.3 之前的版本)。该端口在 java -jar kvstore.jar makebootconfig 命令的“-admin”参数中及配置过程的 deploy-admin 计划中指定(4.3 之前的版本)。

    文档中的示例使用 5001。

  • 必须为每个 SN 指定一系列端口(“HA 范围”),供 SN 内托管的任何复制节点和管理服务用来复制持久性数据。SNA 管理这种端口分配,为管理服务保留一个端口,其余端口以一对一方式分配给每个 RN。范围调整的原则是使其大小等于该 SN 可能托管的最大 RN 数加 1。
  • 如果您愿意

以下情况应使用注册端口:

  • 任何使用管理命令行界面(java -jar kvstore.jar runadmin 命令)的情况,包括存储的初始配置。注意,虽然您最终与管理进程通信,但此情况下使用的是注册端口,而不是管理控制台端口(4.3 之前的版本)。
  • 作为应用代码中的 helperHostPort argument to the KVStoreConfig 构造器的一部分读/写存储。
  • 在命令行中作为使用“-port”传递的值,用来调用 LoadPingKVLite 等实用程序。
  • 如果启用 JMX 监视,则作为 JMX 服务的端口号。

HelloBigDataWorldSchemaExample 等示例程序中情况与此类似。

您应在管理 Web UI 的目标 URL 中使用管理控制台端口(4.3 之前的版本):

    http://node1.example.com:5001/


通常,在托管您尝试访问的组件类型的任何 SN 上,您可以指定一个端口,如果有必要,系统将自动透明地重定向您的请求。如果是管理控制台 Web UI(4.3 之前的版本)或 java -jar kvstore.jar runadmin 命令,只要指定托管管理进程的 SN,这种办法就能起效。

除了在配置 SN 期间,通常无需直接引用 HA 范围中的端口,虽然这样肯定有助于在检查 Ping 结果和浏览系统日志文件时了解 HA 范围。

返回页首

 

如何限制 NoSQL DB 使用的端口?


部署时有时需要将存储限制到一组有限的端口,通常出于安全或数据中心策略的原因。可在存储节点上指定 2 个端口范围,以限制仅使用这些端口:

  • haPortRange 参数,在 makebootconfig 中使用 -harange <start,end> 指定。它用于复制因子 >1 时的复制,且必须包含足够的端口以满足存储节点加 1 的容量。
  • servicePortRange 参数,在 makebootconfig 中使用 -servicerange <start,end> 指定。该范围用于内部(管理)服务器到服务器的低带宽通信,并且基于存储节点托管的每个进程中的服务数目,包括存储节点代理进程本身。该参数是可选的,如果不指定,将使用匿名端口。

以上范围是闭区间。

上面介绍了 haPortRange 的大小。servicePortRange 的大小调整如下所示:

  • 3 个端口用于存储节点进程
  • 3 * 复制节点容量(每个复制节点使用 3 个端口)
  • 2(如果存储节点托管管理进程)

根据以上信息可知,对于容量为 2 且托管管理进程的存储节点,需要的范围大小为:3 + (2 * 3) + 2 = 11。存储节点将基于此公式实施最低大小限制。建议稍微取大一点的范围。

返回页首 

如何指定 NoSQL DB 使用的网络接口?


makebootconfig 的 -hostname 参数会影响每个存储节点使用的网络接口。有时,makebootconfig 可以使用可选的 -hahost 标志设置 haHostname 存储参数。这用于为承载大部分流量的服务器到服务器通信通道指定额外的网络接口。-hahost 的默认值与 -hostname 值相同。

NoSQL DB 如何确定内存预算?


复制节点管理 NoSQL DB 存储中的数据,它是内存的主要使用者。复制节点使用的 Java 堆和缓存大小可能是重要的性能因素。默认情况下,NoSQL DB 根据存储节点的可用内存量计算复制节点堆和缓存的大小。

我们建议您使用 makebootconfig 的 -memory_mb 标志或 memory_mb 存储节点参数指定存储节点的可用内存。如果未定义 memory_mb,它将默认为节点上的可用内存大小。然后 NoSQL DB 将使用 85% 的 memory_mb 作为该存储节点托管的复制节点进程所用的堆。如果存储节点托管多个复制节点,则会将内存平均分配到所有 RN。如果存储节点上的复制节点数发生变化,会动态重新计算每个 RN 的内存大小。堆所占百分比由 rnHeapPercent 存储节点参数控制。您可以选择覆盖默认值 85%。

每个复制节点使用一个缓存,该缓存的大小默认为复制节点堆的 70%。您可以通过设置 rnCachePercent 复制节点参数来覆盖 70% 的默认值。

也可以通过设置复制节点 javaMiscParams 参数中的 -Xmx 来直接指定复制节点堆。同样地,可以使用 cacheSize 复制节点参数直接设置复制节点缓存。虽然可以这样,但仍建议使用 memory_mb 存储节点设置。

例如,假设您通过将 memory_mb 设置为 3000 来指定存储节点可以使用 3000 MB 的内存。如果该存储节点托管两个复制节点,每个 RN 的堆将为 (3000 * .85)/2 = 1275MB。每个 RN 缓存将为 (1275 * .70) = 892MB。 

返回页首

 

应部署多少管理服务?


为提高可靠性,会复制 NoSQL DB 管理进程。让管理功能持续可用(即使在出现节点故障时)非常重要,这样您才能继续监视、诊断和修复问题。

每个管理服务都通过 deploy-admin 计划创建并添加到 NoSQL DB。由于管理服务将元数据持久保存在复制存储中,管理指南的“确定复制因子”一节中提供的信息也适用于应部署的管理服务数目。为提高耐久性和可用性,强烈建议至少部署三个管理服务。如果您的部署中只有一个或两个管理服务,且一个服务停用,您将无法执行许多类型的管理命令。

如果有至少三个管理服务在运行,您可以轻松地将其中一个管理服务从一个存储节点移到另一个存储节点:首先在目标存储节点上部署第四个管理服务,然后使用 remove-admin 计划删除原来三个管理服务中的一个。 

返回页首

 

是否应在同一节点上创建多个存储节点?


强烈建议为集群中的每个节点分配一个存储节点 (SN),以利提高可用性和性能。如果您认为给定节点有 I/O 和 CPU 资源可托管多个复制节点,可将存储节点的容量参数设置大于 1 的值,系统将知道此 SN 上可托管多个 RN。这样,系统就可以:

  • 确保分片中的每个复制节点都托管在不同的存储节点上,以降低分片的故障发生率
  • 在复制节点间动态分配内存和其他硬件资源
  • 确保在启动时及任何故障切换之后,主复制节点(即存储中提供写操作服务的复制节点)在各存储节点间均匀分布。

如果在同一节点上托管多个 SN,当该节点发生故障时,将丢失多个 SN,并且可能导致无法访问数据。

您可以用多种方法设置存储节点的容量参数:

  • 使用 makebootconfig 命令
  • 使用 change-policy 命令
  • 使用计划 change-params 命令。

在非常有限的情况下(如对于早期原型和实验),在同一节点上创建多个 SN 可能很有用。

在一台计算机上,存储节点由其根目录 (KVROOT) 加上配置文件名(默认为“config.xml”)唯一标识。这意味着您可以通过以下方式创建多个 SN:

为每个 SN 创建唯一的 KVROOT。通常,这些是在不同节点上,但也可以将它们放在一个节点上。例如,如果您决定将所有 SN 置于 /var/kv/stores 目录下,您可以通过以下方式创建和启动多个 SN:

mkdir /var/kv/stores/root1
mkdir /var/kv/stores/root2
mkdir /var/kv/stores/root3
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root1 -host fooHost 
  -port 5000 -admin 5001 -harange 5005,5010 -capacity 1
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root2 -host fooHost 
  -port 5020 -harange 5025,5030 -capacity 1
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root3 -host fooHost 
  -port 5040 -harange 5045,5050 -capacity 1
java -jar kvstore.jar start -root /var/kv/stores/root1
java -jar kvstore.jar start -root /var/kv/stores/root2
java -jar kvstore.jar start -root /var/kv/stores/root3
 
返回页首  


如何编写 Oracle NoSQL Database 配置脚本?


您可能发现需要重复构建相同的 NoSQL DB 配置以进行测试。可以用多种方式编写管理员 CLI 命令脚本。

管理员 CLI 的许多用法都是简单命令(如 java -jar kvstore.jar makebootconfig 可初始配置 StorageNode),如上所示。这些与任何其他 UNIX 命令一样都易于编写脚本,在此不再赘述。

可以用两种方式编写 java -jar kvstore.jar runadmin 中可用的交互式命令(包括用于创建和执行计划的命令)的脚本。您可以创建一个包含要运行的命令序列的文件,并使用 java -jar kvstore.jar runadmin load -file <script> 批量运行这些命令。

例如,名为 deploy.kvs 的脚本文件可能包含如下命令:

  configure -name mystore
  plan deploy-zone -name boston -rf 3
  plan deploy-sn -dcname boston -host localhost -port 5000 -wait
  plan deploy-admin -sn sn1 -port 5001 -wait (port argument is applicable prior to 4.3. only)

可通过发出以下命令执行此脚本

  java -jar kvstore.jar runadmin -host localhost -port 5000 load -file 
    deploy.kvs

另一种编写命令脚本的办法是以单独的 shell 命令行形式运行各 CLI 命令。此命令行末尾处的参数可视为一条 CLI 命令。

这种使用模式让您可以利用功能更强的脚本编程语言(如 UNIX shell)特性,并可以更灵活地将 NoSQL DB 命令与其他命令集成,而这些是交互式 java -jar kvstore.jar runadmin 环境中所不具备的。

可以按以下方式用 shell 脚本表达与以上示例中相同的命令序列:

  #!/bin/sh
 
  HOST=localhost
  PORT=5000
  HTTPPORT=5001
  KVADMIN="java -jar lib/kvstore.jar runadmin -host $HOST -port $PORT"
 
  # Each CLI command that follows "$KVADMIN" is executed in a new invocation of 
    runAdmin
  $KVADMIN configure -name mystore
  $KVADMIN plan deploy-datacenter -name boston -rf 3 -wait
  $KVADMIN plan deploy-sn -dcname boston -host localhost -port $PORT -wait
  $KVADMIN plan deploy-admin -sn sn1 -port $HTTPPORT -wait

返回页首 

NoSQL Database 能否与 Oracle Database 交互?


NoSQL Database 支持通过 Oracle Database 外部表函数检索记录。这样就有可能从 Oracle Database 执行某些查询并从 NoSQL Database 检索记录。有关更多信息,请参见:“使用外部表访问 Oracle NoSQL Database 简明手册:(http://docs.oracle.com/cd/NOSQL/html/examples/externaltables/cookbook.html)、关于 oracle.kv.exttab 软件包示例程序的 Javadoc。

Oracle Big Data Spatial and Graph 如何与 Oracle NoSQL Database 集成?


Oracle Big Data Spatial and Graph 包括两个主要组件:一个分布式属性图形,具有 40 个高性能并行内存中分析函数 (PGX);以及各种空间分析函数和服务,用于根据事物彼此之间的远近程度、事物是否在边界或区域内部来评估数据,或者用于处理和可视化地理空间地图数据和图像。Oracle NoSQL Database 可用作属性图和空间矢量数据的信息库。Big Data Spatial and Graph 受益于 Oracle NoSQL Database 的分布式架构、性能和安全功能,包括辅助索引、并行扫描、自定义扫描,父/子表和安全的部署配置。


API

 

如何使用多个主键高效地删除子键树

 

KVStore.multiDelete() 方法可以删除整个子树,但一次只能删除一个(完全限定的)主键。

要删除较大的子树(其根位于层次结构主键部分的较高位置),可以使用 storeKeysIterator 找到要删除的每个完整主键,然后对每个主键调用 multiDelete()

如果允许完成 storeKeysIterator,它将对期望子树范围内的所有键(包括每个主键中的次键)进行迭代。因此,关键是只取迭代器的第一个结果键,提取主键部分以调用 multiDelete(),然后放弃迭代器,重新开始新的迭代器,而不是一直在一个迭代器内循环。

下面的示例代码中对此进行了说明。

Key partialKey = ...;     // major key prefix

/*
* Since we never take more than one key per iterator, a larger
* batch size would be a waste.
*/
final int batchSize = 1;
for (;;) {
    Iterator<Key> i = kv.storeKeysIterator
        (Direction.UNORDERED, batchSize, partialKey,
         null, Depth.DESCENDANTS_ONLY);
    if (!i.hasNext()) {
        break;
    }
    Key descendant = Key.createKey(i.next().getMajorPath());
    kv.multiDelete(descendant, null,
                   Depth.PARENT_AND_DESCENDANTS);
}
 
返回页首 

生成序列值的优秀实践


NoSQL DB 应用可以通过将存储中的一条记录指定为序列,以相当简单的方式实现序列。只需选择一个标识序列的键。该键可以是应用选择的任何项,例如“app-sequence-1”。此记录的值将是长整型,是序列中的下一个可用值。

使用读取-修改-写入操作读取下一个可用序列并递增。使用 KVStore.get() 读取值并使用 putIfVersion() 写入值。与任何读取-修改-写入操作类似,如果 putIfVersion() 失败,则意味着有另一个客户端在更新,应重试读取-修改-写入循环。

序列不是递增 1,而是要递增一个大得多的值,比如说 500。这实际上是为客户端分配一块或一个范围的序列值。然后客户端应“缓存”此序列号范围并从范围内分配记录键。分配完所有缓存值时,应执行另一个读取-修改-写入操作。

虽然单个序列记录将是客户端之间的单点争用,但这种潜在的性能问题可以通过如上所述的分配更大块的序列来解决。您还可以为不同目的分配多个独立序列,例如用于不同类型的记录或用于键范围。
 

返回页首

 

如何使用 Avro 联合对可选字段进行编码


要在 Avro 中声明可选字段,请使用 Avro 联合。例如:

{
     "name":"data",
     "type":["null","string"],
     "default":"null"
}

对于上面的示例,“data”字段的类型可以是“string”或“null”。类型可以为“null”使该字段可选。

以此方式使用联合时,要注意在 JSON 中联合是以下面的两种方式之一编码的:

  • 如果类型是“null”,则字段编码成 JSON null。

  • 否则,将编码成带一个名称/值对的 JSON 对象,其中名称为类型的名称,值是递归编码的值。对于 Avro 的命名类型(record、fixed 或 enum),则使用用户指定的名称。对于任何其他类型,则使用类型名称。

例如,要使用联合模式:

["null", "string", "Foo"]

其中,“Foo”是记录名,您将进行以下编码:

  • “null”编码为“null”

  • 字符串“a”编码为 {"string" : "a"}

  • Foo 实例编码为 {"Foo" : {...}},其中,{...} 表示 Foo 记录实例的 JSON 编码。

也就是说,要将上述“data”类型编码成字符串,您应使用以下语句:

{"data":{"string":"My Data String"}}

要将同一字段编码成 Foo 记录实例,您应使用:

{"data":{"Foo":{...}}   

(您将使用实际的 Foo 记录编码填写“{...}”)

要将同一字段编码成 null 字段,只需使用:

{"data":null}
 
返回页首 

运行时异常与受检异常


客户端 API 中定义的大多数异常都是运行时异常。我们不使用受检异常是否有任何设计上的策略或原因?

受检异常仅适合异常必须总是由直接调用方处理的场合,因为在某种意义上来说,异常就是一种不同类型的返回值。这些称为“意外事件”。例如,oracle.kv.OperationExecutionException 包含有关一个多操作请求中的操作返回值的信息。意外事件异常是受检异常,以便要求调用方显式处理此类异常,就像调用方处理返回值那样。

其他异常(称为“故障”)通常是调用方无法直接处理的问题的结果,通常由异常事件引起。它们可能导致操作重试,但通常由更高级别(而非直接调用方)处理。因为它们不是由直接调用方处理的,所以是运行时异常。这可以避免在客户端应用的所有方法中堆满了这些方法并不关心的异常的 throws 声明。

目前,NoSQL DB 中唯一的意外事件(受检)异常是 OperationExecutionException,其他异常均为故障(运行时)异常。每个异常都扩展 oracle.kv.FaultException 或 oracle.kv.ContingencyException 以表明此特性。

这里介绍了意外事件异常和故障异常的一般信息

注意,近几年大多数程序员偏好运行时异常,且大多数近来设计的编程语言不具备针对受检异常能力。因此,当前的趋势是运行时异常。当然,并非所有程序员或编程语言设计人员对此持相同看法。NoSQL DB 保留了在适当时添加额外的意外事件异常的选项。

 

返回页首

 

如何实现数值键并正确排序?


Oracle NoSQL 数据库将所有键都视为 String,因此将它们作为字符串进行排序。这可能给具有数值键并希望对其正确排序的应用带来问题。数字(integer、long、double 等)的简单字符串表示不能正确排序。例如,考虑以下整型值:

{1, 2, 10, 12, 1000}

这是这些值的正确升序排序,但其简单字符串表示则按以下方式排序:

{"1", "10", "1000", "12", "2"}

一种简单的修复办法是在字符串值的左侧进行填充,使其长度相同。例如:

{"0001", "0002", "0010", "0012", "1000"}

这种办法可行,但它有几个特性会导致某些应用出问题:

  1. 它不是特别紧凑,这是键的一个重要属性

  1. 它不处理负数

  1. 它不处理浮点数

如果不需要负数和浮点数,另一种可行的办法是用 base32hex 编码,这种办法可以正确排序,比手动填充更紧凑。没有标准的实现方式,因此必须找到一种实现方式。值得一提的是,Base64 虽然紧凑,但不能正确排序,如果需要正确排序,则不应用作编码。

至少还有几种更通用的机制实现,它们比较紧凑,且适用于负数和浮点数。其中一种机制内置在 Lucene 中:

http://lucene.apache.org/core/3_0_3/api/core/index.html?org/apache/lucene/util/NumericUtils.html

下面讨论了另外一种:

http://jasonfager.com/770-lexi-sortable-number-strings/

其实现形式如下:

https://gist.github.com/jfager/490993#file_lexi_sortable.java

该讨论提到可以使用一种更紧凑的表示形式,但必须由应用编码。

 

返回页首

 

故障排除


如何修复使用 Java SE Development Kit 8, Update 121 (JDK 8u121) 时的 java.io.ObjectInputStream filterCheck 错误?


Oracle 提供了一个关于这个主题的支持说明。请通过以下网址查看:http://support.oracle.com/rs?type=doc&id=2227233.1

如何修复使用 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

服务正常运行

STOPPING

服务停止。这可能需要一些时间。例如,复制节点可能在执行检查点操作,或者存储节点可能在关闭托管服务

WAITING_FOR_DEPLOY

服务在其启动过程中正等待命令或其他服务的确认。如果是存储节点,则是等待初始的 deploy-SN 命令。其他服务应无需用户的任何管理干预即退出此阶段

STOPPED

有意、干净的关闭

ERROR_RESTARTING

服务处于错误状态,将尝试重新启动

ERROR_NO_RESTART

服务处于错误状态,不会自动重新启动。需要用户的管理干预

UNREACHABLE

Admin 无法访问该服务。如果是通过 Admin 发出的命令看到的状态,此状态可能屏蔽 STOPPED 或 ERROR 状态

.

正常运行的服务从 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 的任何节点上完成。

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

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

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

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

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

  6. 通过 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(但请注意,这将禁用防火墙规则,导致潜在的安全问题)。

在此感谢 Johan Louwers 的撰稿。

 

返回页首

 

java.rmi.ConnectException:Connection refused to host 是什么意思?


show plan -id <id> 命令显示计划状态和可能发生的任何错误。如果您在错误部分中看到此异常,则意味着管理服务在尝试执行命令时无法访问其中一个 NoSQL DB 组件。

第一步是检查 show plan -id <id> 命令显示的错误信息,看看无法启动的组件显示的错误。此问题的常见原因是无法启动的复制节点。一些常见的问题包括复制节点进程内存不足、自定义 JVM 配置类型错误,或端口已被使用。

如果这第一步没有显示问题,下一步是检查存储的整体状态。一种办法是使用 show topology 命令,接着是 verify 命令。show topology 命令将显示存储布局,而 verify 将检查每个组件的状态。无法访问的组件将显示状态 UNREACHABLE。

下一步是查看 NoSQL 日志文件中有关无法访问组件的更多详细错误信息。首先查看聚合的存储级日志,该日志可在托管管理服务的节点上找到,位于 KVROOT/<storename>/logs/<storename>*.log 下。这将显示存储中所有不同组件的信息。

假设在存储节点 sn3 上的复制节点 rg1-rn3 不响应。浏览 <storename>.log 中由这些组件产生的条目。每个日志条目的开头是发出日志消息的组件的名称。有时,聚合的存储级日志有太多的信息,或者有时一个组件的信息未传递到 Admin,因此不包括在聚合日志中。在这种情况下,更有用的是直接查看复制节点或存储节点日志,可以在其主机上的 <KVROOT>/<storename>/logs 目录中找到。

如果在初始部署期间发生问题,那么特别有用的是查看存储节点日志,以确保根据安装说明该节点上的存储节点代理已正确创建,且该进程按照安装说明如期启动。

 

返回页首

 

我在日志中看到 JVM 警告:Failed to reserve shared memory


默认情况下,NoSQL DB 使用 JVM 选项“-XX:+UseLargePages”启动复制节点进程,以便为此进程启用大页面操作系统选项。有些 JVM 不支持大页面,并将发出此警告。该警告是建议性的,存储可以运行。

为什么在 jconsole 中看不到 NoSQL Database 的 MBean?


首先,确保已按照“管理指南”第 8 章中所述启用 JMX 代理。

存储节点的 JMX 代理在存储节点代理的主注册端口号上提供 MBean,这也用于存储节点托管的所有其他 RMI 服务。要在 jconsole 中查看 MBean,必须将 jconsole 连接到 SNA 注册表监听的主机和端口。例如,您可以按如下方式启动 jconsole:

jconsole node1.example.com:5000

您也可以不带参数启动 jconsole,然后在“New Connection”对话框中选择“Remote Process”,在地址栏中输入“node1.example.com:5000”。

 

返回页首

 

javax.net.ssl.SSLHandshakeException 是什么意思?


这些异常表明启用安全的部署出现配置问题。当您对 plan deploy-sn 命令使用 show plan 命令时,将看到这些错误。如下异常:

javax.net.ssl.SSLHandshakeException:Remote host closed connection during
handshake 

表明目标存储节点未配置成启用安全,并且未运行 SSL。如下异常:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
Certificate signature validation failed

表明 SSL 证书不兼容。

要启用安全,您必须在初始配置存储节点时对 makebootconfig 实用程序使用 -store-security enable 或 -store-security configure 标志,或通过使用“security-config add-security”命令为不安全的安装添加安全性。详细信息请参见“安全指南”。

 

返回页首