排解 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-mart 或 apigee-runtime pod，該 pod 與 apigee-cassandra-restore 工作位於相同網路。您也可以使用 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 MB/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. 在另一個殼層工作階段中，取得 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 逐一重複上述步驟，直到所有 Pod 都處於 Ready 狀態的 2/2 且具有 Running 狀態為止。 CrashLoopBackoff

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 客服團隊聯絡：

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. 如果您已按照上述步驟診斷問題，請收集所有主控台輸出內容，複製到檔案中，然後將檔案附加到支援案件。