Tại sao Mongo bị kẹt trong STARTUP2?

Tôi có một Mongobộ bản sao với một vài phụ. Một hộp, chứa một thể hiện thứ cấp, đã bị hỏng và mất cơ sở dữ liệu.

Tôi đã bắt đầu lại trường Mongohợp thứ cấp và bây giờ nó bị kẹt trong STARTUP2 trong hơn 12 giờ. Liệu nó có ý nghĩa? Các tài liệu nói Mongophải ở trong STARTUP2 trong một khoảng thời gian ngắn trước khi vào trạng thái PHỤC HỒI

STARTUP2 chính xác có nghĩa là gì? Có phải nó sao chép cơ sở dữ liệu từ chính? Làm cách nào để xác minh nó (giả sử Mongo đang chạy trong Linux)?

Câu trả lời của eoinbrazil là một phần không chính xác. Một nút mới có thể có trong STARTUP2 trong một thời gian dài. Các liên kết được đăng nói:

Mỗi thành viên của bộ bản sao sẽ vào trạng thái STARTUP2 ngay khi mongod hoàn tất tải cấu hình của thành viên đó, tại thời điểm đó, nó trở thành thành viên tích cực của bộ bản sao. Thành viên sau đó quyết định có thực hiện đồng bộ hóa ban đầu hay không. Nếu một thành viên bắt đầu đồng bộ hóa ban đầu, thành viên đó vẫn ở trong STARTUP2 cho đến khi tất cả dữ liệu được sao chép và tất cả các chỉ mục được xây dựng. Sau đó, các thành viên chuyển sang PHỤC HỒI.

Tôi đang quản lý bộ sưu tập 700 GB và khi tôi thêm một nút mới, trạng thái STARTUP2 vẫn hoạt động tốt trong 24 giờ. Nhưng bạn vẫn có thể thấy nếu có điều gì đó xảy ra, bằng cách xem nếu cơ sở dữ liệu phát triển. Bạn có thể thấy kích thước của cơ sở dữ liệu trên nút mới với

show databases

hoặc bạn cũng có thể quan sát thư mục dữ liệu, để xem nó có còn phát triển không. (trên linux với các lệnh ls, df, du, iotop, v.v ....)

Trạng thái STARTUP2 có nghĩa là nút không thể bỏ phiếu. Một thành viên của RS bước vào trạng thái này sau khi quá trình MongoD hoàn tất tải cấu hình của nó. Ở trạng thái này, thành viên đã tạo các luồng để xử lý các hoạt động sao chép bên trong nhưng nó vẫn chưa thay đổi trạng thái thành Phục hồi và chuyển từ trạng thái đó sang Trung học (xem [trạng thái và chi tiết của chúng trong tài liệu]) .

Nếu nút của bạn đã ở trạng thái này trong hơn một khoảng thời gian ngắn thì bạn sẽ gặp một số hành vi lạ. Điều này là khá nhiều không thể phân tích mà không có nhật ký để xác định lý do tại sao nó bị mắc kẹt. Chạy rs.status () và db.printSlaveReplicationInfo () sẽ cung cấp cho bạn một số chi tiết về hình ảnh cục bộ trên nút.

Cách tiếp cận thông thường để giải quyết vấn đề này sẽ là tắt nút, xóa các tệp dữ liệu của nó (các tệp đó trong dbpath) và khởi động lại nó. Điều này sẽ khởi động lại quá trình đồng bộ hóa ban đầu và nó sẽ chuyển sang THỨ HAI. Nếu nó bị kẹt trong STARTUP2 một lần nữa, bạn sẽ cần xem nhật ký để thu thập thêm thông tin về lý do - có một số nguyên nhân nhưng một nguyên nhân có thể xảy ra là mạng không ổn định hoặc một số tranh chấp tài nguyên cục bộ.

Một điểm cần lưu ý là trong khi quá trình đồng bộ hóa ban đầu đang diễn ra, nút sẽ vẫn ở STARTUP2, do đó tùy thuộc vào lượng dữ liệu được đồng bộ hóa, đây có thể là một khoảng thời gian đáng kể (có thể là vài ngày).

Một nguyên nhân có thể là thứ cấp của bạn trở nên "cũ" như đã nêu ở đây .

Khi bạn đang đồng bộ lại một thành viên, hãy đảm bảo RS không bị tải nặng.

Trạng thái STARTUP2 có thể là do không đủ dung lượng đĩa. Chà, vì không có nơi nào để đồng bộ hóa, nên nó chỉ có thể ở trạng thái @ STARTUP2.