Mongodump ảnh hưởng đến hiệu suất ứng dụng rất tệ


8

Chúng tôi có một ví dụ mongo khá lớn (150 GB) không có shending và sao lưu thường xuyên ( mongodump) của chúng tôi có ảnh hưởng rất lớn đến hiệu suất ứng dụng. Tệ hơn thế, do ứng dụng mongo sử dụng quá nhiều, bản sao lưu kéo dài hơn 10 giờ.

Tôi biết rằng chúng tôi cần shending và chúng tôi có kế hoạch chuyển sang ElasticSearch, vì vậy tôi đang tìm kiếm một giải pháp ngắn hạn.

Có điều gì tôi có thể làm để cải thiện điều này, như giới hạn số lượng truy vấn mỗi giây cho mongodump hoặc bất cứ điều gì không?

Chúng tôi có một mongo độc lập trên máy chủ RAM 32 GB 190 GB chia sẻ nó với nginx, rabbitmq và một số thứ nhỏ. Không phải là thiết lập sạch nhất từng có, tôi biết :)

Câu trả lời:


16

Tất cả dữ liệu được truyền qua mongodumpphải được đọc vào bộ nhớ bởi máy chủ MongoDB. Cũng đáng lưu ý rằng mongodumpsao lưu dữ liệu và định nghĩa chỉ mục; thời gian để khôi phục cũng có thể lâu hơn đáng kể so với các phương pháp khác vì mongorestoresẽ cần phải tạo lại bất kỳ chỉ mục phụ nào sau khi dữ liệu được tải.

Như đã lưu ý trong tài liệu MongoDB , mongodumprất hữu ích để sao lưu và khôi phục các triển khai nhỏ nhưng không lý tưởng để chụp các bản sao lưu đầy đủ của các hệ thống lớn hơn:

Khi được kết nối với một phiên bản MongoDB, mongodump có thể ảnh hưởng xấu đến hiệu suất mongod. Nếu dữ liệu của bạn lớn hơn bộ nhớ hệ thống, các truy vấn sẽ đẩy bộ làm việc ra khỏi bộ nhớ, gây ra lỗi trang.

Một máy chủ độc lập giới hạn các tùy chọn sao lưu của bạn nếu bạn cũng muốn duy trì triển khai của mình trong khi thực hiện sao lưu.

Dưới đây là một vài cách tiếp cận được đề xuất theo thứ tự từ hầu hết đến ít được đề xuất nhất:

Cách tiếp cận số 1: Sử dụng dịch vụ sao lưu đám mây

Để có giải pháp ngắn hạn dễ dàng nhất, tôi sẽ xem xét sử dụng dịch vụ sao lưu đám mây thương mại như MongoDB Cloud Manager . MongoDB Cloud Manager cung cấp sao lưu liên tục với các ảnh chụp nhanh theo lịch và chính sách duy trì (xem Chuẩn bị sao lưu để biết thêm thông tin). Dịch vụ đám mây cũng tránh cho bạn phải triển khai bất kỳ máy chủ / cơ sở hạ tầng bổ sung nào, vì vậy ngay cả khi bạn có kế hoạch thực hiện trong tương lai, đây là một giải pháp ngắn hạn hữu ích.

Cách tiếp cận chung sẽ là:

Là một lợi ích bổ sung, Cloud Manager cũng bao gồm một tác nhân giám sát có thể nắm bắt lịch sử số liệu từ việc triển khai của bạn và cho phép bạn định cấu hình cảnh báo.

Cách tiếp cận # 2: Chuyển đổi triển khai của bạn thành một bộ bản sao và sao lưu từ một thứ cấp ẩn

Cách tiếp cận này yêu cầu cung cấp một số cơ sở hạ tầng bổ sung, nhưng giảm tải tác động của sao lưu từ máy chủ chính của bạn. Thông thường các bộ bản sao được cung cấp ít nhất ba thành viên để có tính sẵn sàng cao và chuyển đổi dự phòng tự động, nhưng nếu mục tiêu duy nhất của bạn là sao lưu, bạn có thể sử dụng cấu hình hai máy chủ ít lý tưởng hơn.

Cách tiếp cận chung sẽ là:

  • Cung cấp một máy chủ thứ hai sẽ được sử dụng để sao lưu
  • Chuyển đổi máy chủ độc lập của bạn thành một bộ bản sao .
  • Thêm máy chủ dự phòng của bạn dưới dạng thứ cấp ẩn với mức độ ưu tiên là 0 (nó sẽ không bao giờ trở thành chính) và 0 phiếu.
  • Sử dụng một trong các phương pháp sao lưu được hỗ trợ để thực hiện sao lưu trên thứ cấp ẩn của bạn. Các phương thức sao lưu được liệt kê theo thứ tự khuyến nghị chung: ảnh chụp nhanh hệ thống tệp (nếu được hỗ trợ bởi cấu hình của bạn) hoặc sao chép tệp (giả sử bạn dừng mongod) thích hợp hơn mongodump.
  • (lý tưởng) thêm một thứ cấp mang dữ liệu khác nếu bạn muốn các lợi ích khả dụng và chuyển đổi dự phòng cao của cấu hình bộ bản sao.

Cách tiếp cận # 3: Sử dụng ảnh chụp nhanh hệ thống tập tin (nếu có & phù hợp)

Chiến lược sao lưu ít tác động hơn so với hiện tại của bạn mongodumplà sử dụng ảnh chụp nhanh hệ thống tệp , giả sử bạn có hệ thống tệp hỗ trợ ảnh chụp nhanh (và tất cả dữ liệu và tệp nhật ký của bạn nằm trên một ổ đĩa để bạn có thể có ảnh chụp nhanh nhất quán khi chạy mongod). Mặt trái của ảnh chụp nhanh hệ thống tập tin là tất cả dữ liệu không phải đọc vào bộ nhớ mongod, tuy nhiên ảnh chụp nhanh vẫn có thể có tác động (đặc biệt là khi tạo ảnh chụp nhanh ban đầu trên hệ thống bận). Ảnh chụp nhanh liên tiếp hiệu quả hơn và ít ảnh hưởng hơn, nhưng vẫn chưa phải là giải pháp sao lưu hoàn chỉnh vì ảnh chụp nhanh là cục bộ trên máy chủ của bạn (và hiện tại bạn chỉ có một bản độc lập).

Hãy cẩn thận

  • Cả hai cách tiếp cận # 1 và # 2 đều liên quan đến việc cho phép sao chép để sao lưu dự phòng. Bản sao sẽ thêm một số I / O cục bộ bổ sung trên máy chủ chính của bạn vì tất cả các thao tác ghi được ghi chú trong một bộ sưu tập giới hạn đặc biệt gọi là oplog (nhật ký hoạt động) .

  • Bạn đã đề cập đến một nhu cầu có khả năng bảo vệ trong tương lai, nhưng trước khi làm như vậy tôi sẽ cách ly khối lượng công việc MongoDB của bạn khỏi các quy trình khác chia sẻ cùng một máy chủ. Nếu bạn có thể thay đổi chiến lược sao lưu của mình thành một thứ gì đó hiệu quả hơn mongodump, hãy loại bỏ sự tranh chấp tài nguyên và nắm bắt một số lịch sử số liệu cơ bản để xem xét ... bạn có thể thấy rằng việc bảo vệ là chưa bắt buộc.


3

Tôi đến bữa tiệc muộn nhưng gặp phải vấn đề tương tự chỉ gần đây trên VM với dung lượng RAM tương đối nhỏ (RAM 4 GB, HD 50 GB, dữ liệu 5 GB). Cách giải quyết của chúng tôi là sử dụng tùy chọn của mongodump --forceTableScanvà, nếu nên sử dụng phụ, thêm vào --readPreference secondary. Điều đó đã tăng tốc độ đổ rác của chúng tôi theo hệ số 10 đến 30.

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.