关于后端:混沌工程是谁背着我偷偷写-Bug-🤸

GreptimeDB 反对以单机和分布式的模式进行部署，但紧随而来一个尖利的问题：咱们对投入生产的这套简单零碎有多少信念？

在 0.3 到 0.4 的迭代过程中，咱们引入了混沌工程（Chaos engineering）来进步零碎的健壮性。

咱们抉择了 Chaos Mesh 作为故障注入工具。咱们在 Pod 中运行一个测试程序（Testcase），该程序通过定义 CR（Custom Resource）为 DB 集群中特定的 Pod 注入故障；并在转移故障后，对 DB 集群的可用性和数据完整性进行验证。
上面是一个示例，向 greptimedb-cluster 命名空间中名为 greptimedb-datanode-1 的 Pod 注入一个 Pod Kill 的故障。

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  namespace: greptimedb-cluster
spec:
  action: pod-kill
  mode: one
  selector:
    filedSelectors:
      'metadata.name': 'greptimedb-datanode-1'

为了便于调试测试程序，测试程序在开发环境中，能够间接运行在主机上，并通过 Kubectl 的端口转发拜访 K8s 中的 DB 服务。

测试笼罩不高时，可能会有一些“负负得正”的状况，让整套零碎看起来“失常”运行（实际上即便覆盖率较高，也仍然可能存在这些问题）。 所以咱们能够从最小场景开始测试，这个阶段你须要十分清晰地晓得零碎的预期行为 ，并通过查看系统日志，判断零碎的行为是否真的合乎预期，以便发现问题后及时补相应的集成测试。

例如，咱们须要验证零碎是否能容忍 Datanode 节点被 Kill，并触发 Region Failover 流程（行将 Region 迁徙到其余可用节点）。咱们能够通过构建一个最小场景（大量表，大量数据）来进行验证，通常当故障被注入到故障真正产生会有肯定的工夫距离，此时咱们须要一些办法去判断零碎是否实在产生故障了。

通常有几种做法：通过调用 Kube API 察看 ReplicatSet 的 Pod 正本数量少于预期；亦或是通过对指标节点进行读写来感知——在观测到故障前不间断的发动一些（大量的）将会路由到指标节点的读写操作，当客户端会返回故障时，即可视为指标节点不可用。随后期待集群复原（例如调用 Kube API 期待 ReplicatSet 的 Pod 正本数量回到预期），咱们就能够开始验证服务可用性和数据的完整性。

GreptimeDB 能够将数据保留在 AWS S3 或者阿里云 OSS 等等这样的便宜对象存储上。S3 这类存储相比本地存储来说，在测试中还是有不少差别的，次要体现在对 S3 拜访的提早上。 应尽早地贴近实在场景，即测试应用 S3 存储的 DB 集群。 咱们在开发测试程序的时候，也要将被测试 DB 集群的数据存储在凑近开发环境的 S3 中。

在开始混沌测试前，尽可能地把思路梳理清晰，在集成测试中把将要测试到链路进行笼罩。混沌测试还是有不少额定工作量的，后期把测试做到位能节俭不少工夫。当然混沌测试和集成测试也能够说是相辅相成的，有些问题只有你真的在混沌测试中遇到了，才会突破你之前的一些判断：“哇 *，原来这个不是我想的小概率事件🤣”。

任何偶尔产生的问题都要深究，对于小概率产生的问题其实须要大量的重试，并通过日志精准地定位问题。

构建一个混沌测试须要投入不少精力：通常注入一个故障，其中会波及到多个步骤，例如注入故障，察看到故障产生，期待服务完全恢复等。 通过对这些步骤进行形象，咱们能够做到实现注入一个故障，测试多个不同的场景。

咱们在混沌工程中发现的 Bugs 次要集中在以下几类：

Trait 的不同实现，行为不统一；
字段或接口冗余；
多个 Bug 叠加，负负得正；
未应用别名造成的歧义；
Corner Case 中数据与缓存不统一；
迭代过程中多人合作造成的一些脱漏。

咱们还很意外地发现了一个上游的 Bug，OpenDAL FsBackend 的异步写入在 sync_all 之前未调用 flush，导致其有潜在失落数据的危险。咱们在 0.4 版本中及时反馈并修复了这个 Bug，能够通过上面链接具体理解：

https://github.com/GreptimeTeam/greptimedb/issues/2382
https://github.com/apache/incubator-opendal/issues/3052
https://github.com/tokio-rs/tokio/issues/6005

Greptime 格睿科技致力于为智能汽车、物联网及可观测等产生大量时序数据的畛域提供实时、高效的数据存储和剖析服务，帮忙客户开掘数据的深层价值。目前次要有以下三款产品：

GreptimeDB 是一款用 Rust 语言编写的时序数据库，具备分布式、开源、云原生和兼容性强等特点，帮忙企业实时读写、解决和剖析时序数据的同时升高长期存储老本。
GreptimeCloud 能够为用户提供全托管的 DBaaS 服务，可能与可观测性、物联网等畛域高度联合。
GreptimeAI 是为 LLM 利用量身定制的可观测性解决方案。
车云一体解决方案是一款深刻车企理论业务场景的时序数据库解决方案，解决了企业车辆数据呈几何倍数增长后的理论业务痛点。

GreptimeCloud 和 GreptimeAI 已正式公测，欢送关注公众号或官网理解最新动静！对企业版 GreptimDB 感兴趣也欢送分割小助手（微信搜寻 greptime 增加小助手）。

官网：https://greptime.cn/

GitHub: https://github.com/GreptimeTeam/greptimedb

文档：https://docs.greptime.cn/

Twitter: https://twitter.com/Greptime

Slack: https://www.greptime.com/slack

LinkedIn: https://www.linkedin.com/company/greptime

关于后端:混沌工程是谁背着我偷偷写-Bug-🤸

前言

混沌工程是怎么施行的

一些摸索和教训

1. 从最小场景开始

2. 尽可能贴近实在的场景

3. 梳理思路 + 补充集成测试

4. 关注偶发的问题

5. 构建可复用故障

在混沌工程中发现的 Bugs

对于 Greptime：