Khởi động lại/Tự động ghép Mongodb trong Sản xuất

Question

Điều tôi muốn đạt được là có tập lệnh /etc/init.d khởi động Mongodb đáng tin cậy hơn, ngay cả khi nó bị hỏng - nó sẽ cố gắng tự động sửa chữa trong trường hợp hệ thống đang ở trạng thái bị khóa.

Vâng, tôi có thể tự mình viết kịch bản này, nhưng tôi nghĩ có ai đó ở đó chắc đã làm điều này rồi.

Tôi nhận thấy rằng sau khi máy chủ gặp khó khăn, Mongodb ở trạng thái không khởi động lại thông qua tập lệnh /etc/init.d/mongod. Rõ ràng các tập tin khóa (s) cần phải được loại bỏ và nó cần phải được bắt đầu với tùy chọn --repair và sửa --dbpath đầu tiên, trước khi nó có thể được khởi động lại thành công. Trong một số trường hợp, người dùng cũng cần thay đổi quyền sở hữu của các tệp db cho người dùng chạy mongodb. Một vấn đề nữa là script /etc/init.d/mongod tiêu chuẩn không báo cáo một sự thất bại trong tình huống này, mà là trả về một cách vui vẻ và không chính xác với trạng thái "OK", báo cáo rằng Mongod đã được bắt đầu, mặc dù nó không phải.

$ sudo /etc/init.d/mongod start 
Starting mongod: forked process: 9220 
all output going to: /data/mongo/log/mongod.log 
                  [ OK ] 
$ sudo /etc/init.d/mongod status 
mongod dead but subsys locked 

Hệ điều hành là CentOS hoặc Fedora.

Có ai đã sửa đổi tập lệnh /etc/init.d hoặc trỏ đến tập lệnh như vậy, tự động sửa chữa trong tình huống đó không? Hoặc có công cụ nào khác hoạt động như một chú chó đồng hồ cho Mongod không?

Bất kỳ ý kiến ​​nào về lý do tại sao ý tưởng xấu có thể tự động sửa chữa mongodb?

$ sudo /etc/init.d/mongod status 
mongod dead but subsys locked 

$ sudo ls -l /var/lib/mongo/mongod.lock 
-rw-r--r--. 1 mongod mongod 5 Nov 19 11:52 /var/lib/mongo/mongod.lock 


$ sudo tail -50 /data/mongo/log/mongod.log 
************** 
old lock file: /data/mongo/db/mongod.lock. probably means unclean shutdown 
recommend removing file and running --repair 
see: http://dochub.mongodb.org/core/repair for more information 
************* 
Sat Nov 19 11:55:44 exception in initAndListen std::exception: old lock file, terminating 
Sat Nov 19 11:55:44 dbexit: 

Sat Nov 19 11:55:44 shutdown: going to close listening sockets... 
Sat Nov 19 11:55:44 shutdown: going to flush oplog... 
Sat Nov 19 11:55:44 shutdown: going to close sockets... 
Sat Nov 19 11:55:44 shutdown: waiting for fs preallocator... 
Sat Nov 19 11:55:44 shutdown: closing all files... 
Sat Nov 19 11:55:44  closeAllFiles() finished 

Sat Nov 19 11:55:44 dbexit: really exiting now 

Answer 1

Vì vậy, bit đầu tiên cần đề cập đến là ghi nhật ký. Nhật ký được lập hoá đơn hiệu quả là "sửa chữa nhanh". Tính năng ghi nhật ký được bật theo mặc định trong phiên bản 2.0 trở lên và nó sẽ thực hiện "sửa chữa" theo mặc định.

Vì vậy, nếu đĩa của bạn có thể xử lý thêm thông lượng ghi nhật ký, điều này có thể giải quyết được sự cố của bạn.

Bất kỳ ý kiến ​​nào về lý do tại sao bạn nên cố gắng tự động sửa lỗi mongodb?

Vấn đề số 1 với sửa chữa MongoDB tự động đơn giản là một lần.

Nếu bạn có một cơ sở dữ liệu 200GB, hệ thống sẽ cần phải làm như sau khi sửa chữa:

1. Phân bổ ~ 200GB của file (bạn có không gian ổ?)
2. đã đọc tất cả các dữ liệu từ các tập tin có sẵn vào bộ nhớ (200GB read)
3. Kiểm tra mỗi tài liệu cho tính hợp lệ và viết lại cho các tập tin mới (200GB write)
4. Tái tạo tất cả các chỉ số (200GB reads + large number of writes)
5. mọi thứ Flush vào đĩa

Nếu bạn nhìn vào ghi chú của tôi đó là một số lượng nghiêm trọng của ổ đĩa sân đập để thực hiện một sửa chữa.

Nhưng hầu hết các lượt cài đặt sản xuất đều chạy các bản sao. Trong trường hợp này, thay vì sửa chữa, bạn chỉ có thể khôi phục từ bản sao lưu.Khôi phục từ một bản sao lưu chỉ ghi dữ liệu một lần và đó là một quá trình mà bạn đã có sẵn tại chỗ.

Mặc dù mã init.d trả lại OK, việc giám sát hệ thống của bạn phải cho bạn biết rằng DB không hoạt động.

Answer 2

Chỉ muốn chỉ ra rằng việc ghi nhật ký hiện hoạt động trong phiên bản 32 bit. Tuy nhiên, nó không được bật theo mặc định trong 32-bit.