MongoDB
 sql >> Cơ Sở Dữ Liệu >  >> NoSQL >> MongoDB

Những cân nhắc cơ bản khi sao lưu MongoDB

Hệ thống cơ sở dữ liệu có trách nhiệm lưu trữ và đảm bảo tính khả dụng nhất quán của dữ liệu liên quan bất cứ khi nào cần vào bất kỳ thời điểm nào đang hoạt động. Hầu hết các công ty không thể tiếp tục hoạt động kinh doanh sau các trường hợp mất dữ liệu do lỗi cơ sở dữ liệu, cầu nối bảo mật, lỗi của con người hoặc sự cố nghiêm trọng có thể phá hủy hoàn toàn các nút điều hành trong quá trình sản xuất. Việc lưu giữ cơ sở dữ liệu trong cùng một trung tâm dữ liệu có nguy cơ cao bị mất tất cả dữ liệu trong trường hợp xảy ra những sự cố này.

Sao lưu và Sao lưu là những cách thường được sử dụng để đảm bảo dữ liệu có tính khả dụng cao. Việc lựa chọn giữa hai tùy thuộc vào tần suất thay đổi của dữ liệu. Sao lưu được ưu tiên nhất khi dữ liệu không thay đổi thường xuyên hơn và không mong đợi có nhiều tệp sao lưu như vậy. Mặt khác, sao chép được ưu tiên hơn đối với dữ liệu thường xuyên thay đổi bên cạnh một số ưu điểm khác được liên kết như cung cấp dữ liệu ở một vị trí cụ thể bằng cách giảm độ trễ của các yêu cầu. Tuy nhiên, cả sao chép và sao lưu đều có thể được sử dụng để đảm bảo tính toàn vẹn và nhất quán của dữ liệu tối đa trong quá trình khôi phục trong bất kỳ trường hợp hỏng hóc nào.

Sao lưu cơ sở dữ liệu mang lại nhiều lợi thế hơn ngoài việc cung cấp điểm khôi phục để cung cấp kiến ​​thức cơ bản để tạo môi trường mới để phát triển, truy cập mở và dàn dựng mà không cần xử lý với quá trình sản xuất. Nhóm phát triển có thể nhanh chóng và dễ dàng thử nghiệm các tính năng mới được tích hợp và đẩy nhanh quá trình phát triển của chúng. Bản sao lưu cũng có thể được sử dụng để kiểm tra lỗi mã ở bất kỳ nơi nào dữ liệu kết quả không nhất quán.

Cân nhắc khi sao lưu MongoDB

Bản sao lưu được tạo tại một số điểm nhất định để phản ánh (hoạt động như một ảnh chụp nhanh của cơ sở dữ liệu) dữ liệu nào mà cơ sở dữ liệu lưu trữ tại thời điểm nhất định. Nếu cơ sở dữ liệu bị lỗi tại một điểm nhất định, chúng ta có thể sử dụng tệp sao lưu cuối cùng để khôi phục DB về một điểm trước khi nó bị lỗi. Tuy nhiên, cần phải xem xét một số yếu tố trước khi thực hiện khôi phục và chúng bao gồm:

  1. Mục tiêu Điểm khôi phục
  2. Mục tiêu thời gian khôi phục
  3. Cách ly Cơ sở dữ liệu và Ảnh chụp nhanh
  4. Các biến chứng với Sharding
  5. Quá trình khôi phục
  6. Yếu tố hiệu suất và bộ nhớ khả dụng
  7. Tính linh hoạt
  8. Mức độ phức tạp của việc triển khai

Mục tiêu Điểm Khôi phục

Việc này được thực hiện để xác định lượng dữ liệu bạn sẵn sàng bị mất trong quá trình sao lưu và khôi phục. Ví dụ:nếu chúng tôi có dữ liệu người dùng và dữ liệu luồng nhấp, dữ liệu người dùng sẽ được ưu tiên hơn so với phân tích luồng nhấp vì dữ liệu sau có thể được tạo lại bằng cách giám sát các hoạt động trong ứng dụng của bạn sau khi khôi phục. Việc sao lưu liên tục nên được ưu tiên cho các dữ liệu quan trọng như thông tin ngân hàng, dữ liệu ngành sản xuất và thông tin hệ thống truyền thông và phải được thực hiện trong khoảng thời gian gần nhau. Nếu dữ liệu không thay đổi thường xuyên, thì việc mất nhiều dữ liệu có thể ít tốn kém hơn nếu bạn thực hiện một ảnh chụp nhanh được khôi phục, chẳng hạn như 6 tháng hoặc 1 năm trước đó.

Mục tiêu Thời gian Khôi phục

Đây là để phân tích và xác định xem thao tác khôi phục có thể được thực hiện nhanh như thế nào. Trong quá trình khôi phục, các ứng dụng của bạn sẽ phải chịu một số thời gian chết, điều này cũng tỷ lệ thuận với lượng dữ liệu cần được khôi phục. Nếu bạn đang khôi phục một tập hợp lớn dữ liệu thì sẽ mất nhiều thời gian hơn.

Cách ly Cơ sở dữ liệu và Ảnh chụp nhanh

Isolation là thước đo mức độ gần gũi của các ảnh chụp nhanh sao lưu từ các máy chủ cơ sở dữ liệu chính về mặt cấu hình logic và vật lý. Nếu chúng xảy ra đủ gần, thời gian khôi phục sẽ giảm với chi phí tăng khả năng bị phá hủy cùng lúc cơ sở dữ liệu bị phá hủy. Không nên lưu trữ các bản sao lưu và môi trường sản xuất trong cùng một hệ thống để tránh bất kỳ sự gián đoạn nào trên các máy chủ cũng làm giảm các bản sao lưu.

Các biến chứng với Sharding

Đối với hệ thống cơ sở dữ liệu phân tán thông qua sharding, một số bản sao lưu phức tạp được trình bày và các hoạt động ghi có thể phải tạm dừng trên toàn bộ hệ thống. Các phân đoạn khác nhau sẽ hoàn thành các loại sao lưu khác nhau vào những thời điểm khác nhau. Xem xét các bản sao lưu hợp lý và sao lưu Ảnh chụp nhanh,

Bản sao lưu lôgic

  • Các mảnh có kích thước khác nhau do đó sẽ kết thúc vào các thời điểm khác nhau
  • Kết xuất MongoDB-base sẽ bỏ qua --oplog do đó sẽ không nhất quán ở mỗi phân đoạn.
  • Trình cân bằng có thể bị tắt trong khi nó được cho là đang bật chỉ vì một số phân đoạn có thể chưa hoàn thành quá trình khôi phục

Sao lưu Ảnh chụp nhanh

  • Hoạt động tốt cho một bản sao từ phiên bản 3.2 trở lên. Do đó, bạn nên cân nhắc cập nhật phiên bản MongoDB của mình.

Quá trình khôi phục

Một số người thực hiện sao lưu mà không cần kiểm tra xem chúng có hoạt động trong trường hợp khôi phục hay không. Bản sao lưu về bản chất là cung cấp khả năng khôi phục nếu không nó sẽ trở nên vô dụng. Bạn nên luôn cố gắng chạy các bản sao lưu ở các máy chủ thử nghiệm khác nhau để xem chúng có hoạt động hay không.

Yếu tố Hiệu suất và Bộ nhớ Khả dụng

Các bản sao lưu cũng có xu hướng có nhiều kích thước như dữ liệu từ chính cơ sở dữ liệu và cần được nén đủ để không chiếm nhiều dung lượng không cần thiết có thể cắt giảm tài nguyên lưu trữ tổng thể của hệ thống. Chúng có thể được lưu trữ thành các tệp zip do đó làm giảm kích thước tổng thể của chúng. Bên cạnh đó, như đã đề cập trước đây, người ta có thể lưu trữ các bản sao lưu trong các trung tâm dữ liệu khác nhau từ chính cơ sở dữ liệu đó.

Các bản sao lưu có thể xác định các hiệu suất khác nhau của cơ sở dữ liệu mà một số có thể làm suy giảm nó. Trong trường hợp đó, các bản sao lưu liên tục sẽ tạo ra một số khoảng lùi do đó cần được chuyển đổi thành các bản sao lưu theo lịch trình để tránh cạn kiệt các cửa sổ bảo trì. Trong hầu hết các trường hợp, các máy chủ thứ cấp được triển khai để hỗ trợ sao lưu. Trong trường hợp này:

  • Không thể sao lưu một cách nhất quán các nút đơn vì MongoDB sử dụng chức năng đọc không cam kết mà không có oplog khi sử dụng lệnh mongodump và trong trường hợp đó, việc sao lưu sẽ không an toàn.
  • Sử dụng các nút phụ để sao lưu vì quá trình tự mất thời gian tùy theo lượng dữ liệu liên quan và các ứng dụng được kết nối sẽ phải chịu một số thời gian chết. Nếu bạn sử dụng tệp chính cũng phải cập nhật Oplog thì bạn có thể mất một số dữ liệu trong thời gian ngừng hoạt động đó
  • Quá trình khôi phục mất rất nhiều thời gian nhưng tài nguyên lưu trữ được chỉ định rất nhỏ.

Tính linh hoạt

Đôi khi bạn có thể không muốn một số dữ liệu trong quá trình sao lưu, chẳng hạn như ví dụ về Mục tiêu Điểm khôi phục, người ta có thể muốn việc khôi phục được thực hiện và lọc ra dữ liệu người dùng nhấp vào. Để làm như vậy, bạn cần một chiến lược sao lưu một phần sẽ cung cấp sự linh hoạt để lọc ra dữ liệu mà bạn không quan tâm, do đó giảm thời gian khôi phục và tài nguyên sẽ bị lãng phí. Sao lưu gia tăng cũng có thể hữu ích để chỉ những phần dữ liệu đã thay đổi sẽ được sao lưu từ ảnh chụp nhanh cuối cùng thay vì sao lưu toàn bộ cho mọi ảnh chụp nhanh.

Mức độ phức tạp của việc triển khai

Chiến lược sao lưu của bạn phải dễ thiết lập và duy trì theo thời gian. Bạn cũng có thể lên lịch sao lưu để không cần thực hiện thủ công bất cứ khi nào bạn muốn.

Kết luận

Hệ thống cơ sở dữ liệu đảm bảo "sự sống sau khi chết" nếu chỉ có hệ thống sao lưu dự phòng được thiết lập tốt tại chỗ. Cơ sở dữ liệu có thể bị phá hủy bởi các yếu tố thảm họa, lỗi của con người hoặc các cuộc tấn công bảo mật có thể dẫn đến mất mát hoặc hỏng dữ liệu. Trước khi thực hiện sao lưu, người ta phải xem xét loại dữ liệu về kích thước và tầm quan trọng. Luôn luôn không nên giữ các bản sao lưu của bạn trong cùng một trung tâm dữ liệu với cơ sở dữ liệu của bạn để giảm khả năng các bản sao lưu bị hủy đồng thời. Các bản sao lưu có thể làm thay đổi hiệu suất của cơ sở dữ liệu do đó người ta nên cẩn thận về chiến lược sử dụng và thời điểm thực hiện sao lưu. Không thực hiện sao lưu của bạn trên nút chính vì nó có thể dẫn đến thời gian ngừng hoạt động của hệ thống trong quá trình sao lưu và do đó mất dữ liệu quan trọng.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Mongoose Đang cố gắng mở kết nối chưa được đóng kín

  2. Đếm các trường trong Bộ sưu tập MongoDB

  3. Sử dụng trình tạo Active Record sau khi cài đặt Mongoid?

  4. Công cụ MongoDB từ cộng đồng mà cụm điều khiển bổ sung

  5. MongoDB - Tạo bản sao lưu