ApsaraDB for MongoDB:Mengapa melakukan upgrade ke versi MongoDB yang lebih baru

Dokumen yatim menyebabkan inkonsistensi data selama migrasi

• Versi yang terdampak: Instans kluster sharded yang menjalankan MongoDB 4.2 atau lebih baru

• Versi perbaikan: MongoDB 4.4 atau lebih baru

Setelah sebuah chunk dimigrasikan dari shard sumber ke shard tujuan, shard sumber menyimpan chunk tersebut sementara sebelum dihapus. Gangguan migrasi meninggalkan dokumen yatim. Dokumen yatim tidak memengaruhi permintaan pada node mongos karena permintaan diperiksa oleh data routing dari node ConfigServer. Namun, dokumen yatim menumpuk dan menyebabkan inkonsistensi data selama migrasi berikutnya.

MongoDB 4.4 memperkenalkan migrasi chunk self-recovery dan pembersihan otomatis dokumen yatim. Jika node gagal di tengah migrasi, MongoDB secara otomatis melanjutkan proses tersebut — tidak perlu menjalankan cleanupOrphaned secara manual. Jalankan perintah tersebut hanya untuk memastikan bahwa thread pembersihan latar belakang aktif.

Untuk detailnya, lihat cleanupOrphaned.

Perintah compact memblokir operasi baca dan tulis

• Versi yang terdampak: Semua arsitektur yang menjalankan MongoDB 4.2 atau lebih lama

• Versi perbaikan: MongoDB 4.4 atau versi yang lebih baru

Menjalankan compact untuk melakukan defragmentasi disk pada MongoDB 4.2 atau lebih lama memblokir semua operasi baca dan tulis selama durasi eksekusi. Operasi ini tidak dapat diinterupsi, sehingga satu-satunya opsi pemulihan adalah me-restart instans, yang berdampak pada kelangsungan bisnis.

MongoDB 4.4 mengoptimalkan perilaku locking dari compact sehingga operasi CRUD tidak diblokir. Hanya beberapa operasi DDL — createIndex dan dropIndex — yang terpengaruh secara singkat. Jadwalkan eksekusi compact di luar jendela pemeliharaan Anda.

Untuk detailnya, lihat Defragmentasi disk instans dan pemblokiran compact.

Perintah compact menyebabkan node memasuki status RECOVERING

• Versi yang terdampak: Semua arsitektur dengan versi utama MongoDB 4.2 atau lebih lama dan versi minor sebelum 4.2.18

• Versi perbaikan: MongoDB 4.4 atau lebih baru

Pada versi yang terdampak, menjalankan compact menyebabkan node mongos memasuki status RECOVERING. Jika node tetap dalam status ini cukup lama, komponen aktivasi ApsaraDB for MongoDB menganggapnya tidak sehat dan memicu rebuild, menyebabkan downtime tak terencana.

Mulai dari MongoDB 4.2.18, node mongos tidak lagi memasuki status RECOVERING setelah menjalankan compact, sehingga mencegah ketidaktersediaan node dan alur rebuild yang tidak diharapkan.

Untuk detailnya, lihat Defragmentasi disk instans dan RECOVERING pada compact.

Cadangan fisik pada node tersembunyi mengonsumsi ruang disk berlebihan

• Versi yang terdampak: Semua arsitektur yang menjalankan MongoDB 4.2 atau lebih lama yang menggunakan disk lokal

• Versi perbaikan: MongoDB 5.0 atau versi yang lebih baru (disk cloud)

Mekanisme cadangan fisik pada instans berbasis disk lokal menyebabkan ukuran file disk terus bertambah selama unggah cadangan. File besar yang terakumulasi mengonsumsi ruang disk signifikan dan memicu peringatan penggunaan disk yang salah selama kegagalan node atau alih bencana.

Instans berbasis disk cloud menggabungkan cadangan fisik dengan snapshot disk, mengurangi waktu yang diperlukan untuk mempertahankan checkpoint cadangan WiredTiger (WT) dan menyelesaikan pembengkakan ruang disk pada node tersembunyi. Untuk instans set replika dengan data lebih dari 2 TB, gunakan cadangan snapshot untuk menghindari waktu pencadangan yang lama, tingkat kegagalan tinggi, dan konflik operasi O&M yang terjadi pada pencadangan fisik berbasis disk lokal.

Data routing sisa merusak database yang dibuat ulang dengan nama yang sama

• Versi yang terdampak: Instans kluster sharded yang menjalankan MongoDB 4.4 atau lebih lama

• Versi perbaikan: MongoDB 5.0 atau lebih baru

Saat Anda menghapus database dengan dropDatabase di kluster sharded lalu membuat ulang database dengan nama yang sama, data routing sisa di node ConfigServer menyebabkan operasi baca dan tulis gagal.

Pada MongoDB 4.2 atau lebih lama, Anda harus menjalankan dropDatabase berulang kali lalu menjalankan flushRouterConfig pada semua node mongos untuk membersihkan data routing — jika tidak, data sisa akan menurunkan performa.

MongoDB 5.0 mengoptimalkan penanganan data routing dropDatabase sehingga data routing secara otomatis dibersihkan, menghilangkan kebutuhan pembersihan manual ini.

Untuk detailnya, lihat dropDatabase dan flushRouterConfig.

Kepedulian tulis default {w:1} menyebabkan kegagalan sinkronisasi data pada node secondary

• Versi yang terdampak: Semua arsitektur yang menjalankan versi sebelum MongoDB 5.0

• Versi perbaikan: MongoDB 5.0 atau versi yang lebih baru

Dengan kepedulian tulis default {w:1}, data yang ditulis cepat ke node primary mungkin hanya sebagian yang sampai ke node secondary, menyebabkan node tersebut memasuki status RECOVERING. Hal ini menurunkan ketersediaan instans, mengganggu workload pemisahan baca/tulis, dan mencegah cadangan inkremental serta pemulihan pada titik waktu.

MongoDB 5.0 mengubah kepedulian tulis default dari {w:1} menjadi {w:"majority"}. Data hanya dapat di-query setelah mayoritas anggota set replika mengonfirmasi tulisan tersebut, meningkatkan keandalan data dengan sedikit penurunan performa. Untuk skenario throughput tulis tinggi di mana Anda dapat menerima perilaku sebelumnya, atur kembali kepedulian tulis ke {w:1}.

Untuk informasi selengkapnya, lihat Default Write Concern dan setDefaultRWConcern.

Balancer melakukan rebalance data terlalu lambat untuk mendukung scale-out

• Versi yang terdampak: Semua arsitektur yang menjalankan versi sebelum MongoDB 5.0

• Versi perbaikan: MongoDB 5.0 atau lebih baru

Balancer tidak dapat memigrasikan chunk cukup cepat untuk melakukan rebalance data selama kejadian scale-out, yang menurunkan performa karena data tetap terdistribusi tidak merata di seluruh shard.

MongoDB 5.0 menambahkan parameter chunkMigrationConcurrency dan balancerMigrationsThrottlingMs sehingga Anda dapat menyesuaikan konkurensi dan throughput migrasi balancer sesuai workload Anda.

Untuk detailnya, lihat chunkMigrationConcurrency dan balancerMigrationsThrottlingMs.

Pemimbangan berbasis jumlah chunk menyebabkan ketidakseimbangan beban di kluster sharded

• Versi yang terdampak: Semua arsitektur dengan versi utama MongoDB 5.0 atau lebih lama dan versi minor sebelum 6.0.3

• Versi perbaikan: MongoDB 6.0 atau lebih baru

Balancer mendistribusikan data berdasarkan jumlah chunk, bukan volume data. Ketika chunk jumbo atau chunk kosong ada — atau ketika subset data menerima trafik yang jauh lebih tinggi — chunk tampak seimbang berdasarkan jumlah, tetapi shard membawa beban yang tidak seimbang.

MongoDB 6.0.3 mengubah balancer untuk mendistribusikan data berdasarkan perbedaan volume data di seluruh shard, bukan jumlah chunk. Hal ini menyelesaikan ketidakseimbangan beban yang disebabkan oleh chunk jumbo, chunk kosong, dan pola data panas.

Untuk detailnya, lihat Perubahan pada balancer di MongoDB 6.0.3.

Masalah kernel lainnya

Tabel berikut mencantumkan masalah kernel tambahan pada versi MongoDB sebelumnya yang diidentifikasi oleh tim ApsaraDB for MongoDB.