`Mongodump` lớn theo sau là 'mongorestore`


7

Tôi có một cơ sở dữ liệu Mongo khá lớn (~ 240GB) mà tôi cần chuyển qua một mạng chậm chạp và vào một máy chủ mới.

Theo truyền thống cho những tình huống này, tôi đã tìm thấy rằng một mongodumptheo sau là một mongorestoređã được nhiều nhanh hơn so với một db.cloneCollection()phương pháp. Tuy nhiên, tôi nhận ra rằng việc thực hiện đầy đủ mongodumptheo sau mongorestorelà một sự lãng phí (tôi nghĩ) vì tôi thực hiện tất cả việc truyền dữ liệu, sau đó thực hiện tất cả các thao tác chèn.

Tôi muốn chuyển dữ liệu từ mongo cũ ( mongodumpbước) trong khi đồng thời chèn dữ liệu có sẵn vào cơ sở dữ liệu mới ( mongorestorebước).

Có ai biết làm thế nào để song song hóa quá trình bán phá giá và chèn trong MongoDB không? (Và điều này thực sự sẽ nhanh hơn?)


Bạn đã xem xét thực hiện sao lưu hệ thống tập tin hoặc ảnh chụp nhanh lvm chưa? Đây là cách nhanh hơn nhiều so với mongodump / mongorestore.
Iľja

Tôi đã di chuyển giữa các phiên bản Mongo, vì vậy tôi không chắc liệu nó có hoạt động không.
therealrootuser

Câu trả lời:


12

Trước hết, bạn có thể sử dụng một đường ống

mongodump -h sourceHost -d yourDatabase  | mongorestore -h targetHost -d yourDatabase 

Điều này giúp giảm thời gian, vì mỗi tài liệu được đọc sẽ ít nhiều được khôi phục ngay lập tức targetHost.

Tuy nhiên, điều này có nhược điểm là bạn có thể gặp vấn đề nếu thủ tục bị hủy bỏ vì một số lý do, ví dụ như lỗi mạng. Đối với việc song song hóa, bạn có thể thực hiện các thao tác trên cho mỗi bộ sưu tập, nhưng tôi nghi ngờ rằng bạn sẽ có bất kỳ hiệu suất nào, vì yếu tố hạn chế rất có thể là IO, và thậm chí nếu không, đồng thời rất có thể sẽ là kẻ giết người.

Những gì tôi sẽ làm là tạo ra một bộ bản sao tạm thời , bao gồm máy chủ cũ, máy chủ mới và trọng tài. Đồng bộ hóa ban đầu khá nhanh và ngay cả khi bạn gặp sự cố mạng, cơ chế đồng bộ hóa sẽ đảm bảo mọi thứ đều ổn. Sau khi đồng bộ hóa ban đầu được thực hiện, bạn chỉ cần đặt máy chủ cũ xuống làm chính và khởi động lại máy chủ mới mà không có tùy chọn replSetName , làm cho nó trở thành độc lập một lần nữa. Bây giờ bạn có thể kết nối với máy chủ mới và tất cả dữ liệu được chuyển.

Ưu điểm là điều này hoạt động với thời gian chết tối thiểu và không tham dự. Sau khi bạn khởi tạo bộ bản sao, ứng dụng của bạn vẫn có thể sử dụng máy chủ cũ và thậm chí dữ liệu mới sẽ được tự động chuyển sang máy chủ mới. Vì vậy, bạn không cần phải ngồi ngoài nó - và tất cả chúng ta đều biết rằng quá trình có thể kết thúc lúc 3 giờ sáng, bất kể múi giờ. ;) Bất cứ lúc nào sau khi đồng bộ hóa ban đầu kết thúc (thậm chí vài giờ hoặc vài ngày sau đó), bạn có thể biến máy chủ mới thành độc lập và thay đổi chuỗi kết nối của ứng dụng của bạn sang máy chủ mới. Đây là vấn đề 2 hoặc 3 phút, nếu được lên kế hoạch hợp lý.

Biên tập

Phương pháp này có một nhược điểm, tuy nhiên: Bạn chỉ có thể nâng cấp từ một bản phát hành lên một bản phát hành cao hơn. Vì vậy, di chuyển từ 2.4 (khảo cổ học tại thời điểm viết bài này) sang 3,4 (tiên tiến), bạn sẽ phải lặp lại quá trình nhiều lần:

  • Từ 2,4 đến 2,6
  • Từ 2.6 đến 3.0
  • Từ 3.0 đến 3.2
  • Từ 3,2 đến 3,4

5

Câu trả lời được chấp nhận không phù hợp với tôi, vì nó thiếu một số thông số:

mongodump --host source:port --db databasename --gzip --archive | \
mongorestore --drop -vvvvvv -h target:port --db databasename --gzip --archive

--gzipcó thể và có lẽ nên được bỏ qua, vì điều này chỉ nén dữ liệu trong đường ống (trên bus của máy thực thi lệnh), chứ không phải dữ liệu (qua dây) giữa cơ sở dữ liệu và máy thực thi lệnh. Có lẽ nó chỉ gây ra chi phí điện toán không cần thiết. Nếu tôi không nhầm, MongoDB sẽ nén dữ liệu qua dây (giữa máy chủ và trình điều khiển).

--archivekhông có tên tệp ghi stdoutvà đọc stdintương ứng, nếu không có tên tệp nào được đưa ra

--drop thay thế hoàn toàn cơ sở dữ liệu đích.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.