全部产品
Search
文档中心

ApsaraDB for MongoDB:Cara kerja replica set di MongoDB

更新时间:Jun 27, 2025

Replica set dalam ApsaraDB for MongoDB terdiri dari beberapa proses mongod yang mencakup node utama dan beberapa node sekunder. Driver MongoDB hanya menulis data ke node utama, kemudian data disinkronkan ke node sekunder untuk memastikan konsistensi data di seluruh replica set. Dengan demikian, replica set menyediakan ketersediaan tinggi.

Gambar berikut diambil dari dokumentasi resmi MongoDB dan menggambarkan replica set MongoDB tipikal dengan satu node utama dan dua node sekunder.

Pemilihan node utama (1)

Replica set diinisialisasi dengan menjalankan perintah replSetInitiate atau menggunakan perintah rs.initiate() di mongo shell. Setelah inisialisasi, anggota saling bertukar pesan detak jantung dan memulai pemilihan node utama. Node yang menerima suara mayoritas menjadi node utama, sementara node lainnya menjadi node sekunder.

Inisialisasi Replica Set

    config = {
        _id : "my_replica_set",
        members : [
             {_id : 0, host : "rs1.example.net:27017"},
             {_id : 1, host : "rs2.example.net:27017"},
             {_id : 2, host : "rs3.example.net:27017"},
       ]
    }
    rs.initiate(config)

Definisi Mayoritas

Mayoritas didefinisikan sebagai sekelompok anggota pemilih yang mencakup lebih dari separuh jumlah total anggota. Jika jumlah anggota tidak melebihi rata-rata semua anggota pemilih, pemilihan tidak dapat dilakukan, sehingga penulisan data ke replica set tidak dimungkinkan.

Jumlah anggota pemilih

Mayoritas

Jumlah maksimum node gagal

1

1

0

2

2

0

3

2

1

4

3

1

5

3

2

6

4

2

7

4

3

Disarankan untuk mengatur jumlah anggota replica set menjadi angka ganjil. Tabel di atas menunjukkan bahwa baik replica set dengan tiga node maupun dengan empat node dapat mentolerir kegagalan satu node, memberikan ketersediaan layanan yang sama. Namun, replica set dengan empat node menawarkan penyimpanan data yang lebih andal.

Node sekunder khusus

Node sekunder dalam replica set berpartisipasi dalam pemilihan node utama dan dapat terpilih sebagai node utama. Data terbaru dari node utama disinkronkan ke node sekunder untuk memastikan konsistensi data di seluruh node.

Anda dapat membaca data dari node sekunder, sehingga menambahkan node sekunder dapat meningkatkan performa baca dan ketersediaan layanan replica set. ApsaraDB for MongoDB memungkinkan konfigurasi node sekunder untuk memenuhi persyaratan skenario yang berbeda.

  • Arbiter

    Node arbiter hanya berperan sebagai pemilih dalam pemilihan dan tidak dapat dipilih sebagai node utama atau mensinkronkan data dari node utama.

    Misalnya, jika Anda memiliki replica set dengan satu node utama dan satu node sekunder, kegagalan salah satu node akan mencegah pemilihan node utama baru, membuat replica set tidak tersedia. Menambahkan node arbiter memungkinkan pemilihan tetap berlangsung.

    Node arbiter adalah node ringan yang tidak menyimpan data. Jika jumlah anggota replica set genap, disarankan untuk menambahkan node arbiter guna meningkatkan ketersediaan replica set.

  • Priority0

    Node dengan prioritas 0 tidak dapat dipilih sebagai node utama.

    Misalnya, jika Anda memiliki replica set dengan node di Pusat Data A dan Pusat Data B, atur prioritas anggota di Pusat Data B menjadi 0 untuk memastikan node utama terpilih berada di Pusat Data A.

    Catatan

    Jika prioritas anggota di Pusat Data B diatur menjadi 0, pastikan mayoritas node replica set berada di Pusat Data A. Jika tidak, pemilihan node utama mungkin gagal selama pemisahan jaringan.

  • Vote0

    Di MongoDB 3.0, replica set dapat memiliki maksimal 50 anggota, tetapi hanya tujuh anggota yang dapat memilih dalam pemilihan node utama. Atur atribut members[n].votes menjadi 0 untuk anggota yang tidak diharapkan untuk memilih.

  • Hidden

    Anggota tersembunyi dalam replica set tidak dapat dipilih sebagai node utama karena prioritasnya adalah 0 dan tidak terlihat oleh driver MongoDB.

    Node tersembunyi dapat digunakan untuk pencadangan data atau tugas komputasi offline tanpa memengaruhi layanan replica set karena tidak menangani permintaan dari driver MongoDB.

  • Delayed

    Node tertunda harus berupa node tersembunyi. Data pada node ini mencerminkan status data sebelumnya pada node utama. Misalnya, jika dikonfigurasi dengan penundaan satu jam, data pada node tertunda sama dengan data pada node utama satu jam sebelumnya.

    Jika data salah atau tidak valid ditulis ke node utama, Anda dapat menggunakan data pada node tertunda untuk mengembalikan data ke status sebelumnya.

Pemilihan node utama (2)

Pemilihan node utama tidak hanya terjadi setelah inisialisasi replica set, tetapi juga dalam skenario berikut:

  • Rekonfigurasi Replica Set

    Pemilihan dipicu jika node utama gagal atau turun jabatan secara sukarela menjadi node sekunder. Faktor-faktor seperti pesan detak jantung antar node, prioritas node, dan waktu entri oplog terakhir memengaruhi pemilihan.

    • Prioritas Node

      Semua node cenderung memilih node dengan prioritas tertinggi. Node dengan prioritas 0 tidak dapat memicu pemilihan. Jika node sekunder memiliki prioritas lebih tinggi daripada node utama dan selisih waktu entri log terbaru kurang dari 10 detik, node utama turun jabatan, dan node sekunder tersebut menjadi kandidat node utama.

    • Optime

      Hanya node sekunder dengan entri oplog terbaru yang memenuhi syarat untuk dipilih sebagai node utama.

  • Pemisahan Jaringan

    Hanya node yang terhubung ke mayoritas node pemilih yang dapat dipilih sebagai node utama. Jika node utama terputus dari mayoritas node, ia turun jabatan menjadi node sekunder. Selama pemisahan jaringan, replica set mungkin memiliki beberapa node utama sementara. Saat menulis data, disarankan untuk mengatur kebijakan yang hanya mengizinkan sinkronisasi data dari node utama yang terhubung ke mayoritas node.

Sinkronisasi data

Data disinkronkan dari node utama ke node sekunder berdasarkan oplog. Setelah operasi tulis selesai pada node utama, entri oplog ditulis ke koleksi khusus local.oplog.rs. Node sekunder terus mengimpor entri oplog baru dari node utama dan menerapkan operasi tersebut.

Untuk mencegah pertumbuhan tak terbatas ukuran oplog, local.oplog.rs dikonfigurasi sebagai koleksi capped. Ketika ukuran oplog mencapai ambang batas, entri paling awal dihapus. Semua operasi dalam oplog bersifat idempoten, memastikan hasil yang sama meskipun diterapkan berulang kali.

Berikut adalah contoh entri oplog yang berisi bidang seperti ts, h, op, ns, dan o:

    {
      "ts" : Timestamp(1446011584, 2),
      "h" : NumberLong("1687359108795812092"), 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 
    }
  • ts: Waktu operasi dilakukan, terdiri dari dua angka. Angka pertama adalah timestamp UNIX, dan angka kedua adalah penghitung operasi dalam satu detik.

  • h: Pengenal unik operasi.

  • v: Versi oplog.

  • op: Jenis operasi.

    • i: Sisipkan.

    • u: Perbarui.

    • d: Hapus.

    • c: Jalankan perintah seperti createDatabase dan dropDatabase.

    • n: Null, digunakan untuk tujuan khusus.

  • ns: Koleksi tempat operasi dilakukan.

  • o: Detail operasi.

  • o2: Kondisi operasi pembaruan, valid hanya untuk operasi pembaruan.

Selama sinkronisasi awal, node sekunder menjalankan perintah init sync untuk menyinkronkan semua data dari node utama atau node sekunder lainnya dengan data terbaru. Kemudian, node sekunder menggunakan fitur tailable cursor untuk menanyakan entri oplog terbaru dalam koleksi local.oplog.rs dari node utama dan menerapkan operasi tersebut.

Proses sinkronisasi awal melibatkan langkah-langkah berikut:

  1. Sebelum waktu T1, alat sinkronisasi data menjalankan perintah listDatabases, listCollections, dan cloneCollection. Pada waktu T1, semua data dalam database cloud (kecuali database local.oplog.rs) mulai disinkronkan dari node utama ke node sekunder. Sinkronisasi selesai pada waktu T2.

  2. Semua operasi dalam entri oplog yang dihasilkan dari T1 hingga T2 diterapkan ke node sekunder. Operasi dalam entri oplog bersifat idempoten, sehingga operasi yang telah diterapkan dapat diterapkan kembali.

  3. Berdasarkan indeks untuk setiap koleksi pada node utama, indeks untuk koleksi yang sesuai dibuat pada node sekunder.

    Catatan

    Ukuran oplog harus dikonfigurasi berdasarkan ukuran database dan volume data yang akan ditulis oleh aplikasi. Jika oplog terlalu besar, ruang penyimpanan mungkin terbuang. Jika terlalu kecil, node sekunder mungkin gagal menyelesaikan sinkronisasi awal. Misalnya, jika database menyimpan banyak data dan oplog tidak cukup besar, oplog mungkin gagal menyimpan semua entri oplog yang dihasilkan dari T1 hingga T2, sehingga node sekunder tidak dapat menyinkronkan semua data dari node utama.

Modifikasi Replica Set

Anda dapat memodifikasi replica set dengan menjalankan perintah replSetReconfig atau perintah rs.reconfig() di mongo shell. Contohnya, Anda dapat menambahkan atau menghapus anggota, serta mengubah prioritas, suara, tersembunyi, dan atribut tertunda dari anggota.

Contohnya, Anda dapat menjalankan perintah berikut untuk mengatur prioritas anggota kedua dalam replica set menjadi 2:

    cfg = rs.conf();
    cfg.members[1].priority = 2;
    rs.reconfig(cfg);

Mengembalikan Operasi pada Node Utama

Jika node utama replica set gagal dan operasi tulis telah dilakukan pada node utama baru ketika node utama sebelumnya bergabung kembali, node utama sebelumnya harus mengembalikan operasi yang belum disinkronkan untuk memastikan konsistensi data.

Node utama sebelumnya menulis data pengembalian ke direktori khusus, memungkinkan administrator basis data menjalankan perintah mongorestore untuk mengembalikan operasi sesuai kebutuhan.

Pengaturan baca/tulis replica set

  • Preferensi Baca

    Secara default, semua permintaan baca untuk replica set diarahkan ke node utama. Namun, Anda dapat memodifikasi mode preferensi baca pada driver untuk mengarahkan permintaan baca ke node lain.

    • primary: Mode default, semua permintaan baca diarahkan ke node utama.

    • primaryPreferred: Permintaan baca diarahkan ke node utama secara preferensial. Jika node utama tidak tersedia, permintaan baca diarahkan ke node sekunder.

    • secondary: Semua permintaan baca diarahkan ke node sekunder.

    • secondaryPreferred: Permintaan baca diarahkan ke node sekunder secara preferensial. Jika semua node sekunder tidak tersedia, permintaan baca diarahkan ke node utama.

    • nearest: Permintaan baca diarahkan ke node terdekat yang dapat dijangkau, yang dapat dideteksi dengan menjalankan perintah ping.

  • Tingkat Kepedulian Tulis

    Secara default, node utama mengembalikan pesan keberhasilan setelah data ditulis ke node utama. Anda dapat mengatur tingkat kepedulian tulis pada driver untuk menentukan aturan keberhasilan operasi tulis. Untuk informasi lebih lanjut, lihat Tingkat Kepedulian Tulis.

    Tingkat kepedulian tulis berikut menunjukkan bahwa operasi tulis berhasil hanya setelah data ditulis ke mayoritas node sebelum permintaan habis waktu. Periode timeout adalah lima detik.

        db.products.insert(
          { item: "envelopes", qty : 100, type: "Clasp" },
          { writeConcern: { w: "majority", wtimeout: 5000 } }
        )

    Pengaturan sebelumnya berlaku untuk permintaan individu. Anda juga dapat memodifikasi tingkat kepedulian tulis default dari replica set, yang berlaku untuk semua permintaan.

        cfg = rs.conf()
        cfg.settings = {}
        cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }
        rs.reconfig(cfg)