Cassandra のログを表示する

Cassandra は、Apigee Hybrid ランタイムに Apigee Core Persistence Services（CPS）を提供するために使用されるランタイムデータストアです。Cassandra はファイルシステム上で状態を管理する必要がある分散データシステムなので、Cassandra データベースは Kubernetes の StatefulSet ノードプールにデプロイされます。

データストアに格納された、Message Processor がポリシーを実行するために必要なエンティティは次のとおりです。

鍵管理システム（KMS）データ（会社、デベロッパー、デベロッパーアプリ、API プロダクト、API キーなど）
Key-Value マップ（KVM）データ
レスポンスキャッシュ データ
OAuth データ（アクセストークン、更新トークン、認証コードなど）
割り当てデータ（バケット、カウンタなど）

Cassandra ログファイル

ログは、インストール環境で発生した問題のトラブルシューティングに役立ちます。詳細については、ロギングをご覧ください。

エラーのトラブルシューティング

このセクションでは、Hybrid の Cassandra リングに関する問題のトラブルシューティングと解決方法について説明します。

ログファイル

ログは、インストール環境で発生した問題のトラブルシューティングに役立ちます。詳細については、ロギングをご覧ください。

ノードの障害を診断して修復する

Cassandra ポッドが起動に失敗した場合や Pending ステータスから変化しない場合は、ノードに問題があると考えることができます。このような問題は、基になるノードの障害を示している場合があります。ノードの障害を診断して修復する手順は次のとおりです。

ポッドのリストを取得して、実行中でないポッドがあるかどうかを確認します。

$ kubectl get pods -n your_namespace
        NAME          READY   STATUS    RESTARTS   AGE
        cassandra-0   0/1     Pending   0          13s
        cassandra-1   1/1     Running   0          8d
        cassandra-2   1/1     Running   0          8d

ワーカーノードを確認します。NotReady 状態のノードがあれば、それが障害ノードです。

kubectl get nodes -n your_namespace
    NAME                          STATUS   ROLES    AGE   VERSION
    ip-10-30-1-190.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-1-22.ec2.internal    Ready    master   8d    v1.13.2
    ip-10-30-1-36.ec2.internal    NotReady <none>   8d    v1.13.2
    ip-10-30-2-214.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-2-252.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-2-47.ec2.internal    Ready    <none>   8d    v1.13.2
    ip-10-30-3-11.ec2.internal    Ready    <none>   8d    v1.13.2
    ip-10-30-3-152.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-3-5.ec2.internal     Ready    <none>   8d    v1.13.2

ダウンしている Cassandra ポッドをクラスタから削除します。

$ kubectl exec -it apigee-cassandra-0 -- nodetool status
    $ kubectl exec -it apigee-cassandra-0 -- nodetool removenode deadnode_hostID

アフィニティによって Cassandra ポッドがデッドノードで起動しないようにするため、デッドノードから VolumeClaim を削除します。
```
kubectl get pvc -n your_namespace
    kubectl delete pvc volumeClaim_name -n your_namespace
```

ボリュームテンプレートを更新し、新しく追加されたノードの PersistentVolume を作成します。ボリュームテンプレートの例を次に示します。

apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: cassandra-data-3
    spec:
      capacity:
        storage: 100Gi
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      storageClassName: local-storage
      local:
        path: /apigee/data
      nodeAffinity:
        "required":
          "nodeSelectorTerms":
          - "matchExpressions":
            - "key": "kubernetes.io/hostname"
              "operator": "In"
              "values": ["ip-10-30-1-36.ec2.internal"]

値を新しいホスト名または IP に置き換え、テンプレートを適用します。
```
kubectl apply -f volume-template.yaml
```