Failover

Failover mempromosikan cluster siaga ke primary mandiri ketika primary asli benar-benar tidak tersedia. Ini adalah operasi yang mengutamakan ketersediaan dan mungkin kehilangan data yang tidak direplikasi sebelum kegagalan.

Panduan ini mengasumsikan topologi asli:

cluster-a (primary)  ->  cluster-b (standby)

Setelah failover, cluster-b menjadi primer mandiri:

cluster-b (primary)

Kapan Menggunakan Failover

Gunakan failover hanya jika:

• Primer asli tidak dapat merespons permintaan.
• Primer tidak dapat dipulihkan dalam waktu yang dapat diterima.
• Memulihkan ketersediaan tulis lebih penting daripada menunggu primary yang lama.

Jika primary masih dapat dijangkau, gunakan Switchover sebagai gantinya. Peralihan menghindari kehilangan data.

Risiko Kehilangan Data

Failover tidak menunggu primary yang asli. Data apa pun yang ditulis ke primary lama namun belum direplikasi ke standby dapat hilang.

Kemungkinan kehilangan data ditentukan oleh jeda CDC pada saat primary tidak tersedia.

Sebelum menjalankan failover, pahami tradeoff-nya:

Tujuan	Peralihan	Peralihan Tujuan
Memulihkan penulisan saat media utama tidak dapat dijangkau	Tidak	Ya
Menghindari kehilangan data	Ya	Tidak dijamin
Membutuhkan nomor utama lama untuk merespons	Ya	Tidak

Sebelum Anda Mulai

Konfirmasikan hal-hal berikut:

• Primer asli tidak tersedia.
• Anda telah memutuskan untuk tidak menunggu pemulihan utama.
• Lalu lintas aplikasi dapat dialihkan ke siaga.
• Otomatisasi lalu lintas tidak akan mengirim penulisan kembali ke primary lama jika sudah pulih.
• Anda memiliki ID cluster siaga, alamat, token, dan pchannels.

Persyaratan keamanan yang paling penting adalah untuk mencegah split brain. Setelah failover, hanya siaga yang dipromosikan yang harus menerima penulisan aplikasi.

Membangun Konfigurasi Failover

Buat konfigurasi yang hanya berisi cluster siaga dan tidak ada topologi replikasi. Tetapkan force_promote=True.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

Promosikan Siaga

Kirim permintaan ke cluster siaga.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

Jika permintaan berhasil, cluster-b menjadi primer mandiri dan dapat menerima penulisan.

Mengalihkan Lalu Lintas Aplikasi

Setelah promosi:

1. Alihkan lalu lintas tulis ke cluster-b.
2. Hapus cluster-a dari titik akhir tulis, penyeimbang beban, catatan DNS, dan otomatisasi.
3. Verifikasi bahwa cluster-b menerima penulisan.
4. Jaga agar cluster-a tetap terisolasi hingga dinonaktifkan atau secara eksplisit dibangun kembali.

Contoh verifikasi penulisan:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

Sesuaikan nama koleksi dan bidang skema agar sesuai dengan penerapan Anda.

Memverifikasi Hasil

Verifikasi cluster yang dipromosikan secara langsung:

• Menulis berhasil di cluster-b.
• Membaca mengembalikan data yang diharapkan.
• Tidak ada komponen aplikasi yang menulis ke cluster-a.

Menangani Primer Lama

Setelah failover, perlakukan cluster-a sebagai basi. Jangan kirimkan penulisan aplikasi ke sana jika sudah dapat dijangkau lagi. Ini mungkin berisi data yang tidak pernah direplikasi ke cluster-b, dan cluster-b mungkin sudah berisi tulisan baru setelah failover.

Jangan menyambungkan kembali cluster-a ke topologi lama secara otomatis. Menghubungkan kembali ke primary yang lama adalah tugas pemulihan terpisah yang harus direncanakan dengan hati-hati.

Meminimalkan Kehilangan Data

Anda tidak bisa menghilangkan semua risiko kehilangan data dari failover, tetapi Anda bisa menguranginya:

• Pantau kelambatan CDC secara terus menerus.
• Selalu sediakan cluster siaga untuk menangani kecepatan penulisan primer.
• Jaga agar latensi jaringan lintas cluster dan kehilangan paket tetap rendah.
• Buatlah penulisan aplikasi menjadi idempoten.
• Coba lagi penulisan yang keberhasilannya tidak pasti setelah failover.
• Lebih memilih peralihan kapan pun server utama masih dapat merespons.

PERTANYAAN UMUM

Apakah failover selalu kehilangan data?

Tidak, tetapi bisa saja. Jika semua penulisan telah direplikasi sebelum failover, tidak ada data yang hilang. Jika terjadi kelambatan CDC, data yang tertinggal mungkin akan hilang.

Berapa lama waktu yang dibutuhkan untuk failover?

Biasanya selesai dalam hitungan detik, tergantung pada status cluster dan ketersediaan bidang kontrol dalam keadaan siaga.

Dapatkah saya menjalankan failover di server utama?

Tidak. Failover ditujukan untuk cluster siaga. Jika primary saat ini tersedia, gunakan peralihan.

Dapatkah primary yang lama bergabung kembali secara otomatis?

Tidak. Setelah failover, primary lama harus diperlakukan sebagai basi dan dinonaktifkan atau dibangun kembali sebelum dapat berpartisipasi dalam replikasi lagi.

Bagaimana cara menghindari split brain?

Pastikan hanya cluster yang dipromosikan yang menerima penulisan. Hapus primary lama dari semua jalur penulisan sebelum dapat pulih dan menerima trafik.