Memecahkan masalah pemulihan Cassandra

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Tidak ada dokumentasi Apigee Edge yang setara untuk topik ini.

Gejala

Selama pemulihan Cassandra di Apigee hybrid, Anda mungkin mengalami error di log pemulihan.

Pesan error

Anda melihat salah satu hal berikut di log:

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

Kemungkinan penyebab

Penyebab Deskripsi Petunjuk pemecahan masalah yang berlaku untuk
Waktu tunggu koneksi habis Error ini adalah error konektivitas antara pod apigee-cassandra-restore dan pod apigee-cassandra-default-*. Apigee hybrid
Waktu operasi habis Error ini terjadi jika waktu tunggu pemulihan habis setelah lebih dari 15 menit. Apigee hybrid
Sudah ada Pesan error ini tidak terkait dengan penyebab masalah dan merupakan hasil dari operasi percobaan ulang tugas pemulihan. Apigee hybrid

Penyebab: Waktu tunggu koneksi habis

Error berikut adalah error konektivitas antara pod apigee-cassandra-restore dan pod apigee-cassandra-default-*: 

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

Diagnosis

  1. Jika jaringan host Anda tidak dapat dijangkau dari jaringan pod, pastikan hostNetwork disetel ke false di bagian cassandra di overrides.yaml seperti yang ditunjukkan dalam Memulihkan region dari pencadangan.
  2. Untuk menguji konektivitas, login ke pod apigee-mart atau apigee-runtime, yang berada di jaringan yang sama dengan tugas apigee-cassandra-restore. Anda juga dapat menggunakan pod lain di jaringan pod.
    1. Dapatkan nama pod apigee-mart: 
      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    2. Jalankan sesi bash di dalam pod mart: 
      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Ganti MART_POD_NAME dengan nama pod MART. Contoh, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    3. Jalankan uji konektivitas terhadap port 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

    Jika Anda mendapatkan error Connection timed out dalam output, berarti Anda memiliki masalah konektivitas. Namun, jika Anda melihat pesan Connected to, hal ini menunjukkan bahwa koneksi berhasil, dan Anda perlu menekan Ctrl + C untuk menutup koneksi dan melanjutkan.

Resolusi

Pastikan setelan HostNetwork ditetapkan ke false dalam file overrides.yaml yang digunakan untuk pemulihan, dan ulangi proses pemulihan. Jika setelan sudah ditetapkan ke false, tetapi Anda melihat error konektivitas, pastikan pod Cassandra sudah aktif dan berjalan dengan perintah berikut: 

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

Output Anda akan terlihat seperti contoh berikut:

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 %

Penyebab: Waktu operasi habis

Error berikut terjadi jika waktu tunggu pemulihan habis setelah lebih dari 15 menit. Error ini menunjukkan masalah I/O seperti penyimpanan dan jaringan yang tidak dapat mengirimkan konten cadangan yang tidak dikompresi tepat waktu. 

/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

Diagnosis

  1. Periksa log apigee-cassandra-default-0 untuk mencatat stempel waktu awal pemulihan: 

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1

  2. Bandingkan stempel waktu dengan log pembuatan tabel terbaru:

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1

    Hasil dari perbandingan ini akan menunjukkan bahwa pod Cassandra masih dalam proses pembuatan tabel setelah waktu tunggu terlampaui.

  3. Uji bandwidth penyimpanan dengan perintah berikut:

    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'

    Jika kecepatan tulis kurang dari 100 M/s, hal ini dapat menunjukkan kurangnya StorageClass (SSD) yang sesuai yang digunakan.

  4. Uji bandwidth jaringan:

    1. Jalankan netcat di pod Cassandra untuk memproses port: 

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'

    2. Dalam sesi shell terpisah, dapatkan nama pod apigee-mart: 

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"

    3. Jalankan sesi bash di dalam pod apigee-mart. Anda juga dapat menggunakan pod lain di jaringan pod: 

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Ganti MART_POD_NAME dengan nama pod MART. Contoh, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    4. Jalankan pengujian bandwidth jaringan terhadap pod Cassandra yang masih menjalankan netcat: 

      dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456

    Anda dapat mengulangi proses ini untuk pod Cassandra lainnya. Jika kecepatan yang dihasilkan kurang dari 10 M/dtk, bandwidth jaringan kemungkinan besar adalah penyebab masalah.

Resolusi

Setelah kecepatan I/O lambat dikonfirmasi dengan langkah-langkah di atas, pastikan cluster Anda mematuhi persyaratan minimum jaringan dan penyimpanan. Uji bandwidth lagi setelahnya.

Penyebab: Sudah ada

Diagnosis

Anda akan melihat error yang mirip dengan berikut ini: 

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Resolusi

Pesan error ini tidak terkait dengan penyebab masalah dan merupakan hasil operasi percobaan ulang tugas pemulihan. Pesan error yang sebenarnya akan ditampilkan dalam log pod pertama yang gagal.

Mendapatkan log dari kegagalan awal untuk mendiagnosis masalah.

Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik.

Solusi untuk Masalah Umum 391861216

Diagnosis

Pod Cassandra bernomor tertinggi berada dalam status CrashLoopBackoff setelah pemulihan. Hal ini dapat terjadi karena masalah umum 391861216. Anda melihat error di log pod Cassandra yang mirip dengan berikut ini: 

Cannot change the number of tokens from 512 to 256

Resolusi

Lakukan langkah-langkah berikut untuk mengatasi masalah yang mendasarinya. Tindakan ini akan memungkinkan Cassandra dimulai secara normal sambil mempertahankan data.

  1. Mulai penghapusan PVC untuk pod Cassandra yang macet dalam status CrashLoopBackoff. Tetapkan POD_NAME ke nama pod dalam status CrashLoopBackoff. Tetapkan APIGEE_NAMESPACE ke namespace cluster tempat Apigee diinstal. 

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

  2. Hapus pod dalam status CrashLoopBackoff. 

    kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

  3. Ubah host seed untuk Cassandra secara manual ke pod bernomor tertinggi. Misalnya, jika Anda memiliki tiga replika, SEED_POD_NAME harus berupa apigee-cassandra-default-2. Tindakan ini hanya diperlukan sekali dan dapat dilewati untuk pod berikutnya. 

    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. Hapus node dengan 512 token dari ring 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' | 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. Tunggu hingga pod Cassandra pulih, mulai ulang mungkin lebih dari sekali, dan mencapai status Ready 2/2. Pod tertinggi berikutnya kemudian akan beralih ke status CrashLoopBackoff. 

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

  6. Perbarui POD_NAME dan ulangi langkah-langkah sebelumnya di atas untuk pod yang tersisa, satu per satu, saat pod tersebut memasuki status CrashLoopBackoff hingga semua pod berada dalam status Ready 2/2 dan memiliki status Running.

  7. Pastikan semua pod telah berhasil bergabung ke ring 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'

    Semua node Cassandra harus memiliki status UN dan 256 token.

  8. Kembalikan perubahan ke host seed untuk Cassandra. 

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

    Pengontrol Datastore Apigee akan memulai ulang pod Cassandra lagi karena mengembalikan perubahan host seed.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut meskipun setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut, lalu hubungi Layanan Pelanggan Google Cloud:

  1. Selain data biasa yang mungkin diminta untuk Anda berikan, kumpulkan data diagnostik dari semua pod Cassandra dengan perintah berikut: 

    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. Kompresi, lalu berikan dalam kasus dukungan:

    tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*
  3. Mengumpulkan dan memberikan log dari pod pemulihan. Perhatikan bahwa log berumur pendek, sehingga log harus dikumpulkan tepat setelah kegagalan.
  4. Jika Anda mengikuti langkah-langkah diagnosis di atas, kumpulkan semua output konsol, salin ke dalam file, lalu lampirkan file tersebut ke kasus dukungan.