ApsaraDB for MongoDB：Mengapa saya perlu memutakhirkan instans saya ke versi MongoDB yang lebih baru?

Ketidaksesuaian data terjadi selama migrasi data karena adanya dokumen yatim di instans kluster sharded

• Versi dan arsitektur yang terpengaruh: Instans kluster sharded yang menjalankan MongoDB 4.2 atau lebih baru.

• Deskripsi: Jika dokumen yatim tidak dibersihkan di instans kluster sharded, ketidaksesuaian data dapat terjadi selama migrasi.

• Versi yang direkomendasikan: MongoDB 4.4 atau lebih baru.

• Alasan rekomendasi:

  Setelah sebuah chunk dimigrasikan dari shard sumber ke shard baru, chunk di shard sumber dipertahankan selama periode tertentu sebelum dihapus. Dalam banyak kasus, dokumen yatim dihasilkan akibat interupsi migrasi. Dokumen yatim tidak memengaruhi permintaan pada node mongos karena permintaan tersebut diverifikasi oleh data routing node ConfigServer.

  MongoDB 4.4 atau lebih baru mendukung pemulihan otomatis migrasi chunk dan pembersihan dokumen yatim secara otomatis. Jika node gagal, MongoDB secara otomatis memulihkan proses migrasi yang terganggu. Anda tidak perlu menjalankan perintah cleanupOrphaned untuk membersihkan dokumen yatim. Namun, Anda dapat menjalankan perintah ini untuk memastikan apakah thread backend sedang membersihkan dokumen yatim di instans.

  Untuk informasi lebih lanjut, lihat cleanupOrphaned.

Operasi compact memblokir permintaan baca dan tulis

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur yang menjalankan MongoDB 4.2 atau lebih lama.

• Deskripsi: Operasi compact untuk mendefragmentasi disk memblokir permintaan baca dan tulis di versi sebelumnya. Dalam hal ini, Anda harus me-restart instans karena operasi tidak dapat diinterupsi, yang dapat memengaruhi bisnis Anda.

• Versi yang direkomendasikan: MongoDB 4.4 atau lebih baru.

• Alasan rekomendasi:

  Mulai dari MongoDB 4.4, perilaku penguncian perintah compact dioptimalkan sehingga operasi baca dan tulis (CRUD) tidak diblokir, kecuali beberapa operasi DDL seperti createIndex dan dropIndex. Anda dapat menjalankan perintah compact di luar jendela pemeliharaan yang ditentukan.

  Untuk informasi lebih lanjut, lihat Defragmentasi disk instans untuk meningkatkan utilisasi disk dan compact Blocking.

  Catatan

  Untuk mendefragmentasi disk, kami merekomendasikan penggunaan fitur analisis penyimpanan yang disediakan oleh ApsaraDB for MongoDB. Untuk informasi lebih lanjut tentang fitur ini, lihat Analisis Penyimpanan.

Operasi compact menyebabkan node memasuki status RECOVERING

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur dengan versi utama MongoDB 4.2 atau lebih lama dan versi minor lebih lama dari MongoDB 4.2.18.

• Deskripsi: Node di instans yang menjalankan versi sebelumnya memasuki status RECOVERING setelah operasi compact dilakukan. Jika node tetap dalam status tersebut untuk waktu yang lama, komponen aktivasi instans ApsaraDB for MongoDB akan menganggap node tidak sehat dan memicu operasi pembangunan ulang.

• Versi yang direkomendasikan: MongoDB 4.4 atau lebih baru.

• Alasan rekomendasi:

  Mulai dari MongoDB 4.2.18, node mongos tidak memasuki status RECOVERING setelah menjalankan perintah compact. Ini mencegah adanya node mongos yang tidak tersedia dan aliran tugas pembangunan ulang yang tidak diharapkan.

  Untuk informasi lebih lanjut, lihat Defragmentasi disk instans untuk meningkatkan utilisasi disk dan compact RECOVERING.

  Catatan

  Untuk mendefragmentasi disk, kami merekomendasikan penggunaan fitur analisis penyimpanan yang disediakan oleh ApsaraDB for MongoDB. Untuk informasi lebih lanjut tentang fitur ini, lihat Analisis Penyimpanan.

Cadangan fisik di node tersembunyi mengonsumsi sejumlah besar ruang disk

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur yang menjalankan MongoDB 4.2 atau lebih lama dan menggunakan disk lokal.

• Deskripsi: Ukuran file disk terus meningkat selama unggahan cadangan karena mekanisme cadangan fisik. Jika sejumlah besar file disk terakumulasi, ruang disk yang signifikan dikonsumsi. Jika terjadi kegagalan node atau switchover, peringatan salah terkait penggunaan disk dapat dipicu.

• Versi yang direkomendasikan: MongoDB 5.0 atau lebih baru (disk cloud).

• Alasan rekomendasi:

  Cadangan penuh di instans yang menggunakan disk cloud menggabungkan cadangan fisik dengan snapshot disk. Pendekatan ini mengurangi waktu yang diperlukan untuk memelihara titik kontrol cadangan di WiredTiger (WT) dan menyelesaikan pembengkakan ruang disk akibat cadangan pada node tersembunyi di kluster sharded secara efisien.

  Snapshot cadangan dan pemulihan data berdasarkan snapshot cadangan yang disediakan oleh instans yang menggunakan disk cloud memberikan kinerja yang lebih baik. Jika jumlah data dalam instans set replika melebihi 2 TB, kami merekomendasikan penggunaan snapshot cadangan untuk mencadangkan data. Dengan cara ini, masalah seperti waktu pencadangan fisik yang lama untuk instans yang menggunakan disk lokal, tingkat kegagalan pencadangan yang tinggi, dan kegagalan untuk melakukan operasi O&M lainnya dapat dihindari.

Data routing ada di instans kluster sharded saat Anda membuat ulang database yang memiliki nama sama dengan database yang telah dihapus

• Versi dan arsitektur yang terpengaruh: Instans kluster sharded yang menjalankan MongoDB 4.4 atau lebih lama.

• Deskripsi: Saat menjalankan perintah dropDatabase di instans kluster sharded dan kemudian membuat ulang database dengan nama yang sama, operasi baca dan tulis tidak dapat dilakukan seperti yang diharapkan karena data routing masih ada di node ConfigServer instans.

• Versi yang direkomendasikan: MongoDB 5.0 atau lebih baru.

• Alasan rekomendasi:

  MongoDB 5.0 atau lebih baru mengoptimalkan pemrosesan data routing perintah dropDatabase. Dengan demikian, data routing tidak ada di instans kluster sharded yang menjalankan MongoDB 5.0 atau lebih baru. Di MongoDB 4.2 atau lebih lama, Anda harus menjalankan perintah dropDatabase berulang kali dan menjalankan perintah flushRouterConfig di semua node mongos untuk menyegarkan data routing. Jika tidak, data routing residu dapat menurunkan kinerja database.

  Untuk informasi lebih lanjut, lihat dropDatabase dan flushRouterConfig.

Sinkronisasi data antara node primer dan sekunder abnormal karena pengaturan writeConcern default {w:1}

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur yang menjalankan versi lebih lama dari MongoDB 5.0.

• Deskripsi: Jika data dengan cepat ditulis ke node primer instans, node sekunder mungkin hanya menerima sebagian data dan kemudian memasuki status RECOVERING. Ini menurunkan ketersediaan instans. Node sekunder mungkin gagal membaca data yang diharapkan, yang merugikan bisnis yang memerlukan pembagian baca/tulis. Dalam hal ini, pencadangan inkremental tidak dapat dilakukan seperti yang diharapkan, dan data tidak dapat dipulihkan ke titik waktu sebelumnya.

• Versi yang direkomendasikan: MongoDB 5.0 atau lebih baru.

• Alasan rekomendasi:

  Mulai dari MongoDB 5.0, nilai default writeConcern diubah dari {w:1} menjadi {w:"majority"}. Ini berarti data yang akan ditulis hanya dapat di-query setelah data dikonfirmasi oleh sebagian besar node di instans set replika. Hal ini meningkatkan keandalan data dengan sedikit penurunan performa dan menyelesaikan kehilangan data yang disebabkan oleh respons query lambat atau node primer dalam status ROLLBACK karena sebagian data diterima oleh node sekunder dan kontrol aliran yang dipicu pada node primer.

  Anda dapat mengatur writeConcern ke {w:1} dalam skenario yang memerlukan performa tulis tinggi.

  Untuk informasi lebih lanjut, lihat Default Write Concern dan setDefaultRWConcern.

Balancer mendistribusikan data secara merata dengan kecepatan lambat, memberikan performa penskalaan yang buruk, dan gagal melakukan aktivitas penskalaan keluar selama jam sibuk

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur yang menjalankan versi lebih lama dari MongoDB 5.0.

• Deskripsi: Balancer tidak dapat memigrasikan data dengan kecepatan lebih tinggi. Akibatnya, data tidak dapat didistribusikan secara merata dengan cepat dalam skenario yang memerlukan aktivitas penskalaan keluar, menurunkan kinerja database.

• Versi yang direkomendasikan: MongoDB 5.0 atau lebih baru.

• Alasan rekomendasi:

  Mulai dari MongoDB 5.0, parameter chunkMigrationConcurrency dan balancerMigrationsThrottlingMs ditambahkan untuk menyesuaikan konkurensi migrasi dan performa balancer.

  Untuk informasi lebih lanjut, lihat chunkMigrationConcurrency dan balancerMigrationsThrottlingMs.

  Catatan

  Jika instans Anda menjalankan MongoDB 5.0 dan tidak mendukung dua parameter tersebut, perbarui versi minor instans. Untuk informasi lebih lanjut, lihat Perbarui versi minor instans.

Beban di instans kluster sharded didistribusikan secara tidak merata karena ketidakseimbangan data

• Versi dan arsitektur yang terpengaruh: Instans dari semua arsitektur dengan versi utama MongoDB 5.0 atau lebih lama dan versi minor lebih lama dari MongoDB 6.0.3.

• Deskripsi: Balancer memeriksa distribusi data berdasarkan jumlah chunk di antara shard. Jika terdapat chunk Jumbo dan kosong serta sebagian data sering diakses, ketidakseimbangan data dan beban dapat terjadi di antara shard.

• Versi yang direkomendasikan: MongoDB 6.0 atau lebih baru.

• Alasan rekomendasi:

  Mulai dari MongoDB 6.0.3, balancer mendistribusikan data secara merata berdasarkan perbedaan volume data di antara shard, bukan perbedaan jumlah chunk. Hal ini menyelesaikan ketidakseimbangan data dan beban akibat adanya chunk Jumbo dan kosong serta data yang sering diakses di versi sebelumnya.

  Untuk informasi lebih lanjut, lihat Perubahan pada balancer di MongoDB 6.0.3.

Masalah kernel lainnya