ApsaraDB for MongoDB：Memecahkan masalah pemanfaatan disk tinggi pada instans

Instans kluster sharding

Anda dapat menggunakan salah satu metode berikut untuk melihat penggunaan disk pada instans kluster sharding di Konsol ApsaraDB for MongoDB:

• Analisis Detail Menggunakan Grafik Pemantauan

  Di halaman Monitoring Data, pilih node dan lihat nilai Disk Usage (Bytes) dan Disk Usage (%).

• Analisis Detail dengan Menjalankan Perintah

  Jalankan perintah db.stats() dan db.$collection_name.stats() yang disediakan oleh ApsaraDB for MongoDB untuk menganalisis penggunaan disk di setiap node.

Operasi compact

Jalankan perintah db.runCommand({compact:"collectionName"}) pada node sekunder dan kemudian lakukan switchover utama/sekunder untuk meminimalkan dampak pada bisnis Anda. Parameter collectionName menunjukkan nama koleksi. Ganti nilai parameter dengan nama koleksi aktual Anda.

Untuk informasi lebih lanjut tentang perintah compact, lihat Defragmentasi Disk Instans untuk Meningkatkan Pemanfaatan Disk.

Kesenjangan antara ruang yang digunakan oleh node utama dan sekunder besar karena banyaknya log jurnal

Pada versi sebelum MongoDB 4.0, jika ukuran file terbuka di host mencapai batas atas yang ditentukan, thread cleaner di server log MongoDB dihentikan. Akibatnya, log jurnal terus bertambah tanpa batas. Jika konten serupa dengan blok kode berikut muncul dalam log runtime instans, Anda dapat sementara memecahkan masalah ini dengan meningkatkan versi MongoDB ke 4.0 atau lebih baru atau dengan me-restart proses mongod. Untuk informasi lebih lanjut, lihat thread log-server keluar diam-diam saat kesalahan terjadi sementara proses mongodb masih berjalan.

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Terlalu banyak file terbuka di sistem 
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:tidak bisa membuka [/proc/55692/stat] Terlalu banyak file terbuka di sistem src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Exception tak tertangkap di 'Location13538: tidak bisa membuka [/proc/55692/stat] Terlalu banyak file terbuka di sistem' dalam subsistem pengumpulan data diagnostik penuh waktu. Mematikan subsistem pengumpulan data diagnostik penuh waktu.

Data didistribusikan secara tidak merata karena pemilihan jenis kunci sharding yang tidak masuk akal

Dalam instans kluster sharding, penting untuk memilih jenis kunci sharding. Dalam kebanyakan kasus, sharding hash atau rentang digunakan. Sharding hash lebih cocok daripada sharding rentang untuk penyeimbangan beban disk. Sharding hash menggunakan fungsi hash bawaan untuk mendistribusikan data secara merata di antara shard berdasarkan berbagai nilai kunci. Sharding rentang mendistribusikan data di antara shard berdasarkan rentang nilai kunci, yang menghasilkan distribusi data yang tidak merata. Data didistribusikan pada chunk yang padat. Ini dapat menyebabkan beban kerja I/O tinggi dan distribusi data tidak merata jangka pendek di disk tempat chunk tersebut berada.

Data didistribusikan secara tidak merata karena pemilihan bidang kunci sharding yang tidak masuk akal

Jumlah chunk pada setiap shard pada dasarnya sama. Namun, sebagian besar data hanya disimpan di beberapa chunk yang padat, yang menghasilkan distribusi data yang tidak merata. Untuk melihat log runtime instans, jalankan perintah sh.status(). Informasi peringatan mungkin ditampilkan di output. Kode berikut memberikan contoh informasi peringatan:

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] kemungkinan kunci kardinalitas rendah terdeteksi di superHotItemPool.haodanku_all - kunci adalah { batch: "201908260000" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] kemungkinan kunci kardinalitas rendah terdeteksi di superHotItemPool.haodanku_all - kunci adalah { batch: "201908260200" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] kemungkinan kunci kardinalitas rendah terdeteksi di superHotItemPool.haodanku_all - kunci adalah { batch: "201908260230" }

Balancer MongoDB memantau jumlah chunk pada setiap shard tanpa memedulikan volume data. Dalam kasus ini, jumlah chunk pada setiap shard seimbang, sedangkan data mungkin sangat condong. Dalam sebuah chunk, kunci sharding hampir sama. Saat ukuran chunk mencapai 64 MB, chunk kosong dibuat. Dengan cara ini, jumlah chunk bertambah dan migrasi chunk selesai. Namun, chunk yang dimigrasi adalah chunk kosong. Akibatnya, shard mungkin memiliki jumlah chunk yang sama tetapi ukuran data yang sangat berbeda. Dalam kasus ini, Anda harus merancang ulang kunci sharding dengan menggunakan kolom yang sesuai yang memiliki tingkat diskriminasi tinggi.

Shard jumbo muncul dari database yang tidak di-shard

Anda dapat melakukan sharding pada beberapa database dalam instans kluster sharding ApsaraDB for MongoDB. Dalam hal ini, data dalam database yang tidak di-shard hanya disimpan di satu shard. Jika database memiliki sejumlah besar data, shard yang menyimpan data memiliki jumlah data yang lebih besar daripada shard lainnya.

Dalam kasus lain, ketika data secara logis diimpor dari instans ApsaraDB for MongoDB sumber ke instans ApsaraDB for MongoDB tujuan, instans tujuan mungkin tidak di-shard.

Untuk menyelesaikan masalah dalam skenario sebelumnya, kami menyarankan Anda melakukan operasi berikut:

• Jika impor data ke instans kluster tujuan diinisialisasi, kami menyarankan Anda melakukan sharding pada instans tujuan sebelum impor data.

• Jika sejumlah besar database tidak di-shard dan volume data dari database serupa, kami menyarankan Anda menjalankan perintah movePrimary yang disediakan oleh ApsaraDB for MongoDB untuk memigrasi database tertentu ke shard tertentu.

• Jika database memiliki jumlah data yang sangat besar dan tidak di-shard, kami menyarankan Anda melakukan sharding pada database atau membagi database sebagai set replika individu.

• Jika ruang disk cukup, kami menyarankan Anda mengabaikan masalah ini.