排查 Cassandra 恢复问题

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

注意：本文档仅适用于 Apigee Hybrid 用户。

症状

在 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 的日志中。

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

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

已知问题 391861216 的解决方法

诊断

编号最高的 Cassandra Pod 在恢复后处于 CrashLoopBackoff 状态。这可能是由于已知问题 391861216 造成的。您会在 Cassandra Pod 日志中看到类似于以下内容的错误：

Cannot change the number of tokens from 512 to 256

解决方法

请执行以下步骤来解决潜在问题。这样一来，Cassandra 就可以正常启动，同时保留数据。

1. 开始删除卡在 CrashLoopBackoff 状态的 Cassandra Pod 的 PVC。将 POD_NAME 设置为处于 CrashLoopBackoff 状态的 Pod 的名称。将 APIGEE_NAMESPACE 设置为安装 Apigee 所在集群的命名空间。

   kubectl delete pvc cassandra-data-POD_NAME -n APIGEE_NAMESPACE --wait=false

2. 删除处于 CrashLoopBackoff 状态的 Pod。

   kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

3. 手动将 Cassandra 的种子主机更改为编号最高的 Pod。例如，如果您有三个副本，SEED_POD_NAME 应为 apigee-cassandra-default-2。这只需要执行一次，后续 Pod 可以跳过此步骤。

   kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":"SEED_POD_NAME.apigee-cassandra-default.APIGEE_NAMESPACE.svc.cluster.local"}}}}}'

4. 从 Cassandra 环中移除具有 512 个令牌的节点。

   kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status' | awk '/^DN .*\?.* 512 / {print $6; exit}; /^DN .* [KMG]iB.* 512 / {print $7; exit}' | xargs -I {} kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode {}'

5. 等待 Cassandra Pod 恢复，重启可能不止一次，并达到 Ready 状态 2/2。然后，下一个最高优先级的 Pod 将进入 CrashLoopBackoff 状态。

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

6. 更新 POD_NAME，并对剩余的 Pod 重复上述步骤（一次一个），因为它们会进入 CrashLoopBackoff 状态，除非所有 Pod 都处于 Ready 状态 2/2 且操作状态为 Running。

7. 验证所有 Pod 是否已成功加入 Cassandra 环。

   kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status'

   所有 Cassandra 节点都应具有 UN 状态和 256 个令牌。

8. 还原对 Cassandra 的种子主机所做的更改。

   kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":""}}}}}'

   Apigee Datastore 控制器会在还原种子主机更改时再次重启 Cassandra 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. 如果您已按照上述诊断步骤执行操作，请收集所有控制台输出，将其复制到文件中，然后将文件附加到支持请求中。