Elasticsearch:Replikasi data antar kluster dengan CCR

Perbandingan solusi

Untuk skenario disaster recovery jarak jauh yang memerlukan RPO rendah dan latensi rendah, CCR merupakan pilihan terbaik:

• CCR menyinkronkan data dalam hitungan detik, sehingga meminimalkan kehilangan data.

• Jika kluster pemimpin mengalami kegagalan, Anda dapat mengarahkan traffic ke kluster pengikut untuk memulihkan layanan tanpa menunggu pemulihan snapshot.

• Meskipun biaya penerapan awal lebih tinggi, CCR lebih hemat biaya dalam jangka panjang karena mencegah kerugian bisnis akibat kehilangan data.

Arsitektur

CCR menggunakan arsitektur aktif-pasif. Kluster pemimpin menerima semua operasi tulis, sedangkan kluster pengikut bersifat read-only dan mereplikasi data dari kluster pemimpin.

• Kluster pemimpin: Kluster sumber yang menangani semua operasi tulis.

• Kluster pengikut: Kluster tujuan yang bersifat read-only dan menyinkronkan data dari kluster pemimpin menggunakan CCR.

Proses replikasi data

Proses replikasi data dalam CCR terdiri dari dua fase:

Inisialisasi

Kluster pengikut mengirim permintaan inisialisasi ke kluster pemimpin. Kluster pemimpin kemudian mentransfer semua file segmen Lucene dari indeks pemimpin ke indeks pengikut, mirip dengan mekanisme pemulihan snapshot.

Sinkronisasi inkremental

Setiap shard dalam indeks pengikut secara berkala mengirim permintaan pull ke kluster pemimpin untuk mengambil operasi terbaru sejak titik sinkronisasi terakhir. Secara default, hal ini terjadi setiap detik. Prosesnya sebagai berikut:

1. Menentukan titik awal pull: Kluster pengikut menyimpan remote_checkpoint lokal, yang menunjukkan operasi terbaru yang berhasil diterapkan secara lokal. Checkpoint ini sesuai dengan global_checkpoint dalam transaction log (translog) kluster pemimpin.

2. Membaca operasi dari translog pemimpin: Kluster pemimpin menggunakan from_seq_no yang diberikan oleh kluster pengikut untuk menemukan posisi awal dalam translog-nya. Kluster tersebut kemudian membaca semua operasi berikutnya (index, update, delete) dan mengembalikannya sebagai daftar.

3. Memainkan ulang operasi di kluster pengikut: Kluster pengikut memainkan ulang operasi tersebut secara lokal sesuai urutan dan memperbarui remote_checkpoint-nya. Jika pemutaran ulang gagal, misalnya karena konflik versi, sinkronisasi dihentikan sementara dan kesalahan dicatat dalam log.

4. Polling berkelanjutan: Kluster pengikut terus-menerus melakukan polling untuk operasi baru pada interval tetap, biasanya mencapai latensi sub-detik.

Peran translog

Transaction log (translog) merupakan sumber data untuk sinkronisasi inkremental dalam CCR. Translog memiliki fungsi berikut dalam Elasticsearch:

• Mencegah kehilangan data: Secara default, Elasticsearch melakukan refresh setiap detik, yang membuat segmen Lucene baru yang dapat dicari dari buffer memori. Namun, segmen ini belum disimpan ke disk. Translog mencatat semua operasi tulis. Jika node mengalami crash, Anda dapat memulihkan data dengan memainkan ulang log tersebut.

• Menjamin konsistensi replika: Elasticsearch pertama-tama menulis operasi ke translog, lalu meneruskannya ke shard replika. Respons sukses hanya dikembalikan setelah shard primary dan replika mengonfirmasi penulisan tersebut.

• Mendukung sinkronisasi inkremental dalam CCR: CCR menggunakan API internal Elasticsearch untuk membaca translog dan mengambil semua perubahan setelah nomor urut tertentu, yang memungkinkan replikasi data near real-time.

Translog disimpan secara terpisah untuk setiap shard. Setiap shard memiliki direktori translog sendiri yang berlokasi di indices/{index_uuid}/{shard_id}/translog/. File translog (.tlog) disimpan dalam format biner dan dikelola menggunakan mekanisme generasi. Elasticsearch membuat file generasi baru setiap kali flush terjadi atau ketika ukuran file mencapai batasnya, yaitu 512 MB secara default.