Bộ bản sao MongoDB hoạt động như thế nào?

Trong bối cảnh mở rộng cơ sở dữ liệu MongoDB, nó có một số tính năng được gọi là Replication và Sharding. Sao chép có thể hiểu đơn giản là sao chép tập dữ liệu trong khi sharding là phân vùng tập dữ liệu thành các phần riêng biệt. Bằng cách chia nhỏ, bạn đã chia bộ sưu tập của mình thành các phần khác nhau. Sao chép cơ sở dữ liệu của bạn có nghĩa là bạn tạo các hình ảnh của tập dữ liệu của mình. Về chức năng được cung cấp.  

Nhân rộng

Replication là phương pháp sao chép dữ liệu trên nhiều máy chủ. Ví dụ: chúng tôi có một ứng dụng và nó đọc và ghi dữ liệu vào cơ sở dữ liệu và cho biết máy chủ A này có tên và số dư sẽ được sao chép/sao chép sang hai máy chủ khác ở hai vị trí khác nhau

Bằng cách này, sẽ có dự phòng và tăng tính khả dụng của dữ liệu 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. Vì vậy, nó sẽ tăng hiệu suất đọc tỷ lệ. Tập hợp các máy chủ duy trì cùng một bản sao dữ liệu được gọi là máy chủ bản sao hoặc phiên bản MongoDB

Các tính năng chính của bản sao

  • Bộ bản sao là cụm gồm N nút khác nhau duy trì cùng một bản sao của bộ dữ liệu
  • Máy chủ chính nhận tất cả các thao tác ghi và ghi lại tất cả các thay đổi đối với dữ liệu tôi. e, xin lỗi
  • Sau đó, các thành viên phụ sao chép và áp dụng những thay đổi này trong quy trình không đồng bộ
  • Tất cả các nút phụ được kết nối với các nút chính. có một tín hiệu nhịp tim từ các nút chính. Nếu máy chủ chính ngừng hoạt động, một máy chủ phụ đủ điều kiện sẽ giữ máy chủ chính mới

Tại sao sao chép?

  • Khả năng phục hồi thảm họa dữ liệu cao
  • Không có thời gian chết để bảo trì [như xây dựng lại chỉ mục sao lưu và nén]
  • Đọc Scaling [Các bản sao bổ sung để đọc từ]

Sao chép được hình thành như thế nào?

Để thực hiện sao chép trong MongoDB, trước tiên chúng ta cần tạo các bộ sao chép và cấp quyền cho tệp script. Cú pháp cơ bản của –replSet  là −

mongod --port "PORT" --dbpath "YOUR_DB_DATA_PATH" --replSet "REPLICA_SET_INSTANCE_NAME"

Hoặc

create a ".sh"  file create_replicaset.sh and init_mongoreplica.js

ví dụ.  

Sau đó chạy đoạn script sau

./create_replicaset.sh
  • Các thư mục sẽ được tạo và sau đó chạy mongo
  • Trong thiết bị đầu cuối Mongo, sử dụng lệnh rs. started[] để bắt đầu một bộ bản sao mới

sharding

Sharding là một phương pháp phân bổ dữ liệu trên nhiều máy. MongoDB đã sử dụng sharding để giúp triển khai với tập dữ liệu rất lớn và thông lượng hoạt động lớn. Bằng cách phân mảnh, bạn kết hợp nhiều thiết bị hơn để mang phần mở rộng dữ liệu và nhu cầu của các thao tác đọc và ghi

Tại sao Sharding?

  • Các hệ thống cơ sở dữ liệu có tập dữ liệu lớn hoặc yêu cầu thông lượng cao có thể nghi ngờ khả năng của một máy chủ
  • Ví dụ: Luồng truy vấn cao có thể làm cạn kiệt giới hạn CPU của máy chủ
  • Kích thước bộ làm việc lớn hơn RAM của hệ thống để nhấn mạnh dung lượng I/O của ổ đĩa

Sharding hoạt động như thế nào?

Sharding xác định vấn đề với việc chia tỷ lệ theo chiều ngang, phá vỡ tập dữ liệu hệ thống và lưu trữ trên nhiều máy chủ, thêm máy chủ mới để tăng âm lượng khi cần

Bây giờ, thay vì một tín hiệu làm tín hiệu chính, chúng tôi có nhiều máy chủ được gọi là Shard. Chúng tôi có các máy chủ định tuyến khác nhau sẽ định tuyến dữ liệu đến các máy chủ phân đoạn. Ví dụ. Giả sử chúng ta có Dữ liệu 1, Dữ liệu 2 và Dữ liệu 3, dữ liệu này sẽ được chuyển đến máy chủ định tuyến sẽ định tuyến dữ liệu [i. e, Dữ liệu khác nhau sẽ chuyển đến một Phân đoạn cụ thể] Mỗi ​​Phân đoạn chứa một số phần dữ liệu. Tại đây, máy chủ cấu hình sẽ giữ siêu dữ liệu và nó sẽ định cấu hình máy chủ định tuyến để tích hợp dữ liệu cụ thể vào một phân đoạn, tuy nhiên máy chủ cấu hình là phiên bản MongoDB nếu nó ngừng hoạt động thì toàn bộ máy chủ sẽ ngừng hoạt động, vì vậy nó lại có Cơ sở dữ liệu cấu hình bản sao

Ưu điểm của Sharding.  

  • Sharding thêm nhiều máy chủ hơn vào trường dữ liệu tự động điều chỉnh tải dữ liệu trên nhiều máy chủ khác nhau
  • Số lượng hoạt động mà mỗi phân đoạn quản lý đã giảm
  • Nó cũng tăng khả năng ghi bằng cách chia tải ghi thành nhiều phiên bản
  • Nó mang lại tính sẵn sàng cao do triển khai các máy chủ bản sao cho phân đoạn và cấu hình
  • Tổng dung lượng sẽ được tăng lên bằng cách thêm nhiều phân đoạn

Để tạo các cụm phân đoạn trong MongoDB, Chúng tôi cần định cấu hình phân đoạn, máy chủ cấu hình và bộ định tuyến truy vấn.  

Bộ bản sao trong ApsaraDB cho MongoDB là một nhóm các quy trình mongod và chứa một nút chính và nhiều nút phụ. Trình điều khiển MongoDB chỉ ghi dữ liệu vào nút chính. Sau đó, dữ liệu được đồng bộ từ nút chính sang nút phụ. Điều này đảm bảo tính nhất quán của dữ liệu trên tất cả các nút trong bộ bản sao. Do đó, các bộ bản sao cung cấp tính khả dụng cao

Hình dưới đây được trích xuất từ ​​tài liệu chính thức của MongoDB. Nó hiển thị một bộ bản sao MongoDB điển hình có chứa một nút chính và hai nút phụ

Bầu chọn nút chính [1]

Một bộ bản sao được khởi tạo bằng cách chạy lệnh

create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
3 hoặc chạy lệnh
create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
4 trong trình bao mongo. Sau khi bộ bản sao được khởi tạo, các thành viên gửi tin nhắn nhịp tim cho nhau và bắt đầu bầu chọn nút chính. Nút nhận được phiếu bầu từ đa số thành viên sẽ trở thành nút chính và các nút khác trở thành nút phụ

Khởi tạo bộ bản sao

    config = {
        _id : "my_replica_set",
        members : [
             {_id : 0, host : "rs1.example.net:27017"},
             {_id : 1, host : "rs2.example.net:27017"},
             {_id : 2, host : "rs3.example.net:27017"},
       ]
    }
    rs.initiate[config]

định nghĩa của đa số

Một nhóm thành viên biểu quyết chỉ được coi là đa số nếu nhóm đó có số lượng thành viên nhiều hơn mức trung bình của tổng số thành viên. Nếu số lượng thành viên trong một bộ bản sao bằng hoặc ít hơn số lượng trung bình của tất cả các thành viên bỏ phiếu, cuộc bầu cử không thể thực hiện được. Trong trường hợp này, bạn không thể ghi dữ liệu vào bộ bản sao

Số lượng thành viên bỏ phiếu Đa sốSố nút bị lỗi tối đa110220321431532642743

Chúng tôi khuyên bạn nên đặt số thành viên trong bản sao được đặt thành số lẻ. Bảng trước cho thấy rằng cả bộ bản sao có ba nút và bộ bản sao có bốn nút đều chịu được lỗi của một nút. Hai bộ bản sao cung cấp cùng một dịch vụ khả dụng. Tuy nhiên, bộ bản sao có bốn nút cung cấp khả năng lưu trữ dữ liệu đáng tin cậy hơn

Các nút phụ đặc biệt

Các nút phụ của bộ bản sao tham gia bầu chọn nút chính. Một nút phụ cũng có thể được chọn làm nút chính. Dữ liệu mới nhất được ghi vào nút chính được đồng bộ hóa với các nút phụ để đảm bảo tính nhất quán của dữ liệu trên tất cả các nút

Bạn có thể đọc dữ liệu từ các nút phụ. Do đó, bạn có thể thêm các nút phụ vào bộ bản sao để cải thiện hiệu suất đọc và tính khả dụng của dịch vụ của bộ bản sao. ApsaraDB cho MongoDB cho phép bạn định cấu hình các nút phụ của bộ bản sao để đáp ứng yêu cầu của các tình huống khác nhau

  • trọng tài

    Nút trọng tài chỉ tham gia bầu cử với tư cách cử tri. Nó không thể được chọn làm nút chính hoặc đồng bộ hóa dữ liệu từ nút chính

    Giả sử rằng bạn triển khai một bộ bản sao chứa một nút chính và một nút phụ. Nếu một nút bị lỗi, cuộc bầu chọn nút chính không thể thực hiện được. Do đó, bộ bản sao sẽ không khả dụng. Trong trường hợp này, bạn có thể thêm một nút trọng tài vào bộ bản sao để kích hoạt bầu chọn nút chính

    Nút trọng tài là nút nhẹ không lưu trữ dữ liệu. Nếu số lượng thành viên trong bộ bản sao là số chẵn, chúng tôi khuyên bạn nên thêm nút trọng tài để tăng tính khả dụng của bộ bản sao

  • Ưu tiên0

    Nút có mức độ ưu tiên 0 trong cuộc bầu chọn nút chính không thể được chọn làm nút chính

    Giả sử rằng bạn triển khai một bộ bản sao có chứa các nút trong cả Trung tâm dữ liệu A và Trung tâm dữ liệu B. Để đảm bảo rằng nút chính đã chọn được triển khai trong Trung tâm dữ liệu A, hãy đặt mức độ ưu tiên của các thành viên bộ bản sao trong Trung tâm dữ liệu B thành 0

    Lưu ý Nếu bạn đặt mức độ ưu tiên của các thành viên trong Trung tâm dữ liệu B thành 0, chúng tôi khuyên bạn nên triển khai phần lớn các nút được đặt bản sao trong Trung tâm dữ liệu A. Nếu không, cuộc bầu chọn nút chính có thể không thành công trong quá trình phân vùng mạng

  • bình chọn0

    Trong MongoDB 3. 0, một bộ bản sao chứa tối đa 50 thành viên và tối đa bảy thành viên có thể bỏ phiếu trong cuộc bầu chọn nút chính. Bạn phải đặt thành viên[n]. thuộc tính phiếu bầu thành 0 cho các thành viên không được phép bỏ phiếu

  • Ẩn giấu

    Thành viên ẩn trong bộ bản sao không thể được chọn làm nút chính vì mức độ ưu tiên của nó là 0. Các nút ẩn ẩn đối với trình điều khiển MongoDB

    Bạn có thể sử dụng các nút ẩn để sao lưu dữ liệu hoặc thực hiện các tác vụ tính toán ngoại tuyến. Điều này không ảnh hưởng đến các dịch vụ của bộ bản sao vì các nút ẩn không xử lý các yêu cầu từ trình điều khiển MongoDB

  • trì hoãn

    Một nút bị trì hoãn phải là một nút ẩn. Dữ liệu trên nút bị trì hoãn phản ánh trạng thái trước đó của dữ liệu trên nút chính. Nếu bạn định cấu hình độ trễ một giờ, thì dữ liệu trên nút bị trì hoãn sẽ giống với dữ liệu trên nút chính một giờ trước

    Do đó, nếu bạn ghi dữ liệu không chính xác hoặc không hợp lệ vào nút chính, bạn có thể sử dụng dữ liệu trên nút bị trì hoãn để khôi phục dữ liệu trên nút chính về trạng thái trước đó

Bầu chọn nút chính [2]

Một cuộc bầu chọn nút chính được kích hoạt không chỉ sau khi khởi tạo bộ bản sao mà còn trong các trường hợp sau

  • Cấu hình lại bộ bản sao

    Một cuộc bầu chọn nút chính được kích hoạt nếu nút chính không thành công hoặc tự nguyện bước xuống và trở thành nút phụ. Một cuộc bầu chọn nút chính bị ảnh hưởng bởi nhiều yếu tố, chẳng hạn như thông báo nhịp tim giữa các nút, mức độ ưu tiên của các nút và thời điểm mục nhập oplog cuối cùng được tạo

    • Ưu tiên nút

      Tất cả các nút có xu hướng bỏ phiếu cho nút có mức độ ưu tiên cao nhất. Nút ưu tiên 0 không thể kích hoạt cuộc bầu chọn nút chính. Nếu một nút phụ có mức độ ưu tiên cao hơn nút chính và chênh lệch thời gian giữa lần nhập nhật ký mới nhất của nút phụ và nút chính trong vòng 10 giây, thì nút chính sẽ giảm xuống. Trong trường hợp này, nút phụ này trở thành ứng cử viên cho nút chính

    • thời gian tối ưu

      Chỉ các nút phụ có mục nhập oplog mới nhất mới đủ điều kiện để được chọn làm nút chính

  • phân vùng mạng

    Chỉ các nút được kết nối với đa số các nút biểu quyết mới có thể được bầu làm nút chính. Nếu nút chính bị ngắt kết nối khỏi phần lớn các nút khác trong bộ bản sao, thì nút chính sẽ tự nguyện giảm xuống và trở thành nút phụ. Một bộ bản sao có thể có nhiều nút chính trong một khoảng thời gian ngắn trong quá trình phân vùng mạng. Khi trình điều khiển MongoDB ghi dữ liệu, chúng tôi khuyên bạn nên đặt chính sách cho phép đồng bộ hóa dữ liệu chỉ từ nút chính được kết nối với phần lớn các nút

đồng bộ hóa dữ liệu

Dữ liệu được đồng bộ từ nút chính sang nút phụ dựa trên oplog. Sau khi thao tác ghi trên nút chính hoàn tất, mục nhập oplog được ghi vào nút cục bộ đặc biệt. xin lỗi. bộ sưu tập rs. Các nút phụ liên tục nhập các mục oplog mới từ nút chính và áp dụng các hoạt động

Để ngăn chặn sự tăng trưởng không giới hạn về kích thước của oplog, cục bộ. xin lỗi. rs được định cấu hình dưới dạng bộ sưu tập giới hạn. Khi lượng dữ liệu oplog đạt đến ngưỡng được chỉ định, các mục nhập sớm nhất sẽ bị xóa. Tất cả các hoạt động trong oplog phải là idempotent. Điều này đảm bảo rằng một thao tác tạo ra kết quả giống nhau bất kể nó có được áp dụng nhiều lần cho các nút phụ hay không

Khối mã sau đây là một mục nhập oplog mẫu, chứa các trường như ts, h, op, ns và o

    {
      "ts" : Timestamp[1446011584, 2],
      "h" : NumberLong["1687359108795812092"], 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
    }
  • ts. thời gian khi hoạt động được thực hiện. Giá trị chứa hai số. Số đầu tiên là dấu thời gian UNIX. Số thứ hai là bộ đếm cho biết số thứ tự của mỗi hoạt động xảy ra trong vòng một giây. Bộ đếm được thiết lập lại mỗi giây
  • h. định danh duy nhất của hoạt động
  • v. phiên bản oplog
  • tùy tùng. loại hoạt động
    • i. chèn
    • u. cập nhật
    • d. xóa bỏ
    • c. chạy các lệnh như createDatabase và dropDatabase
    • n. vô giá trị. Giá trị này được sử dụng cho các mục đích đặc biệt
  • ns. bộ sưu tập mà hoạt động được thực hiện
  • o. các chi tiết hoạt động. Trường này chỉ hợp lệ cho hoạt động cập nhật
  • o2. các điều kiện của một hoạt động cập nhật. Trường này chỉ hợp lệ cho hoạt động cập nhật

Trong quá trình đồng bộ hóa ban đầu, nút phụ chạy lệnh

create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
5 để đồng bộ hóa tất cả dữ liệu từ nút chính hoặc nút phụ khác lưu trữ dữ liệu mới nhất. Sau đó, nút phụ liên tục sử dụng tính năng
create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
6 để truy vấn các mục oplog mới nhất trong cục bộ. xin lỗi. rs của nút chính và áp dụng các hoạt động trong các mục oplog này

Quá trình đồng bộ hóa ban đầu bao gồm các bước sau

  1. Trước thời điểm T1 tool đồng bộ dữ liệu chạy các lệnh
    create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
    7,
        {
          "ts" : Timestamp[1446011584, 2],
          "h" : NumberLong["1687359108795812092"], 
          "v" : 2, 
          "op" : "i", 
          "ns" : "test.nosql", 
          "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
        }
    0,
        {
          "ts" : Timestamp[1446011584, 2],
          "h" : NumberLong["1687359108795812092"], 
          "v" : 2, 
          "op" : "i", 
          "ns" : "test.nosql", 
          "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
        }
    1. Tại thời điểm T1, tất cả dữ liệu trong cơ sở dữ liệu đám mây [ngoại trừ cục bộ. xin lỗi. rs] bắt đầu được đồng bộ hóa từ nút chính sang nút phụ. Giả sử rằng quá trình đồng bộ hoàn tất tại thời điểm T2
  2. Tất cả các hoạt động trong các mục oplog được tạo từ T1 đến T2 được áp dụng cho nút phụ. Hoạt động trong các mục oplog là idempotent. Do đó, các hoạt động đã được áp dụng trong Bước 1 có thể được áp dụng lại
  3. Dựa trên chỉ mục cho từng bộ sưu tập trên nút chính, chỉ mục cho các bộ sưu tập tương ứng được tạo trên nút phụ. Chỉ mục cho mỗi bộ sưu tập trên nút chính đã được tạo ở Bước 1

    Lưu ý Bạn phải định cấu hình kích thước oplog dựa trên kích thước cơ sở dữ liệu và khối lượng dữ liệu sẽ được ghi bởi ứng dụng. Nếu oplog quá khổ, không gian lưu trữ có thể bị lãng phí. Nếu kích thước oplog quá nhỏ, nút phụ có thể không hoàn thành đồng bộ hóa ban đầu. Ví dụ: ở Bước 1, nếu cơ sở dữ liệu lưu trữ một lượng lớn dữ liệu và oplog không đủ lớn, oplog có thể không lưu trữ được tất cả các mục nhập oplog được tạo từ T1 đến T2. Do đó, nút phụ không thể đồng bộ hóa tất cả các bộ dữ liệu từ nút chính

Sửa đổi bộ bản sao

Bạn có thể sửa đổi một bộ bản sao bằng cách chạy lệnh

    {
      "ts" : Timestamp[1446011584, 2],
      "h" : NumberLong["1687359108795812092"], 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
    }
2 hoặc chạy lệnh
    {
      "ts" : Timestamp[1446011584, 2],
      "h" : NumberLong["1687359108795812092"], 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
    }
3 trong trình bao mongo. Ví dụ: bạn có thể thêm hoặc xóa thành viên và thay đổi các thuộc tính ưu tiên, bỏ phiếu, ẩn và trì hoãn của thành viên

Ví dụ: bạn có thể chạy lệnh sau để đặt mức độ ưu tiên của thành viên thứ hai trong bản sao được đặt thành 2

    cfg = rs.conf[];
    cfg.members[1].priority = 2;
    rs.reconfig[cfg];

Quay lại các hoạt động trên nút chính

Giả sử rằng nút chính của bộ bản sao bị lỗi. Nếu các thao tác ghi đã được thực hiện trên nút chính mới khi nút chính cũ tham gia lại bộ bản sao, thì nút chính cũ phải khôi phục các thao tác chưa được đồng bộ hóa với các nút khác. Điều này đảm bảo tính nhất quán dữ liệu giữa nút chính cũ và nút chính mới

Nút chính cũ ghi dữ liệu khôi phục vào một thư mục chuyên dụng. Điều này cho phép quản trị viên cơ sở dữ liệu chạy lệnh

    {
      "ts" : Timestamp[1446011584, 2],
      "h" : NumberLong["1687359108795812092"], 
      "v" : 2, 
      "op" : "i", 
      "ns" : "test.nosql", 
      "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
    }
4 để khôi phục hoạt động khi cần

Bản sao cài đặt đọc/ghi

  • đọc tùy chọn

    Theo mặc định, tất cả các yêu cầu đọc cho một bộ bản sao được định tuyến đến nút chính. Tuy nhiên, bạn có thể sửa đổi các chế độ tùy chọn đọc trên trình điều khiển để định tuyến các yêu cầu đọc tới các nút khác

    • sơ cấp. Đây là chế độ mặc định. Tất cả các yêu cầu đọc được chuyển đến nút chính
    • chínhPreferred. Các yêu cầu đọc được ưu tiên chuyển đến nút chính. Nếu nút chính không khả dụng, các yêu cầu đọc sẽ được chuyển đến các nút phụ
    • thứ hai. Tất cả các yêu cầu đọc được chuyển đến các nút phụ
    • trung họcPreferred. Các yêu cầu đọc được ưu tiên chuyển đến các nút phụ. Nếu tất cả các nút phụ không khả dụng, các yêu cầu đọc sẽ được chuyển đến nút chính
    • gần nhất. Các yêu cầu đọc được định tuyến đến nút có thể truy cập gần nhất, nút này có thể được phát hiện bằng cách chạy lệnh
          {
            "ts" : Timestamp[1446011584, 2],
            "h" : NumberLong["1687359108795812092"], 
            "v" : 2, 
            "op" : "i", 
            "ns" : "test.nosql", 
            "o" : { "_id" : ObjectId["563062c0b085733f34ab4129"], "name" : "mongodb", "score" : "100" } 
          }
      5
  • Viết mối quan tâm

    Theo mặc định, nút chính trả về một thông báo cho biết thao tác ghi thành công sau khi dữ liệu được ghi vào nút chính. Bạn có thể đặt mối quan tâm ghi trên trình điều khiển để chỉ định quy tắc cho thao tác ghi thành công. Để biết thêm thông tin, hãy xem Viết mối quan tâm

    Mối quan tâm ghi sau đây chỉ ra rằng thao tác ghi chỉ thành công sau khi dữ liệu được ghi vào phần lớn các nút trước khi hết thời gian yêu cầu. Khoảng thời gian chờ là năm giây

    create a ".sh"  file create_replicaset.sh and init_mongoreplica.js
    2

    Các cài đặt trước áp dụng cho các yêu cầu riêng lẻ. Bạn cũng có thể sửa đổi mối quan tâm ghi mặc định của bộ bản sao. Mối quan tâm ghi của bộ bản sao áp dụng cho tất cả các yêu cầu đối với bộ bản sao

    Bản sao MongoDB hoạt động như thế nào?

    MongoDB đạt được bản sao bằng cách sử dụng bộ bản sao. Bộ bản sao là một nhóm các phiên bản mongod lưu trữ cùng một bộ dữ liệu. Trong một bản sao, một nút là nút chính nhận tất cả các thao tác ghi. Tất cả các phiên bản khác, chẳng hạn như phiên bản phụ, áp dụng các thao tác từ phiên bản chính để chúng có cùng một tập dữ liệu .

    Bộ bản sao kết nối với MongoDB như thế nào?

    Để kết nối với triển khai bộ bản sao, chỉ định tên máy chủ và số cổng của từng phiên bản, được phân tách bằng dấu phẩy và tên bộ bản sao làm giá trị của tham số replicaSet trong . Trong ví dụ sau, tên máy chủ là host1 , host2 và host3 và số cổng đều là 27017. . In the following example, the hostnames are host1 , host2 , and host3 , and the port numbers are all 27017 .

    Làm cách nào để thiết lập bộ bản sao trong MongoDB từng bước?

    Quan trọng .
    Tắt phiên bản mongod độc lập
    Khởi động lại phiên bản. Sử dụng tùy chọn --replSet để chỉ định tên của bộ bản sao mới. .
    Kết nối mongosh với cá thể mongod
    Sử dụng rs. started[] để bắt đầu bộ bản sao mới. rs

    Bạn nên mô tả bộ bản sao trong MongoDB như thế nào?

    Các Bộ bản sao Mongodb này là sự kết hợp của nhiều phiên bản mongod khác nhau, mỗi phiên bản có một nút chính và nhiều nút phụ. Nút phụ tự động sao chép các thay đổi được thực hiện cho nút chính, đảm bảo dữ liệu giống nhau được duy trì trên tất cả các máy chủ

Chủ Đề