Sistem basis data memiliki tanggung jawab untuk menyimpan dan memastikan ketersediaan data yang relevan secara konsisten kapan pun dibutuhkan dan kapan pun dalam pengoperasiannya. Sebagian besar perusahaan gagal untuk melanjutkan bisnis setelah kasus kehilangan data sebagai akibat dari kegagalan database, jembatan keamanan, kesalahan manusia, atau kegagalan bencana yang dapat sepenuhnya menghancurkan node operasi dalam produksi. Menyimpan database di pusat data yang sama membuat seseorang berisiko tinggi kehilangan semua data jika terjadi kekejaman ini.
Replikasi dan Cadangan adalah cara yang umum digunakan untuk memastikan ketersediaan data yang tinggi. Pemilihan antara keduanya tergantung pada seberapa sering data berubah. Cadangan paling disukai di mana data tidak berubah lebih sering dan tidak ada harapan memiliki begitu banyak file cadangan. Di sisi lain, replikasi lebih disukai untuk data yang sering berubah selain beberapa manfaat lain yang terkait seperti menyajikan data di lokasi tertentu dengan mengurangi latensi permintaan. Namun, baik replikasi maupun pencadangan dapat digunakan untuk integritas dan konsistensi data maksimum selama pemulihan jika terjadi kegagalan.
Pencadangan basis data memberikan lebih banyak keuntungan selain menyediakan titik pemulihan untuk menyediakan dasar-dasar untuk menciptakan lingkungan baru untuk pengembangan, akses terbuka, dan staging tanpa mengganggu produksi. Tim pengembangan dapat dengan cepat dan mudah menguji fitur yang baru terintegrasi dan mempercepat pengembangannya. Cadangan juga dapat digunakan ke pos pemeriksaan untuk kesalahan kode di mana pun data yang dihasilkan tidak konsisten.
Pertimbangan untuk Mencadangkan MongoDB
Cadangan dibuat pada titik-titik tertentu untuk mencerminkan (bertindak sebagai snapshot dari database) data apa yang dihosting oleh database pada saat itu. Jika database gagal pada titik tertentu, kita dapat menggunakan file cadangan terakhir untuk memutar kembali DB ke titik sebelum gagal. Namun, seseorang perlu mempertimbangkan beberapa faktor sebelum melakukan pemulihan dan itu termasuk:
- Tujuan Titik Pemulihan
- Tujuan Waktu Pemulihan
- Isolasi Basis Data dan Cuplikan
- Komplikasi dengan Sharding
- Proses Pemulihan
- Faktor Kinerja dan Penyimpanan yang Tersedia
- Fleksibilitas
- Kompleksitas Penerapan
Tujuan Titik Pemulihan
Ini dilakukan untuk menentukan berapa banyak data yang siap Anda hilangkan selama proses pencadangan dan pemulihan. Misalnya, jika kami memiliki data pengguna dan data aliran klik, data pengguna akan diprioritaskan di atas analitik aliran klik karena yang terakhir dapat dibuat ulang dengan memantau operasi di aplikasi Anda setelah pemulihan. Pencadangan berkelanjutan harus lebih disukai untuk data penting seperti informasi bank, data industri produksi, dan informasi sistem komunikasi dan harus dilakukan dalam interval yang dekat. Jika data tidak sering berubah, mungkin lebih murah untuk kehilangan sebagian besar jika Anda melakukan snapshot yang dipulihkan misalnya 6 bulan atau 1 tahun sebelumnya.
Tujuan Waktu Pemulihan
Ini untuk menganalisis dan menentukan seberapa cepat operasi restorasi dapat dilakukan. Selama pemulihan, aplikasi Anda akan mengalami beberapa waktu henti yang juga berbanding lurus dengan jumlah data yang perlu dipulihkan. Jika Anda memulihkan sejumlah besar data, itu akan memakan waktu lebih lama.
Isolasi Basis Data dan Cuplikan
Isolasi adalah ukuran seberapa dekat snapshot cadangan dari server database utama dalam hal konfigurasi logis dan fisik. Jika mereka kebetulan cukup dekat, waktu pemulihan berkurang dengan mengorbankan peningkatan kemungkinan dihancurkan pada saat yang sama database dihancurkan. Tidak disarankan untuk meng-host cadangan dan lingkungan produksi dalam sistem yang sama untuk menghindari gangguan pada server dari mitigasi ke dalam cadangan juga.
Komplikasi dengan Sharding
Untuk sistem basis data terdistribusi melalui sharding, beberapa kerumitan pencadangan disajikan dan aktivitas penulisan mungkin harus dijeda di seluruh sistem. Pecahan yang berbeda akan menyelesaikan berbagai jenis pencadangan pada waktu yang berbeda. Mempertimbangkan pencadangan logis dan pencadangan Snapshot,
Cadangan Logis
- Pecahan memiliki ukuran yang berbeda sehingga akan selesai pada waktu yang berbeda
- Dumps berbasis MongoDB akan mengabaikan --oplog sehingga tidak akan konsisten di setiap shard.
- Penyeimbang bisa mati padahal seharusnya aktif hanya karena beberapa pecahan mungkin belum menyelesaikan proses pemulihan
Cadangan Snapshot
- Berfungsi dengan baik untuk satu replika dari versi 3.2 dan yang lebih baru. Oleh karena itu, Anda harus mempertimbangkan untuk memperbarui versi MongoDB Anda.
Proses Pemulihan
Beberapa orang melakukan pencadangan tanpa menguji apakah mereka akan berfungsi jika terjadi pemulihan. Cadangan pada dasarnya adalah untuk memberikan kemampuan pemulihan jika tidak, itu akan menjadi tidak berguna. Anda harus selalu mencoba menjalankan pencadangan di server pengujian yang berbeda untuk melihat apakah mereka berfungsi.
Faktor Kinerja dan Penyimpanan yang Tersedia
Cadangan juga cenderung mengambil banyak ukuran sebagai data dari database itu sendiri dan perlu dikompresi cukup untuk tidak menempati banyak ruang yang tidak perlu yang dapat memotong sumber daya penyimpanan keseluruhan sistem. Mereka dapat diarsipkan ke dalam file zip sehingga mengurangi ukuran keseluruhannya. Selain itu, seperti yang disebutkan sebelumnya, seseorang dapat mengarsipkan cadangan di pusat data yang berbeda dari database itu sendiri.
Cadangan dapat menentukan kinerja database yang berbeda karena beberapa dapat menurunkannya. Dalam hal ini, pencadangan berkelanjutan akan membuat beberapa kemunduran sehingga harus dikonversi ke pencadangan terjadwal untuk menghindari penipisan jendela pemeliharaan. Dalam kebanyakan kasus, server sekunder digunakan untuk mendukung pencadangan. Dalam hal ini:
- Node tunggal tidak dapat dicadangkan secara konsisten karena MongoDB menggunakan read-uncommitted tanpa oplog saat menggunakan perintah mongodump dan dalam hal ini pencadangan tidak akan aman.
- Gunakan node sekunder untuk pencadangan karena proses itu sendiri membutuhkan waktu sesuai dengan jumlah data yang terlibat dan aplikasi yang terhubung akan mengalami waktu henti. Jika Anda menggunakan primer yang juga harus memperbarui Oplog, maka Anda mungkin kehilangan beberapa data selama waktu henti tersebut
- Proses pemulihan membutuhkan banyak waktu, tetapi sumber daya penyimpanan yang ditetapkan sangat kecil.
Fleksibilitas
Sering kali Anda mungkin tidak menginginkan beberapa data selama pencadangan, seperti contoh Tujuan Titik Pemulihan, seseorang mungkin ingin pemulihan dilakukan dan menyaring data klik pengguna. Untuk melakukannya, Anda memerlukan strategi pencadangan sebagian yang akan memberikan fleksibilitas untuk menyaring data yang tidak Anda minati, sehingga mengurangi durasi pemulihan dan sumber daya yang akan terbuang percuma. Pencadangan tambahan juga dapat berguna sehingga hanya bagian data yang telah berubah yang akan dicadangkan dari snapshot terakhir daripada mengambil seluruh cadangan untuk setiap snapshot.
Kompleksitas Penerapan
Strategi pencadangan Anda harus mudah diatur dan dipelihara seiring waktu. Anda juga dapat menjadwalkan pencadangan sehingga tidak perlu melakukannya secara manual kapan pun Anda mau.
Kesimpulan
Sistem basis data menjamin "kehidupan setelah kematian" jika hanya ada sistem pencadangan yang mapan. Basis data dapat dihancurkan oleh faktor bencana, kesalahan manusia, atau serangan keamanan yang dapat menyebabkan hilangnya atau rusaknya data. Sebelum melakukan pencadangan, kita harus mempertimbangkan jenis data dalam hal ukuran dan kepentingannya. Selalu tidak disarankan untuk menyimpan cadangan Anda di pusat data yang sama dengan database Anda untuk mengurangi kemungkinan cadangan dihancurkan secara bersamaan. Pencadangan dapat mengubah kinerja basis data sehingga orang harus berhati-hati tentang strategi yang digunakan dan kapan harus melakukan pencadangan. Jangan melakukan pencadangan pada node utama karena dapat mengakibatkan waktu henti sistem selama pencadangan dan akibatnya kehilangan data penting.
