Menyiapkan Replikasi CDC

Panduan ini menunjukkan cara menggunakan dua cluster Milvus mandiri dengan Milvus Operator dan mengonfigurasi replikasi CDC dari cluster sumber ke cluster target.

Contoh-contoh menggunakan:

• source-cluster sebagai cluster utama.
• target-cluster sebagai cluster siaga.
• milvus sebagai ruang nama untuk cluster Milvus.
• milvus-operator sebagai ruang nama untuk Milvus Operator.

Sebelum memulai, baca Milvus CDC untuk memahami model primary-standby dan opsi failover.

Prasyarat

• Milvus v2.6.16 atau yang lebih baru.
• Milvus Operator v1.3.4 atau yang lebih baru.
• Tersedia klaster Kubernetes.
• Klaster sumber dan target dapat terhubung satu sama lain melalui jaringan.
• Anda memiliki kredensial admin untuk kedua cluster Milvus.
• Anda mengetahui jumlah saluran fisik untuk setiap cluster.

Langkah 1: Tingkatkan Operator Milvus

Tambahkan repositori Helm Operator Milvus:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/

Perbarui repositori:

helm repo update zilliztech-milvus-operator

Instal atau tingkatkan Milvus Operator:

helm -n milvus-operator upgrade --install milvus-operator \
  zilliztech-milvus-operator/milvus-operator \
  --create-namespace

Periksa apakah pod operator sudah berjalan:

kubectl get pods -n milvus-operator

Contoh keluaran:

NAME                               READY   STATUS    RESTARTS   AGE
milvus-operator-6f7d8c9c7d-xm4tj   1/1     Running   0          54s

Langkah 2: Menyebarkan Cluster Sumber

Buat berkas bernama milvus_source_cluster.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

Terapkan konfigurasi:

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

Periksa apakah pod cluster sumber sudah berjalan:

kubectl get pods -n milvus

Contoh keluaran:

NAME                                                   READY   STATUS    RESTARTS   AGE
source-cluster-etcd-0                                  1/1     Running   0          3m
source-cluster-minio-6d8f7d9b9f-9t7j2                  1/1     Running   0          3m
source-cluster-milvus-standalone-7f8d9c8f6d-r2m5x      1/1     Running   0          2m
source-cluster-milvus-cdc-66d64747bd-sckxj             1/1     Running   0          2m

Pastikan pod CDC, seperti source-cluster-milvus-cdc-..., berada dalam status Running.

Langkah 3: Menyebarkan Cluster Target

Buat berkas bernama milvus_target_cluster.yaml:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

Komponen CDC juga diaktifkan pada cluster target. Komponen ini tidak aktif saat target dalam keadaan siaga, tetapi diperlukan jika target nantinya menjadi yang utama setelah peralihan.

Terapkan konfigurasi:

kubectl apply -f milvus_target_cluster.yaml

Periksa apakah pod cluster target sudah berjalan:

kubectl get pods -n milvus | grep -E 'NAME|target-cluster'

Contoh keluaran:

NAME                                                   READY   STATUS    RESTARTS   AGE
target-cluster-etcd-0                                  1/1     Running   0          3m
target-cluster-minio-5f7c8d9b6f-k8s2q                  1/1     Running   0          3m
target-cluster-milvus-standalone-66dc8d9f7f-5n6bp      1/1     Running   0          2m
target-cluster-milvus-cdc-7f8c9d6b8c-q4t9m             1/1     Running   0          2m

Langkah 4: Siapkan Informasi Cluster

Dapatkan alamat layanan Milvus untuk kedua cluster:

kubectl get svc -n milvus | grep -E 'NAME|source-cluster|target-cluster'

Contoh keluaran:

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)              AGE
source-cluster-milvus                 ClusterIP   10.98.124.90     <none>        19530/TCP,9091/TCP   8m
target-cluster-milvus                 ClusterIP   10.109.234.172   <none>        19530/TCP,9091/TCP   3m

Siapkan dua jenis alamat:

• Alamat cluster dituliskan pada konfigurasi replikasi dan digunakan oleh komponen CDC. Alamat-alamat ini harus dapat dijangkau dari pod CDC.
• Alamat klien hanya digunakan oleh klien Python Anda saat memanggil API Milvus. Jika Anda menjalankan klien Python di luar kluster Kubernetes, ekspos layanan Milvus melalui metode akses normal, seperti penyeimbang beban, akses masuk, atau port-forward.

Siapkan informasi koneksi dan daftar pchannel untuk kedua klaster:

source_cluster_addr = "http://source-cluster-milvus.milvus.svc.cluster.local:19530"
target_cluster_addr = "http://target-cluster-milvus.milvus.svc.cluster.local:19530"

source_client_addr = source_cluster_addr
target_client_addr = target_cluster_addr

# If your Python client runs outside the Kubernetes cluster, replace only
# source_client_addr and target_client_addr with externally reachable addresses.
# Keep source_cluster_addr and target_cluster_addr reachable from CDC pods.
# For example:
# source_client_addr = "http://127.0.0.1:19530"
# target_client_addr = "http://127.0.0.1:19531"

source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"

source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"

pchannel_num = 16
source_cluster_pchannels = [
    f"{source_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]
target_cluster_pchannels = [
    f"{target_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]

Ganti alamat dengan alamat layanan Milvus yang sebenarnya di lingkungan Anda. Jangan setel source_cluster_addr atau target_cluster_addr ke alamat port-forward lokal kecuali jika pod CDC juga dapat menjangkau alamat tersebut. Daftar pchannel harus sesuai dengan penerapan Milvus Anda. Jangan menyalin nilai contoh tanpa memeriksa konfigurasi cluster Anda.

Langkah 5: Membuat Konfigurasi Replikasi

Buat konfigurasi replikasi dari source-cluster ke target-cluster:

replicate_config = {
    "clusters": [
        {
            "cluster_id": source_cluster_id,
            "connection_param": {
                "uri": source_cluster_addr,
                "token": source_cluster_token,
            },
            "pchannels": source_cluster_pchannels,
        },
        {
            "cluster_id": target_cluster_id,
            "connection_param": {
                "uri": target_cluster_addr,
                "token": target_cluster_token,
            },
            "pchannels": target_cluster_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": source_cluster_id,
            "target_cluster_id": target_cluster_id,
        }
    ],
}

Langkah 6: Terapkan Konfigurasi Replikasi

Terapkan konfigurasi yang sama ke kedua cluster:

from pymilvus import MilvusClient

source_client = MilvusClient(
    uri=source_client_addr,
    token=source_cluster_token,
)
target_client = MilvusClient(
    uri=target_client_addr,
    token=target_cluster_token,
)

try:
    source_client.update_replicate_configuration(**replicate_config)
    target_client.update_replicate_configuration(**replicate_config)
finally:
    source_client.close()
    target_client.close()

Untuk otomatisasi produksi, gunakan klien berumur pendek yang terpisah untuk operasi bidang kontrol ini. Hal ini untuk menghindari berbagi saluran gRPC yang sama dengan lalu lintas DML aplikasi saat peran cluster berubah.

Setelah konfigurasi diterapkan, perubahan yang ditulis ke source-cluster akan direplikasi ke target-cluster.

Langkah 7: Verifikasi Replikasi Data

Untuk memverifikasi bahwa replikasi berfungsi:

1. Sambungkan ke source-cluster.
2. Buat sebuah koleksi.
3. Masukkan data ke dalam koleksi.
4. Muat koleksi dan jalankan kueri atau pencarian di source-cluster.
5. Hubungkan ke target-cluster.
6. Jalankan kueri atau pencarian yang sama di target-cluster tanpa memuat koleksi secara manual di klaster siaga.
7. Konfirmasikan bahwa data yang diharapkan terlihat di kedua cluster.

Cluster target adalah cluster siaga dalam topologi ini. Jangan jalankan operasi DDL atau DCL manual, seperti load_collection, pada cluster siaga. Operasi tersebut harus dilakukan pada cluster sumber dan direplikasi ke cluster target.

Kode verifikasi yang tepat tergantung pada skema pengumpulan Anda. Untuk alur kerja pengumpulan Milvus dasar, lihat dokumentasi mulai cepat Milvus.

Jeda CDC

CDC lag adalah jendela data antara cluster utama dan cluster siaga. Anda harus memantaunya terus menerus setelah replikasi dikonfigurasi.

Jeda CDC dapat meningkat ketika:

• Laju penulisan primer tinggi.
• Latensi jaringan atau kehilangan paket meningkat di antara cluster.
• Cluster siaga kelebihan beban.
• Node CDC kekurangan pasokan.
• Operasi DDL atau impor yang besar sedang berjalan.

Gunakan jeda CDC untuk memandu keputusan operasional:

• Jika jeda rendah, peralihan akan selesai lebih cepat.
• Jika jeda tinggi, peralihan mungkin kehilangan lebih banyak data.

Anda dapat memperkirakan jeda CDC dengan kueri PromQL berikut ini:

clamp_min(
  max by (channel_name) (
    milvus_wal_last_confirmed_time_tick
  )
  -
  min by (channel_name) (
    milvus_cdc_last_replicated_time_tick
  ),
  0
)

Hasilnya dalam hitungan detik. Untuk setiap saluran sumber, kueri membandingkan timetick WAL terakhir yang dikonfirmasi dengan timetick terakhir yang direplikasi oleh CDC. Jika sebuah primer mereplikasi ke beberapa cluster siaga, ekspresi min by (channel_name) melaporkan kemajuan replikasi yang paling lambat untuk saluran itu.

Jika Prometheus mengikis beberapa cluster Milvus, tambahkan filter label yang sesuai dengan penerapan Anda, seperti namespace atau app_kubernetes_io_instance, untuk menghindari pencampuran metrik dari cluster yang berbeda.

PERTANYAAN UMUM

Apakah saya perlu menghubungi update_replicate_configuration di kedua cluster?

Ya. Terapkan topologi yang sama ke semua cluster yang berpartisipasi. Jika salah satu cluster bukan yang utama pada saat panggilan, maka cluster tersebut akan menunggu hingga topologi diterapkan melalui CDC.

Bagaimana saya harus memilih cluster_id?

Gunakan ID yang stabil dan unik untuk setiap cluster. ID ini juga digunakan dalam nama pchannel dan referensi topologi replikasi.

Dapatkah saya mengubah pchannel setelah replikasi dikonfigurasi?

Anda dapat memperbarui topologi, tetapi daftar pchannel harus sesuai dengan tata letak cluster. Perlakukan perubahan pchannel sebagai operasi lanjutan dan verifikasi replikasi dengan hati-hati setelahnya.