MongoDB luôn là một chủ đề nóng được các lập trình viên chú ý, tuy nhiên việc chỉ phụ thuộc vào một cơ sở dữ liệu thì rất nguy hiểm vì chúng ta sẽ không có phương án thay thế đề phòng cho các trường hợp sự cố xảy ra. Chính vì thế mà hôm nay, Stringee và các bạn sẽ cùng nhau tìm hiểu về Replica Set. Một cơ chế rất thú vị cho phép chúng ta có thể triển khai một cụm các máy chủ MongoDB có khả năng hỗ trợ và đảm nhiệm các nhiệm vụ đọc/ghi thay cho nhau.

1. Giới thiệu về Replica Set trong MongoDB

Replica Set là một nhóm các instance MongoDB để duy trì một cơ sở dữ liệu. Một Replica Set bao gồm một cơ số các node và các node ảo. Trong các node tường mình, sẽ có một thành viên được coi là node chính và các node còn lại sẽ là các node thứ cấp được sao chép dữ liệu từ nút chính. Nếu nút chính bị lỗi một trong những nút phụ sẽ được thay thế thành một nút chính mới.

2. Nhân bản dữ liệu bất đồng bộ

Các node phụ sẽ thực hiện nhân bản các bản ghi từ node gốc và thực hiện các phương thức này tương tự cho data set của chúng một cách bất đồng bộ. Bằng cách thực hiện nhân bản dữ liệu từ node phụ theo node chính, Replica Set có thể tiếp tục đúng chương trình của nó mặc cho việc một hoặc nhiều hơn số thành viên trong group gặp sự cố.

2.1. Slow operations

Từ phiên bản 4.2, các node phụ của Replica Set sẽ cấu hình oplog có thời gian lâu hơn quá trình đồng bộ chậm có thời gian cấu hình. Các bản tin oplog này sẽ có đặc điểm sau:

  • Là các bản ghi log cho các node phụ được log ra trong diagnostic log
  • Được log bằng các component RHEL
applied op: <oplog entry> took <num>ms.
  • Không phụ thuộc vào các log level
  • Không phụ thuộc vào profiling level
  • Có thể sẽ bị ảnh hưởng bởi slowOpSampleRate, từ thuộc vào phiên bản MongoDB
    • Trong phiên bản 4.2, các slow oplog này không bị ảnh hưởng bởi slowOpSampleRate
    • Trong các phiên bản sau, tham số cấu hình này sẽ gây ảnh hưởng lớn tới các node phụ trong Replica Set

2.2. Độ trễ trong quá trình đồng bộ và quản lý luồng dữ liệu

Độ trễ sao chép đề cập đến lượng thời gian cần thiết để sao chép (tức là sao chép) thao tác ghi trên thiết bị chính sang thiết bị phụ. 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 ra áp lực bộ nhớ đệ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 độ áp dụng thao tác ghi chính với mục tiêu giữ độ trễ cam kết phần lớn dưới giá trị tối đa có thể định cấu hình flowControlTargetLagSeconds. Mặc định, cấu hình flow control sẽ được bật.

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

>>> Xem thêm bài viết về MongoDB:

- Tìm hiểu về cơ sở dữ liệu phi quan hệ MongoDB

- Sử dụng map reduce trong MongoDB

- Giới thiệu về GridFS trong MongoDB

3. Tính tự động đảm bảo độ khả dụng

  • Replication cung cấp tính dự phòng và nâng cao tính khả dụng của mongoDB. Với nhiều bản sao chép trên nhiều database server khác nhau, replication nâng cao mức độ chịu lỗi chống lại việc mất dữ liệu trên single database.
  • Trong một số trường hợp, replication có thể cải thiện khả năng đọc dữ liệu vì client có thể đọc dữ liệu trên nhiều database server khác nhau. Duy trì các bản sao dữ liệu làm tăng tính cục bộ và khả dụng của dữ liệu.
  • Các replica cũng có thể duy trì cho các mục đích như khôi phục dữ liệu, sao lưu.
  • Logic kết nối ứng dụng của bạn phải bao gồm khả năng cho phép chuyển đổi dự phòng tự động và các lựa chọn tiếp theo. Trình điều khiển MongoDB có thể phát hiện việc mất dữ liệu chính và tự động thử lại một số thao tác ghi nhất định một lần, cung cấp khả năng xử lý bổ sung tích hợp sẵn cho các chuyển đổi dự phòng và lựa chọn tự động.
  • Việc giảm tùy chọn cấu hình sao chép ElectionTimeoutMillis từ mặc định 10000 (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ể kêu 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 vẫn hoạt động bình thường. Điều này có thể dẫn đến tăng số lần khôi phục cho các thao tác ghi w: 1.

Kết

Trên đây là những phân tích của Stringee về Replica Set trong MongoDB. Đây là một giải pháp mang tính lâu dài và có chiều sâu cho phép các lập trình viên và các nhà vận hành đưa ra cho các hệ thống lớn và có tải trọng cao. Hãy theo dõi chúng tôi để học thêm nhiều kiến thức mới nhé.

Stringee Communication APIs là giải pháp cung cấp các tính năng giao tiếp như gọi thoại, gọi video, tin nhắn chat, SMS hay tổng đài CSKH cho phép tích hợp trực tiếp vào ứng dụng/website của doanh nghiệp nhanh chóng. Nhờ đó giúp tiết kiệm đến 80% thời gian và chi phí cho doanh nghiệp bởi thông thường nếu tự phát triển các tính năng này có thể mất từ 1 - 3 năm.

Bộ API giao tiếp của Stringee hiện đang được tin dùng bởi các doanh nghiệp ở mọi quy mô, lĩnh vực ngành nghề như TPBank, VOVBacsi24, VNDirect, Shinhan Finance, Ahamove, Logivan, Homedy,  Adavigo, bTaskee…

Quý bạn đọc quan tâm xin mời đăng ký NHẬN TƯ VẤN TẠI ĐÂY: