排查 Cassandra 恢复问题

您正在查看 Apigee 和 Apigee 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.yaml 中 cassandra 下的 hostNetwork 设置为 false，如从备份恢复区域中所示。
  2. 如需测试连接，请登录到与 apigee-cassandra-restore 作业位于同一网络中的 apigee-mart 或 apigee-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. 如果您已按照上述诊断步骤执行操作，请收集所有控制台输出，将其复制到文件中，然后将文件附加到支持请求中。