排查 Cassandra 恢复问题

您正在查看 ApigeeApigee Hybrid 文档。
此主题没有等效的 Apigee Edge 文档。

症状

在 Apigee Hybrid 中的 Cassandra 恢复期间,您可能会遇到恢复日志错误。

错误消息

您会在日志中看到以下其中一项:

java.net.ConnectException: Connection timed out (Connection timed out)
/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1
/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

可能的原因

原因 说明 适用的问题排查说明
连接超时 此错误是 apigee-cassandra-restore pod 和 apigee-cassandra-default-* pod 之间的连接错误。 Apigee Hybrid
操作超时 如果恢复时间超过 15 分钟,就会出现此错误。 Apigee Hybrid
已存在 此错误消息与问题的原因无关,是恢复作业的重试操作的结果。 Apigee Hybrid

原因:连接超时

以下错误是 apigee-cassandra-restore Pod 和 apigee-cassandra-default-* Pod 之间的连接错误:

java.net.ConnectException: Connection timed out (Connection timed out)

诊断

  1. 如果无法从 pod 网络访问您的主机网络,请确保将 overrides.yamlcassandra 下的 hostNetwork 设置为 false,如从备份恢复区域中所示。
  2. 如需测试连接,请登录到与 apigee-cassandra-restore 作业位于同一网络中的 apigee-martapigee-runtime pod。您还可以使用 pod 网络中的任何其他 pod。
    1. 获取 apigee-mart pod 的名称:
      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    2. 在 Mart pod 中执行 bash 会话:
      kubectl exec -it MART_POD_NAME -n apigee -- bash

      MART_POD_NAME 替换为 MART Pod 的名称。 例如 apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl

    3. 针对 Cassandra 端口运行连接测试:
      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:9042
      curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:7001

    如果您在输出中收到 Connection timed out 错误,则表示存在连接问题。但是,如果您看到 Connected to 消息,表示连接成功,您需要按 Ctrl + C 关闭连接并继续。

解决方法

确保用于恢复的 overrides.yaml 文件中的 HostNetwork 设置设为 false,然后重复恢复过程。如果此设置已设置为 false,但您会看到连接错误,请确保 Cassandra pod 已启动并运行以下命令:

kubectl get pods -n apigee -l app=apigee-cassandra

输出内容应如下所示:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          14m
apigee-cassandra-default-1   1/1     Running   0          13m
apigee-cassandra-default-2   1/1     Running   0          11m
exampleuser@example hybrid-files %

原因:操作超时

如果恢复时间超过 15 分钟,则会发生以下错误。此错误表示存储空间和网络无法按时传输备份的未压缩内容等 I/O 问题。

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client
request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

诊断

  1. 检查 apigee-cassandra-default-0 日志以记下恢复开始的时间戳:

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
  2. 将时间戳与表创建的最新日志进行比较:

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1

    此比较的结果应显示 Cassandra pod 在超出超时后仍在创建表。

  3. 使用以下命令测试存储带宽:

    kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
    kubectl -n apigee exec -it apigee-cassandra-default-1 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
    kubectl -n apigee exec -it apigee-cassandra-default-2 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

    如果写入速度低于 100 M/s,则可能表示缺少相应的 StorageClass (SSD)。

  4. 测试网络带宽:

    1. 在 Cassandra pod 上运行 netcat 以监听端口:

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
    2. 在一个单独的 shell 会话中,获取 apigee-mart pod 的名称:

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    3. apigee-mart pod 中执行 bash 会话。您还可以使用 Pod 网络中的任何其他 Pod:

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      MART_POD_NAME 替换为 MART Pod 的名称。 例如 apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl

    4. 对仍在运行 netcat 的 Cassandra pod 运行网络带宽测试:

      dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456

    您可以对其他 Cassandra pod 重复此过程。如果由此产生的速度低于 10M/s,则网络带宽最有可能是问题原因。

解决方法

在通过上述步骤确认 I/O 速度缓慢后,请确保您的集群符合最低网络存储空间要求。然后,再次测试带宽。

原因:已存在

诊断

您会看到类似于以下内容的错误:

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

解决方法

此错误消息与问题的原因无关,是恢复作业的重试操作的结果。实际的错误消息应显示在第一个失败的 pod 的日志中。

从初始失败中获取日志,以诊断问题。

如果问题仍然存在,请转到必须收集诊断信息

必须收集的诊断信息

如果按照上述说明操作后问题仍然存在,请收集以下诊断信息,然后与 Google Cloud Customer Care 联系:

  1. 除了系统可能会要求您提供的常规数据之外,请使用以下命令从所有 Cassandra pod 收集诊断数据:

    for p in $(kubectl -n apigee get pods -l app=apigee-cassandra --no-headers -o custom-columns=":metadata.name") ; do \
            for com in info describecluster failuredetector version status ring info gossipinfo compactionstats tpstats netstats cfstats proxyhistograms gcstats ; do kubectl \
            -n apigee exec ${p} -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD '"$com"' 2>&1 '\
            | tee /tmp/k_cassandra_nodetool_${com}_${p}_$(date +%Y.%m.%d_%H.%M.%S).txt | head -n 40 ; echo '...' ; done; done
          
  2. 请对其进行压缩,并在支持请求中提供:

    tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*
  3. 恢复 pod 收集并提供日志。请注意,日志是短期的,因此应在发生故障后立即收集。
  4. 如果您已按照上述诊断步骤执行操作,请收集所有控制台输出,将其复制到文件中,然后将文件附加到支持请求中。