Hướng dẫn của nhà phát triển về bộ bản sao MongoDB

MongoDB thường liên quan đến việc làm việc với một tập hợp lớn dữ liệu bao gồm các mảng được nhúng và các đối tượng mảng. Do đó, điều quan trọng là phải đảm bảo tốc độ xử lý cơ sở dữ liệu của bạn càng nhanh càng tốt để tăng cường hoạt động đọc và ghi. Bên cạnh đó, để tránh những bất thường về dữ liệu có thể phát sinh do dữ liệu không nhất quán, bạn cần đảm bảo dữ liệu của mình luôn ở trạng thái sẵn sàng cao hơn đề phòng trường hợp bạn muốn khôi phục sau sự cố phần cứng hoặc một số gián đoạn dịch vụ. MongoDB cung cấp một số 2 khái niệm cho mục đích đó - ReplicaSets và Sharding.

Sao chép trong MongoDB

Bản sao Master-Slave

Đây là một trong những kỹ thuật lâu đời nhất được sử dụng để đảm bảo dữ liệu luôn có sẵn cho người dùng ngay cả khi một hệ thống bị lỗi. Tuy nhiên, bản sao Master-Slave không được chấp nhận trong các phiên bản mới nhất của MongoDB từ 3.2 và do đó đã được thay thế bằng các bộ Bản sao.

Để tạo cấu hình này, một người khởi động 2 phiên bản mongod trong khi xem xét một phiên bản đang ở chế độ chính và phiên bản còn lại là chế độ nô lệ.

Để bắt đầu một phiên bản ở chế độ chính, hãy chạy:

mongod --master --port portNumber

Các tùy chọn --master hướng dẫn mongod tạo một bộ sưu tập local.oplog. $ Main trong đó danh sách các thao tác được xếp hàng đợi để các nô lệ áp dụng trong việc sao chép dữ liệu.

Để bắt đầu một phiên bản mongod ở chế độ nô lệ, chỉ cần chạy:

mongod --slave --source <masterhostname><:<port>>

Ở đây bạn cần chỉ định tên máy chủ và cổng của cá thể chính cho đối số --source. Đây là tổng quan tóm tắt về việc sử dụng bản sao Master nô lệ và vì nó không được dùng nữa, chúng tôi sẽ quan tâm đến các bộ Bản sao.

Bộ bản sao

Đây là một nhóm các quy trình MongoDB được gọi là các cá thể mongod về cơ bản lưu trữ cùng một tập dữ liệu. Nó được đặc trưng bởi một nút chính và một số nút phụ để mang dữ liệu. Nút chính nhận tất cả các hoạt động ghi và ghi lại tất cả các thay đổi khác đối với tập dữ liệu của nó trong nhật ký hoạt động của nó. Mặt khác, các nút phụ, sao chép nhật ký hoạt động của nút chính và áp dụng các hoạt động cho tập dữ liệu của chúng để tập dữ liệu của chúng phản ánh tập dữ liệu của chính. Nói một cách dễ hiểu, chúng ta có thể nói chúng ta có máy A là nút chính và máy B và C là các nút phụ. Máy A nhận thao tác ghi và thực hiện các thay đổi đối với dữ liệu của nó, sau đó lập danh sách các thay đổi đã được thực hiện. Sau đó, Máy B và C sẽ sao chép các thao tác từ danh sách được cung cấp, trong trường hợp này là nhật ký hoạt động, và thực thi chúng để dữ liệu kết quả giống như trong Máy A.

Như đã đề cập trước đây, điều quan trọng là phải đảm bảo dữ liệu có tính khả dụng cao, đặc biệt là trong cài đặt sản xuất. Nhân rộng có tác dụng trợ giúp bằng cách cung cấp dự phòng dữ liệu trong các trường hợp Mongod khác nhau. Trong trường hợp mất dữ liệu, vì các bản sao của cùng một dữ liệu được lưu trữ trên các cơ sở dữ liệu khác nhau ở nhiều vị trí, nên dễ dàng khôi phục nó ở cơ sở hiện có.

Với nhiều phiên bản đang chạy, các hoạt động đọc và ghi từ máy khách được gửi đến các máy chủ khác nhau và do đó tốc độ xử lý tăng lên. Cấu trúc cơ bản của quá trình sao chép được hiển thị bên dưới.

Đôi khi mạng chính có thể không khả dụng, chẳng hạn như do ngắt kết nối internet hoặc gián đoạn dịch vụ. Trong trường hợp này, tập hợp bản sao sẽ chỉ định nút phụ làm nút chính. Về cơ bản các yêu cầu đọc được thực hiện cho trang chính, một số trường hợp, các yêu cầu đọc có thể được gửi đến thư thứ hai nhưng hãy cẩn thận vì dữ liệu trả về có thể không phản ánh những gì có trong trang chính hoặc đúng hơn là dữ liệu có thể không được cập nhật.

Trọng tài

Trong trường hợp bầu cử sơ bộ, bạn sẽ cần thêm một phiên bản mongod cho tập hợp bản sao để thêm phiếu bầu trong quy trình bầu cử. Trường hợp này được gọi là trọng tài và các đặc điểm nổi bật của nó là:

Nó không có bản sao của tập dữ liệu, do đó không yêu cầu phần cứng mạnh mẽ như các nút mang dữ liệu ..
Không thể được thăng cấp để trở thành người chính.
Họ luôn có 1 phiếu đại cử tri để cho phép tập hợp bản sao có số lượng thành viên bỏ phiếu không đồng đều mà không cần một thành viên bổ sung sao chép dữ liệu. Do đó, vai trò quan trọng của nó là chọn một nút chính khi nó không có sẵn.
Nó vẫn không thay đổi.

Trái ngược với bộ phân xử, các bộ bản sao khác có thể được chuyển đổi thành bộ chính từ phụ và ngược lại.

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

Quá trình sao chép diễn ra dưới hai hình thức đồng bộ dữ liệu. Đầu tiên, các thành viên trong tập hợp được điền đầy đủ dữ liệu trong lần đồng bộ ban đầu. Quá trình sao chép tiếp theo diễn ra để áp dụng các thay đổi nâng cao cho toàn bộ tập dữ liệu.

Trong lần đồng bộ ban đầu, dữ liệu được sao chép từ một thành viên của tập hợp bản sao sang một thành viên khác. Khi quá trình hoàn tất, thành viên chuyển đổi sang nút phụ.

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

Có thể xảy ra gián đoạn dịch vụ như ngắt kết nối mạng dẫn đến kết quả là chấm dứt giao tiếp giữa thiết bị chính và thiết bị thứ hai. Nếu quá trình ngắt kết nối kéo dài hơn 10 giây hoặc không hoàn toàn, nhóm bản sao còn lại sẽ bầu chọn một thành viên trở thành thành viên chính mới. Nút phụ nhận được đa số phiếu bầu sẽ trở thành nút chính mới.

Trong phiên bản 3.0 của MongoDB, một tập hợp bản sao có thể có tối đa 50 thành viên với 7 thành viên bỏ phiếu.

Các thành viên của nhóm bản sao ưu tiên không

Đây là các thành viên thứ cấp không thể chuyển tiếp để trở thành các nút chính cũng như không thể kích hoạt một cuộc bầu cử. Có những vai trò quan trọng trong tập dữ liệu là:duy trì các bản sao của tập dữ liệu, chọn một nút chính và thực hiện các thao tác đọc. Chúng hoạt động giống như một bản sao lưu mà một thành viên mới có thể không thêm ngay lập tức. Do đó, nó sẽ lưu trữ dữ liệu cập nhật và có thể thay thế ngay lập tức một thành viên không có sẵn.

Thành viên nhóm bản sao ẩn MongoDB

Đây là những thành viên không có kết nối với các ứng dụng khách. Chúng được sử dụng cho các khối lượng công việc có yêu cầu sử dụng khác với các thành viên thứ cấp khác. Họ chỉ nhận được lưu lượng sao chép cơ bản trong quá trình đồng bộ hóa ban đầu.

Thành viên nhóm bản sao bị trễ MongoDB

Những dữ liệu này sao chép dữ liệu từ tệp oplog của nút chính trong một số khoảng thời gian cụ thể. Chúng luôn phản ánh trạng thái bị trì hoãn hoặc một dạng trước đó của tập hợp. Do đó, chúng rất quan trọng trong việc phát hiện lỗi và đưa ra gợi ý về cách người ta có thể khôi phục từ những lỗi đó, chẳng hạn như nếu có một cơ sở dữ liệu đã bị loại bỏ. Khi chọn khoảng thời gian trì hoãn, điều này cần được xem xét:

Thời lượng phải nhỏ hơn dung lượng của nhật ký hoạt động, đối với công cụ lưu trữ WiredTiger, MMAPv1 và In-Memory là 50GB. Nếu không, thành viên bị trì hoãn không thể tái tạo thành công các hoạt động.
Khoảng thời gian trì hoãn phải bằng hoặc lớn hơn một chút so với thời lượng cửa sổ bảo trì dự kiến của bạn.

Cấu hình

Đây là thành viên không ưu tiên, nó bị ẩn do đó không hiển thị với các ứng dụng và cuối cùng có thể tham gia vào quá trình bầu cử. Do đó, để định cấu hình mức độ ưu tiên, giả sử bạn có 10 thành viên trong tập hợp bản sao của mình, bạn có thể chọn một thành viên ở vị trí n làm thành viên [n] và đặt các thuộc tính của nó là:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

Hoặc bằng cách sử dụng trình bao mongo được kết nối với trình chính, bạn có thể chạy lệnh này để đặt thành viên đầu tiên của tập hợp bản sao là bị trì hoãn:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Sau khi thiết lập cấu hình này, thứ cấp bị trì hoãn không thể trở thành chính và do đó bị ẩn khỏi các ứng dụng. Thành viên sẽ bị trì hoãn 1 giờ (3600 giây) kể từ hoạt động oplog.

Vài người trở thành MongoDB DBA - Đưa MongoDB vào Sản xuất Tìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng MongoDBDownload miễn phí

Cách bắt đầu một tập hợp bản sao

Trong hướng dẫn này, chúng ta sẽ xem từng bước cách chúng ta có thể định cấu hình tập hợp bản sao trong MongoDB.

Giả sử bạn có 3 mongodb muốn sao chép và chúng được định cấu hình như sau:
1. Mongod1.conf đang chạy ở cổng 27017
2. Mongod2.conf đang chạy ở cổng 27018
3. Mongod3.conf đang chạy ở cổng 27019
Đảm bảo thêm tên tập hợp bản sao sẽ không thay đổi trong mỗi tệp. Bạn có thể làm như vậy bằng cách thêm hoặc thay đổi giá trị replSet của tùy chọn thành tên mà bạn chọn.
Chúng ta có thể bắt đầu phiên bản đầu tiên bằng cách chạy
```
sudo mongod --config /etc/mongo/mongod1.conf
```
Đây là nếu, bạn không có phiên bản chạy mongod nào. Sau đó, làm tương tự cho các trường hợp khác. Để kiểm tra các phiên bản đang chạy trong máy của bạn, hãy chạy
```
ps -ax | grep mongo
```
Bạn sẽ nhận được một số danh sách như sau:
```
4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
```
Điều này có nghĩa là phiên bản đầu tiên trong MongoDB theo mặc định chạy ở cổng 27017, do đó chúng tôi đặt nó là phiên bản đầu tiên trong danh sách. Nếu bạn đã bắt đầu những người khác, họ cũng sẽ được liệt kê trong danh sách với các url đường dẫn tương ứng của họ. Để kết nối với một phiên bản trong mongo shell, hãy chạy lệnh sau:
```
mongo  --port port_number i.e mongo  --port 27017.
```
Tuy nhiên, trong trường hợp của chúng tôi, chúng tôi cần kết nối với tên tập hợp bản sao vì vậy chúng tôi phải thêm tên nó vào lệnh:
```
mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
```
Trong trường hợp này, replicaSetName của chúng tôi =“testrep”

Hãy kiểm tra xem có bộ bản sao nào được kích hoạt hay không bằng cách chạy rs.status ()

Nếu bạn nhận được kết quả như:

{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

Sau đó, nó có nghĩa là không có tập hợp bản sao nào được kích hoạt. Khác nếu bạn nhận được kết quả là

{
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

thì có nghĩa là bản sao chưa được khởi tạo.

Phương thức rs.initiate () sẽ giúp chúng ta bắt đầu một tập hợp bản sao mới và thể hiện mà nó được khởi tạo sẽ trở thành nút chính của chúng ta. Vì vậy, chúng ta có thể khởi tạo một trong trường hợp của mình bằng cách chạy phương thức khởi tạo. rs.initiate ().

Kiểm tra lại trạng thái thiết lập bản sao bằng cách chạy rs.status (). Thành viên. Bây giờ bạn sẽ thấy một cái gì đó giống như

"members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

Tốt, tốt để đi. Mối quan tâm của chúng ta sẽ là tùy chọn thành viên, vì chúng ta có thể thấy đó là mảng n với 1 thành viên trong đó. Kiểm tra tùy chọn stateStr của thành viên đầu tiên trong trường hợp này, nó được đặt thành Chính, có nghĩa là đây sẽ hoạt động như nút chính của chúng tôi.

Thêm một thành viên mới vào tập hợp bản sao bằng tên máy chủ của nó. Để kiểm tra tên máy chủ của phiên bản được kết nối mà bạn muốn thêm, hãy chạy
```
db.serverStatus().host
```
Bạn sẽ nhận được một cái gì đó giống như
```
ervername.local:27019
```
Vì vậy, từ PRIMARY bạn có thể thêm một thành viên khác bằng cách chạy lệnh này trong mongo shell:
```
rs.add("servername.local:27019");
```

Chạy lệnh trạng thái

rs.status().members

Để kiểm tra xem các thay đổi đã được thực hiện hay chưa.

Bây giờ bạn sẽ có một cái gì đó giống như sau:

[
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

Bây giờ chúng ta có 2 thành viên, một là nút CHÍNH và nút kia là nút THỨ HAI. Bạn có thể thêm nhiều thành viên hơn nhưng không vượt quá 50. Bây giờ, hãy để chúng tôi tạo cơ sở dữ liệu trong ví dụ tại cổng 27018 làm cơ sở dữ liệu chính.

Nếu chúng ta ngắt kết nối chính, quá trình chuyển đổi dự phòng sẽ xảy ra và vì chúng ta chỉ có 1 chính nên nó sẽ tự động được chuyển thành thiết bị phụ. Bây giờ nếu chúng tôi kết nối với một trên cổng 27019, bạn sẽ nhận được cùng một cơ sở dữ liệu và bộ sưu tập với tài liệu của chúng.

Bây giờ, nếu nút chính bị ngắt kết nối được kết nối lại, nó sẽ được thêm vào làm nút phụ vì nó sao chép các hoạt động từ oplog của nút chính hiện có.

Tập hợp bản sao MongoDB Viết mối quan tâm

Nếu MongoDB trả về mối quan tâm ghi nhật ký thành công, dữ liệu sẽ được lưu trữ vào đĩa do đó sẽ có sẵn sau khi khởi động lại mongod. Tuy nhiên, đối với các hoạt động ghi, dữ liệu chỉ bền sau khi nó được sao chép và cam kết với tạp chí theo sự ủng hộ của đa số thành viên biểu quyết của tập hợp bản sao.

Một số dữ liệu có thể quá lớn để cập nhật hoặc chèn, do đó có thể mất nhiều thời gian hơn dự kiến để dữ liệu được sao chép trong các thành viên khác. Vì lý do này, bạn nên chỉnh sửa cấu hình writeConcern để phục vụ cho khoảng thời gian mà một hoạt động sẽ được thực thi. Các cấu hình writeConcern mặc định quy định rằng tập hợp bản sao chỉ yêu cầu xác nhận từ thành viên chính. Mối quan tâm ghi mặc định xác nhận hoạt động ghi chỉ dành cho chính nhưng có thể được ghi đè để kiểm tra hoạt động ghi trên một số thành viên tập hợp bản sao bằng cách chỉ định mối quan tâm ghi cho một thao tác ghi cụ thể. Ví dụ:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

Tùy chọn ghi trong trường hợp này ra lệnh rằng thao tác sẽ chỉ trả lại phản hồi sau khi nó đã được lan truyền đến trang chính và ít nhất 2 thư thứ hai hoặc nếu nó hết thời gian sau 3,6 giây.

Định cấu hình Mối quan tâm Viết cho MongoDB

Tùy chọn MongoDB getLastErrorDefaults cung cấp cho chúng tôi các tham số để thay đổi cài đặt mặc định mối quan tâm ghi trong cấu hình bộ bản sao. Điều này ngụ ý rằng hoạt động phải được hoàn thành với hầu hết các thành viên biểu quyết trước khi trả lại kết quả.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

Giá trị thời gian chờ sẽ ngăn chặn các hoạt động ghi chặn, nghĩa là nếu có 5 thành viên xác nhận mối quan tâm về việc ghi nhưng không may có 4 thành viên trở xuống trong tập hợp bản sao, hoạt động sẽ chặn cho đến khi tất cả các thành viên có sẵn. Bằng cách thêm ngưỡng thời gian chờ, quá trình chặn hoạt động sẽ bị hủy bỏ sau khoảng thời gian này.

Chặn sao chép

Chặn một hoạt động đặc biệt là khi tất cả các thành viên đã được sao chép đảm bảo sẽ không còn lãng phí thời gian khi chờ đợi một thành viên nhóm sao chép khác sẵn sàng để trả lại phản hồi. Tùy chọn lệnh MongoDB getLastError chỉ định cách cập nhật sao chép được thực hiện bằng cách sử dụng thuộc tính “w” tùy chọn.

Ví dụ:truy vấn này

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

yêu cầu rằng việc chặn sẽ xảy ra cho đến khi N số thành viên đã sao chép thao tác ghi cuối cùng. Nếu N có sẵn hoặc nhỏ hơn 2, truy vấn sẽ được trả về. Ngược lại, nếu giá trị của N bằng 2, thì cái chính tương đương với cái chính, sẽ chỉ phản hồi sau khi 1 trong số các nô lệ của nó đã được sao chép cho thao tác cuối cùng.

Thời gian chờ tham số về cơ bản là đặt thời gian tính bằng mili giây, sau đó lệnh getLastError sẽ hết thời gian chờ và trả về lỗi trước khi tùy chọn cuối cùng được sao chép.

Chặn nhiều như cách nào đó có lợi thì đôi khi nó cũng có hạn chế. Nó làm chậm đáng kể các thao tác đọc, đặc biệt nếu bạn đặt giá trị “w” quá lớn. Tôi khuyên bạn nên đặt giá trị “w” thành 2 hoặc 3 để cải thiện độ an toàn và hiệu quả.

Tùy chọn đọc trong MongoDB

Về cơ bản, đây là lộ trình liền kề mà các hoạt động đọc của máy khách được thực hiện đối với tập hợp bản sao. Thiết lập MongoDB mặc định định cấu hình các thao tác đọc thành thao tác chính vì đây là thiết lập có phiên bản mới nhất của tài liệu mà bạn đang tìm nạp. Như đã đề cập trước đây, lợi thế tối cao để khai thác tập hợp bản sao là cải thiện hiệu suất của hệ thống cơ sở dữ liệu của chúng tôi. Do đó, nên phân phối các thao tác đọc cho nhiều thành viên thứ cấp để giảm độ trễ cho các ứng dụng không nhất thiết phải cập nhật dữ liệu. Tuy nhiên, có nhiều lý do quan trọng hơn tại sao bạn cũng nên sử dụng tùy chọn chính như tùy chọn cơ bản của bạn:

Duy trì tính khả dụng của dữ liệu trong quá trình chuyển đổi dự phòng.
Đối với các ứng dụng được phân phối theo địa lý, ứng dụng chính sẽ cung cấp các lượt đọc cục bộ cho các ứng dụng khách trong cùng một trung tâm dữ liệu.
Không ảnh hưởng đến các ứng dụng giao diện người dùng, đặc biệt là những ứng dụng đang chạy hệ thống.

Mongo.setReadPref () Phương pháp

Phương pháp này về cơ bản là để xác định cách khách hàng sẽ định tuyến tất cả các truy vấn đến các thành viên của tập bản sao. Nó cần 2 đối số, mode và tagSet.

Đối số chế độ chỉ định tùy chọn đọc có thể là chính, chínhPreferred, phụ, phụPreferred hoặc gần nhất.

Chế độ tagSet chỉ định tùy chọn đọc tùy chỉnh, bạn cũng có thể chỉ định chúng dưới dạng một mảng đối tượng. Ví dụ về thiết lập sẽ là:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Điều xảy ra ở đây là, nếu khách hàng cố gắng truy cập vào thẻ đầu tiên và yêu cầu không được thực hiện, họ sẽ được chọn vào tùy chọn đọc thứ hai.

Chế độ tùy chọn đọc

Chính:điều này xác định rằng tất cả các thao tác đọc được đọc từ một tập hợp bản sao nhất định là chính và là chế độ đọc tùy chọn mặc định.
PrimaryPreferred:Nếu chỉ bản chính không có sẵn thì các thao tác đọc có thể được thực hiện từ các bản thứ hai.
Thứ cấp:tất cả các thao tác đọc được thực hiện từ các thành viên thứ cấp của tập hợp bản sao.
Thứ cấp được ưu tiên:nếu chỉ không có sẵn thứ cấp, các thao tác đọc có thể được thực hiện từ chính.
Gần nhất:thành viên có độ trễ mạng ít nhất được chọn cho hoạt động đọc bất kể loại của nó.

Bộ thẻ và cấu hình của chúng

Đây là những tùy chọn cho phép bạn lập mô hình theo cách bạn muốn sở thích viết và sở thích đọc của mình trông như thế nào. Chúng được lưu trữ trong đối tượng cấu hình tập hợp bản sao. Nếu bạn chạy rs.conf (). Thành viên, bạn sẽ nhận được đối tượng này được trả về:

Thẻ

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Như bạn có thể thấy, mỗi thành viên đều có thuộc tính tags.

Sự khác biệt chính giữa Tùy chọn Đọc và Quan tâm Viết là ở chỗ, thẻ trước xem xét giá trị của thẻ khi chọn thành viên để đọc trong khi tùy chọn sau thì không.

Giả sử một bộ thẻ cho thao tác đọc được đặt thành:

{ "disk": "ssd", "use": "reporting" }

Một thành viên trong tập hợp bản sao phải thực hiện đầy đủ các thẻ này để hoạt động đọc được thực hiện. Do đó, có thể nói, một cấu hình như thế này

{ "disk": "ssd", "use": "reporting", "rack": "a" }

sẽ đáp ứng truy vấn trong khi truy vấn này

{ "disk": "ssd", "use": "production", "rack": "k" }

sẽ không đáp ứng truy vấn.

Thêm thẻ vào một bản sao tập hợp

Đối với thành viên đã chọn của bạn trong một tập hợp bản sao, bạn có thể thêm các tập hợp thẻ bằng cách sử dụng phương thức rs.conf () trong MongoDB.

Giả sử bạn đã chọn một thành viên ở vị trí 1 trong mảng tập hợp bản sao của mình, bạn có thể thêm các tập hợp thẻ như sau.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Mẫu triển khai cho bộ bản sao MongoDB

Tập hợp bản sao được phân phối theo địa lý - Tăng cường khả năng dự phòng của dữ liệu bên cạnh việc bảo vệ dữ liệu khỏi các lỗi như mất điện. Các phiên bản đang chạy được đặt ở nhiều vị trí.
Bộ bản sao ba thành viên - kiến trúc tiêu chuẩn cơ bản cho bộ bản sao.
Bốn hoặc nhiều Bộ bản sao thành viên - Cho phép dự phòng dữ liệu rộng hơn và cũng hỗ trợ phân phối rộng hơn các hoạt động đọc trong Bộ bản sao.

Kỹ thuật điều chỉnh triển khai bộ bản sao MongoDB

Một tập hợp bản sao lý tưởng sẽ yêu cầu một kiến trúc được bố trí tốt với ít nhất 3 thành viên cho một hệ thống sản xuất. Các chiến lược triển khai này sẽ giúp bạn kích hoạt một tập hợp bản sao tuyệt vời.

Sử dụng các thành viên bị trì hoãn và ẩn để hỗ trợ các chức năng chuyên dụng như báo cáo và sao lưu.
Luôn đặt số lượng thành viên được triển khai là số lẻ. Như chúng tôi đã thảo luận ở trên, một số lẻ thành viên sẽ được yêu cầu trong việc bầu cử sơ bộ. Do đó, hãy đảm bảo bạn có một số lẻ và nếu không, bạn luôn có thể thêm trọng tài viên.
Đối với các triển khai ở chế độ đọc nhiều, bạn sẽ cần cân bằng tải. Do đó, bạn sẽ được yêu cầu phân phối số lần đọc cho phụ để cải thiện hiệu suất đọc. Bên cạnh đó, khi dữ liệu phát triển theo thời gian, bạn có thể thêm nhiều thành viên hơn và phân phối chúng nhưng hãy lưu ý rằng bạn phải định cấu hình dữ liệu theo cách thiết kế tối quan trọng để chọn thành viên chính.
Luôn xem xét khả năng chịu lỗi. Điều này về cơ bản là xác định có bao nhiêu thành viên có thể không có mặt tại một thời điểm nhất định và bao nhiêu sẽ còn lại để duy trì quá trình bầu cử sơ bộ. Nếu bạn không có bộ phận chính, rất tiếc, bộ bản sao sẽ không chấp nhận bất kỳ thao tác ghi nào.
Thêm thành viên mới vào tập hợp bản sao hiện có trước khi phát sinh nhu cầu.
Sử dụng bộ thẻ tập hợp bản sao để đảm bảo rằng tất cả các hoạt động được sao chép tại các trung tâm dữ liệu cụ thể. Bạn cũng có thể sử dụng các thẻ này để định tuyến cho các hoạt động đọc cho các máy triển khai cụ thể.
Triển khai hầu hết các thành viên của bạn ở một vị trí để tránh thất bại sẽ phát sinh từ việc phân vùng mạng. Việc phân vùng mạng có thể là kết quả của việc giao tiếp không kết nối giữa các trung tâm dữ liệu, do đó cản trở quá trình sao chép và quá trình bầu chọn chính.
Vì lý do an toàn, hãy phân phối các thành viên của bạn theo địa lý bên cạnh việc ẩn một số thành viên. Bạn có thể đặt mức độ ưu tiên của ít nhất 2 hoặc 3 thành viên thành 0 để ngăn họ trở thành ưu tiên hàng đầu.
Sử dụng nhật ký để bảo vệ việc mất dữ liệu có thể dẫn đến sự cố như mất điện. Điều này đảm bảo rằng dữ liệu được ghi vào đĩa trong trường hợp tắt đột ngột.

Nhật ký hoạt động (Oplog)

Oplog duy trì một bản ghi về các hoạt động chính sẽ được áp dụng cho các nô lệ. Nó được lưu trữ trong một cơ sở dữ liệu được gọi là cục bộ trong oplog. $ Main collection. Nó được tạo khi bạn bắt đầu một thành viên tập hợp bản sao lần đầu tiên. Ở giới hạn trên, oplog bị giới hạn ở kích thước 50GB cho tất cả các công cụ lưu trữ. Kích thước nhật ký có thể được thay đổi từ cài đặt mặc định. Nếu đạt đến kích thước này, chẳng hạn như trong 24 giờ hoạt động, các tạp chí thứ hai sẽ không thể sao chép thoải mái từ nó trong khoảng thời gian này và có thể kết thúc không sao chép. Bạn có thể thay đổi kích thước của oplog bằng cách sử dụng tùy chọn replSetResizeOplog, tức là

db.database({replSetResizeOplog:1, size: 16384})

Nếu bạn muốn giảm kích thước của oplog này, nó sẽ dẫn đến việc một số dữ liệu bị xóa. Tác động cốt lõi của điều này trong tập hợp bản sao là các thành viên được đồng bộ hóa với nút này trở nên cũ. Do đó, bạn sẽ cần phải đồng bộ hóa lại các thành viên này.

Các mẫu khối lượng công việc sẽ yêu cầu kích thước Oplog lớn

Cập nhật nhiều tài liệu cùng một lúc. Nhiều hoạt động cập nhật phải được dịch thành một hoạt động riêng lẻ để cải thiện kết quả trên các nút. Thao tác này sẽ sử dụng một không gian rộng lớn của không gian oplog.
Số lượng đáng kể các bản cập nhật tại chỗ. Điều này thường xảy ra khi cập nhật dữ liệu của tài liệu không nhất thiết phải tăng kích thước của tài liệu này. Cơ sở dữ liệu sẽ ghi lại một số lượng lớn thao tác đối với oplog, do đó kích thước của nó sẽ tăng lên.
Các lần xóa bằng cùng một lượng dữ liệu như các lần chèn. Điều này xảy ra khi bạn cố gắng xóa một lượng dữ liệu (gần như) bằng với lượng dữ liệu bạn chèn vào. Thao tác này sẽ có xu hướng tăng kích thước của oplog.

Kết luận

Nhân rộng là một trong những khía cạnh quan trọng của cơ sở dữ liệu mà các nhà phát triển cần phải hiểu. Nó đảm bảo tăng tính khả dụng của dữ liệu. Ví dụ:máy chủ MongoDB của bạn có thể gặp sự cố do mất điện nhưng bạn vẫn muốn khách hàng của mình truy cập vào dữ liệu của nó. Nếu bạn đã sao chép dữ liệu trong một máy chủ khác, các máy khách của bạn sẽ có thể tiếp tục truy cập dữ liệu từ nó nếu máy chủ chính bị lỗi. Bên cạnh đó, việc cân bằng tải được tăng cường để thay vì tất cả người dùng truy cập vào một máy chủ duy nhất, chúng tôi đã thấy sự cân bằng của việc phục vụ lưu lượng truy cập từ các bản sao thứ cấp.