Bangun Set Replika MongoDB yang Kuat dalam Waktu Rekor (4 Metode)

MongoDB adalah database NoSQL yang menggunakan dokumen mirip JSON dengan skema dinamis. Saat bekerja dengan database, selalu baik untuk memiliki rencana darurat jika salah satu server database Anda gagal. Sidebar, Anda dapat mengurangi kemungkinan hal itu terjadi dengan memanfaatkan alat manajemen yang bagus untuk situs WordPress Anda.

Inilah mengapa berguna untuk memiliki banyak salinan data Anda. Ini juga mengurangi latensi baca. Pada saat yang sama, ini dapat meningkatkan skalabilitas dan ketersediaan database. Di sinilah replikasi masuk. Ini didefinisikan sebagai praktik sinkronisasi data di banyak basis data.

Pada artikel ini, kita akan menyelami berbagai aspek penting dari replikasi MongoDB, seperti beberapa fiturnya, dan mekanismenya.

Apa itu Replikasi di MongoDB?

Di MongoDB, kumpulan replika melakukan replikasi. Ini adalah sekelompok server yang mempertahankan kumpulan data yang sama melalui replikasi. Anda bahkan dapat menggunakan replikasi MongoDB sebagai bagian dari penyeimbangan muatan. Di sini, Anda dapat mendistribusikan operasi tulis dan baca di semua instans, berdasarkan kasus penggunaan.

Apa Itu Set Replika MongoDB?

Setiap instance MongoDB yang merupakan bagian dari set replika tertentu adalah anggota. Setiap set replika harus memiliki anggota utama dan setidaknya satu anggota sekunder.

Anggota utama adalah jalur akses utama untuk transaksi dengan set replika. Itu juga satu-satunya anggota yang dapat menerima operasi tulis. Replikasi pertama menyalin oplog utama (log operasi). Selanjutnya, ini mengulangi perubahan yang dicatat pada set data masing-masing sekunder. Oleh karena itu, Setiap kumpulan replika hanya dapat memiliki satu anggota utama dalam satu waktu. Berbagai operasi tulis penerima primer dapat menyebabkan konflik data.

Biasanya, aplikasi hanya menanyakan anggota utama untuk operasi tulis dan baca. Anda dapat merancang pengaturan Anda untuk membaca dari satu atau lebih anggota sekunder. Transfer data asinkron dapat menyebabkan pembacaan node sekunder untuk melayani data lama. Jadi, pengaturan seperti itu tidak ideal untuk setiap kasus penggunaan.

Fitur Set Replika

Mekanisme failover otomatis membedakan replika MongoDB dari pesaingnya. Dengan tidak adanya primer, pemilihan otomatis di antara node sekunder mengambil primer baru.

Set Replika MongoDB vs MongoDB Cluster

Kumpulan replika MongoDB akan membuat berbagai salinan dari kumpulan data yang sama di seluruh node kumpulan replika. Tujuan utama dari set replika adalah untuk:

• Tawarkan solusi cadangan bawaan
• Meningkatkan ketersediaan data

Cluster MongoDB adalah permainan bola yang berbeda sama sekali. Ini mendistribusikan data ke banyak node melalui kunci beling. Proses ini akan memecah-mecah data menjadi banyak bagian yang disebut shard. Selanjutnya, ini menyalin setiap pecahan ke node yang berbeda. Sebuah cluster bertujuan untuk mendukung kumpulan data besar dan operasi throughput tinggi. Ini mencapainya dengan menskalakan beban kerja secara horizontal.

Inilah perbedaan antara kumpulan replika dan klaster, dalam istilah awam:

• Sebuah cluster mendistribusikan beban kerja. Itu juga menyimpan fragmen data (pecahan) di banyak server.
• Kumpulan replika menduplikasi kumpulan data sepenuhnya.

MongoDB memungkinkan Anda menggabungkan fungsionalitas ini dengan membuat klaster yang dipecah. Di sini, Anda dapat mereplikasi setiap pecahan ke server sekunder. Ini memungkinkan shard menawarkan redundansi tinggi dan ketersediaan data.

Memelihara dan menyiapkan set replika secara teknis dapat melelahkan dan menghabiskan waktu. Dan menemukan layanan hosting yang tepat? Itu sakit kepala lainnya. Dengan begitu banyak pilihan di luar sana, sangat mudah menghabiskan waktu berjam-jam untuk meneliti, alih-alih membangun bisnis Anda.

Biarkan saya memberi Anda penjelasan singkat tentang alat yang melakukan semua ini dan lebih banyak lagi sehingga Anda dapat kembali menghancurkannya dengan layanan / produk Anda.

Solusi Hosting Aplikasi Kinsta, yang dipercaya oleh lebih dari 55.000 pengembang, Anda dapat memulai dan menjalankannya hanya dalam 3 langkah mudah. Jika kedengarannya terlalu bagus untuk menjadi kenyataan, berikut beberapa manfaat menggunakan Kinsta:

• Nikmati kinerja yang lebih baik dengan koneksi internal Kinsta : Lupakan kesulitan Anda dengan database bersama. Beralih ke database khusus dengan koneksi internal yang tidak memiliki jumlah kueri atau batas jumlah baris. Kinsta lebih cepat, lebih aman, dan tidak akan menagih Anda untuk bandwidth/lalu lintas internal.
• Kumpulan fitur yang disesuaikan untuk pengembang : Skalakan aplikasi Anda pada platform tangguh yang mendukung Gmail, YouTube, dan Google Penelusuran. Yakinlah, Anda berada di tangan yang paling aman di sini.
• Nikmati kecepatan tak tertandingi dengan pusat data pilihan Anda : Pilih wilayah yang paling cocok untuk Anda dan pelanggan Anda. Dengan lebih dari 25 pusat data untuk dipilih, 275+ PoP Kinsta memastikan kecepatan maksimum dan kehadiran global untuk situs web Anda.

Coba solusi hosting aplikasi Kinsta gratis hari ini!

Bagaimana Replikasi Bekerja di MongoDB?

Di MongoDB, Anda mengirim operasi penulis ke server utama (node). Primer menugaskan operasi di seluruh server sekunder, mereplikasi data.

Tiga Jenis Node MongoDB

Dari ketiga jenis node MongoDB, dua telah muncul sebelumnya: node primer dan sekunder. Tipe ketiga dari node MongoDB yang berguna selama replikasi adalah arbiter. Node arbiter tidak memiliki salinan kumpulan data dan tidak dapat menjadi yang utama. Karena itu, arbiter ikut serta dalam pemilihan pendahuluan.

Kami sebelumnya telah menyebutkan apa yang terjadi ketika simpul utama turun, tetapi bagaimana jika simpul sekunder menggigit debu? Dalam skenario itu, node utama menjadi sekunder dan database menjadi tidak terjangkau.

Pemilihan Anggota

Pemilihan dapat terjadi dalam skenario berikut:

• Menginisialisasi set replika
• Kehilangan konektivitas ke node utama (yang dapat dideteksi oleh detak jantung)
• Pemeliharaan kumpulan replika menggunakan metode rs.reconfig atau stepDown
• Menambahkan simpul baru ke kumpulan replika yang ada

Satu set replika dapat memiliki hingga 50 anggota, tetapi hanya 7 atau kurang yang dapat memberikan suara dalam pemilihan apa pun.

Waktu rata-rata sebelum klaster memilih primer baru tidak boleh lebih dari 12 detik. Algoritma pemilihan akan mencoba untuk memiliki sekunder dengan prioritas tertinggi yang tersedia. Pada saat yang sama, anggota dengan nilai prioritas 0 tidak dapat menjadi primadona dan tidak berpartisipasi dalam pemilihan.

Kepedulian Menulis

Untuk daya tahan, operasi tulis memiliki kerangka kerja untuk menyalin data dalam jumlah node tertentu. Anda bahkan dapat menawarkan umpan balik kepada klien dengan ini. Kerangka kerja ini juga dikenal sebagai "masalah tulis". Ini memiliki anggota pembawa data yang perlu mengakui masalah penulisan sebelum operasi kembali berhasil. Umumnya, set replika memiliki nilai 1 sebagai perhatian penulisan. Dengan demikian, hanya yang utama yang harus mengakui penulisan sebelum mengembalikan pengakuan masalah penulisan.

Anda bahkan dapat menambah jumlah anggota yang diperlukan untuk mengakui operasi tulis. Tidak ada batasan jumlah anggota yang dapat Anda miliki. Tapi, jika angkanya tinggi, Anda harus berurusan dengan latensi tinggi. Ini karena klien harus menunggu pengakuan dari semua anggota. Selain itu, Anda dapat menetapkan masalah tertulis dari "mayoritas". Ini menghitung lebih dari separuh anggota setelah menerima pengakuan mereka.

Baca Preferensi

Untuk operasi baca, Anda bisa menyebutkan preferensi baca yang menjelaskan cara database mengarahkan kueri ke anggota kumpulan replika. Biasanya, node utama menerima operasi baca tetapi klien dapat menyebutkan preferensi baca untuk mengirimkan operasi baca ke node sekunder. Berikut adalah opsi untuk preferensi baca:

• primaryPreferred : Biasanya, operasi baca berasal dari simpul utama tetapi jika ini tidak tersedia, data ditarik dari simpul sekunder.
• primary : Semua operasi baca berasal dari node utama.
• sekunder : Semua operasi baca dijalankan oleh node sekunder.
• terdekat : Di sini, permintaan baca diarahkan ke node terdekat yang dapat dijangkau, yang dapat dideteksi dengan menjalankan perintah ping . Hasil dari operasi pembacaan dapat berasal dari setiap anggota set replika, terlepas dari apakah itu yang utama atau yang sekunder.
• secondaryPreferred : Di sini, sebagian besar operasi baca berasal dari node sekunder, tetapi jika tidak ada yang tersedia, data diambil dari node utama.

Replikasi Mengatur Sinkronisasi Data

Untuk mempertahankan salinan terbaru kumpulan data bersama, anggota sekunder kumpulan replika mereplikasi atau menyinkronkan data dari anggota lain.

MongoDB memanfaatkan dua bentuk sinkronisasi data. Sinkronisasi awal untuk mengisi anggota baru dengan kumpulan data lengkap. Replikasi untuk mengeksekusi perubahan yang sedang berlangsung ke kumpulan data lengkap.

Sinkronisasi Awal

Selama sinkronisasi awal, node sekunder menjalankan perintah init sync untuk menyinkronkan semua data dari node primer ke node sekunder lainnya yang berisi data terbaru. Oleh karena itu, simpul sekunder secara konsisten memanfaatkan fitur tailable cursor untuk menanyakan entri oplog terbaru dalam koleksi local.oplog.rs dari simpul utama dan menerapkan operasi ini dalam entri oplog ini.

Dari MongoDB 5.2, sinkronisasi awal dapat berupa salinan file atau logis.

Sinkronisasi logis

Saat Anda menjalankan sinkronisasi logis, MongoDB:

1. Mengembangkan semua indeks koleksi saat dokumen disalin untuk setiap koleksi.
2. Gandakan semua database kecuali untuk database lokal. mongod memindai setiap koleksi di semua database sumber dan memasukkan semua data ke dalam duplikatnya dari koleksi ini.
3. Mengeksekusi semua perubahan pada kumpulan data. Dengan memanfaatkan oplog dari sumbernya, mongod memutakhirkan set datanya untuk menggambarkan keadaan saat ini dari set replika.
4. Ekstrak catatan oplog yang baru ditambahkan selama penyalinan data. Pastikan anggota target memiliki ruang disk yang cukup di dalam database lokal untuk menyimpan sementara catatan oplog ini selama durasi tahap penyalinan data ini.

Saat sinkronisasi awal selesai, anggota akan bertransisi dari STARTUP2 ke SECONDARY .

Sinkronisasi Awal Berbasis Salinan File

Langsung saja, Anda hanya dapat menjalankan ini jika Anda menggunakan MongoDB Enterprise. Proses ini menjalankan sinkronisasi awal dengan menduplikasi dan memindahkan file di sistem file. Metode sinkronisasi ini mungkin lebih cepat daripada sinkronisasi awal logis dalam beberapa kasus. Perlu diingat, sinkronisasi awal berbasis salinan file dapat menyebabkan penghitungan yang tidak akurat jika Anda menjalankan metode count() tanpa predikat kueri.

Namun, metode ini juga memiliki keterbatasan yang adil:

• Selama sinkronisasi awal berbasis salinan file, Anda tidak dapat menulis ke database lokal anggota yang sedang disinkronkan. Anda juga tidak dapat menjalankan pencadangan pada anggota yang sedang disinkronkan atau anggota yang sedang disinkronkan.
• Saat memanfaatkan mesin penyimpanan terenkripsi, MongoDB menggunakan kunci sumber untuk mengenkripsi tujuan.
• Anda hanya dapat menjalankan sinkronisasi awal dari satu anggota tertentu dalam satu waktu.

Replikasi

Anggota sekunder mereplikasi data secara konsisten setelah sinkronisasi awal. Anggota sekunder akan menduplikasi oplog dari sinkronisasi mereka dari sumber dan menjalankan operasi ini dalam proses asinkron.

Sekunder mampu secara otomatis memodifikasi sinkronisasi mereka dari sumber sesuai kebutuhan berdasarkan perubahan waktu ping dan keadaan replikasi anggota lain.

Replikasi Streaming

Dari MongoDB 4.4, sinkronisasi dari sumber mengirimkan aliran entri oplog yang berkelanjutan ke sinkronisasi sekundernya. Replikasi streaming mengurangi kelambatan replikasi di jaringan beban tinggi dan latensi tinggi. Ini juga bisa:

• Kurangi risiko kehilangan operasi tulis dengan w:1 karena failover primer.
• Kurangi staleness untuk membaca dari sekunder.
• Kurangi latensi pada operasi tulis dengan w:“majority” dan w:>1 . Singkatnya, masalah tulis apa pun yang perlu menunggu replikasi.

Replikasi Multithread

MongoDB biasa menulis operasi dalam batch melalui banyak utas untuk meningkatkan konkurensi. MongoDB mengelompokkan batch berdasarkan id dokumen sambil menerapkan setiap grup operasi dengan utas yang berbeda.

MongoDB selalu mengeksekusi operasi tulis pada dokumen yang diberikan dalam urutan tulis aslinya. Ini berubah di MongoDB 4.0.

Dari MongoDB 4.0, baca operasi yang menargetkan sekunder dan dikonfigurasikan dengan tingkat perhatian baca “majority” atau “local” sekarang akan membaca dari cuplikan data WiredTiger jika pembacaan terjadi pada sekunder tempat kumpulan replikasi sedang diterapkan. Membaca dari snapshot menjamin tampilan data yang konsisten, dan memungkinkan pembacaan terjadi bersamaan dengan replikasi yang sedang berlangsung tanpa memerlukan kunci.

Oleh karena itu, pembacaan sekunder yang membutuhkan tingkat perhatian baca ini tidak perlu lagi menunggu batch replikasi diterapkan dan dapat ditangani saat diterima.

Cara Membuat Set Replika MongoDB

Seperti disebutkan sebelumnya, MongoDB menangani replikasi melalui kumpulan replika. Selama beberapa bagian berikutnya, kami akan menyoroti beberapa metode yang dapat Anda gunakan untuk membuat kumpulan replika untuk kasus penggunaan Anda.

Metode 1: Membuat Set Replika MongoDB Baru di Ubuntu

Sebelum kita mulai, Anda harus memastikan bahwa Anda memiliki setidaknya tiga server yang menjalankan Ubuntu 20.04, dengan MongoDB terpasang di setiap server.

Untuk menyiapkan kumpulan replika, penting untuk memberikan alamat tempat setiap anggota kumpulan replika dapat dijangkau oleh orang lain di kumpulan tersebut. Dalam hal ini, kami menyimpan tiga anggota di set. Meskipun kami dapat menggunakan alamat IP, itu tidak disarankan karena alamat dapat berubah secara tidak terduga. Alternatif yang lebih baik dapat menggunakan nama host DNS logis saat mengonfigurasi kumpulan replika.

Kita dapat melakukannya dengan mengonfigurasi subdomain untuk setiap anggota replikasi. Meskipun ini ideal untuk lingkungan produksi, bagian ini akan menguraikan cara mengonfigurasi resolusi DNS dengan mengedit file host masing-masing server. File ini memungkinkan kami menetapkan nama host yang dapat dibaca ke alamat IP numerik. Jadi, jika alamat IP Anda berubah, yang harus Anda lakukan adalah memperbarui file host di tiga server daripada mengkonfigurasi ulang replika yang disetel dari awal!

Sebagian besar, hosts disimpan di direktori /etc/ . Ulangi perintah di bawah ini untuk masing-masing dari ketiga server Anda:

 sudo nano /etc/hosts

Pada perintah di atas, kami menggunakan nano sebagai editor teks kami, namun Anda dapat menggunakan editor teks apa pun yang Anda sukai. Setelah beberapa baris pertama yang mengonfigurasi localhost, tambahkan entri untuk setiap anggota set replika. Entri ini berbentuk alamat IP diikuti dengan nama pilihan Anda yang dapat dibaca manusia. Meskipun Anda dapat memberi nama apa pun yang Anda suka, pastikan untuk deskriptif sehingga Anda tahu membedakan setiap anggota. Untuk tutorial ini, kami akan menggunakan nama host di bawah ini:

• mongo0.replset.member
• mongo1.replset.member
• mongo2.replset.member

Dengan menggunakan nama host ini, file /etc/hosts Anda akan terlihat mirip dengan baris yang disorot berikut:

Simpan dan tutup file.

Setelah mengonfigurasi resolusi DNS untuk kumpulan replika, kami perlu memperbarui aturan firewall agar mereka dapat berkomunikasi satu sama lain. Jalankan perintah ufw berikut pada mongo0 untuk menyediakan akses mongo1 ke port 27017 pada mongo0:

 sudo ufw allow from mongo1_server_ip to any port 27017

Di tempat parameter mongo1_server_ip , masukkan alamat IP aktual server mongo1 Anda. Selain itu, jika Anda telah memperbarui instans Mongo di server ini untuk menggunakan port non-default, pastikan untuk mengubah 27017 untuk mencerminkan port yang digunakan instans MongoDB Anda.

Sekarang tambahkan aturan firewall lain untuk memberikan akses mongo2 ke port yang sama:

 sudo ufw allow from mongo2_server_ip to any port 27017

Di tempat parameter mongo2_server_ip , masukkan alamat IP aktual server mongo2 Anda. Kemudian, perbarui aturan firewall untuk dua server Anda yang lain. Jalankan perintah berikut di server mongo1, pastikan untuk mengubah alamat IP di tempat parameter server_ip untuk mencerminkan masing-masing dari mongo0 dan mongo2:

 sudo ufw allow from mongo0_server_ip to any port 27017

 sudo ufw allow from mongo2_server_ip to any port 27017

Terakhir, jalankan kedua perintah ini di mongo2. Sekali lagi, pastikan Anda memasukkan alamat IP yang benar untuk setiap server:

 sudo ufw allow from mongo0_server_ip to any port 27017

 sudo ufw allow from mongo1_server_ip to any port 27017

Langkah Anda selanjutnya adalah memperbarui setiap file konfigurasi instans MongoDB untuk mengizinkan koneksi eksternal. Untuk mengizinkan ini, Anda perlu memodifikasi file konfigurasi di setiap server untuk mencerminkan alamat IP dan menunjukkan set replika. Meskipun Anda dapat menggunakan editor teks pilihan apa pun, kami menggunakan editor teks nano sekali lagi. Mari buat modifikasi berikut di setiap file mongod.conf.

Di mongo0:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo0.replset.member# replica set replication: replSetName: "rs0"

Di mongo1:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo1.replset.member replication: replSetName: "rs0"

Di mongo2:

 # network interfaces net: port: 27017 bindIp: 127.0.0.1,mongo2.replset.member replication: replSetName: "rs0"

 sudo systemctl restart mongod

Dengan ini, Anda telah mengaktifkan replikasi untuk setiap instance MongoDB server.

Anda sekarang dapat menginisialisasi set replika dengan menggunakan metode rs.initiate() . Metode ini hanya perlu dijalankan pada satu instance MongoDB dalam kumpulan replika. Pastikan replika mengatur nama dan anggota sesuai dengan konfigurasi yang Anda buat di setiap file konfigurasi sebelumnya.

 rs.initiate( { _id: "rs0", members: [ { _id: 0, host: "mongo0.replset.member" }, { _id: 1, host: "mongo1.replset.member" }, { _id: 2, host: "mongo2.replset.member" } ] })

Jika metode mengembalikan "ok": 1 dalam output, itu berarti set replika dimulai dengan benar. Di bawah ini adalah contoh tampilan output:

 { "ok": 1, "$clusterTime": { "clusterTime": Timestamp(1612389071, 1), "signature": { "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId": NumberLong(0) } }, "operationTime": Timestamp(1612389071, 1) }

Matikan Server MongoDB

Anda dapat mematikan server MongoDB dengan menggunakan metode db.shutdownServer() . Di bawah ini adalah sintaks untuk hal yang sama. force dan timeoutsecs adalah parameter opsional.

 db.shutdownServer({ force: <boolean>, timeoutSecs: <int> })

Metode ini mungkin gagal jika anggota kumpulan replika mongod menjalankan operasi tertentu saat pembuatan indeks. Untuk menghentikan operasi dan memaksa anggota untuk dimatikan, Anda dapat memasukkan force parameter boolean ke true.

Mulai ulang MongoDB Dengan –replSet

Untuk menyetel ulang konfigurasi, pastikan setiap simpul dalam kumpulan replika Anda dihentikan. Kemudian hapus database lokal untuk setiap node. Mulai lagi menggunakan flag –replSet dan jalankan rs.initiate() hanya pada satu instance mongod untuk set replika.

 mongod --replSet "rs0"

rs.initiate() dapat mengambil dokumen konfigurasi set replika opsional, yaitu:

• Opsi Replication.replSetName atau —replSet untuk menentukan nama kumpulan replika di bidang _id .
• Array anggota, yang berisi satu dokumen untuk setiap anggota kumpulan replika.

Metode rs.initiate() memicu pemilihan dan memilih salah satu anggota untuk menjadi yang utama.

Tambahkan Anggota ke Set Replika

Untuk menambahkan anggota ke set, mulai instance mongod di berbagai mesin. Selanjutnya, jalankan klien mongo dan gunakan perintah rs.add() .

Perintah rs.add() memiliki sintaks dasar berikut:

 rs.add(HOST_NAME:PORT)

Misalnya,

Asumsikan mongo1 adalah instance mongod Anda, dan sedang mendengarkan pada port 27017. Gunakan perintah klien Mongo rs.add() untuk menambahkan instance ini ke set replika.

 rs.add("mongo1:27017")

Hanya setelah Anda terhubung ke node utama, Anda dapat menambahkan instance mongod ke kumpulan replika. Untuk memverifikasi apakah Anda terhubung ke primer, gunakan perintah db.isMaster() .

Hapus Pengguna

Untuk menghapus anggota, kita bisa menggunakan rs.remove()

Untuk melakukannya, pertama-tama, matikan instance mongod yang ingin Anda hapus dengan menggunakan metode db.shutdownServer() yang telah kita bahas di atas.

Selanjutnya, hubungkan ke primer set replika saat ini. Untuk menentukan primer saat ini, gunakan db.hello() saat terhubung ke anggota set replika mana pun. Setelah Anda menentukan yang utama, jalankan salah satu dari perintah berikut:

 rs.remove("mongodb-node-04:27017") rs.remove("mongodb-node-04")

Jika set replika perlu memilih primer baru, MongoDB mungkin memutuskan sambungan shell sebentar. Dalam skenario ini, secara otomatis akan menyambung kembali sekali lagi. Juga, ini mungkin menampilkan kesalahan DBClientCursor::init call() failed meskipun perintah berhasil.

Metode 2: Mengonfigurasi Set Replika MongoDB untuk Penerapan dan Pengujian

Secara umum, Anda dapat menyiapkan kumpulan replika untuk pengujian dengan mengaktifkan atau menonaktifkan RBAC. Dalam metode ini, kami akan menyiapkan kumpulan replika dengan kontrol akses yang dinonaktifkan untuk menerapkannya di lingkungan pengujian.

Pertama, buat direktori untuk semua instance yang merupakan bagian dari kumpulan replika menggunakan perintah berikut:

 mkdir -p /srv/mongodb/replicaset0-0 /srv/mongodb/replicaset0-1 /srv/mongodb/replicaset0-2

Perintah ini akan membuat direktori untuk tiga instance MongoDB replicaset0-0, replicaset0-1, dan replicaset0-2. Sekarang, mulai instance MongoDB untuk masing-masing menggunakan set perintah berikut:

Untuk Server 1:

 mongod --replSet replicaset --port 27017 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Untuk Server 2:

 mongod --replSet replicaset --port 27018 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Untuk Server 3:

 mongod --replSet replicaset --port 27019 --bind_ip localhost,<hostname(s)|ip address(es)> --dbpath /srv/mongodb/replicaset0-0 --oplogSize 128

Parameter –oplogSize digunakan untuk mencegah mesin kelebihan beban selama fase pengujian. Ini membantu mengurangi jumlah ruang disk yang dikonsumsi setiap disk.

Sekarang, sambungkan ke salah satu instance menggunakan shell Mongo dengan menghubungkan menggunakan nomor port di bawah ini.

 mongo --port 27017

Kita dapat menggunakan perintah rs.initiate() untuk memulai proses replikasi. Anda harus mengganti parameter hostname dengan nama sistem Anda.

 rs conf = { _id: "replicaset0", members: [ { _id: 0, host: "<hostname>:27017}, { _id: 1, host: "<hostname>:27018"}, { _id: 2, host: "<hostname>:27019"} ] }

Anda sekarang dapat mengirimkan file objek konfigurasi sebagai parameter untuk perintah inisiasi dan menggunakannya sebagai berikut:

 rs.initiate(rsconf)

Dan begitulah! Anda telah berhasil membuat kumpulan replika MongoDB untuk tujuan pengembangan dan pengujian.

Metode 3: Mengubah Instans Mandiri menjadi Kumpulan Replika MongoDB

MongoDB memungkinkan penggunanya untuk mengubah instans mandiri mereka menjadi set replika. Sementara instans mandiri sebagian besar digunakan untuk fase pengujian dan pengembangan, kumpulan replika adalah bagian dari lingkungan produksi.

Untuk memulai, mari matikan instance mongod kita menggunakan perintah berikut:

 db.adminCommand({"shutdown":"1"})

Mulai ulang instans Anda dengan menggunakan parameter –repelSet di perintah Anda untuk menentukan kumpulan replika yang akan Anda gunakan:

 mongod --port 27017 – dbpath /var/lib/mongodb --replSet replicaSet1 --bind_ip localhost,<hostname(s)|ip address(es)>

Anda harus menentukan nama server Anda bersama dengan alamat unik dalam perintah.

Hubungkan shell dengan instans MongoDB Anda dan gunakan perintah inisiasi untuk memulai proses replikasi dan berhasil mengonversi instans menjadi set replika. Anda dapat melakukan semua operasi dasar seperti menambahkan atau menghapus instance menggunakan perintah berikut:

 rs.add(“<host_name:port>”)

 rs.remove(“host-name”)

Selain itu, Anda dapat memeriksa status kumpulan replika MongoDB menggunakan perintah rs.status() dan rs.conf() .

Metode 4: MongoDB Atlas — Alternatif yang Lebih Sederhana

Replikasi dan sharding dapat bekerja sama untuk membentuk sesuatu yang disebut cluster sharded. Meskipun penyiapan dan konfigurasi dapat memakan waktu cukup lama meskipun mudah, MongoDB Atlas adalah alternatif yang lebih baik daripada metode yang disebutkan sebelumnya.

Ini mengotomatiskan set replika Anda, membuat prosesnya mudah diterapkan. Itu dapat menerapkan set replika yang dipecah secara global dengan beberapa klik, memungkinkan pemulihan bencana, manajemen yang lebih mudah, lokalitas data, dan penerapan multi-region.

Di MongoDB Atlas, kita perlu membuat kluster – kluster bisa berupa kumpulan replika, atau kluster pecahan. Untuk proyek tertentu, jumlah node dalam cluster di wilayah lain dibatasi hingga total 40.

Ini tidak termasuk cluster gratis atau bersama dan wilayah cloud Google yang berkomunikasi satu sama lain. Jumlah total node antara dua wilayah mana pun harus memenuhi batasan ini. Misalnya, jika ada proyek di mana:

• Wilayah A memiliki 15 node.
• Wilayah B memiliki 25 node
• Wilayah C memiliki 10 node

Kami hanya dapat mengalokasikan 5 node lagi ke wilayah C sebagai,

1. Wilayah A+ Wilayah B = 40; memenuhi batasan 40 sebagai jumlah maksimum node yang diizinkan.
2. Wilayah B+ Wilayah C = 25+10+5 (Simpul tambahan dialokasikan ke C) = 40; memenuhi batasan 40 sebagai jumlah maksimum node yang diizinkan.
3. Wilayah A+ Wilayah C =15+10+5 (Simpul tambahan dialokasikan ke C) = 30; memenuhi batasan 40 sebagai jumlah maksimum node yang diizinkan.

Jika kita mengalokasikan 10 node lagi ke region C, membuat region C memiliki 20 node, maka Region B + Region C = 45 node. Ini akan melebihi batasan yang diberikan, sehingga Anda mungkin tidak dapat membuat cluster multi-region.

Saat Anda membuat klaster, Atlas membuat wadah jaringan dalam proyek untuk penyedia awan jika sebelumnya tidak ada. Untuk membuat cluster kumpulan replika di MongoDB Atlas, jalankan perintah berikut di Atlas CLI:

 atlas clusters create [name] [options]

Pastikan Anda memberikan nama cluster yang deskriptif, karena tidak dapat diubah setelah cluster dibuat. Argumen dapat berisi huruf, angka, dan tanda hubung ASCII.

Ada beberapa opsi yang tersedia untuk pembuatan klaster di MongoDB berdasarkan kebutuhan Anda. Misalnya, jika Anda ingin pencadangan cloud berkelanjutan untuk klaster Anda, setel --backup ke true.

Menangani Penundaan Replikasi

Penundaan replikasi mungkin cukup mengecewakan. Ini adalah penundaan antara operasi pada primer dan penerapan operasi itu dari oplog ke sekunder. Jika bisnis Anda berurusan dengan kumpulan data besar, penundaan akan terjadi dalam batas tertentu. Namun, terkadang faktor eksternal juga dapat berkontribusi dan meningkatkan keterlambatan. Untuk mendapatkan manfaat dari replikasi terbaru, pastikan bahwa:

1. Anda merutekan lalu lintas jaringan Anda dalam bandwidth yang stabil dan memadai. Latensi jaringan berperan besar dalam memengaruhi replikasi Anda, dan jika jaringan tidak cukup untuk memenuhi kebutuhan proses replikasi, akan ada penundaan dalam mereplikasi data di seluruh rangkaian replika.
2. Anda memiliki throughput disk yang memadai. Jika sistem file dan perangkat disk pada sekunder tidak dapat mengalirkan data ke disk secepat primer, maka sekunder akan mengalami kesulitan mengikuti. Oleh karena itu, node sekunder memproses permintaan tulis lebih lambat dari node utama. Ini adalah masalah umum di sebagian besar sistem multi-penyewa, termasuk instans virtual dan penerapan skala besar.
3. Anda meminta masalah tulis pengakuan tulis setelah selang waktu untuk memberikan kesempatan bagi sekunder untuk mengejar primer, terutama ketika Anda ingin melakukan operasi pemuatan massal atau penyerapan data yang memerlukan sejumlah besar penulisan ke primer. Sekunder tidak akan dapat membaca oplog dengan cukup cepat untuk mengikuti perubahan; terutama dengan masalah menulis yang tidak diakui.
4. Anda mengidentifikasi tugas latar belakang yang sedang berjalan. Tugas tertentu seperti tugas cron, pembaruan server, dan pemeriksaan keamanan mungkin memiliki efek yang tidak terduga pada penggunaan jaringan atau disk, menyebabkan keterlambatan dalam proses replikasi.

Jika Anda tidak yakin apakah ada kelambatan replikasi dalam aplikasi Anda, jangan khawatir – bagian selanjutnya membahas strategi pemecahan masalah!

Pemecahan Masalah Set Replika MongoDB

Anda telah berhasil menyiapkan kumpulan replika, tetapi Anda melihat data Anda tidak konsisten di seluruh server. Ini sangat mengkhawatirkan untuk bisnis berskala besar, namun, dengan metode pemecahan masalah yang cepat, Anda dapat menemukan penyebabnya atau bahkan memperbaiki masalahnya! Diberikan di bawah ini adalah beberapa strategi umum untuk memecahkan masalah penerapan kumpulan replika yang dapat berguna:

Periksa Status Replika

Kita dapat memeriksa status set replika saat ini dan status setiap anggota dengan menjalankan perintah berikut dalam sesi mongosh yang terhubung ke set replika utama.

 rs.status()

Periksa Lag Replikasi

Seperti yang telah dibahas sebelumnya, kelambatan replikasi dapat menjadi masalah serius karena membuat anggota yang "terlambat" tidak memenuhi syarat untuk segera menjadi yang utama dan meningkatkan kemungkinan bahwa operasi baca terdistribusi akan menjadi tidak konsisten. Kita dapat memeriksa panjang log replikasi saat ini dengan menggunakan perintah berikut:

 rs.printSecondaryReplicationInfo()

Ini mengembalikan nilai syncedTo yang merupakan waktu ketika entri oplog terakhir ditulis ke sekunder untuk setiap anggota. Berikut adalah contoh untuk menunjukkan hal yang sama:

 source: m1.example.net:27017 syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Mon Oct 10 2022 10:19:35 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary

Anggota yang tertunda dapat ditampilkan sebagai 0 detik di belakang yang utama ketika periode tidak aktif pada yang utama lebih besar dari nilai members[n].secondaryDelaySecs .

Tes Koneksi Antara Semua Anggota

Setiap anggota dari kumpulan replika harus dapat terhubung dengan setiap anggota lainnya. Selalu pastikan untuk memverifikasi koneksi di kedua arah. Sebagian besar, konfigurasi firewall atau topologi jaringan mencegah konektivitas normal dan diperlukan yang dapat memblokir replikasi.

Misalnya, mari kita asumsikan bahwa instance mongod mengikat localhost dan nama host 'ExampleHostname' yang dikaitkan dengan Alamat IP 198.41.110.1:

 mongod --bind_ip localhost, ExampleHostname

Untuk terhubung ke instance ini, klien jarak jauh harus menentukan nama host atau Alamat IP:

 mongosh --host ExampleHostname mongosh --host 198.41.110.1

Jika set replika terdiri dari tiga anggota, m1, m2, dan m3, menggunakan port default 27017, Anda harus menguji koneksi seperti di bawah ini:

Pada m1:

 mongosh --host m2 --port 27017 mongosh --host m3 --port 27017

Pada m2:

 mongosh --host m1 --port 27017 mongosh --host m3 --port 27017

Pada m3:

 mongosh --host m1 --port 27017 mongosh --host m2 --port 27017

Jika koneksi ke segala arah gagal, Anda harus memeriksa konfigurasi firewall Anda dan mengonfigurasi ulang untuk mengizinkan koneksi.

Memastikan Komunikasi Aman Dengan Otentikasi Keyfile

Secara default, autentikasi keyfile di MongoDB bergantung pada mekanisme salted challenge response authentication (SCRAM). Untuk melakukan ini, MongoDB harus membaca dan memvalidasi kredensial yang disediakan pengguna yang menyertakan kombinasi nama pengguna, kata sandi, dan database autentikasi yang diketahui oleh instance MongoDB tertentu. Ini adalah mekanisme persis yang digunakan untuk mengotentikasi pengguna yang memberikan kata sandi saat terhubung ke database.

Saat Anda mengaktifkan autentikasi di MongoDB, Kontrol Akses Berbasis Peran (RBAC) secara otomatis diaktifkan untuk kumpulan replika, dan pengguna diberikan satu atau beberapa peran yang menentukan akses mereka ke sumber daya database. Ketika RBAC diaktifkan, itu berarti hanya pengguna Mongo terotentikasi yang valid dengan hak istimewa yang sesuai yang dapat mengakses sumber daya pada sistem.

File kunci bertindak seperti kata sandi bersama untuk setiap anggota di kluster. Ini memungkinkan setiap instance mongod dalam kumpulan replika untuk menggunakan konten keyfile sebagai kata sandi bersama untuk mengautentikasi anggota lain dalam penerapan.

Hanya instance mongod dengan keyfile yang benar yang dapat bergabung dengan kumpulan replika. Panjang kunci harus antara 6 dan 1024 karakter dan hanya boleh berisi karakter dalam set base64. Harap perhatikan bahwa MongoDB menghapus karakter spasi saat membaca kunci.

Anda dapat menghasilkan keyfile dengan menggunakan berbagai metode. Dalam tutorial ini, kami menggunakan openssl untuk menghasilkan string karakter acak 1024 yang kompleks untuk digunakan sebagai kata sandi bersama. Itu kemudian menggunakan chmod untuk mengubah izin file untuk memberikan izin baca hanya untuk pemilik file. Avoid storing the keyfile on storage mediums that can be easily disconnected from the hardware hosting the mongod instances, such as a USB drive or a network-attached storage device. Below is the command to generate a keyfile:

 openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>

Next, copy the keyfile to each replica set member . Make sure that the user running the mongod instances is the owner of the file and can access the keyfile. After you've done the above, shut down all members of the replica set starting with the secondaries. Once all the secondaries are offline, you may go ahead and shut down the primary. It's essential to follow this order so as to prevent potential rollbacks. Now shut down the mongod instance by running the following command:

 use admin db.shutdownServer()

After the command is run, all members of the replica set will be offline. Now, restart each member of the replica set with access control enabled .

For each member of the replica set, start the mongod instance with either the security.keyFile configuration file setting or the --keyFile command-line option.

If you're using a configuration file, set

• security.keyFile to the keyfile's path, and
• replication.replSetName to the replica set name.

 security: keyFile: <path-to-keyfile> replication: replSetName: <replicaSetName> net: bindIp: localhost,<hostname(s)|ip address(es)>

Start the mongod instance using the configuration file:

 mongod --config <path-to-config-file>

If you're using the command line options, start the mongod instance with the following options:

• –keyFile set to the keyfile's path, and
• –replSet set to the replica set name.

 mongod --keyFile <path-to-keyfile> --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>

You can include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the –bind_ip. For more information, see Localhost Binding Compatibility Changes.

Next, connect to a member of the replica set over the localhost interface . You must run mongosh on the same physical machine as the mongod instance. This interface is only available when no users have been created for the deployment and automatically closes after the creation of the first user.

We then initiate the replica set. From mongosh, run the rs.initiate() method:

 rs.initiate( { _id: "myReplSet", members: [ { _id: 0, host: "mongo1:27017" }, { _id: 1, host: "mongo2:27017" }, { _id: 2, host: "mongo3:27017" } ] } )

As discussed before, this method elects one of the members to be the primary member of the replica set. To locate the primary member, use rs.status() . Connect to the primary before continuing.

Now, create the user administrator . You can add a user using the db.createUser() method. Make sure that the user should have at least the userAdminAnyDatabase role on the admin database.

The following example creates the user 'batman' with the userAdminAnyDatabase role on the admin database:

 admin = db.getSiblingDB("admin") admin.createUser( { user: "batman", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )

Enter the password that was created earlier when prompted.

Next, you must authenticate as the user administrator . To do so, use db.auth() to authenticate. Misalnya:

db.getSiblingDB(“admin”).auth(“batman”, passwordPrompt()) // or cleartext password

Alternatively, you can connect a new mongosh instance to the primary replica set member using the -u <username> , -p <password> , and the --authenticationDatabase parameters.

 mongosh -u "batman" -p --authenticationDatabase "admin"

Even if you do not specify the password in the -p command-line field, mongosh prompts for the password.

Lastly, create the cluster administrator . The clusterAdmin role grants access to replication operations, such as configuring the replica set.

Let's create a cluster administrator user and assign the clusterAdmin role in the admin database:

 db.getSiblingDB("admin").createUser( { "user": "robin", "pwd": passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )

Enter the password when prompted.

If you wish to, you may create additional users to allow clients and interact with the replica set.

And voila! You have successfully enabled keyfile authentication!

Ringkasan

Replication has been an essential requirement when it comes to databases, especially as more businesses scale up. It widely improves the performance, data security, and availability of the system. Speaking of performance, it is pivotal for your WordPress database to monitor performance issues and rectify them in the nick of time, for instance, with Kinsta APM, Jetpack, and Freshping to name a few.

Replication helps ensure data protection across multiple servers and prevents your servers from suffering from heavy downtime(or even worse – losing your data entirely). In this article, we covered the creation of a replica set and some troubleshooting tips along with the importance of replication. Do you use MongoDB replication for your business and has it proven to be useful to you? Let us know in the comment section below!