ApsaraDB for MongoDB:Pemanfaatan disk space tinggi pada instans MongoDB

Arsitektur kluster sharded

Jika instans ApsaraDB for MongoDB Anda menggunakan arsitektur kluster sharded, login ke Konsol ApsaraDB for MongoDB dan gunakan metode berikut untuk memeriksa penggunaan ruangnya:

• Analisis grafik pemantauan

  Di halaman Monitoring Information, pilih node target untuk melihat Disk Usage (Bytes) dan Disk Usage (%)-nya.

• Analisis mendetail

  Lakukan analisis berurutan penggunaan ruang setiap node dengan menggunakan perintah native MongoDB db.stats() dan db.$collection_name.stats().

Metode compact

Untuk meminimalkan dampak pada bisnis Anda, pertama-tama jalankan perintah db.runCommand({compact:"collectionName"}) pada node secondary, lalu lakukan alih bencana primary/secondary. Ganti collectionName dengan nama koleksi Anda.

Untuk informasi lebih lanjut tentang cara menggunakan perintah compact, lihat Defragmentasi disk untuk meningkatkan pemanfaatan disk.

Kesenjangan ruang akibat journal log besar

Pada versi ApsaraDB for MongoDB sebelum 4.0, jika jumlah file terbuka pada mesin host mencapai batasnya, thread pembersihan log server internal terganggu dan journal log terus bertambah tanpa batas. Jika Anda melihat entri log seperti berikut dalam log waktu proses MongoDB, upgrade kernel ke ApsaraDB for MongoDB 4.0 atau versi lebih baru. Sebagai solusi sementara, restart proses mongod. Untuk detail lebih lanjut, lihat log-server thread exit quietly on error while the mongodb process still running.

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system 
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.

Jenis kunci shard yang tidak sesuai

Pada kluster sharded, pemilihan jenis kunci shard sangat penting. Dua jenis utama adalah sharding hash dan sharding berbasis rentang. Untuk penyeimbangan disk, sharding hash sering kali merupakan strategi yang lebih baik daripada sharding berbasis rentang karena ApsaraDB for MongoDB menggunakan fungsi hash internal untuk mendistribusikan data secara merata ke seluruh shard berdasarkan nilai kunci. Sebaliknya, sharding berbasis rentang mendistribusikan data berdasarkan rentang nilai kunci, yang dapat memusatkan data baru pada satu chunk "panas", menyebabkan I/O disk tinggi pada shard tersebut dan ketidakseimbangan data jangka pendek.

Bidang kunci shard yang tidak sesuai

Meskipun jumlah chunk pada setiap shard mungkin serupa, sebagian besar data terkonsentrasi pada beberapa chunk saja. Akibatnya, shard yang berisi chunk "panas" ini menyimpan data jauh lebih banyak daripada shard lainnya. Saat Anda menjalankan perintah sh.status() dan memeriksa log waktu proses ApsaraDB for MongoDB, Anda mungkin melihat pesan peringatan seperti berikut:

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }

Balancer mongos terutama mempertimbangkan jumlah chunk pada setiap shard untuk menentukan apakah data seimbang. Hal ini dapat menyebabkan skenario di mana jumlah chunk seimbang tetapi distribusi data aktual sangat condong. Ini terjadi karena nilai kunci shard dalam satu chunk hampir identik. Saat chunk mencapai ambang batas pemisahan 64 MB, MongoDB memisahkannya dan membuat chunk kosong. Seiring waktu, meskipun jumlah chunk meningkat dan migrasi terjadi, chunk yang dimigrasikan sering kali kosong—menghasilkan jumlah chunk seimbang tetapi data tidak seimbang. Untuk memperbaiki ini, rancang ulang strategi sharding Anda agar menggunakan bidang dengan kardinalitas tinggi sebagai kunci shard.

Database tidak di-shard dalam kluster sharded

Instans kluster sharded ApsaraDB for MongoDB mendukung database yang di-shard maupun tidak di-shard. Semua data dari database yang tidak di-shard berada pada satu shard utama, sehingga jika database tersebut besar, shard utamanya mungkin menyimpan data jauh lebih banyak daripada shard lainnya.

Masalah ini juga dapat terjadi saat Anda mengimpor data dari kluster mongos sumber ke kluster baru tetapi lupa mengonfigurasi sharding pada kluster tujuan sebelum impor.

Untuk mengatasi masalah ini, kami merekomendasikan hal berikut:

• Jika Anda menginisialisasi kluster tujuan dengan impor, rancang dan aktifkan sharding sebelum memulai.

• Jika Anda memiliki banyak database tidak di-shard dengan ukuran yang kira-kira sama, gunakan perintah movePrimary untuk memindahkan database tertentu ke shard berbeda.

• Jika terdapat database tidak di-shard yang sangat besar, kami merekomendasikan untuk meng-shard-nya atau memigrasikannya ke instans set replika mandiri.

• Jika situasi ini terjadi tetapi Anda memiliki ruang disk yang cukup, Anda dapat memilih untuk mengabaikan masalah ini.