Các phê phán 'mất dữ liệu' ở mức độ nào vẫn còn hiệu lực của MongoDB?

Question

Các phê phán 'mất dữ liệu' ở mức độ nào vẫn còn hiệu lực của MongoDB? I'm referring to the following:

1. vấn đề MongoDB viết theo những cách không an toàn theo mặc định để thắng benchmarks

Nếu bạn không hành GetLastError(), MongoDB không chờ đợi bất kỳ xác nhận từ cơ sở dữ liệu mà lệnh đã được xử lý. này giới thiệu ít nhất hai lớp của các vấn đề:

• Trong một môi trường đồng thời (hồ kết nối, vv), bạn có thể có đọc tiếp theo thất bại sau một ghi đã "hoàn thành"; không có điều kiện rào cản đối với biết vào thời điểm những gì các cơ sở dữ liệu sẽ nhận ra một ghi cam kết
• Bất kỳ số không rõ của tiết kiệm hoạt động có thể được giảm xuống trên sàn do xếp hàng ở những nơi khác nhau, điều nổi bật trong bộ đệm TCP , vv, khi giọt kết nối của bạn của db đã được KILL'd hoặc segfault, sụp đổ phần cứng, bạn đặt tên cho nó

2. MongoDB có thể bị mất dữ liệu bằng nhiều cách gây sửng sốt

đây là một lis t cách chúng tôi cá nhân trải nghiệm hồ sơ bị mất tích:

1. Đôi khi chúng chỉ biến mất. Nguyên nhân không rõ.
2. Khôi phục trên cơ sở dữ liệu bị hỏng không thành công, nhật ký giao dịch trước.
3. Nhân rộng giữa chủ và nô lệ có khoảng trống trong các mã vạch, khiến các bản nhạc bị thiếu bản ghi mà thầy đã có. Có, không có tổng kiểm tra, và có, trạng thái sao chép có nô lệ hiện tại
4. Sao chép chỉ dừng lại đôi khi, không có lỗi. Giám sát trạng thái sao chép của bạn!

... [những lời chỉ trích khác]

Nếu vẫn còn hiệu lực, những lời chỉ trích sẽ được lo lắng đến một mức độ nào. Bài viết chủ yếu tham khảo v1.6 và v1.8, nhưng kể từ đó v2 đã được phát hành. Những thiếu sót được thảo luận trong bài viết vẫn còn nổi bật như của bản phát hành hiện tại?

Answer 1

Đó bài cụ thể được vạch trần, từng điểm của MongoDB CTO kiêm đồng sáng lập, Eliot Horowitz, ở đây:

http://news.ycombinator.com/item?id=3202959

Ngoài ra còn có một bản tóm tắt tốt ở đây:

http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/

Phiên bản ngắn, có vẻ như đây là cơ bản ai đó trolling cho sự chú ý (thành công), không có bằng chứng vững chắc hoặc corroboration. Đã có những sự cố thực sự trong quá khứ, đã được xử lý khi sản phẩm được phát triển (xem phần giới thiệu nhật ký trong ví dụ 1.8) hoặc khi có nhiều lỗi cụ thể được tìm thấy và sửa lỗi.

Disclaimer: Tôi làm việc cho MongoDB (trước đây là 10gen), và tình yêu thực tế là philnate đến đây và bác bỏ này một cách độc lập đầu tiên - mà có lẽ nói thêm về sản phẩm hơn bất cứ điều gì khác :)

Cập nhật : August 19 2013

Tôi đã nhìn thấy khá nhiều hoạt động trên câu trả lời gần đây, mà tôi cho rằng có liên quan đến thông báo lỗi trong SERVER-10478 - đó chắc chắn là trường hợp cạnh, nhưng tôi vẫn khuyên bạn nên bất cứ ai sử dụng sharding với các tài liệu lớn để nâng cấp ASAP lên v2.2.6 và v2.4.6 bao gồm bản sửa lỗi cho vấn đề này.

Cập nhật: 24 Tháng Ba 2017

tôi không còn làm việc cho MongoDB, nhưng đứng đằng sau câu trả lời này dù sao. Cho rằng câu trả lời này tiếp tục nhận được (và xuống) phiếu bầu và nhận được rất nhiều quan điểm tôi muốn chỉ người ở this post cho thấy sự tiến bộ MongoDB đã thực hiện kể từ khi câu hỏi này được đặt ra. Bây giờ cơ sở dữ liệu đã vượt qua các bài kiểm tra Jepsen và có integrated the tests trong quá trình xây dựng, có rất nhiều hệ thống trưởng thành hơn rất nhiều mà không vượt qua. Bất cứ ai vẫn đánh bại trống mất dữ liệu trong năm 2017 thực sự đã không được chú ý.

Answer 2

Không bao giờ nghe về những vấn đề nghiêm trọng trong các phiên bản gần đây. Những gì bạn cần phải xem xét là MongoDB không có thập kỷ phát triển như hệ thống quan hệ ở phía sau. Hơn nữa, có thể đúng là MongoDB không cung cấp nhiều chức năng để tránh mất dữ liệu. Nhưng ngay cả với các hệ thống quan hệ bạn sẽ không bao giờ chắc chắn rằng bạn sẽ không bao giờ mất bất kỳ dữ liệu nào. Nó phụ thuộc rất nhiều vào cấu hình hệ thống của bạn (vì vậy với Sao lưu và sao lưu dữ liệu thủ công, bạn nên khá an toàn).

Như một hướng dẫn chung để tránh Beta Bugs hoặc lỗi từ các phiên bản đầu, tránh sử dụng phiên bản mới trong sản xuất (có một lý do tại sao debian là rất phổ biến cho các máy chủ). Nếu MongoDB sẽ gặp phải những vấn đề nghiêm trọng như vậy (mọi lúc) danh sách người dùng sẽ nhỏ hơn: https://www.mongodb.com/community/deployments Ngoài ra tôi không thực sự tin vào thông điệp này, tại sao điều này được ẩn danh? Công ty người này có xấu hổ khi nói rằng họ đã sử dụng Mongodb, họ có sợ 10GG không? Trong trường hợp các liên kết đến các báo cáo lỗi (hoặc đã 10gen xóa chúng khỏi JIRA?)

Vì vậy, cho phép nói chuyện trong thời gian ngắn về những điểm:

1. Yep MongoDB hoạt động bình thường trong lửa và chế độ quên. Nhưng bạn có thể sửa đổi bevavior này với một số tùy chọn: https://docs.mongodb.com/manual/reference/command/getLastError/#dbcmd.getLastError. Vì vậy, chỉ vì MongoDB mặc định nó, nó không có nghĩa là bạn không thể thay đổi nó theo nhu cầu của bạn. Nhưng bạn cần phải sống ít hiệu quả hơn nếu bạn không bắn và quên trong ứng dụng của mình, khi bạn đang thêm một chuyến đi.

   Cập nhật: Since version 2.6, các lệnh insert, update, save, remove theo mặc định thừa nhận ghi.

2. Không bao giờ nghe nói về các vấn đề như vậy, ngoại trừ những vấn đề gây ra thất bại ... nhưng điều đó cũng có thể xảy ra với các hệ thống quan hệ. Tôi đoán điểm này chỉ nói về Master-Slave Replication. Replica-Sets là không bao giờ và ổn định. Một số liên kết từ web nơi các dbms khác gây ra mất dữ liệu do sự cố: http://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss-running-oracle-on.htmlhttp://dbaspot.com/oracle-server/430465-parallel-cause-data-lost-another-oracle-bug.htmlhttp://bugs.mysql.com/bug.php?id=18014 (Các liên kết được đăng không có lợi cho hệ thống nhất định hoặc ngụ ý bất kỳ điều gì khác ngoài việc hiển thị có lỗi trong hệ thống khác cũng có thể gây mất dữ liệu.)

3. Có thực sự có khóa ở cấp độ cá thể, tôi không nghĩ rằng trong môi trường được phân bổ này là môi trường toàn cầu, tôi nghĩ rằng điều này sẽ ở cấp độ cá thể cho từng phân đoạn riêng biệt , vì không cần khóa các phiên bản khác vì không có kiểm tra tính nhất quán cần thiết. Phiên bản 2.2 sắp tới sẽ khóa ở Cấp độ DB, vé cho Cấp thu thập và có thể mở rộng hoặc tài liệu tồn tại (https://jira.mongodb.org/browse/SERVER-4328). Nhưng việc khóa ở mức độ sâu hơn có thể ảnh hưởng đến hiệu suất thực tế của MongoDB, vì việc quản lý khóa là tốn kém.

4. Đoạn di chuyển không gây ra nhiều vấn đề khi cân bằng lại sẽ mất một vài đoạn từ mỗi nút và di chuyển chúng sang nút mới. Nó không bao giờ nên gây ra ping/pong của khối cũng không cân bằng bắt đầu chỉ vì một sự khác biệt của một hoặc hai khối. Điều gì có thể có vấn đề là khi khóa phân mảnh của bạn được chọn sai. Vì vậy, bạn có thể kết thúc với tất cả các mục mới được chèn vào một nút thay vì tất cả. Vì vậy, bạn sẽ thấy thường xuyên hơn tái cân bằng mà có thể gây ra vấn đề, nhưng đó sẽ không phải do mongo hơn là shardkey chọn lựa kém của bạn.

5. Không thể bình luận gì về chắc chắn một

6. Không phải 100% này, nhưng tôi nghĩ Replicasets nơi giới thiệu trong 1,6, vì vậy như đã nói trước đó chưa bao giờ sử dụng phiên bản mới nhất cho sản xuất, ngoại trừ bạn có thể sống với sự mất mát của dữ liệu. Như với tất cả các tính năng mới có khả năng lỗi. Ngay cả thử nghiệm rộng rãi có thể không tiết lộ tất cả các vấn đề. Một lần nữa, luôn luôn chạy một số sao lưu thủ công vì lợi ích của các vị thần, ngoại trừ bạn có thể sống với mất dữ liệu.

7. Không thể nhận xét về điều này. Nhưng trong thực tế, phần mềm có thể chứa các lỗi nghiêm trọng. Nhiều trò chơi cũng phải chịu đựng những vấn đề đó và cũng có những lĩnh vực khác cũng như phần mềm chuối khá nổi tiếng. Không thể bình luận về một cái gì đó cụ thể như thế này trước thời gian MongoDB của tôi.

8. Sao chép có thể gây ra các sự cố như vậy. Tùy thuộc vào chiến lược sao chép này có thể là một vấn đề và một hệ thống khác có thể phù hợp hơn. Nhưng nếu không thực sự thực sự viết một khối lượng công việc lớn, bạn có thể không gặp phải vấn đề như vậy. Thật vậy nó có thể là vấn đề để có 3 bản sao thay đổi bỏ phiếu từ một tổng thể. Bạn có thể chữa trị vấn đề bằng cách thêm nhiều mảnh vỡ hơn.

Như một kết luận chung: Vâng có thể là những vấn đề đó tồn tại, nhưng MongoDB đã làm theo hướng này và tôi càng nghi ngờ rằng DBMS khác chưa bao giờ gặp vấn đề này. Chỉ cần lấy dbms quan hệ truyền thống, liệu những quy mô đó có tốt với quy mô web không cần cho các hệ thống như MongoDB, HBase và những thứ khác. Bạn không thể có được một hệ thống phù hợp với mọi nhu cầu. Vì vậy, bạn phải sống với những nhược điểm của một hoặc cố gắng xây dựng một hệ thống kết hợp của nhiều để có được những gì bạn cần.

Tuyên bố từ chối trách nhiệm: Tôi không liên kết với MongoDB hoặc 10gen, tôi chỉ làm việc với MongoDB và nói với ý kiến ​​của tôi về nó.

Answer 3

Tôi không thể nói cho mọi trường hợp, chỉ riêng của tôi. Tuy nhiên tôi không làm việc cho Mongo hoặc đối thủ cạnh tranh của nó, và tôi đã mất dữ liệu khi sử dụng MongoDB, vì vậy ở đây đi.

Các chỉ trích chính của Mông Cổ trong khoảng thời gian đầu tiên tôi sử dụng nó (2010) là:

• phiên bản Giả sử là ổn định của Mongo có lỗi dữ liệu mất chính không được thực hiện rõ ràng cho người dùng. Ví dụ: trước 1,8 cấu hình không được nhóm có khả năng mất dữ liệu. Điều này đã được tài liệu của Mongo, nhưng không đến mức một lỗi dữ liệu mất trong một DB ổn định phiên bản bình thường sẽ được.

Việc bảo vệ chính những lời chỉ trích đó là:

• Người dùng được thông báo về nguy cơ này, mặc dù không quá rõ ràng. Người dùng nên đọc tất cả tài liệu trước khi bắt đầu.

Trong trường hợp của riêng tôi, tôi đã sử dụng 1,7 trong một cấu hình máy chủ duy nhất nhưng nhận thức được rủi ro. Tôi tắt DB để lùi lại. Các hành động tắt DB tự mất dữ liệu của tôi, 10gen hỗ trợ (miễn phí) nhưng không thể phục hồi dữ liệu.

Sau đó, vào năm 2013, một nghiên cứu được đưa ra để lộ MongoDB defaults can cause significant loss of acknowledged writes trong các phân vùng mạng.

Cũng trong năm 2013 Mongo the official production node Mongo drivers wrapped and threw away all errors.

Kể từ đó, in 2014 a completely different bug in the stable MongoDB driver bit tôi và nhiều người dùng khác.

Trong 2016, the Meteor project has issues with MongoDB queries not always returning all matching documents.

Chính sách sau của MongoDB là listening on all interfaces by default with no admin password set cũng đã hoạt động kém đối với nhiều người dùng. Chúng tôi biết hai thập kỷ trước (và có lẽ trước đó, nhưng lúc đó tôi không hoạt động) khi các hộp Linux bắt đầu bị khai thác bởi việc lắng nghe trên tất cả các cổng mặc định là một ý tưởng tồi, đó là lý do tại sao phần mềm khác tránh điều này.

Đã có những lời chỉ trích chung, lặp lại rằng Mongo có các mặc định không an toàn - như ghi nhận các ghi chưa hoàn thành - để giành được điểm chuẩn hiệu suất. Mongo thường trả lời rằng người dùng cần phải nhận thức được điều này bằng cách đọc tất cả các tài liệu liên quan và có thể sử dụng chọn để sử dụng các tùy chọn an toàn nếu cần.

Answer 4

Tính đến tháng hai năm 2017, the most recent Jepsen analysis of MongoDB gợi ý rằng mất dữ liệu là có thể trong tất cả các phiên bản của MongoDB lên đến MongoDB 3.2.11 và 3.4.0-rc4.

Vì vậy, tại thời điểm câu hỏi được viết (2012) câu trả lời phải là có, những lời chỉ trích đó là hợp lệ từ quan điểm lý thuyết. Nhưng có vẻ như khách hàng không quan tâm đến lý thuyết. Như đã hiển thị, tính chính xác không quan trọng. Điều duy nhất quan trọng là thời gian để tiếp thị. Rất buồn.