Sao chép trong MongoDB liên quan đến các tập hợp bản sao bởi các thành viên có kiến trúc gồm các thành viên chính và phụ nhưng đôi khi có một thành viên không mang dữ liệu được gọi là trọng tài viên. Quá trình sao chép là, bất cứ khi nào dữ liệu được ghi vào nút chính, các thay đổi được ghi lại trên tệp oplog mà từ đó các thành viên thứ cấp áp dụng các thay đổi tương tự. Thao tác đọc có thể được thực hiện từ bất kỳ thành viên mang dữ liệu nào do đó tạo ra một kịch bản thường được gọi là Tính sẵn sàng cao.
Tuy nhiên, trong một số trường hợp, các thành viên phụ có thể không bắt kịp với nút chính trong việc thực hiện các thay đổi và trong trường hợp nút chính bị lỗi trước khi những thay đổi này được áp dụng, người ta sẽ buộc phải đồng bộ hóa lại toàn bộ cụm. để chúng có thể ở cùng một trạng thái dữ liệu.
Rollback là gì?
Đây là tính năng chuyển đổi dự phòng tự động trong MongoDB trong đó nút chính trong tập hợp bản sao có thể bị lỗi trong khi thực hiện các thay đổi mà rất tiếc cuối cùng lại không được phản ánh cho các thành viên phụ kịp thời từ oplog do đó cần phải hoàn nguyên trạng thái của trang chính thành một trước khi các thay đổi được thực hiện.
Do đó,Rollbacks chỉ cần thiết khi phần tử chính đã chấp nhận ghi các hoạt động chưa được sao chép cho các thành viên thứ hai trước khi phần tử chính ngừng hoạt động do một số lý do chẳng hạn như phân vùng mạng. Nếu trong trường hợp các hoạt động ghi quản lý được sao chép ở một trong các thành viên có sẵn và có thể truy cập được đối với phần lớn tập hợp bản sao, thì việc khôi phục sẽ không xảy ra.
Lý do chính đằng sau quá trình khôi phục trong MongoDB là để giữ tính nhất quán dữ liệu cho tất cả các thành viên và do đó, khi tập hợp chính tham gia lại tập hợp bản sao, nếu các thay đổi của nó chưa được áp dụng cho các thành viên phụ, nó sẽ được hoàn nguyên về trạng thái trước khi thất bại.
Tuy nhiên, nên hiếm hoặc nên tránh khôi phục trong MongoDB vì chúng có thể dẫn đến mất nhiều dữ liệu và do đó ảnh hưởng đến hoạt động của các ứng dụng được kết nối với cơ sở dữ liệu.
Quy trình khôi phục MongoDB
Chúng ta hãy coi một tập hợp ba thành viên với A là chính, B và C là các thành viên phụ. Chúng tôi sẽ đưa dữ liệu vào A và đồng thời kích hoạt một số phân vùng mạng tới B và C. Chúng tôi sẽ sử dụng MongoDB phiên bản 4.2 và Atlas trong thử nghiệm này.
Đầu tiên, chúng ta sẽ nhận được trạng thái của bản sao được thiết lập bằng cách chạy lệnh rs.status () trên mongo shell
MongoDB Enterprise Cluster0-shard-0:PRIMARY> rs.status()Nhìn vào thuộc tính thành viên, bạn có thể thấy một cái gì đó giống như
"members" : [
{
"_id" : 0,
"name" : "cluster0-shard-00-00-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891079,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:19.509Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:18.532Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 1,
"name" : "cluster0-shard-00-01-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 1891055,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDurable" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"optimeDurableDate" : ISODate("2020-07-15T15:25:11Z"),
"lastHeartbeat" : ISODate("2020-07-15T15:25:17.914Z"),
"lastHeartbeatRecv" : ISODate("2020-07-15T15:25:19.403Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceHost" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"syncSourceId" : 2,
"infoMessage" : "",
"configVersion" : 4
},
{
"_id" : 2,
"name" : "cluster0-shard-00-02-sc27x.mongodb.net:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1891089,
"optime" : {
"ts" : Timestamp(1594826711, 1),
"t" : NumberLong(27)
},
"optimeDate" : ISODate("2020-07-15T15:25:11Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1592935644, 1),
"electionDate" : ISODate("2020-06-23T18:07:24Z"),
"configVersion" : 4,
"self" : true,
"lastHeartbeatMessage" : ""
}
],Điều này sẽ hiển thị cho bạn trạng thái của từng thành viên trong tập hợp bản sao của bạn. Bây giờ chúng tôi đã mở một thiết bị đầu cuối mới cho nút A và điền vào nó 20000 bản ghi:
MongoDB Enterprise Cluster0-shard-0:PRIMARY> for (var y = 20000; y >= 0; y--) {
db.mytest.insert( { record : y } )
}
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest 2020-07-15T21:28:40.436+2128 I NETWORK [thread1] trying reconnect to 127.0.0.1:3001 (127.0.0.1) failed
2020-07-15T21:28:41.436+2128 I
NETWORK [thread1] reconnect 127.0.0.1:3001 (127.0.0.1) ok
MongoDB Enterprise Cluster0-shard-0:SECONDARY> rs.slaveOk()
MongoDB Enterprise Cluster0-shard-0:SECONDARY> db.mytest.count()
20000Trong quá trình phân vùng mạng, A sẽ ngừng hoạt động khiến nó không khả dụng cho B và C và do đó B được bầu làm mạng chính trong trường hợp của chúng tôi. Khi A tham gia lại, nó sẽ được thêm vào làm thứ yếu và bạn có thể kiểm tra xem bằng cách sử dụng lệnh rs.status (). Tuy nhiên, một số bản ghi được quản lý để được sao chép sang thành viên B trước khi phân vùng mạng như được thấy bên dưới:(Hãy nhớ trong trường hợp này B là bản ghi chính bây giờ)
MongoDB Enterprise Cluster0-shard-0:PRIMARY> db.mytest.find({}).count()
12480 Số là số lượng tài liệu có thể được sao chép sang B trước khi A gặp sự cố.
Nếu chúng ta ghi một số dữ liệu vào B và cho phép A tham gia vào mạng, thì chúng ta có thể nhận thấy một số thay đổi đối với A
connecting to: 127.0.0.1:3001/admin
MongoDB Enterprise Cluster0-shard-0:ROLLBACK>
MongoDB Enterprise Cluster0-shard-0:RECOVERING>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:SECONDARY>
MongoDB Enterprise Cluster0-shard-0:PRIMARY>Sử dụng oplogFetcher, các thành viên phụ sẽ đồng bộ hóa các mục nhập nhật ký từ syncSource của họ. OplogFetcher kích hoạt một phương pháp tìm tới oplog nguồn, theo sau là một loạt chuỗi con trỏ getMores. Khi A tham gia lại với tư cách là phương pháp phụ, cách tiếp cận tương tự được áp dụng và tài liệu lớn hơn dấu thời gian của vị từ được trả về. Nếu tài liệu đầu tiên trong B không khớp với mục nhập cuối cùng trong oplog của A, A sẽ bị buộc khôi phục.
Khôi phục dữ liệu khôi phục trong MongoDB
Rollback không phải là một điều xấu trong MongDB nhưng người ta nên cố gắng hết sức có thể để đảm bảo chúng không xảy ra thường xuyên. Đây là một biện pháp tự động an toàn để đảm bảo tính nhất quán dữ liệu giữa các thành viên của một tập hợp bản sao. Trong trường hợp khôi phục xảy ra, đây là một số bước để giải quyết tình huống:
Thu thập dữ liệu khôi phục
Bạn cần thu thập dữ liệu thành viên liên quan đến quá trình khôi phục. Điều này được thực hiện bằng cách đảm bảo các tệp khôi phục được tạo (chỉ khả dụng với MongoDB phiên bản 4.0) bằng cách bật createRollbackDataFiles. Theo mặc định, tùy chọn này được đặt thành true do đó các tệp khôi phục sẽ luôn được tạo.
Tệp khôi phục được đặt trong đường dẫn
Tải dữ liệu tệp khôi phục trong một máy chủ hoặc cơ sở dữ liệu riêng biệt
Mongorestore là một khía cạnh quan trọng của MongoDB có thể hỗ trợ cho việc khôi phục các tệp dữ liệu khôi phục. Điều đầu tiên là sao chép các tệp khôi phục vào một máy chủ mới sau đó sử dụng mongorestore tải các tệp vào máy chủ của bạn. Lệnh mongorestore được hiển thị bên dưới.
mongorestore -u <> -p <> -h 127.0.0.1 -d <rollbackrestoretestdb> -c <rollbackrestoretestc> <path to the .bson file> --authenticationDatabase=<database of user>Làm sạch dữ liệu không cần thiết và sàng lọc qua dữ liệu
Bước này cần người dùng có toàn quyền lựa chọn giữa dữ liệu được giữ lại khỏi các tệp khôi phục và dữ liệu bị loại bỏ. Nên nhập tất cả các dữ liệu của tệp rollback, điểm quyết định này khiến bước này trở thành bước khó nhất trong quá trình khôi phục dữ liệu.
Sử dụng Nhóm chính làm Cụm để Nhập Dữ liệu
Bắt đầu bước cuối cùng bằng cách tải xuống dữ liệu đã được làm sạch thông qua việc sử dụng mongorestore và mongodump, hãy làm theo bước này bằng cách nhập lại dữ liệu vào cụm sản xuất ban đầu.
Ngăn chặn việc khôi phục MongoDB
Để ngăn việc khôi phục dữ liệu xảy ra khi sử dụng MongoDB, người ta có thể làm như sau.
Chạy tất cả các thành viên bỏ phiếu ‘MAJORITY’
Điều này có thể được thực hiện bằng cách sử dụng w:đa số ghi mối quan tâm có khả năng tùy chọn xác nhận yêu cầu sẽ cho phép hoạt động ghi vào các thẻ cụ thể của các cá thể Mongod. Điều này có thể đạt được bằng cách sử dụng tùy chọn w theo sau là thẻ
Thao tác của Người dùng
Phiên bản cập nhật của MongoDB, tức là phiên bản 4.2 có khả năng tắt tất cả các hoạt động đang diễn ra trong trường hợp khôi phục.
Tạo Chỉ mục
Phiên bản 4.2 của phiên bản tương thích tính năng MongoDB (fcv) "4.2" có khả năng đợi tất cả các chỉ số đang được xây dựng và hoàn thành tất cả trước khi quá trình khôi phục diễn ra nơi. Tuy nhiên, phiên bản 4.0 đang chờ quá trình tiếp tục và xây dựng chỉ mục nền, do đó khả năng khôi phục là cao.
Kích thước và Hạn chế
Phiên bản 4.0 của MongoDB không có giới hạn được liệt kê của dữ liệu nhất định có thể được khôi phục khi xây dựng chỉ mục nền đang tiến hành.
Kết luận
Khôi phục MongoDB là một hiện tượng phổ biến đối với những người sử dụng MongoDB mà không có kiến thức về cách ngăn chặn nó. Việc khôi phục có thể ngăn ngừa được nếu một người quan tâm tuân theo và tuân thủ một số phương pháp an toàn và cách tránh khôi phục trong MongoDB. Nói chung, bạn luôn nên nâng cấp lên phiên bản MongoDB mới nhất để tránh một số trục trặc có thể phòng tránh được.
