Memecahkan masalah operator AlloyDB Omni Kubernetes

Pilih versi dokumentasi:

Halaman ini menunjukkan cara menyelesaikan masalah pada operator Kubernetes AlloyDB Omni.

Mengumpulkan informasi proses debug

Bagian ini menjelaskan cara mengumpulkan log dan konfigurasi untuk proses debug.

Mengambil log dari pod operator

Untuk mengambil log dari pod operator, jalankan perintah berikut:

kubectl logs deployments/fleet-controller-manager -c manager -n alloydb-omni-system
kubectl logs deployments/local-controller-manager -c manager -n alloydb-omni-system

Mengambil log pod database

Untuk mengambil log pod database, jalankan perintah berikut:

kubectl logs al-<id-instance-name>-0 -n db
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster-name -c database -n db

Log berikut adalah contoh pemeriksaan kondisi database yang berhasil:

I1106 16:17:28.826188      30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:28.826295      30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:34.810447      30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:34.834844      30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"
I1106 16:17:38.825843      30 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-sample"
I1106 16:17:38.825959      30 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="dbc-bugbash" dbcluster="dbcluster-s
ample"

Ambil postgresql.log

Untuk mengambil postgresql.log, jalankan perintah berikut:

kubectl exec -it al-id-instance-name-0 -n db -c database -- cat /obs/diagnostic/postgresql.log

Ambil file YAML DBInstance

Untuk mengambil file YAML DBInstance, jalankan perintah berikut:

kubectl get dbclusters.a <dbcluster-name> -n db -o yaml

Mengambil konfigurasi dan log untuk skenario HA

Untuk mengambil konfigurasi dan log khusus untuk skenario ketersediaan tinggi (HA), jalankan perintah berikut:

kubectl get replicationconfig -n <namespace>
kubectl get deletestandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get createstandbyjobs.alloydbomni.internal -n <namespace> -o yaml
kubectl get failovers.alloydbomni.dbadmin.goog -n <namespace> -o yaml

Mengambil status pod dan STS

Untuk mengambil status pod dan StatefulSet (STS), jalankan perintah berikut:

kubectl describe pod -n <namespace> <pod-name>
kubectl describe statefulset -n <namespace> al-<id-instance-name>

Mengidentifikasi error

Bagian ini menjelaskan cara mengidentifikasi error.

Cari status error dan kode error

Untuk mengidentifikasi kode error, periksa file YAML DBCluster di bagian status. Lihat dokumentasi kode error untuk mengetahui informasi selengkapnya.

Untuk mengambil file YAML DBCluster, jalankan perintah berikut:

kubectl get dbclusters.a <dbcluster-name> -n <dbcluster-namespace> -o yaml

Cari criticalIncidents. Bagian ini berisi kode error dan stack trace.

Berikut adalah contoh criticalIncidents:

status:
    certificateReference:
      certificateKey: ca.crt
      secretRef:
        name: dbs-al-cert-dr-mce
        namespace: dr
    conditions:
    -   lastTransitionTime: "2024-10-07T22:46:03Z"
    ...
    criticalIncidents:
    -   code: DBSE0304
      createTime: "2024-10-03T11:50:54Z"
      message: 'Healthcheck: Health check invalid result.'
      resource:
        component: healthcheck
        location:
          group: alloydbomni.internal.dbadmin.goog
          kind: Instance
          name: bc0f-dr-mce
          namespace: dr
          version: v1
      stackTrace:
      -   component: healthcheck
        message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
          = Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
          dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
          Lag is 384837.296269 seconds, wanted 35 seconds'

Anda juga dapat mengambil status dengan mengekstrak kolom tertentu dalam format JSON:

kubectl get dbcluster.${DBTYPE:?} -n "${PROJECT:?}" "${DBCLUSTER:?}" -o json -o jsonpath='{.status.criticalIncidents}' | jq

Outputnya mirip dengan hal berikut ini:

[
  {
    "code": "DBSE0085",
    "createTime": "2024-03-14T05:41:37Z",
    "message": "Platform: Pod is unschedulable.",
    "resource": {
      "component": "provisioning",
      "location": {
        "group": "alloydb.internal.dbadmin.goog",
        "kind": "Instance",
        "name": "b55f-testdbcluster",
        "namespace": "dbs-system",
        "version": "v1"
      }
    },
    "stackTrace": [
      {
        "component": "provisioning",
        "message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
      }
    ]
  }
]

Jika pesan error merujuk ke pod database, periksa instance dan resource pod dalam namespace yang sama:

kubectl get instances.a dbcluster_name -n dbcluster_namespace -o yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=dbcluster_name -l alloydbomni.internal.dbadmin.goog/task-type=database -n dbcluster_namespace

Men-debug masalah memori

Bagian ini menjelaskan cara men-debug masalah memori.

Jalankan dan ambil heapdump

Aktifkan fitur ini hanya untuk tujuan pemecahan masalah. Jangan lupa untuk menonaktifkannya setelah itu.

Untuk mengambil heapdump, selesaikan langkah-langkah berikut:

  1. Ubah deployment operator di namespace alloydb-omni-system dengan nama fleet-controller-manager dan local-controller-manager.
  2. Tambahkan argumen berikut ke pod --pprof-address=:8642 atau ke port lain yang tersedia.
  3. Tunggu hingga pod pengontrol dimulai ulang.

  4. Teruskan port sebelumnya. Contoh:

    kubectl port-forward -n alloydb-omni-system fleet-controller-manager-pod-name 8642:8642

  5. Di terminal lain, jalankan go tool pprof http://localhost:8642/debug/pprof/heap. Ubah port agar cocok dengan port sebelumnya jika Anda tidak menggunakan 8642.

  6. Hubungkan ke alamat dan jalankan perintah pemecahan masalah. Misalnya: top.

  7. Setelah menyelesaikan pemecahan masalah, urungkan langkah 1 dengan menghapus argumen dan menunggu pod dimulai ulang.

Menentukan jumlah resource yang dipantau operator

Untuk memahami resource yang sedang digunakan, jalankan perintah berikut:

kubectl get backuprepositories -A  | wc -l
kubectl get failovers -A  | wc -l
kubectl get instancebackupplans -A  | wc -l
kubectl get instancebackups -A  | wc -l
kubectl get instancerestores -A  | wc -l
kubectl get instances -A  | wc -l
kubectl get instanceswitchovers -A  | wc -l
kubectl get lrojobs -A  | wc -l
kubectl get replicationconfigs -A  | wc -l
kubectl get sidecars -A  | wc -l
kubectl get deployments -A  | wc -l
kubectl get statefulsets -A  | wc -l
kubectl get certificates.cert-manager.io -A  | wc -l
kubectl get issuers.cert-manager.io -A  | wc -l
kubectl get configmaps -A  | wc -l
kubectl get persistentvolumeclaims -A  | wc -l
kubectl get persistentvolumes -A  | wc -l
kubectl get pods -A  | wc -l
kubectl get secrets -A  | wc -l
kubectl get services -A  | wc -l
kubectl get storageclasses.storage.k8s.io -A  | wc -l

Misalnya, jika jumlah secret tinggi, hal ini dapat menyebabkan error Out Of Memory (OOM).

kubectl get secrets -A | wc -l

Proses debug HA lanjutan

Bagian ini mereferensikan resource yang merupakan penerapan internal. Fitur ini dapat berubah kapan saja dan tidak memiliki komitmen kompatibilitas mundur. Hanya terapkan perbaikan manual pada masalah di database non-produksi. Langkah-langkah ini dapat membuat database tidak dapat dipulihkan.

Penyiapan HA AlloyDB Omni memiliki tiga fase:

  1. Siapkan primer untuk menerima koneksi dari standby.
  2. Lakukan inisialisasi standby dan hubungkan ke primer.
  3. Tetapkan setelan utama untuk membuat koneksi sinkron.

Langkah 2 biasanya yang paling lambat. Bergantung pada ukuran database, proses ini mungkin memerlukan waktu beberapa jam.

Setiap instance replikasi harus memiliki replicationconfig yang terpasang padanya. Contoh: bash ❯ k get replicationconfigs.alloydbomni.internal.dbadmin.goog NAME PARENT TYPE ROLE READY HEALTHY 9f47-dbcluster-sample--7576-dbcluster-sample 9f47-dbcluster-sample Physical Upstream True True ds-7576-dbcluster-sample 7576-dbcluster-sample Physical Downstream True True

Dalam contoh ini:

  • Instance 9f47-dbcluster-sample dikonfigurasi sebagai upstream fisik.
  • Instance 7576-dbcluster-sample dikonfigurasi sebagai downstream fisik.

Spesifikasi Konfigurasi Replikasi menunjukkan setelan yang diinginkan, sedangkan status mencerminkan status sebenarnya yang dibaca dari database. Jika ada ketidakcocokan antara spesifikasi dan status, pengontrol masih mencoba menerapkan perubahan, atau ada beberapa error yang mencegah perubahan diterapkan. Hal ini akan tercermin di kolom status.

Tugas standby

Harus ada dua set tugas internal yang melacak alur kerja siaga:

  • createstandbyjobs.alloydbomni.internal.dbadmin.goog
  • deletestandbyjobs.alloydbomni.internal.dbadmin.goog

Jika penyiapan tampak macet, lihat tugas yang terkait dengan cluster database (DBC). Pekerjaan mungkin memiliki pesan error yang menjelaskan status penyiapan. Tugas akan dibersihkan secara otomatis beberapa saat setelah selesai, sehingga Anda mungkin tidak melihat tugas apa pun jika tidak ada tugas yang sedang berlangsung.

k get createstandbyjob

Outputnya mirip dengan hal berikut ini:

apiVersion: alloydbomni.dbadmin.gdc.goog/v1
  kind: CreateStandbyJob
  metadata:
    creationTimestamp: "2024-11-05T03:34:26Z"
    finalizers:
    -   createstandbyjob.dbadmin.goog/finalizer
    generation: 1804
    labels:
      dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
    name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
    namespace: db
    resourceVersion: "11819071"
    uid: 1f24cedf-b326-422f-9405-c96c8720cd90
  spec:
    attempt: 3
    cleanup: false
    currentStep: SetupSynchronous
    currentStepTime: "2024-11-05T03:45:31Z"
    metadata:
      dbc: foo-ha-alloydb1-clone1
      primaryInstance: ac00-foo-ha-alloydb1-clone1
      retryError: 'etcdserver: leader changed'
      standbyInstance: 6036-foo-ha-alloydb1-clone1
    requeueTime: "2024-11-05T18:33:03Z"
    startTime: "2024-11-05T03:36:56Z"

Verifikasi utama

Hal pertama yang harus diverifikasi adalah apakah primer disiapkan dengan benar. Harus ada Profil Replikasi untuk setiap standby. Jika isSynchronous bernilai benar pada spesifikasi dan status, penyiapan akan selesai. Jika isSynchronous salah pada spesifikasi dan status, berarti belum mencapai langkah 3. Lihat tugas siaga untuk melihat apakah ada tugas yang sedang berjalan, dan apakah ada pesan error.

  replication:
    profiles:
    -   isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      password:
        name: ha-rep-pw-dbcluster-sample
        namespace: default
      passwordResourceVersion: "896080"
      role: Upstream
      type: Physical
      username: alloydbreplica

Verifikasi bahwa anotasi disableHealthcheck adalah salah (false). Fitur ini dimaksudkan untuk dinonaktifkan hanya selama failover atau switchover.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Kueri

Untuk memverifikasi bahwa resource di pod DB telah disiapkan dengan benar, login ke database sebagai pengguna administrator alloydbadmin. Kemudian, jalankan kueri berikut:

Slot replikasi

alloydbadmin=# select * from pg_replication_slots;

-[ RECORD 1 ]-------+---------------------------------------------
slot_name           | d85d_dbcluster_sample
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | t
active_pid          | 250
xmin                | 16318
catalog_xmin        |
restart_lsn         | 0/CA657F0
confirmed_flush_lsn |
wal_status          | reserved
safe_wal_size       |
two_phase           | f

Status baik adalah keberadaan slot replikasi yang memiliki nama yang sama dengan instance standby. Tidak adanya slot replikasi menunjukkan bahwa langkah penyiapan pertama belum berhasil diselesaikan.

Jika active == t tidak benar, berarti siaga tidak terhubung karena beberapa alasan (jaringan, siaga tidak menyelesaikan penyiapan, dll.) dan proses debug kemungkinan perlu dilanjutkan di sisi siaga.

Statistik replikasi

alloydbadmin=# select * from pg_stat_replication;

-[ RECORD 1 ]----+----------------------------------------------------------------
pid              | 250
usesysid         | 16385
usename          | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr      | 10.54.79.196
client_hostname  | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port      | 24914
backend_start    | 2024-10-30 21:44:26.408261+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/CA64DA8
write_lsn        | 0/CA64DA8
flush_lsn        | 0/CA64DA8
replay_lsn       | 0/CA64DA8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 2
sync_state       | sync
reply_time       | 2024-11-04 22:08:04.370838+00

Jika tidak ada, berarti tidak ada koneksi yang aktif. sync_state harus sync. Jika bukan sync, berarti langkah terakhir penyiapan belum selesai. Melihat log / tugas akan memberikan detail selengkapnya.

Verifikasi standby

Siaga harus memiliki profil replikasi yang cocok dengan profil yang sama dengan primer:

  replication:
    profiles:
    -   host: 10.54.79.210
      isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      passwordResourceVersion: "896080"
      port: 5432
      role: Downstream
      type: Physical
      username: alloydbreplica

Jika tidak ada koneksi dari standby ke primer, ada dua kemungkinan umum:

  1. Standby masih disiapkan.
  2. Standby mengalami error saat menyiapkan atau mencoba menghubungkan.

Untuk memeriksa apakah opsi 1 terjadi, dapatkan log pod database dan cari pernyataan log bernama dbdaemon/setupPhysicalReplicationDownstream. Berikut adalah contoh log penyiapan yang berhasil:

I1104 22:42:42.604871     103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590     103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403     103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440     103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749     103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783     103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565     103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621     103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689     103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838     103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732     103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"

Jika terjadi error koneksi, periksa log pod db serta file log di database di /obs/diagnostic/postgresql.log dan lihat apa errornya saat mencoba terhubung. Salah satu error umum adalah tidak ada konektivitas jaringan antara perangkat siaga dan perangkat utama.

Perbaikan manual

Cara termudah untuk memperbaiki masalah HA adalah dengan menonaktifkan lalu mengaktifkan kembali HA dengan menyetel numberOfStandbys ke 0, lalu meresetnya ke angka yang Anda inginkan. Jika siaga macet dan tidak dapat dinonaktifkan, ikuti langkah-langkah berikut untuk mereset penyiapan HA secara manual agar kosong:

  1. Hapus instance standby secara manual.

  2. Hubungkan ke database utama. Kueri slot replikasi saat ini dan hapus slot replikasi siaga yang ingin Anda hapus:

    select pg_drop_replication_slot('<replication_slot_name_here>');

  3. Hapus profil replikasi dari instance utama yang ingin Anda hapus.

Jika instance belum direkonsiliasi baru-baru ini, Anda dapat mengedit nilai anotasi forceReconcile tersebut. Tetapkan ke nilai numerik apa pun, yang merupakan stempel waktu terakhir kali anotasi tersebut diperbarui. Satu-satunya tujuan anotasi tersebut adalah untuk menyediakan kolom yang dapat kita perbarui untuk memaksakan rekonsiliasi baru.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

Mengumpulkan log audit dan mesin database

Log mesin database dan log audit tersedia sebagai file di dalam pod database (memerlukan akses root):

  • obs/diagnostic/postgresql.log
  • obs/diagnostic/postgresql.audit
export NAMESPACE=dbcluster-namespace
export DBCLUSTER=dbcluster-sample

export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER} -l alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
kubectl exec -n ${NAMESPACE} ${DBPOD} -it -- /bin/bash

$ ls -la /obs/diagnostic/
-rw------- 1 postgres postgres    98438 Sep 25 20:15 postgresql.audit
-rw------- 1 postgres postgres 21405058 Sep 25 20:24 postgresql.log

Mengumpulkan metrik database dan pod database

Operator AlloyDB Omni menyediakan serangkaian metrik dasar untuk mesin AlloyDB Omni dan pod yang menghostingnya. Metrik tersedia sebagai endpoint Prometheus yang tersedia di port 9187. Untuk mengakses endpoint, Anda perlu mengidentifikasi nama pod untuk pod database dan pod pemantauan database, menggunakan label DBCluster dan task-type sebagai berikut.

export NAMESPACE=default
export DBCLUSTER=dbcluster-sample

export DBPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

export MONITORINGPOD=`kubectl get pod -n ${NAMESPACE} -l alloydbomni.internal.dbadmin.goog/dbcluster=${DBCLUSTER},alloydbomni.internal.dbadmin.gdc.goog/task-type=monitoring -o jsonpath='{.items[0].metadata.name}'`

Mengakses metrik database AlloyDB Omni

kubectl port-forward -n ${NAMESPACE} ${MONITORINGPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP

Mengakses metrik pod database

kubectl port-forward -n ${NAMESPACE} ${DBPOD} 9187:9187
curl http://localhost:9187/metrics | grep HELP

Anda juga dapat mengonfigurasi Prometheus untuk Melakukan Scraping metrik di cluster Kubernetes Anda. Lihat konfigurasi penemuan layanan Prometheus Kubernetes untuk mengetahui detailnya.