"Data yang hilang" dan chunksize ialah dua perkara yang tidak berkaitan dan tidak mempunyai sambungan logik langsung. Saya tidak tahu siapa yang akan menggabungkan kedua-dua perkara ini dan memberitahu anda. Memandangkan saya tidak tahu senario tertentu yang dimaksudkan oleh kehilangan data, saya akan memberikan anda beberapa jawapan yang mungkin berguna kepada anda berdasarkan apa yang saya tahu. Nampaknya anda mengambil berat tentang masalah kehilangan data dan bukannya chunksize langsung. Tambahan pula, biasanya tiada masalah jika chunksize dibiarkan pada nilai default, jadi saya akan melangkau isu chunksize. Beri sedikit penjelasan tentang "kehilangan data". Untuk mana-mana pangkalan data, kehilangan data tanpa sebab adalah tidak boleh diterima. Jadi terdapat situasi di mana data hilang, sama ada
Terdapat faktor yang tidak dapat dinafikan, seperti gangguan bekalan elektrik, kerosakan perkakasan, kegagalan rangkaian, dll.
Sebab konfigurasi
Terdapat pepijat yang serius dalam perisian. Tiada apa-apa yang boleh anda lakukan tentang 1 pula. Ini harus diminimumkan melalui fungsi replikasi ReplicaSet.
Perkara 2, jika anda tidak membuka jurnal (ia dibuka secara lalai), anda mungkin kehilangan data dalam masa 30ms jika berlaku gangguan bekalan elektrik atau program ranap. Jika data adalah sangat penting dan tidak boleh bertolak ansur dengan kehilangan 30ms, sila hidupkan parameter j: mongodb://ip:port/db?replicaSet=rs&j=1 (di atas parameter juga boleh dihantar melalui kod Tentukan mengikut butiran satu permintaan, sila rujuk dokumentasi pemacu yang anda gunakan) Parameter ini memastikan penulisan data disekat sehingga jurnal ditulis pada cakera. Tetapi adakah anda fikir data itu selamat jika ia diletakkan pada cakera? Ingat bahawa ini adalah persekitaran yang diedarkan, dan keselamatan data mesin tunggal tidak mewakili kluster. Jadi sekiranya berlaku kecemasan, walaupun jurnal diletakkan, ia belum sempat disalin ke nod lain replika Kemudian primary dipadam tepat pada masanya, dan nod lain akan menjadi primary baharu melalui pilihan raya. Ini Situasi yang menarik akan berlaku pada masa ini dipanggil rollback Jika anda berminat, anda boleh membacanya. Sudah tentu, kelajuan penyalinan biasanya sangat cepat, dan rollback sangat jarang berlaku. Nah, anda mungkin masih merasakan bahawa ia tidak cukup selamat, maka terdapat parameter w yang boleh digunakan: mongodb://ip:port/db?replicaSet=rs&j=1&w=1 Parameter w Ini memastikan bahawa operasi tulis disekat sehingga data mendarat pada berbilang nod (w=1/2/3...n). Adakah ini selamat? Maaf, dalam situasi yang tidak bernasib baik (anda sepatutnya membeli tiket loteri), anda menyalin data ke lebih daripada satu nod Bagaimana jika set nod ini gagal pada masa yang sama? Jadi kita ada w=majoriti (majoriti). Apabila kluster kehilangan kebanyakan nod, ia akan menjadi baca sahaja, jadi tiada data baharu akan ditulis dan tiada rollback. Apabila semuanya dipulihkan, data anda akan tetap ada. Di atas adalah beberapa situasi di mana kehilangan data akan berlaku. Boleh dibayangkan bahawa konfigurasi w dan j pasti akan menjejaskan kecekapan penulisan pada tahap yang besar sambil memastikan keselamatan data. Ini sepatutnya menjadi dasar yang anda sesuaikan berdasarkan toleransi anda terhadap kehilangan data dan tidak dianggap sebagai pepijat. Satu lagi perkara yang terlintas di fikiran ialah saya sering bertemu orang dalam komuniti yang suka melakukan perkara seperti ini:
kill -9 mongod
Jika anda bertanya kepada saya, ia terlalu kejam Mengapa anda menggunakan meriam untuk membunuh nyamuk sebaik sahaja anda muncul? Kehilangan data dalam kes ini hanya boleh dikatakan layak. Sebenarnya,
kill mongod
selamat, tetapi -9 adalah salah anda.
Bagi titik 3, pepijat yang membawa kepada kehilangan data memang berlaku semasa proses pembangunan mongodb 3.0.8-3.0.10 adalah kawasan yang paling sukar dilanda, jadi elakkan versi ini. Setelah berkata demikian, proses pembangunan perisian manakah yang tidak mempunyai beberapa masalah? 3.0.11 dikeluarkan pada hari yang sama masalah ditemui pada 3.0.10, dan kelajuan pembaikan sudah sangat pantas.
Baiklah, selepas berkata begitu banyak, saya tidak tahu sama ada ia berguna kepada penyoal. Sekadar peringatan, huraikan masalah itu sejelas mungkin, jika tidak, anda hanya boleh meneka seperti saya jenis masalah yang anda hadapi dalam senario apa Situasi yang paling mungkin adalah pepatah lama:
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
"Data yang hilang" dan chunksize ialah dua perkara yang tidak berkaitan dan tidak mempunyai sambungan logik langsung. Saya tidak tahu siapa yang akan menggabungkan kedua-dua perkara ini dan memberitahu anda. Memandangkan saya tidak tahu senario tertentu yang dimaksudkan oleh kehilangan data, saya akan memberikan anda beberapa jawapan yang mungkin berguna kepada anda berdasarkan apa yang saya tahu.
Nampaknya anda mengambil berat tentang masalah kehilangan data dan bukannya chunksize langsung. Tambahan pula, biasanya tiada masalah jika chunksize dibiarkan pada nilai default, jadi saya akan melangkau isu chunksize.
Beri sedikit penjelasan tentang "kehilangan data". Untuk mana-mana pangkalan data, kehilangan data tanpa sebab adalah tidak boleh diterima. Jadi terdapat situasi di mana data hilang, sama ada
Terdapat faktor yang tidak dapat dinafikan, seperti gangguan bekalan elektrik, kerosakan perkakasan, kegagalan rangkaian, dll.
Sebab konfigurasi
Terdapat pepijat yang serius dalam perisian.
Tiada apa-apa yang boleh anda lakukan tentang 1 pula. Ini harus diminimumkan melalui fungsi replikasi ReplicaSet.
Perkara 2, jika anda tidak membuka jurnal (ia dibuka secara lalai), anda mungkin kehilangan data dalam masa 30ms jika berlaku gangguan bekalan elektrik atau program ranap. Jika data adalah sangat penting dan tidak boleh bertolak ansur dengan kehilangan 30ms, sila hidupkan parameter j:
mongodb://ip:port/db?replicaSet=rs&j=1
(di atas parameter juga boleh dihantar melalui kod Tentukan mengikut butiran satu permintaan, sila rujuk dokumentasi pemacu yang anda gunakan)
Parameter ini memastikan penulisan data disekat sehingga jurnal ditulis pada cakera.
Tetapi adakah anda fikir data itu selamat jika ia diletakkan pada cakera? Ingat bahawa ini adalah persekitaran yang diedarkan, dan keselamatan data mesin tunggal tidak mewakili kluster. Jadi sekiranya berlaku kecemasan, walaupun jurnal diletakkan, ia belum sempat disalin ke nod lain replika Kemudian
primarydipadam tepat pada masanya, dan nod lain akan menjadiprimarybaharu melalui pilihan raya. Ini Situasi yang menarik akan berlaku pada masa ini dipanggil rollback Jika anda berminat, anda boleh membacanya. Sudah tentu, kelajuan penyalinan biasanya sangat cepat, dan rollback sangat jarang berlaku. Nah, anda mungkin masih merasakan bahawa ia tidak cukup selamat, maka terdapat parameter w yang boleh digunakan:mongodb://ip:port/db?replicaSet=rs&j=1&w=1 Parameter
w Ini memastikan bahawa operasi tulis disekat sehingga data mendarat pada berbilang nod (w=1/2/3...n).
Adakah ini selamat? Maaf, dalam situasi yang tidak bernasib baik (anda sepatutnya membeli tiket loteri), anda menyalin data ke lebih daripada satu nod Bagaimana jika set nod ini gagal pada masa yang sama? Jadi kita ada w=majoriti (majoriti). Apabila kluster kehilangan kebanyakan nod, ia akan menjadi baca sahaja, jadi tiada data baharu akan ditulis dan tiada rollback. Apabila semuanya dipulihkan, data anda akan tetap ada.
Di atas adalah beberapa situasi di mana kehilangan data akan berlaku. Boleh dibayangkan bahawa konfigurasi w dan j pasti akan menjejaskan kecekapan penulisan pada tahap yang besar sambil memastikan keselamatan data. Ini sepatutnya menjadi dasar yang anda sesuaikan berdasarkan toleransi anda terhadap kehilangan data dan tidak dianggap sebagai pepijat.
Satu lagi perkara yang terlintas di fikiran ialah saya sering bertemu orang dalam komuniti yang suka melakukan perkara seperti ini:
Jika anda bertanya kepada saya, ia terlalu kejam Mengapa anda menggunakan meriam untuk membunuh nyamuk sebaik sahaja anda muncul? Kehilangan data dalam kes ini hanya boleh dikatakan layak. Sebenarnya,
selamat, tetapi -9 adalah salah anda.
Bagi titik 3, pepijat yang membawa kepada kehilangan data memang berlaku semasa proses pembangunan mongodb 3.0.8-3.0.10 adalah kawasan yang paling sukar dilanda, jadi elakkan versi ini. Setelah berkata demikian, proses pembangunan perisian manakah yang tidak mempunyai beberapa masalah? 3.0.11 dikeluarkan pada hari yang sama masalah ditemui pada 3.0.10, dan kelajuan pembaikan sudah sangat pantas.
Baiklah, selepas berkata begitu banyak, saya tidak tahu sama ada ia berguna kepada penyoal. Sekadar peringatan, huraikan masalah itu sejelas mungkin, jika tidak, anda hanya boleh meneka seperti saya jenis masalah yang anda hadapi dalam senario apa Situasi yang paling mungkin adalah pepatah lama: