排解 Cassandra 還原問題

您正在查看 Apigee 和 Apigee Hybrid 說明文件。
這個主題沒有對應的 Apigee Edge 說明文件。

注意：本文僅適用於 Apigee 混合式使用者。

問題

在 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 和 apigee-cassandra-default-* Pod 之間的連線錯誤。	Apigee Hybrid
作業逾時	如果還原作業在 15 分鐘後逾時，就會發生這個錯誤。	Apigee Hybrid
已存在	這個錯誤訊息與問題原因無關，是還原作業重試作業的結果。	Apigee Hybrid

原因：連線逾時

以下錯誤是 apigee-cassandra-restore 和 apigee-cassandra-default-* Pod 之間的連線錯誤：

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

診斷

1. 如果主機網路無法從 Pod 網路存取，請確認 hostNetwork 已設為 false，如 從備份還原區域所示，該值應位於 overrides.yaml 的 cassandra 下方。
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 容器的名稱。例如：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 容器已啟動並運作：

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 容器的名稱。例如：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 復原，可能需要重新啟動不只一次，並達到 2/2 的 Ready 狀態。接著，下一個最高的 pod 就會進入 CrashLoopBackoff 狀態。

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

6. 更新 POD_NAME，然後逐一對剩餘的 Pod 重複上述步驟，直到所有 Pod 都進入 CrashLoopBackoff 狀態，並且具有 Running 狀態為止。Ready2/2

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 吊掛叢集。

必須收集診斷資訊

如果問題在您按照上述操作說明後仍未解決，請收集下列診斷資訊，然後與 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. 收集並提供 restore Pod 中的記錄。請注意，記錄檔的生命週期很短，因此應在失敗後立即收集。
4. 如果您已按照上述診斷步驟收集所有主控台輸出內容，請將這些內容複製到檔案中，然後將檔案附加到支援案件。