Một trong những vấn đề lớn trong ứng dụng hoặc lỗi dữ liệu do con người gây ra là việc ghi vi phạm vào phần chính sẽ ngay lập tức được sao chép sang phần phụ.
Đây là một trong những lý do mà người dùng tận dụng "slaveDelay" - một tùy chọn để chạy một trong các nút phụ của bạn với độ trễ thời gian cố định (tất nhiên điều đó chỉ giúp ích cho bạn nếu bạn phát hiện ra lỗi hoặc lỗi trong khoảng thời gian ngắn hơn sự chậm trễ về thứ cấp đó).
Trong trường hợp bạn không có thiết lập như vậy, bạn phải dựa vào bản sao lưu để tạo lại trạng thái của các bản ghi mà bạn cần khôi phục về trạng thái trước lỗi của chúng.
Thực hiện tất cả các thao tác trên một bản sao dữ liệu độc lập riêng biệt của bạn - chỉ sau khi xác minh rằng mọi thứ đã được tạo lại đúng cách rồi thì bạn mới nên di chuyển dữ liệu đã sửa vào hệ thống sản xuất của mình.
Điều cần thiết để có thể thực hiện việc này là một bản sao lưu gần đây (giả sử bản sao lưu đã cũ X giờ) và oplog trên cụm của bạn phải chứa nhiều hơn X giờ dữ liệu. Tôi không chỉ định oplog của nút nào vì (a) mọi thành viên của tập hợp bản sao có cùng nội dung trong oplog và (b) nó là Có thể kích thước nhật ký của bạn khác nhau trên các thành viên nút khác nhau, trong trường hợp đó, bạn muốn kiểm tra kích thước "lớn nhất".
Vì vậy, giả sử bản sao lưu gần đây nhất của bạn là 52 giờ, nhưng may mắn là bạn có một oplog lưu trữ dữ liệu trị giá 75 giờ (yay).
Bạn đã nhận ra rằng tất cả các nút của bạn (chính và phụ) đều có dữ liệu "xấu", vì vậy những gì bạn sẽ làm là khôi phục bản sao lưu gần đây nhất này thành một mongod mới. Đây là nơi bạn sẽ khôi phục các bản ghi này về trạng thái ngay trước khi có bản cập nhật vi phạm - và sau đó bạn có thể chuyển chúng vào bản chính hiện tại từ nơi chúng sẽ được sao chép sang tất cả các bản thứ hai.
Trong khi khôi phục bản sao lưu của bạn, hãy tạo một bản sao lưu của bộ sưu tập oplog của bạn thông qua lệnh sau:
mongodump -d local -c oplog.rs -o oplogD
Di chuyển oplog đến thư mục của chính nó, đổi tên nó thành oplog.bson:
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
Bây giờ bạn cần phải tìm hoạt động "vi phạm". Bạn có thể chuyển oplog sang dạng con người có thể đọc được bằng cách sử dụng bsondump lệnh trên tệp oplogR / oplog.bson (và sau đó sử dụng grep hoặc what-not để tìm bản cập nhật "xấu"). Ngoài ra, bạn có thể truy vấn đối với oplog ban đầu trong tập hợp bản sao qua use local và db.oplog.rs.find() lệnh trong shell.
Mục tiêu của bạn là tìm mục nhập này và ghi chú ts của nó trường.
Nó có thể trông như thế này:
"ts" : Timestamp( 1361497305, 2789 )
Lưu ý rằng mongorestore lệnh có hai tùy chọn, một tùy chọn được gọi là --oplogReplay và cái còn lại được gọi là oplogLimit . Bây giờ bạn sẽ phát lại oplog này trên máy chủ độc lập đã được khôi phục NHƯNG bạn sẽ dừng trước thao tác cập nhật vi phạm này.
Lệnh sẽ là (máy chủ và cổng là nơi chứa bản sao lưu mới được khôi phục của bạn):
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
Thao tác này sẽ khôi phục từng thao tác từ tệp oplog.bson trong thư mục oplogR dừng ngay trước mục nhập có giá trị ts Dấu thời gian (1361497305, 2789).
Hãy nhớ lại rằng lý do bạn làm điều này trên một phiên bản riêng biệt là để bạn có thể xác minh khôi phục và phát lại dữ liệu chính xác đã tạo - khi bạn đã xác minh nó thì bạn có thể ghi các bản ghi đã khôi phục vào vị trí thích hợp trong phiên bản chính thực sự (và cho phép sao chép lan truyền các hồ sơ đã được sửa chữa cho các thư ký thứ hai).
