Kluster pengikut adalah fitur ScaleGrid yang memungkinkan Anda untuk menyinkronkan dua sistem database independen (dengan tipe yang sama). Tidak seperti kloning atau replikasi, ini memungkinkan Anda untuk memelihara salinan data produksi yang aktif dan tepat waktu. Cluster tambahan ini, yang dikenal sebagai cluster pengikut, dapat dimanfaatkan untuk beberapa kasus penggunaan, termasuk untuk menganalisis, mengoptimalkan, dan menguji kinerja aplikasi Anda untuk MongoDB, MySQL, dan PostgreSQL. Dalam entri blog ini, kami akan membahas tiga skenario teratas untuk memanfaatkan kluster pengikut untuk aplikasi Anda.
Bagaimana Cluster Pengikut Berbeda Dari Replikasi?
Tidak seperti klon statis, data ini diimpor pada jadwal yang ditetapkan sehingga kluster pengikut Anda selalu sinkron dengan kluster produksi Anda. Berikut adalah beberapa cara penting yang membedakannya dengan replikasi:
- Anda dapat mengontrol seberapa sering sistem tujuan disinkronkan dari sumber – seminggu sekali, sekali sehari, atau bahkan lebih jarang. Ini membantu mengurangi beban pada sistem sumber.
- Karena keduanya adalah sistem independen, Anda memiliki lebih banyak fleksibilitas atas data yang disinkronkan. Anda dapat memiliki kredensial pengguna yang berbeda dan bahkan menghapus beberapa data dari tujuan berdasarkan persyaratan keamanan (catatan:Ini memerlukan skrip sisi pengguna – ini bukan fitur bawaan dari kluster pengikut).
- Sistem 'pengikut' dapat ditulis, sehingga Anda dapat menggunakannya sebagai lingkungan staging untuk menguji perubahan aplikasi Anda. Ini bukan sesuatu yang dapat Anda lakukan pada node replika.
Catatan:ScaleGrid mengimplementasikan kluster pengikut menggunakan snapshot penyimpanan. Ini tidak tersedia untuk penawaran basis data dalam memori kami seperti hosting untuk Redis™*.
1. Penyiapan Pengembangan/Pengujian Basis Data
Kita semua pernah ke sana – sepotong kode yang seharusnya telah teruji baik dikerahkan dalam produksi, dan kemudian semuanya kacau balau. Alur kerja produksi gagal, atau sangat lambat sehingga pada dasarnya tidak dapat digunakan. Insinyur dibangunkan dari tempat tidur mereka untuk memulai operasi pemadam kebakaran. Sekelompok malam tanpa tidur kemudian, akar penyebab yang ditakuti itu muncul.
Aplikasi berperilaku berbeda pada penyiapan produksi dan teknik.
Dengan kata lain, kami mengujinya pada "data uji". Yang, ternyata, tidak seperti data produksi. Sama sekali.
Cara yang jelas untuk menghindari situasi ini adalah dengan menjalankan pengujian pada data produksi Anda. Bukan produksi aktual tentu saja – itu akan menimbulkan bencana. Pada salinan kloning dari data produksi. Sementara kekhawatiran seputar privasi dan keamanan data membuat ini tidak praktis dalam banyak skenario, persyaratan privasi memungkinkan, ini adalah solusi terbaik. Kita tidak perlu lagi bergantung pada insinyur yang menghasilkan kumpulan data yang sesuai – jika lolos pada data uji, maka akan meneruskan data produksi.
Yaitu, hingga data pengujian tidak sinkron dengan produksi sehingga tidak lagi merupakan perkiraan yang baik. Dan kita kembali ke titik awal.
Di sinilah kelompok pengikut masuk.
Dengan menggunakan kluster pengikut, Anda dapat mengimpor data secara berkala dari database produksi ke database dev/test. Dan karena seluruh impor dilakukan menggunakan snapshot penyimpanan, bukan dump logis, prosesnya hampir seketika. Anda dapat menjadwalkan impor sekali setiap 24 jam, seminggu sekali, atau frekuensi apa pun yang sesuai dengan skenario khusus Anda.
Dengan pengembangan dan kluster QA Anda diatur untuk mengikuti kluster produksi, Anda dapat beristirahat dengan tenang. Jika aplikasi Anda lolos pada kumpulan data pengujian, itu pasti cocok untuk diterapkan dalam produksi!
2. Analisis Data
Jika Anda pernah bekerja sebagai DBA, Anda mungkin pernah berbicara dengan tim Anda tentang kinerja sistem yang melambat secara "misterius" pada waktu-waktu tertentu. Dalam kebanyakan kasus, pelakunya ternyata adalah pekerjaan analitik yang mengakses banyak data dan akhirnya memperlambat seluruh sistem.
Sebagai vendor DBaaS, kami telah melakukan percakapan ini beberapa kali dengan pelanggan kami. Berikut adalah dua opsi yang biasanya kami sarankan:
- Jika tugas analitik berjalan di server utama/master, pindahkan ke server sekunder/replika.
- Jika tugas analitik sudah berjalan di node sekunder, dan penurunan performa tidak dapat diterima, sebaiknya pindahkan tugas ke kluster analitik khusus.
Menggunakan fitur kluster pengikut kami, sangat mudah untuk menjaga agar kluster analitik selalu terbarui dengan data produksi aktual. Anda dapat membuat jadwal pengikut untuk menyinkronkan data terbaru dari produksi tepat sebelum tugas analitik Anda dimulai.
Bagian terbaiknya? Sinkronisasi pengikut tidak melakukan operasi tingkat basis data apa pun – ini hanya mengembalikan snapshot terbaru! Jadi, tidak ada dampak pada cluster produksi Anda.
3. Pelaporan
Kasus penggunaan umum lainnya di mana pelanggan kami menggunakan fitur kluster pengikut adalah untuk pembuatan laporan. Proses pelaporan biasanya jarang berjalan, tetapi mengakses data dalam jumlah besar dan menghabiskan sebagian besar sumber daya cluster database. Jika penurunan kinerja tidak dapat diterima, sebaiknya pelanggan kami memindahkan beban kerja pelaporan ke kluster baru.
Karena operasi pelaporan jarang terjadi, banyak pelanggan kami lebih suka memanfaatkan fitur jeda/lanjutkan untuk 'menjeda' kluster pelaporan saat tidak digunakan. Ini membantu menghemat biaya infrastruktur secara besar-besaran. Biasanya, cluster pelaporan juga jauh "lebih kecil" (CPU/RAM lebih kecil), untuk membantu mengurangi biaya.
Setelah Anda membuat kluster pengikut dari UI kami, Anda dapat menggunakan alur kerja ini untuk mengotomatiskan alur pelaporan Anda:
- Gunakan API resume kami untuk melanjutkan cluster.
- Tunggu hingga cluster kembali dalam status berjalan (Anda dapat menggunakan API get-status untuk tujuan ini).
- Memicu pencadangan pada kluster produksi Anda, jika diperlukan (biasanya, jika pencadangan reguler dijadwalkan pada produksi Anda, Anda dapat melewati langkah ini. Namun, jika Anda ingin pelaporan Anda berjalan pada data terbaru, ini penting).
- Tunggu hingga pencadangan selesai.
- Memicu tugas sinkronisasi pada pengikut – ini menemukan snapshot terbaru di cluster sumber dan memulihkan ke tujuan.
- Tunggu sampai pekerjaan sinkronisasi selesai.
- Jalankan tugas pelaporan Anda.
- Gunakan API jeda kami untuk menjeda cluster hingga tugas pelaporan Anda berikutnya!
Apakah menurut Anda kluster pengikut cocok untuk kasus pengguna khusus Anda? Anda dapat mempelajari semua tentang cara menerapkan dan mengelola kluster pengikut untuk MongoDB, MySQL, dan PostgreSQL di dokumen bantuan kami!
Jika Anda tidak yakin apakah kluster pengikut adalah solusi yang tepat untuk kasus penggunaan Anda, tinggalkan komentar atau hubungi kami di [email protected] – kami dengan senang hati mendiskusikan fitur mana yang paling sesuai dengan kebutuhan Anda.
