Pembaruan: April 2018
Jawaban ini benar pada saat pertanyaan, tetapi hal-hal telah berubah sejak saat itu. Sejak versi 3.4 paralelisme telah diperkenalkan, dan tiket yang saya rujuk awalnya telah ditutup. Untuk informasi lebih lanjut, saya membahas beberapa detail dalam jawaban yang lebih baru . Saya akan meninggalkan sisa jawabannya apa adanya karena tetap menjadi referensi yang baik untuk masalah / kendala umum serta berlaku untuk siapa pun pada versi yang lebih lama.
Jawaban Asli
Saya memberikan penjelasan lengkap tentang apa yang terjadi dengan migrasi chunk di kursus M202 Advanced jika Anda tertarik. Secara umum, katakan saja migrasi tidak terlalu cepat, bahkan untuk potongan kosong, karena pembersihan dilakukan untuk memastikan migrasi bekerja dalam sistem yang aktif (ini masih terjadi bahkan jika tidak terjadi penyeimbangan kecuali terjadi penyeimbangan).
Selain itu, hanya ada satu migrasi yang terjadi pada satu waktu di seluruh cluster - tidak ada paralelisme. Jadi, terlepas dari kenyataan bahwa Anda memiliki dua simpul "penuh" dan dua simpul "kosong", pada waktu tertentu paling banyak terjadi satu migrasi (antara beling dengan potongan paling banyak dan beling dengan yang paling sedikit). Oleh karena itu, setelah menambahkan 2 pecahan, Anda tidak mendapatkan apa-apa dalam hal kecepatan penyeimbangan dan hanya meningkatkan jumlah bongkahan yang harus dipindahkan.
Untuk migrasi sendiri, ukuran chunk cenderung ~ 30MiB (tergantung pada bagaimana Anda mengisi data, tetapi umumnya ini akan menjadi rata-rata Anda dengan ukuran chunk max maksimum). Anda dapat menjalankan db.collection.getShardDistribution()beberapa informasi itu, dan lihat jawaban saya di sini untuk mengetahui cara mendapatkan lebih banyak informasi tentang potongan Anda.
Karena tidak ada aktivitas lain yang terjadi, agar migrasi terjadi, target shard (salah satu pecahan yang baru ditambahkan) perlu membaca ~ 30MiB data dari pecahan sumber (salah satu dari yang asli 2) dan memperbarui server konfigurasi ke mencerminkan lokasi chunk yang baru setelah selesai. Memindahkan 30MiB data seharusnya tidak menjadi hambatan bagi sistem normal tanpa beban.
Jika lambat, ada sejumlah alasan yang memungkinkan mengapa demikian, tetapi yang paling umum untuk sistem yang tidak sibuk adalah:
- Sumber Disk I / O - jika data tidak ada dalam memori aktif ketika sedang dibaca, itu harus di-paging dari disk
- Jaringan - jika ada latensi, pembatasan kecepatan, kehilangan paket, dll. Maka pembacaan mungkin memakan waktu cukup lama
- Target Disk I / O - data dan indeks harus ditulis ke disk, banyak indeks dapat memperburuk ini, tetapi biasanya ini bukan masalah pada sistem yang dimuat dengan ringan
- Masalah dengan migrasi yang menyebabkan aborsi dan migrasi gagal (masalah dengan server konfigurasi, masalah dengan penghapusan pada pendahuluan)
- Kelambanan replikasi - untuk migrasi ke set replika, menulis kekhawatiran
w:2atau w:majoritydigunakan secara default dan membutuhkan sekunder yang terkini untuk memuaskannya.
Jika sistem sibuk maka pertikaian memori, pertikaian kunci biasanya akan menjadi tersangka di sini juga.
Untuk mendapatkan informasi lebih lanjut tentang berapa lama migrasi, jika gagal, dll., Lihat entri di Anda config.changelog:
// connect to mongos
use config
db.changelog.find()
Seperti yang Anda lihat, dan seperti yang biasanya saya katakan kepada orang-orang ketika saya melakukan pelatihan / pendidikan, jika Anda tahu Anda akan membutuhkan 4 pecahan, maka biasanya lebih baik untuk memulai dengan 4 daripada meningkatkan. Jika Anda melakukannya, maka Anda perlu menyadari bahwa menambahkan beling dapat memakan waktu yang lama, dan awalnya merupakan negatif bersih pada sumber daya daripada keuntungan (lihat bagian II dari seri perangkap perangkap saya untuk diskusi lebih rinci tentang itu).
Akhirnya, untuk melacak / meningkatkan / mengomentari permintaan fitur untuk meningkatkan paralelisme migrasi chunk, lihat SERVER-4355