Cách được đề xuất để sao lưu các tập dữ liệu lớn trong MongoDB là gì? Giả sử chúng tôi có kích thước dữ liệu theo thứ tự 10TB - bạn sẽ sao lưu dữ liệu đó như thế nào?
Chúng tôi đang xem xét một nút đặt bản sao ẩn, có thể bị trì hoãn. Sự chậm trễ sẽ bảo vệ chúng ta khỏi những giọt vô tình của toàn bộ cơ sở dữ liệu. Đây có phải là một giải pháp khả thi không, và bạn có đề nghị điều tra nào khác không?
Cảm ơn!
Câu trả lời:
Với nhu cầu 10TB để được sao lưu, điều này hơi phức tạp.
Mặc dù các thành viên bộ sao chép bị trì hoãn có thể cung cấp một cách tương đối dễ dàng để giúp bạn thực hiện các thao tác tình cờ, không có sự thay thế nào cho các bản sao lưu thích hợp, rất giống như RAID không phải là sự thay thế cho các bản sao lưu dựa trên hệ thống tệp.
Điều đó phụ thuộc rất nhiều vào cách thiết lập của bạn trông như thế nào.
Với 10TB, tôi giả sử bạn có một số loại SAN được đính kèm. Cách dễ nhất để sao lưu MongoDB trong các môi trường đó là đảm bảo rằng bạn đã ghi nhật ký được kích hoạt cả trên hệ thống tập tin và MongoDB và chỉ cần chụp nhanh vào khối lượng SAN của một trong hai phần phụ, có thể là một ẩn để đảm bảo các hoạt động của bạn không Sẽ không bị gián đoạn. Việc này thường chỉ mất vài giây, nhưng vui lòng chắc chắn rằng cửa sổ oplog sao chép của bạn là đủ. Nếu không, bạn có thể cần phải đồng bộ lại thứ cấp.
Tôi phải không đồng ý với RolandoMyQueryDBA về việc sử dụng mongodump. Trước hết, nó áp đặt các khóa trên máy chủ. Mặc dù chúng được nâng lên tương đối nhanh, nhưng số lượng khóa có thể tăng lên và gây trở ngại cho các hoạt động của bạn, trừ khi chạy trên một nút ẩn hoặc khi không có tùy chọn đọc đánh vào các mục phụ. Thêm vào đó, nó không chính xác nhanh. Tôi hy vọng nó sẽ chạy trong nhiều giờ, ít nhất, rất có thể mất nhiều thời gian hơn cửa sổ sao lưu của bạn. Lưu ý bên lề: Luôn luôn chạy mongodump với--oplog tùy chọn. Cũng nên nhớ rằng mongodump không sao lưu các chỉ mục, mà là các thao tác để tạo các chỉ mục. Những chỉ số đó phải được tạo lại trong quá trình khôi phục, điều này có thể làm tăng ồ ạt thời gian bạn cần cho nó. Theo kinh nghiệm của tôi, nếu bạn phải khôi phục cơ sở dữ liệu, bạn muốn có nó càng nhanh càng tốt. Một điểm khác tại sao mongodump không phù hợp để sao lưu 10TB.
Bạn có thể thực hiện một ảnh chụp nhanh LVM trên một cá thể mongod đang chạy với điều kiện bạn đã bật tính năng ghi nhật ký trong mongod (và theo kinh nghiệm của tôi, việc bật nó ở cấp độ FS cũng không ảnh hưởng gì). Tuy nhiên, ảnh chụp nhanh LVM đi kèm với một số hàm ý. Đầu tiên, rõ ràng bạn cần có đủ dung lượng đĩa để có thể thực hiện các thay đổi trong các hoạt động sao lưu. Hãy để tôi làm rõ điều đó.
Giả sử bạn có tốc độ thay đổi hàng giờ là 500 GB. Và bạn muốn sao lưu dự phòng của mình bị xóa trước khi nó được tải lên một số lưu trữ. Ngay cả khi sử dụng song song bzip2 , việc nén 10TB sẽ cần vài giờ để hoàn thành, đơn giản vì thực tế là rất có thể thông lượng lưu trữ lớn của bạn sẽ trở thành yếu tố giới hạn của bạn. Giả sử sẽ mất 2 giờ để nén dữ liệu xuống còn 2TB. Vì vậy, bây giờ chúng tôi sẽ cần tổng dung lượng ổ đĩa trống 2TB + 2 * 500GB, cần 1TB cho ảnh chụp nhanh LVM. Điều này sẽ tạo ra nhu cầu cung cấp quá mức hệ thống tập tin của bạn bằng cách ít nhất30%. Trong trường hợp bạn muốn có một mức an toàn phù hợp, điều này có thể dễ dàng tăng lên 60-70% (20% cho hệ số sử dụng là 0,8 cho hệ thống tệp gốc, tương tự đối với kích thước ảnh chụp nhanh cộng với không gian cần thiết cho bản sao lưu được nén. ). Trong hầu hết các môi trường sản xuất, điều đó là không thể chấp nhận được, vì việc cung cấp quá mức sẽ là tĩnh (Bạn sẽ không muốn một tập lệnh sao lưu tự động xử lý với LVM của mình chứ?)
Mặc dù sao lưu MMS có một số tính năng tuyệt vời (sao lưu liên tục, phục hồi thời gian dễ dàng), nhưng nó đi kèm với một nhược điểm nghiêm trọng: thẻ giá của nó cho các triển khai lớn có thể dễ dàng trong hàng ngàn. Với tốc độ thay đổi giả định hàng giờ là 500 GB trên 10TB đó, đây sẽ là một khoản tiền trung bình sáu con số cho các bản sao lưu đám mây . Hàng tháng.
Tôi đề nghị anh ta nên đăng ký doanh nghiệp cho các máy chủ của bạn để đủ điều kiện có phiên bản MMS tiền đề, bao gồm cả sao lưu.
Dưới đây là các tùy chọn tôi sẽ thực hiện theo thứ tự ưu tiên giảm dần.
Có hai lựa chọn
Nếu bạn không bận tâm đến thời gian chết, điều đơn giản nhất để làm là
service mongod stopThực hiện một ảnh chụp nhanh LVM hoặc một lực lượng mạnh mẽ cpcủa thư mục dữ liệu Mongo sang một đĩa khác
service mongod startTất nhiên, bạn không muốn thời gian chết nếu 10TB dữ liệu nằm trên một máy độc lập.
Nếu bạn có một bộ bản sao có ba nút, hãy sử dụng một trong các nút để sao lưu
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Sử dụng nút với "_id' : 3tất cả các bản sao lưu vật lý của bạn. Do đó, không có thời gian chết. Để có được ảnh chụp nhanh vào nửa đêm, bạn có thể khởi chạy bản sao lưu lúc 1:00 sáng vì nút ẩn chậm hơn 1 giờ.
Tất nhiên, nhược điểm là có thêm hai máy chủ với 10TB mỗi máy chủ và sự tỉnh táo của sysadmin có nguy cơ.
Bạn có thể sử dụng mongodump đối với máy độc lập nhưng bạn phải mong đợi sự suy giảm hiệu năng vì mongodump là một chương trình máy khách sử dụng kết nối như bất kỳ kết nối nào khác.
Nếu bạn muốn sao lưu tại thời điểm, bạn nên sử dụng
mongodump --oplog Sao lưu logic BSON sẽ nhỏ hơn (đặc biệt là được nén hoặc nén) so với sao lưu vật lý.
Sử dụng mongodump --oplogtốt nhất sẽ được thực hiện đối với các nút ẩn. Bằng cách đó, không có hiệu suất đánh vào Master.
Tôi còn khá mới đối với MongoDB (MongoDBA tình cờ / ngẫu nhiên). Tôi hy vọng câu trả lời của tôi sẽ giúp.