原始网页:https://www.cockroachlabs.com/docs/stable/operational-faqs.html


操作相关的常见问题

当用户尝试以后台启动的方式启动Cockroach进程,进程为什么会挂住?

首先需要确定您在此之前是否使用同样的数据文件夹去启动另一个多节点集群。如果没有,则查看集群配置相关的问题追踪与定位文档。如果用户先前启动并已经停止一个多节点集群,当前正在进行该集群的重启过程,则该挂起现象属于正常现象。

为了保证数据的一致性,只有在集群的绝大多数节点处于运行状态时CockroachDB才能开始工作。这意味着如果3节点集群只有1个节点正在运行,该节点则无法做任何事情。cockroach start--backgroundFlag会使得启动命令一直处于等待状态,直到节点完全初始化并且能够开始处理查询的为止。

总结来说,在绝大多数节点正常运行之前,--backgroundFlag将导致cockroach start命令挂起。为了重启集群,用户需要开启多个终端开启每个节点,或者,在一个终端中以当前shell的后台启动方式启动所有节点。

在节点没有多少流量的时候,为什么内存使用量还会增加?

像大多数数据库一样,CockroachDB会缓存最近最常访问的数据到内存当中,以提供更好的读性能。另一方面CockroachDB周期性写时间序列数据会导致数据量不断增长,直到达到某个阈值。更多关于内存缓存大小的控制,可以查看生产清单

在没有多少写操作的时候,为什么硬盘的使用量还会增加?

集群中存储的时间序列数据将支撑Admin界面的部分监控功能,在被删除之前的将在集群中保存30天。结果将是在集群整个生命周期的前30天,用户将会看到硬盘使用量在稳定增长。即使不写入业务数据,Range数量也不断变多。

是否能够减少或关闭时间序列数据的存储?

是的。默认情况下cockroachDB存储最近30天的时间序列数据,将在Admin界面监控界面显示。用户可以减少时间序列数据的存储周期,或是关闭整个时间序列数据的存储。

NOTE: 在减少或关闭时间序列数据存储之后,CockroachDB将花费24小时来删除时间序列数据,变更结果将反映到Admin界面上。

减少时间序列数据的存储周期

为了减少时间序列数据的存储周期,用户需要将集群配置项timeseries.resolution_10s.storage_duration修改成小于720h0m0s(30 days)的值。例如,如果想要存储最近15天内的时间序列数据,则执行以下命令:

SET CLUSTER SETTING timeseries.resolution_10s.storage_duration = '360h0m0s';
SHOW CLUSTER SETTING timeseries.resolution_10s.storage_duration;

+--------------------------------------------+
| timeseries.resolution_10s.storage_duration |
+--------------------------------------------+
| 360h                                       |
+--------------------------------------------+
(1 row)

关闭整个时间序列数据存储

NOTE: 只有用户使用了例如Prometheus这样的第三方监控工具进行时间序列监控,才推荐关闭时间序列数据存储。像Prometheus这样的工具能够不依赖于CockroachDB去存储时间序列数据,只是从CockroachDB中获取内存中的各项指标数据并保存到自己的存储设备上。

执行以下命令关闭整个时间序列数据存储:

SET CLUSTER SETTING timeseries.storage.enabled = false;
SHOW CLUSTER SETTING timeseries.storage.enabled;

+----------------------------+
| timeseries.storage.enabled |
+----------------------------+
| false                      |
+----------------------------+
(1 row)

如果用户需要删除所有的时间序列数据,需要修改相关集群配置项:

SET CLUSTER SETTING timeseries.resolution_10s.storage_duration = '0s';

为什么增加节点的数量无法提高整体IOPS?

如果查询操作的是不同的数据,则增加节点的数量能够提高整体的吞吐量(TPS或QPS)。然而,如果查询发现在同样的数据上,则可能会出现事务冲突。更多细节可以查看理解和避免事务冲突

CockroachDB在默认情况下为什么要收集集群使用相关的匿名信息?

收集CockroachDB在真实世界中的使用信息能够帮助我们调整产品功能开发的优先级。我们默认选择为“选择加入”,以增加我们从收集工作中获取到的信息。我们也会慎重地只发送加密后的聚合统计数据。更多信息可以查看诊断报告,了解哪些数据会被发送。

节点时钟未正确地同步会导致什么结果?

CockroachDB需要中等程度的时钟同步来保持数据的一致性。基于这个原因,当节点检测到它的时钟与集群至少一半节点的时钟不同步且偏移量超过最大允许阈值的80%(默认500ms)的时候,该节点会自发地关闭。这能够避免了违反可序列化一致性级别,否则将导致的陈旧数据的读取(stale read)和写倾斜(write skew)。通过在每个节点上运行NTP或是其他时间同步软件来避免时钟在最开始的位置就出现过多的偏移,是十分重要的。

一个不常见的用例是,一个节点的时钟在节点检测到变化之前突然跳跃,偏移量超过了最大允许的阈值。这种情况不常见,但是还是可能发生的。例如,当CockroachDB运行在VM中,VM管理程序决定将VM迁移到另一台具有不同时间的设备上。在这种情况下,从时钟变得不同步开始,到节点检测到并自发关闭,两个时间点之间会有一个小的时间窗口。在这个时间窗口内,客户端可能会读取陈旧数据,并写入基于陈旧数据生成的新数据。

更多关于时钟同步的向导,可以查看对应环境的部署教程:

部署环境 选择建议
内部部署 将NTP与Google的外部NTP服务配合使用
AWS 使用亚马逊时间同步服务
Azure 关闭Hyper-V时间同步,将NTP与Google的外部NTP服务配合使用
Digital Ocean 将NTP与Google的外部NTP服务配合使用
GCE 将NTP与Google的外部NTP服务配合使用

TIPS: 在多数情况下,我们推荐将NTP与Google的外部NTP服务配合使用,原因是Google提供了闰秒涂抹的技术。如果你采用了不提供闰秒涂抹的NTP服务,你必须手动配置客户端进行闰秒抹除,并保证在每台机器上均以相同的方式运行。

如何判断节点时钟同步情况的好坏?

根据监控相关的文档里的详细描述,用户可以通过每个CockroachDB节点的http://<host>:<http-port>/_status/vars获取一系列指标,内容的格式能够直接被主流的Prometheus时间序列数据库解析使用。其中有2个指标能够描述每个节点跟其他节点的时钟偏移程度。

指标 定义
clock_offset_meannanos 节点与其他节点的时钟偏差的平均值,单位为纳秒。
clock_offset_stddevnanos 节点与其他节点的时钟偏差的标准差,单位为纳秒。

如果一个节点与其他节点相比的时钟偏差的平均值超过最大允许偏差的80%,则这个节点会自发关闭。因此推荐监控clock_offset_meannanos指标,并将集群配置的最大允许偏移量的80%作为报警阈值。

用户可以在v2.0以上的版本,在Admin界面的时间偏差图中查看到的相关指标。

节点维护时需要准备什么?

默认情况下,如果一个节点下线超过5分钟,则集群将认为该节点已死亡,会将数据重分布到其他节点。如果需要临时停止节点并进行有计划性的维护(例如更新系统软件),且维护时间超过5分钟,则此时用户可以根据维护时长去增加集群配置项server.time_until_store_dead的值,来避免不必要的数据重平衡。

例如,如果用户想要维护一组服务器,集群节点运行在这些服务器上,每个服务器需要下线超过15分钟,则在关闭节点之前,用户需要修改集群配置项:

SET CLUSTER SETTING server.time_until_store_dead = '15m0s';

在完成维护,重启节点之后,再将集群配置项修改成原来的值:

SET CLUSTER SETTING server.time_until_store_dead = '5m0s';

需要确保负载均衡器不会将客户端流量路由到关闭的节点上,即使服务器只是下线几秒钟。如果发现负载均衡器的健康检查不能把即将关闭的节点识别成unready状态,则需要增加集群配置项server.shutdown.drain_wait的值,该配置能够告诉节点在特定时间内以unready的状态进行等待。

SET CLUSTER SETTING server.shutdown.drain_wait = '10s';