ApsaraDB for MongoDB:Cara kerja replica set MongoDB

Pemilihan primary

Replica set diinisialisasi menggunakan replSetInitiate atau rs.initiate(). Setelah inisialisasi, anggota saling bertukar heartbeat dan memilih satu primary. Node yang menerima mayoritas suara menjadi primary; yang lainnya menjadi secondary.

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"

Untuk N anggota yang memiliki hak suara, mayoritas sama dengan N/2 + 1. Jika jumlah anggota aktif kurang dari mayoritas, replica set tidak dapat memilih primary dan menjadi read-only.

Gunakan jumlah anggota ganjil. Replica set dengan tiga node dan empat node sama-sama hanya dapat mentoleransi satu kegagalan, tetapi empat node menyediakan penyimpanan data yang lebih andal.

Node secondary khusus

Secara default, secondary berpartisipasi dalam pemilihan, dapat menjadi primary, dan menyinkronkan data dari primary untuk mempertahankan set data yang identik.

Secondary dapat melayani permintaan baca untuk meningkatkan kapasitas baca. MongoDB mendukung beberapa jenis secondary khusus untuk skenario berbeda.

• Arbiter

  Arbiter hanya memberikan suara dalam pemilihan. Arbiter tidak dapat menjadi primary dan tidak menyimpan data.

  Pada replica set dua node, jika salah satu node mati, tidak ada primary yang dapat dipilih. Menambahkan arbiter memungkinkan pemilihan berhasil meskipun satu node pembawa data tidak tersedia.

  Karena arbiter ringan (tidak menyimpan data), arbiter ideal untuk replica set dengan jumlah anggota genap.

• Priority0

  Node priority 0 tidak dapat dipilih sebagai primary.

  Misalnya, pada penerapan multi-datacenter, atur prioritas anggota di datacenter B ke 0 agar primary selalu berada di datacenter A.

  Catatan

  Mayoritas node harus berada di datacenter A. Jika tidak, tidak ada primary yang dapat dipilih selama partisi jaringan.

• Vote 0

  Pada MongoDB 3.0, replica set mendukung hingga 50 anggota, tetapi hanya tujuh yang dapat memberikan suara. Anggota non-pemilih (Vote0) harus memiliki properti `vote` diatur ke 0.

• Hidden

  Node hidden memiliki prioritas 0 dan tidak terlihat oleh driver.

  Node hidden ideal untuk cadangan data atau komputasi offline karena tidak melayani permintaan client.

• Delayed

  Node delayed adalah node hidden yang datanya tertinggal dari primary dalam periode yang dapat dikonfigurasi, misalnya satu jam.

  Node delayed memungkinkan pemulihan pada titik waktu jika data yang salah ditulis ke primary.

Pemilihan ulang primer

Selain saat inisialisasi, pemilihan ulang primary terjadi dalam skenario berikut:

• Rekonfigurasi replica set

  Pemilihan ulang dipicu ketika secondary mendeteksi primary mati, atau ketika primary secara sukarela mundur. Hasilnya bergantung pada heartbeat, prioritas, dan waktu oplog terbaru.

  • Prioritas node

    Node memberikan suara kepada kandidat dengan prioritas tertinggi. Node priority-0 tidak pernah memulai pemilihan. Jika primary menemukan secondary dengan prioritas lebih tinggi yang keterlambatan datanya kurang dari 10 detik, primary akan mundur agar secondary tersebut mengambil alih.

  • Optime

    Hanya node dengan optime terbaru (stempel waktu entri oplog terbaru) yang dapat dipilih sebagai primary.

• Partisi jaringan

  Node hanya dapat menjadi primary jika terhubung ke mayoritas node yang memiliki hak suara. Jika primary kehilangan koneksi ke mayoritas, primary akan mundur menjadi secondary. Selama partisi jaringan, beberapa primary mungkin sementara berada dalam keadaan aktif bersamaan. Atur write concern ke majority untuk memastikan hanya satu primary yang dapat menyelesaikan operasi tulis secara berhasil.

Sinkronisasi data

Sinkronisasi data dari primary ke secondary menggunakan oplog. Setiap operasi tulis pada primary membuat entri di koleksi `local.oplog.rs`. Secondary terus-menerus mengambil dan menerapkan entri oplog baru.

Koleksi `local.oplog.rs` bersifat capped: ketika mencapai batas ukurannya, entri terlama dihapus. Entri oplog bersifat idempoten — menerapkan ulang operasi menghasilkan hasil yang sama — karena entri tersebut mungkin diterapkan beberapa kali pada secondary.

Entri oplog memiliki format berikut:

    {
      "ts" : Timestamp(1446011584, 2),
      "h" : NumberLong("1687359108795812092"), 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 
    }

Secondary melakukan sinkronisasi awal (init sync) saat pertama kali bergabung, menyalin seluruh set data dari primary atau secondary yang lebih mutakhir. Setelah itu, secondary menggunakan tailable cursor untuk terus-menerus mengambil dan menerapkan entri oplog baru dari koleksi `local.oplog.rs` pada node primary.

Proses `init sync` adalah sebagai berikut:

1. Pada T1, secondary menyalin semua database (kecuali `local`) dari primary menggunakan listDatabases, listCollections, dan cloneCollection. Asumsikan semua operasi selesai pada T2.

2. Secondary menerapkan semua entri oplog yang dihasilkan antara T1 dan T2. Beberapa mungkin tumpang tindih dengan Langkah 1, tetapi penerapan ulang aman karena entri oplog bersifat idempoten.

3. Secondary membuat indeks berdasarkan pengaturan indeks primary. Indeks `_id` untuk setiap koleksi sudah dibuat pada Langkah 1.

   Catatan

   Atur ukuran oplog berdasarkan ukuran database dan volume tulis Anda. Jika oplog terlalu besar, ruang penyimpanan terbuang sia-sia. Jika terlalu kecil, `init sync` mungkin tidak pernah selesai — jika database besar, oplog mungkin tidak menyimpan semua entri antara T1 dan T2, sehingga menyebabkan kegagalan sinkronisasi.

Ubah konfigurasi replica set

Untuk menambah atau menghapus anggota, atau mengubah properti seperti `priority`, `vote`, `hidden`, atau `delayed`, gunakan replSetReconfig atau rs.reconfig().

Misalnya, untuk mengatur prioritas anggota kedua menjadi 2:

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

Penanganan Error (Rollback)

Jika primary mati dengan data yang belum tersinkronisasi dan operasi tulis terjadi pada primary baru sebelum primary lama terhubung kembali, primary lama melakukan rollback terhadap operasi yang belum tersinkronisasi agar sesuai dengan set data primary baru.

Data yang di-rollback disimpan ke direktori rollback. Administrator dapat memulihkannya menggunakan mongorestore jika diperlukan.

Pengaturan baca dan tulis

• Read Preference

  Secara default, semua operasi baca diarahkan ke primary. Konfigurasikan read preference di driver untuk mengarahkan baca ke node lain.

  • primary: Mode default. Semua baca diarahkan ke primary.

  • primaryPreferred: Membaca dari primary; fallback ke secondary jika primary tidak dapat dijangkau.

  • secondary: Semua baca diarahkan ke secondary.

  • secondaryPreferred: Membaca dari secondary; fallback ke primary jika semua secondary tidak dapat dijangkau.

  • nearest: Membaca dari node yang paling dekat, ditentukan berdasarkan latensi ping.

• Write Concern

  Secara default, primary mengembalikan respons setelah menyelesaikan operasi tulis. Konfigurasikan Write Concern di driver untuk menentukan aturan keberhasilan operasi tulis.

  Contoh berikut mengharuskan operasi tulis berhasil pada mayoritas node dalam waktu 5 detik.

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

  Metode di atas berlaku untuk satu permintaan. Untuk mengatur write concern default untuk seluruh replica set:

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