Bản sao mongodb đặt độ trễ đồng bộ hóa

Tại thời điểm T, thao tác ghi cuối cùng được áp dụng trên bộ bản sao được chỉ định ABC chậm hơn so với thao tác gần đây nhất được áp dụng trên

Điều kiện cảnh báo

Bạn có thể định cấu hình các điều kiện cảnh báo trong trang cấp dự án để kích hoạt cảnh báo

Để tìm hiểu thêm về tình trạng cảnh báo, hãy xem

Kích hoạt phổ biến

  • Một bộ bản sao nhàn rỗi. Độ trễ sao chép được báo cáo thực sự chỉ là thời gian kể từ lần ghi cuối cùng. Độ trễ sao chép được tính giữa thời gian thao tác cuối cùng trên sơ cấp và thời gian của thao tác cuối cùng mà thiết bị thứ cấp nhận được. Nếu một bộ bản sao chỉ được ghi vào 10 phút một lần, độ trễ sao chép sẽ là 10 phút ngay sau khi ghi được thực hiện cho bộ chính và ngay trước lần ghi tiếp theo được sao chép vào bộ phụ
  • Thứ cấp được cung cấp dưới mức, có nghĩa là nó cần nhiều tài nguyên được phân bổ hơn và không thể theo kịp chính (phổ biến nếu sử dụng thứ hai để mở rộng quy mô đọc)
  • Không đủ băng thông hoặc một số sự cố mạng khác giữa mạng chính và mạng phụ

Khắc phục sự cố ngay lập tức

  • Điều chỉnh cài đặt cho cảnh báo này để chỉ kích hoạt nếu độ trễ sao chép kéo dài hơn 2 phút. Điều này sẽ làm giảm khả năng dương tính giả
  • Giải quyết các sự cố kết nối mạng giữa sơ cấp và thứ cấp

Để tìm hiểu thêm, hãy xem Khắc phục sự cố Bộ bản sao trong hướng dẫn sử dụng MongoDB

Thực hiện một giải pháp dài hạn

  • Tăng băng thông giữa sơ cấp và thứ cấp
  • Di chuyển (hoặc nâng cấp tại chỗ) máy phụ sang máy được cung cấp giống hệt (hoặc tốt hơn) cho máy chính hiện tại

Theo dõi tiến trình của bạn

Xem các biểu đồ sau để theo dõi tiến trình của bạn

  • Mạng

    Giám sát số liệu mạng để theo dõi hiệu suất mạng

  • Khoảng trống sao chép

    Theo dõi khoảng trống sao chép để xác định xem thứ cấp có thể rơi ra khỏi oplog hay không

  • Độ trễ sao chép

    Theo dõi độ trễ sao chép để xác định xem thứ cấp có thể rơi khỏi oplog hay không

Để tìm hiểu thêm, xem

←   Khắc phục máy chủ Khắc phục lỗi chính bị mất  →

© MongoDB, Inc 2008-nay. MongoDB, Mongo và logo chiếc lá là các nhãn hiệu đã đăng ký của MongoDB, Inc

Bộ bản sao trong MongoDB là một nhóm các quy trình duy trì cùng một bộ dữ liệu. Bộ bản sao cung cấp dự phòng và là cơ sở cho tất cả các triển khai sản xuất. Phần này giới thiệu về bản sao trong MongoDB cũng như các thành phần và kiến ​​trúc của bộ bản sao. Phần này cũng cung cấp hướng dẫn cho các tác vụ phổ biến liên quan đến bộ bản sao

Dự phòng và tính sẵn sàng của dữ liệu

Sao chép cung cấp dự phòng và tăng. Với nhiều bản sao dữ liệu trên các máy chủ cơ sở dữ liệu khác nhau, sao chép cung cấp mức độ chịu lỗi đối với việc mất một máy chủ cơ sở dữ liệu

Trong một số trường hợp, sao chép có thể tăng khả năng đọc vì máy khách có thể gửi các thao tác đọc đến các máy chủ khác nhau. Duy trì các bản sao dữ liệu trong các trung tâm dữ liệu khác nhau có thể tăng vị trí dữ liệu và tính khả dụng cho các ứng dụng phân tán. Bạn cũng có thể duy trì các bản sao bổ sung cho các mục đích chuyên dụng, chẳng hạn như khắc phục thảm họa, báo cáo hoặc sao lưu

Sao chép trong MongoDB

Bộ bản sao là một nhóm các phiên bản duy trì cùng một bộ dữ liệu. Một bộ bản sao chứa một số nút mang dữ liệu và tùy chọn một nút trọng tài. Trong số các nút mang dữ liệu, một và chỉ một thành viên được coi là nút chính, trong khi các nút khác được coi là nút phụ

Nút chính nhận tất cả các thao tác ghi. Một bộ bản sao chỉ có thể có một bản chính có khả năng xác nhận ghi với mối quan tâm ghi; . Sơ cấp ghi lại tất cả các thay đổi đối với bộ dữ liệu của nó trong nhật ký hoạt động của nó, i. e. xin lỗi. Để biết thêm thông tin về hoạt động của nút chính, hãy xem Bản sao đặt chính

Phần phụ sao chép oplog của phần chính và áp dụng các thao tác cho tập dữ liệu của chúng sao cho tập dữ liệu của phần phụ phản ánh tập dữ liệu của phần chính. Nếu bầu cử sơ bộ không khả dụng, thì bầu cử phụ đủ điều kiện sẽ tổ chức một cuộc bầu cử để bầu cho mình bầu cử sơ bộ mới. Để biết thêm thông tin về các thành viên phụ, xem Bộ bản sao Thành viên phụ

Trong một số trường hợp (chẳng hạn như bạn có một bản chính và bản phụ nhưng hạn chế về chi phí không cho phép thêm một bản phụ khác), bạn có thể chọn thêm một phiên bản vào bộ bản sao làm trọng tài. Một trọng tài tham gia nhưng không giữ dữ liệu (i. e. không cung cấp dự phòng dữ liệu). Để biết thêm thông tin về người phân xử, xem Bản sao Set Arbiter

Trọng tài sẽ luôn là trọng tài trong khi trọng tài chính có thể từ chức và trở thành trọng tài phụ và trọng tài phụ có thể trở thành trọng tài chính trong cuộc bầu cử

Sao chép không đồng bộ

Phần phụ sao chép oplog của phần chính và áp dụng các hoạt động cho tập dữ liệu của chúng một cách không đồng bộ. Bằng cách để bộ dữ liệu của bộ phụ phản ánh bộ dữ liệu của bộ chính, bộ bản sao có thể tiếp tục hoạt động bất chấp sự cố của một hoặc nhiều thành viên

Để biết thêm thông tin về cơ chế sao chép, hãy xem và

Hoạt động chậm

Bắt đầu từ phiên bản 4. 2, các thành viên phụ của bộ bản sao hiện mất nhiều thời gian hơn ngưỡng hoạt động chậm để áp dụng. Những tin nhắn oplog chậm này

  • Được đăng nhập cho các phần thứ hai trong

  • Được đăng nhập dưới thành phần có văn bản applied op: took ms

  • Không phụ thuộc vào cấp độ nhật ký (ở cấp độ hệ thống hoặc thành phần)

  • Không phụ thuộc vào mức độ hồ sơ

  • Có thể bị ảnh hưởng bởi , tùy thuộc vào phiên bản MongoDB của bạn

    • Trong MongoDB 4. 2, các mục oplog chậm này không bị ảnh hưởng bởi. MongoDB ghi nhật ký tất cả các mục oplog chậm bất kể tốc độ mẫu

    • Trong MongoDB 4. 4 trở lên, các mục oplog chậm này bị ảnh hưởng bởi

Trình hồ sơ không ghi lại các mục oplog chậm

Độ trễ sao chép và kiểm soát luồng

đề cập đến lượng thời gian cần thiết để sao chép (i. e. sao chép) một thao tác ghi trên một. Một số khoảng thời gian trễ nhỏ có thể được chấp nhận, nhưng các vấn đề nghiêm trọng sẽ xuất hiện khi độ trễ sao chép tăng lên, bao gồm cả việc tạo áp lực bộ đệm trên bộ đệm chính.

Bắt đầu từ MongoDB 4. 2, quản trị viên có thể giới hạn tốc độ mà ứng dụng chính áp dụng ghi của nó với mục tiêu giữ độ trễ dưới giá trị tối đa có thể định cấu hình

Theo mặc định, điều khiển luồng là

Ghi chú

Để kiểm soát luồng tham gia, cụm bản sao được thiết lập/phân đoạn phải có. của

db.serverStatus( { mirroredReads: 1 } )
5 và mối quan tâm đọc. Nghĩa là, điều khiển luồng đã bật sẽ không có tác dụng nếu FCV không phải là
db.serverStatus( { mirroredReads: 1 } )
5 hoặc nếu phần lớn mối quan tâm đã đọc bị tắt

Với kiểm soát luồng được bật, khi độ trễ tăng lên gần với , ghi trên chính phải lấy vé trước khi sử dụng khóa để áp dụng ghi. Bằng cách giới hạn số lượng vé được phát hành mỗi giây, cơ chế kiểm soát luồng cố gắng giữ độ trễ dưới mục tiêu

Để biết thêm thông tin, xem và

Chuyển đổi dự phòng tự động

Khi một thành viên chính không liên lạc với các thành viên khác của nhóm trong khoảng thời gian đã định cấu hình (10 giây theo mặc định), một thành viên phụ đủ điều kiện sẽ yêu cầu một cuộc bầu cử để tự đề cử mình làm thành viên chính mới. Cụm cố gắng hoàn thành bầu cử sơ bộ mới và tiếp tục hoạt động bình thường

Bộ bản sao không thể xử lý các thao tác ghi cho đến khi cuộc bầu cử hoàn tất thành công. Bộ bản sao có thể tiếp tục phân phối các truy vấn đã đọc nếu các truy vấn đó được định cấu hình trong khi bản chính ngoại tuyến

Thời gian trung bình trước khi một cụm bầu chọn chính mới thường không vượt quá 12 giây, giả sử mặc định. Điều này bao gồm thời gian cần thiết để đánh dấu chính là

và gọi và hoàn thành một. Bạn có thể điều chỉnh khoảng thời gian này bằng cách sửa đổi tùy chọn cấu hình sao chép. Các yếu tố như độ trễ mạng có thể kéo dài thời gian cần thiết để hoàn tất các cuộc bầu cử bộ bản sao, do đó ảnh hưởng đến lượng thời gian mà cụm của bạn có thể hoạt động mà không có cuộc bầu chọn chính. Các yếu tố này phụ thuộc vào kiến ​​trúc cụm cụ thể của bạn

Hạ thấp tùy chọn cấu hình sao chép từ mongod3 mặc định (10 giây) có thể giúp phát hiện lỗi chính nhanh hơn. Tuy nhiên, cụm có thể gọi các cuộc bầu cử thường xuyên hơn do các yếu tố như độ trễ mạng tạm thời ngay cả khi cụm chính hoạt động bình thường. Điều này có thể dẫn đến tăng hoạt động ghi

Logic kết nối ứng dụng của bạn phải bao gồm dung sai đối với chuyển đổi dự phòng tự động và các cuộc bầu cử tiếp theo. Trình điều khiển MongoDB có thể tự động phát hiện lỗi chính và một lần duy nhất, cung cấp khả năng xử lý tích hợp bổ sung cho chuyển đổi dự phòng tự động và bầu cử

Trình điều khiển tương thích cho phép ghi có thể thử lại theo mặc định

Bắt đầu từ phiên bản 4. 4, MongoDB cung cấp làm ấm trước bộ đệm của các thành viên phụ có thể bầu chọn với dữ liệu được truy cập gần đây nhất. Làm ấm trước bộ đệm của bộ đệm thứ cấp có thể giúp khôi phục hiệu suất nhanh hơn sau một cuộc bầu cử

Để tìm hiểu thêm về quy trình chuyển đổi dự phòng của MongoDB, hãy xem

Đọc hoạt động

đọc tùy chọn

Theo mặc định, khách hàng đọc từ chính;

đến thứ cấp có nghĩa là các lần đọc từ thứ cấp có thể trả về dữ liệu không phản ánh trạng thái của dữ liệu trên sơ cấp

Các giao dịch nhiều tài liệu chứa thao tác đọc phải sử dụng tùy chọn đọc. Tất cả các hoạt động trong một giao dịch nhất định phải định tuyến đến cùng một thành viên

Để biết thông tin về cách đọc từ các bộ bản sao, hãy xem Tùy chọn đọc

Hiển thị dữ liệu

Tùy thuộc vào mối quan tâm đã đọc, khách hàng có thể xem kết quả ghi trước khi ghi

  • Bất kể mối quan tâm ghi của một lần ghi, các ứng dụng khách khác sử dụng hoặc đọc mối quan tâm có thể thấy kết quả của thao tác ghi trước khi thao tác ghi được xác nhận cho ứng dụng khách phát hành

  • Khách hàng sử dụng hoặc đọc mối quan tâm có thể đọc dữ liệu mà sau đó có thể được khôi phục trong quá trình chuyển đổi dự phòng bộ bản sao

Đối với các hoạt động trong giao dịch nhiều tài liệu, khi giao dịch được thực hiện, tất cả các thay đổi dữ liệu được thực hiện trong giao dịch được lưu và hiển thị bên ngoài giao dịch. Nghĩa là, một giao dịch sẽ không thực hiện một số thay đổi của nó trong khi khôi phục các thay đổi khác

Cho đến khi giao dịch được thực hiện, các thay đổi dữ liệu được thực hiện trong giao dịch sẽ không hiển thị bên ngoài giao dịch

Tuy nhiên, khi một giao dịch ghi vào nhiều phân đoạn, không phải tất cả các hoạt động đọc bên ngoài đều cần đợi kết quả của giao dịch đã cam kết hiển thị trên các phân đoạn. Ví dụ: nếu một giao dịch được thực hiện và ghi 1 hiển thị trên phân đoạn A nhưng ghi 2 chưa hiển thị trên phân đoạn B, thì việc đọc bên ngoài tại mối quan tâm đã đọc có thể đọc kết quả của ghi 1 mà không thấy ghi 2

Để biết thêm thông tin về cách ly đọc, tính nhất quán và lần truy cập gần đây cho MongoDB, hãy xem Cách ly đọc, tính nhất quán và lần truy cập gần đây

Đọc nhân đôi

Các lần đọc được nhân đôi làm giảm tác động của các cuộc bầu cử sơ bộ sau khi ngừng hoạt động hoặc bảo trì theo kế hoạch. Sau một tập hợp bản sao, phần phụ đảm nhận vai trò phần chính mới sẽ cập nhật bộ đệm của nó khi có truy vấn mới. Trong khi bộ đệm đang khởi động, hiệu suất có thể bị ảnh hưởng

Bắt đầu từ phiên bản 4. 4, các lần đọc được nhân đôi làm ấm trước bộ đệm của các thành viên bộ bản sao thứ cấp. Để làm ấm trước bộ đệm của các bộ đệm thứ cấp có thể chọn, bộ đệm chính phản chiếu một mẫu của bộ nhớ đệm mà nó nhận được cho các bộ đệm thứ cấp có thể chọn

Kích thước của tập hợp con của các thành viên bộ bản sao thứ cấp nhận được các lần đọc được nhân đôi có thể được định cấu hình bằng tham số. Xem để biết thêm chi tiết

Ghi chú

Các lần đọc được nhân đôi không ảnh hưởng đến phản hồi của chính đối với khách hàng. Các lần đọc rằng các bản sao chính đối với các bản sao phụ là các hoạt động "cháy và quên". Chính không chờ phản hồi

Hoạt động được hỗ trợ

Đọc phản chiếu hỗ trợ các thao tác sau

  • (Cụ thể, bộ lọc được gửi dưới dạng đọc phản chiếu)

  • (Cụ thể, bộ lọc được gửi dưới dạng đọc phản chiếu)

Kích hoạt/Vô hiệu hóa hỗ trợ cho Mirrored Reads

Bắt đầu từ MongoDB 4. 4, tính năng đọc phản chiếu được bật theo mặc định và sử dụng giá trị mặc định là mongod9. Để vô hiệu hóa các lần đọc được nhân đôi, hãy đặt tham số thành { w: "majority" }1

db.adminCommand( {  setParameter: 1,  mirrorReads: { samplingRate: 0.0 }} )

Với tốc độ lấy mẫu lớn hơn { w: "majority" }2, các bản sao chính phản ánh một tập hợp con của các bản sao phụ. Với tỷ lệ lấy mẫu là mongod9, phần chính phản ánh một phần trăm số lần đọc được hỗ trợ mà nó nhận được cho mỗi phần phụ có thể chọn

Hãy xem xét một bộ bản sao bao gồm một bộ chính và hai bộ phụ có thể lựa chọn. Nếu phần chính nhận được { w: "majority" }5 hoạt động có thể được nhân đôi và tốc độ lấy mẫu là mongod9, thì phần chính sẽ gửi khoảng { w: "majority" }7 lần đọc cho phần phụ có thể lựa chọn. Mỗi phụ có thể chọn chỉ nhận được một phần nhỏ trong số 10 lần đọc. Mỗi lần đọc được nhân đôi, được gửi đến một lựa chọn không trống được chọn ngẫu nhiên của các thứ cấp có thể bầu chọn

Thay đổi tốc độ lấy mẫu cho các lần đọc được nhân đôi

Để thay đổi tốc độ lấy mẫu cho các lần đọc được phản chiếu, hãy đặt tham số thành một số trong khoảng từ { w: "majority" }2 đến mongod0

  • Tốc độ lấy mẫu của { w: "majority" }2 vô hiệu hóa các lần đọc được nhân đôi

  • Tỷ lệ lấy mẫu của một số trong khoảng từ { w: "majority" }2 đến mongod0 dẫn đến việc chuyển tiếp chính một mẫu ngẫu nhiên của tỷ lệ mẫu được chỉ định tới các ứng dụng phụ có thể lựa chọn

  • Tỷ lệ lấy mẫu của mongod0 dẫn đến tất cả chuyển tiếp chính đến các thứ cấp có thể lựa chọn

Để biết chi tiết, xem

Số lần đọc được nhân đôi

Bắt đầu từ MongoDB 4. 4, lệnh và phương thức shell trả về số liệu nếu bạn chỉ định trường trong thao tác

db.serverStatus( { mirroredReads: 1 } )

giao dịch

Bắt đầu từ MongoDB 4. 0, các giao dịch nhiều tài liệu có sẵn cho các bộ bản sao

Các giao dịch nhiều tài liệu chứa thao tác đọc phải sử dụng tùy chọn đọc. Tất cả các hoạt động trong một giao dịch nhất định phải định tuyến đến cùng một thành viên

Cho đến khi giao dịch được thực hiện, các thay đổi dữ liệu được thực hiện trong giao dịch sẽ không hiển thị bên ngoài giao dịch

Tuy nhiên, khi một giao dịch ghi vào nhiều phân đoạn, không phải tất cả các hoạt động đọc bên ngoài đều cần đợi kết quả của giao dịch đã cam kết hiển thị trên các phân đoạn. Ví dụ: nếu một giao dịch được thực hiện và ghi 1 hiển thị trên phân đoạn A nhưng ghi 2 chưa hiển thị trên phân đoạn B, thì việc đọc bên ngoài tại mối quan tâm đã đọc có thể đọc kết quả của ghi 1 mà không thấy ghi 2

Thay đổi luồng

Bắt đầu từ MongoDB 3. 6, các luồng thay đổi có sẵn cho các bộ bản sao và cụm phân đoạn. Các luồng thay đổi cho phép các ứng dụng truy cập các thay đổi dữ liệu theo thời gian thực mà không gặp phải sự phức tạp và rủi ro khi theo dõi oplog. Các ứng dụng có thể sử dụng các luồng thay đổi để đăng ký tất cả các thay đổi dữ liệu trên một hoặc nhiều bộ sưu tập

Tính năng bổ sung

Bộ bản sao cung cấp một số tùy chọn để hỗ trợ nhu cầu ứng dụng. Ví dụ: bạn có thể triển khai một bộ bản sao với các thành viên trong nhiều trung tâm dữ liệu hoặc kiểm soát kết quả bầu cử bằng cách điều chỉnh một số thành viên. Các bộ bản sao cũng hỗ trợ các thành viên chuyên dụng cho các chức năng báo cáo, khắc phục thảm họa hoặc sao lưu

Trong trường hợp nào là khôn ngoan khi sử dụng các thành viên bộ bản sao bị trì hoãn?

Ví dụ: nếu thời gian hiện tại là 09. 52 và một thành viên bị trì hoãn một giờ, thành viên bị trì hoãn không có hoạt động nào gần đây hơn 08. 52 . Bởi vì các thành viên bị trì hoãn là một "bản dự phòng cuộn" hoặc một ảnh chụp nhanh "lịch sử" đang chạy của tập dữ liệu, nên chúng có thể giúp bạn khôi phục từ nhiều loại lỗi khác nhau của con người.

Điều gì gây ra độ trễ sao chép trong MongoDB?

Tại sao bạn gặp phải độ trễ sao chép MongoDB? . the secondary node cannot replicate data fast enough to keep up with the rate that data is being written to the primary node.

Bản sao MongoDB có đồng bộ không?

MongoDB sử dụng bản sao không đồng bộ để phân phối dữ liệu tới các nút phụ, sử dụng oplog (nhật ký hoạt động), nhật ký giao dịch cho các hoạt động ghi trong .

Lợi thế chính của việc có một thành viên bộ bản sao bị trì hoãn là gì?

Ưu điểm chính của việc có thành viên bộ bản sao bị trì hoãn là gì? . it will take one hour before changes on the Primary are replicated to this member.