ApsaraDB for MongoDB:Transaksi dan Read/Write Concern

Informasi dasar

API transaksi MongoDB mirip dengan yang ada di database relasional, sehingga kurva pembelajarannya minimal.

Contoh berikut menunjukkan transaksi lengkap dengan API startTransaction/abortTransaction/commitTransaction, serta pengaturan session dan readConcern/writeConcern.

// Buat koleksi.
db.getSiblingDB("mydb1").foo.insertOne(
    {abc: 0},
    { writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
   {xyz: 0},
   { writeConcern: { w: "majority", wtimeout: 2000 } }
)
// Mulai sesi.
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// Mulai transaksi.
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// Lakukan operasi dalam transaksi.
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (error) {
   // Batalkan transaksi jika terjadi error.
   session.abortTransaction();
   throw error;
}
// Commit transaksi.
session.commitTransaction();
session.endSession();

Perilaku utama transaksi:

• Setiap transaksi harus dikaitkan dengan sebuah session. Satu session hanya mendukung satu transaksi aktif dalam satu waktu. Mengakhiri session akan melakukan rollback terhadap transaksi aktif apa pun.

• Transaksi terdistribusi dapat mencakup beberapa dokumen, koleksi, dan database.

• Transaksi dapat membaca tulisan sendiri yang belum di-commit, tetapi tulisan tersebut tidak terlihat oleh operasi di luar transaksi.

• Tulisan tidak direplikasi ke node secondary hingga transaksi di-commit. Setelah commit, tulisan tersebut secara otomatis diterapkan ke semua node secondary.

• Transaksi mengunci dokumen yang dimodifikasi, memblokir operasi lain hingga selesai. Jika kunci tidak dapat diperoleh dalam waktu 5 milidetik (default), transaksi dibatalkan karena konflik tulis. Timeout ini dikendalikan oleh parameter maxTransactionLockRequestTimeoutMillis.

• Transaksi secara otomatis mencoba ulang pada error sementara seperti gangguan jaringan temporary. Percobaan ulang ini transparan bagi client.

• Transaksi yang berjalan lebih dari 60 detik akan dibatalkan paksa. Timeout ini dikendalikan oleh parameter transactionLifetimeLimitSeconds.

Batasan

• Anda tidak dapat membuat koleksi atau indeks baru dalam transaksi terdistribusi.

• Transaksi tidak dapat menulis ke koleksi capped.

• Transaksi tidak dapat menggunakan read concern snapshot untuk membaca dari koleksi capped. Batasan ini berlaku untuk MongoDB 5.0 dan versi setelahnya.

• Dalam transaksi, Anda tidak dapat membaca dari atau menulis ke koleksi di database config/admin/local.

• Transaksi tidak dapat menulis ke koleksi sistem, seperti koleksi dengan format system.*.

• Transaksi tidak mendukung explain.

• Anda tidak dapat menggunakan getMore di dalam transaksi untuk membaca cursor yang dibuat di luar transaksi. Demikian pula, Anda tidak dapat menggunakan getMore di luar transaksi untuk membaca cursor yang dibuat di dalamnya.

• Operasi pertama dalam transaksi tidak boleh berupa perintah seperti killCursors atau hello.

• Anda tidak dapat menjalankan perintah non-CRUD di dalam transaksi. Contohnya termasuk listCollections, listIndexes, createUser, getParameter, dan count.

• Untuk transaksi terdistribusi, Anda tidak dapat mengatur parameter writeConcernMajorityJournalDefault pada shard ke false.

• Transaksi terdistribusi tidak mendukung shard dengan arbiters.

Praktik terbaik

Risiko bug kernel

Transaksi jangka panjang atau berukuran besar memberikan beban signifikan pada cache WiredTiger. Sejak awal transaksi tertua yang belum di-commit, WiredTiger harus mempertahankan data dan status untuk semua tulisan berikutnya. Transaksi aktif berbagi snapshot yang sama, sehingga tulisan baru menumpuk di cache sepanjang masa transaksi dan tidak dapat di-evict hingga transaksi di-commit atau di-rollback. Cache yang kelebihan beban (penggunaan dan dirty usage melebihi ambang batas) menyebabkan database tersendat, latensi meningkat, CPU penuh, dan potensi deadlock. Isu terkait: SERVER-50365 dan SERVER-51281.

ApsaraDB for MongoDB merekomendasikan upgrade ke MongoDB 5.0 atau versi setelahnya untuk aplikasi yang banyak menggunakan transaksi.

Informasi dasar

Read Concern mengontrol konsistensi dan isolasi dengan level berikut:

• "local": Default untuk baca dari node primary atau secondary. Membaca dari node lokal dan mungkin mengembalikan data yang nantinya di-rollback.

• "available": Default untuk baca dari secondary dalam kluster sharded. Mungkin mengembalikan data yang nantinya di-rollback. Tidak memeriksa versi shard dan mungkin mengembalikan dokumen orphaned. Memberikan latensi akses terendah.

• "majority": Membaca data yang telah diakui oleh mayoritas anggota replica set. Data ini tidak akan di-rollback.

• "linearizable": Level paling ketat. Menunggu semua tulisan sebelumnya diakui oleh mayoritas node. Performa terendah; hanya tersedia di primary.

• "snapshot": Membaca dari snapshot data yang diakui oleh mayoritas node. Dapat dikaitkan dengan titik waktu tertentu menggunakan atClusterTime.

Catatan penggunaan:

• Data terbaru pada satu node mongod belum tentu merepresentasikan data terkini dalam replica set, terlepas dari level Read Concern.

• Level Read Concern yang berbeda dapat ditentukan per operasi. MongoDB 4.4+ juga mendukung default di sisi server, yang dapat ditimpa oleh pengaturan tingkat operasi.

• Read Concern diabaikan saat membaca dari database local. Semua data di database local dapat dibaca terlepas dari levelnya.

• Transaksi terdistribusi hanya mendukung tiga level Read Concern: "local", "majority", dan "snapshot".

• Session konsisten kausal harus menggunakan level Read Concern "majority".

Praktik terbaik

Informasi dasar

Write Concern menggunakan format berikut. Referensi lengkap: Write Concern.

{ w: <value>, j: <boolean>, wtimeout: <number> }

• Write Concern mengontrol jaminan persistensi data pada level berikut:

  • {w: 0}: Tanpa acknowledgment. Tidak mengonfirmasi penyelesaian; kehilangan data mungkin terjadi.

  • {w: 1}: Mengakui tulisan di memori. Default sebelum MongoDB 5.0. Kehilangan data masih mungkin terjadi karena data belum dipersist ke disk.

  • {j: true}: Acknowledgment jurnal. Mengonfirmasi tulisan telah di-flush ke write-ahead log (WAL) pada penyimpanan persisten. Tulisan tidak akan hilang.

  • { w: "majority" }: Acknowledgment mayoritas. Default untuk MongoDB 5.0+. Menunggu tulisan direplikasi ke mayoritas node. Data tidak akan di-rollback.

  • Acknowledgment replica: Menunggu replikasi ke jumlah node tertentu sebelum mengakui.

  • Acknowledgment kustom: Anda dapat menggunakan parameter settings.getLastErrorModes untuk menentukan metode acknowledgment kustom lain menggunakan tag.

Catatan penggunaan:

• Write Concern dapat ditentukan untuk setiap operasi tulis atau transaksi. Jika diabaikan, default akan digunakan.

  Catatan

  Di MongoDB 5.0+, default global Write Concern untuk replica set standar beranggotakan tiga berubah dari {w:1} menjadi {w:"majority"}. Hal ini dapat menyebabkan degradasi performa setelah upgrade.

• Node hidden, node delayed, dan node voting lain dengan priority 0 dalam replica set semuanya dapat dihitung untuk acknowledgment "majority".

• Level Write Concern yang berbeda dapat ditentukan per operasi. MongoDB 4.4+ juga mendukung default di sisi server, yang dapat ditimpa oleh pengaturan tingkat operasi.

• Saat Anda menulis ke database local, Write Concern yang ditentukan diabaikan.

• Session konsisten kausal harus menggunakan Write Concern "majority".

Praktik terbaik