Khắc phục sự cố với Cụm phân mảnh MongoDB

Chọn Khóa Phân đoạn và Tính khả dụng của Cụm

Sharding liên quan đến việc chia dữ liệu thành các nhóm nhỏ được gọi là phân đoạn để giảm khối lượng công việc tổng thể cho một thông lượng nhất định hoạt động. Việc phân nhóm này đạt được thông qua việc chọn một khóa tối ưu, chủ yếu là phần quan trọng nhất trước khi phân loại. Một khóa tối ưu phải đảm bảo:

1. Mongos có thể tách hầu hết các truy vấn với một mongod cụ thể. Ví dụ:nếu có nhiều hoạt động hơn phải chịu một phân đoạn duy nhất, thì phân đoạn đó bị lỗi sẽ chỉ làm cho dữ liệu liên quan đến nó bị vắng mặt tại thời điểm đó. Bạn nên chọn khóa phân đoạn sẽ cung cấp nhiều phân đoạn hơn để giảm lượng dữ liệu không có sẵn trong trường hợp phân đoạn bị lỗi.
2. MongoDB sẽ có thể chia đều dữ liệu giữa các phần. Điều này đảm bảo rằng các hoạt động thông lượng cũng sẽ được phân bổ đồng đều, giảm nguy cơ xảy ra lỗi do khối lượng công việc nhiều hơn.
3. Viết khả năng mở rộng trên toàn bộ cụm để đảm bảo tính khả dụng cao. Mỗi phân đoạn phải là một tập hợp bản sao, trong đó nếu một bản sao mongod nhất định không thành công, các thành viên tập hợp bản sao còn lại có thể bầu một thành viên khác làm thành viên chính do đó đảm bảo hoạt động liên tục.

Nếu trong bất kỳ trường hợp nào, một phân đoạn nhất định có xu hướng không thành công, hãy bắt đầu bằng cách kiểm tra xem có bao nhiêu hoạt động thông lượng nó có phải là chủ đề và cân nhắc chọn một phím làm sắc nét tốt hơn để có nhiều phân đoạn hơn.

Điều gì xảy ra nếu? Phiên bản Mongos vắng mặt

Trước tiên, hãy kiểm tra xem bạn có đang kết nối với đúng cổng hay không vì có thể bạn đã vô tình thay đổi. Ví dụ:triển khai với nền tảng AWS, có khả năng xảy ra sự cố này do các nhóm bảo mật có thể không cho phép kết nối trên cổng đó. Để kiểm tra ngay lập tức, hãy thử chỉ định đầy đủ máy chủ:cổng để đảm bảo rằng bạn đang sử dụng giao diện lặp lại. Điều tốt là, nếu mỗi máy chủ ứng dụng có phiên bản mongos của riêng nó, các máy chủ ứng dụng có thể tiếp tục truy cập cơ sở dữ liệu. Bên cạnh đó, các phiên bản mongos có trạng thái thay đổi theo thời gian và có thể khởi động lại mà không nhất thiết phải mất dữ liệu. Khi phiên bản được kết nối lại, nó sẽ truy xuất bản sao của cơ sở dữ liệu cấu hình và bắt đầu truy vấn định tuyến.

Đảm bảo rằng cổng bạn đang cố gắng kết nối lại cũng không bị quá trình khác chiếm giữ.

Điều gì xảy ra nếu? Một thành viên vắng mặt trong nhóm bản sao mảnh

Bắt đầu bằng cách kiểm tra trạng thái của phân đoạn bằng cách chạy lệnh sh.status (). Nếu kết quả trả về không có clusterId thì phân đoạn thực sự không khả dụng. Luôn kiểm tra các gián đoạn và hỏng hóc khả dụng và nếu bạn không thể khôi phục nó trong thời gian ngắn nhất có thể, hãy tạo một thành viên mới để thay thế càng sớm càng tốt để tránh mất nhiều dữ liệu hơn.

Nếu một thành viên phụ không khả dụng nhưng với các mục oplog hiện tại, khi được kết nối lại, nó có thể bắt kịp trạng thái thiết lập mới nhất bằng cách đọc dữ liệu hiện tại từ oplog như quá trình sao chép bình thường. Nếu nó không thể tái tạo dữ liệu, bạn cần thực hiện đồng bộ hóa ban đầu bằng cách sử dụng một trong hai tùy chọn này ...

1. Khởi động lại mongod với thư mục dữ liệu trống và để tính năng đồng bộ hóa ban đầu bình thường của MongoDB khôi phục dữ liệu. Tuy nhiên, cách này sẽ mất nhiều thời gian để sao chép dữ liệu nhưng khá dễ dàng.
2. Khởi động lại máy chủ bằng bản sao của thư mục dữ liệu gần đây từ một thành viên khác trong nhóm bản sao. Quy trình nhanh chóng nhưng có nhiều bước phức tạp

Đồng bộ hóa ban đầu sẽ cho phép MongoDB ...

1. Sao chép tất cả các cơ sở dữ liệu có sẵn ngoại trừ cơ sở dữ liệu cục bộ. Đảm bảo rằng thành viên đích có đủ dung lượng đĩa trong cơ sở dữ liệu cục bộ để tạm thời lưu trữ các bản ghi oplog trong một khoảng thời gian mà dữ liệu đang được sao chép.
2. Áp dụng tất cả các thay đổi cho tập dữ liệu sử dụng oplog từ nguồn. Quá trình sẽ chỉ hoàn tất nếu trạng thái của bản sao chuyển đổi từ STARTUP2 sang SECONDARY.

Điều gì xảy ra nếu? Tất cả các thành viên của một tập hợp bản sao đều vắng mặt

Dữ liệu được giữ trong một phân đoạn sẽ không khả dụng nếu tất cả các thành viên của phân đoạn tập hợp bản sao bị vắng mặt. Vì các phân đoạn khác vẫn có sẵn, các thao tác đọc và ghi vẫn có thể thực hiện được ngoại trừ việc ứng dụng sẽ được cung cấp một phần dữ liệu. Bạn sẽ cần phải điều tra nguyên nhân của sự gián đoạn và cố gắng kích hoạt lại phân đoạn càng sớm càng tốt. Kiểm tra trình biên dịch truy vấn hoặc phương pháp giải thích điều gì có thể đã dẫn đến sự cố đó.

Điều gì xảy ra nếu? Dữ liệu cấu hình cũ dẫn đến lỗi con trỏ

Đôi khi một phiên bản mongos có thể mất nhiều thời gian để cập nhật bộ đệm siêu dữ liệu từ cơ sở dữ liệu cấu hình dẫn đến một truy vấn trả về cảnh báo:

could not initialize cursor across all shards because : stale config detected

Lỗi này sẽ luôn xuất hiện cho đến khi các phiên bản mongos làm mới bộ nhớ đệm của chúng. Điều này sẽ không lan truyền trở lại ứng dụng. Để khắc phục điều này, bạn cần buộc làm mới phiên bản bằng cách chạy fluRouterConfig.

Để xóa bộ nhớ cache cho một lần chạy bộ sưu tập cụ thể

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Để xóa bộ nhớ cache cho một cơ sở dữ liệu cụ thể chạy

db.adminCommand({ flushRouterConfig: "<db>" } )

Để xóa bộ nhớ cache cho tất cả cơ sở dữ liệu và bộ sưu tập của chúng, hãy chạy:

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Điều gì xảy ra nếu? Máy chủ cấu hình trở nên không khả dụng

Máy chủ cấu hình trong trường hợp này có thể được coi là thành viên chính mà từ đó các nút phụ sao chép dữ liệu của chúng. Nếu nó vắng mặt, các nút phụ có sẵn sẽ phải chọn một trong số các thành viên của chúng để trở thành nút chính. Để tránh gặp phải trường hợp bạn có thể không có máy chủ cấu hình, hãy xem xét phân phối các thành viên tập hợp bản sao trên hai trung tâm dữ liệu kể từ ...

• Nếu một trung tâm dữ liệu gặp sự cố, dữ liệu sẽ vẫn có sẵn để đọc thay vì không có hoạt động nào nếu bạn sử dụng một trung tâm dữ liệu duy nhất .
• Nếu trung tâm dữ liệu bao gồm các thành viên thiểu số gặp sự cố, tập hợp bản sao vẫn có thể phục vụ cả hoạt động ghi và đọc.

Bạn nên phân phối các thành viên trên ít nhất ba trung tâm dữ liệu.

Một khả năng phân phối khác là phân phối đồng đều các thành viên mang dữ liệu trên hai trung tâm dữ liệu và các thành viên còn lại trong đám mây.

Sửa Lỗi Chuỗi Cơ sở dữ liệu

Từ MongoDB 3.4, máy chủ cấu hình SCCC không được hỗ trợ cho các phiên bản mongod được sao chép. Nếu bạn cần nâng cấp cụm phân đoạn của mình lên phiên bản 3.4, bạn cần chuyển đổi máy chủ cấu hình từ SCCC sang CSRS.

Tránh thời gian ngừng hoạt động khi di chuyển máy chủ cấu hình

Thời gian ngừng hoạt động có thể xảy ra do một số yếu tố như mất điện hoặc tần số mạng do đó dẫn đến lỗi của một máy chủ cấu hình đối với cụm. Sử dụng CNAME để xác định máy chủ đó để đổi tên hoặc đánh số lại trong quá trình kết nối lại. Nếu lệnh cam kết moveChunk không thành công trong quá trình di chuyển, MongoDB sẽ thông báo lỗi:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

Điều này có nghĩa là phân đoạn cũng chưa được kết nối với cơ sở dữ liệu cấu hình do đó phân đoạn chính sẽ chấm dứt thành viên này Để tránh sự không nhất quán về dữ liệu. Bạn cần giải quyết lỗi di chuyển phân đoạn một cách độc lập bằng cách tham khảo ý kiến ​​của bộ phận hỗ trợ MongoDB. Đồng thời đảm bảo cung cấp một số tài nguyên ổn định như mạng và nguồn cho cụm.

Kết luận

Một cụm phân đoạn MongoDB làm giảm khối lượng công việc mà một máy chủ duy nhất sẽ phải chịu để cải thiện hiệu suất của các hoạt động thông lượng. Tuy nhiên, việc không định cấu hình chính xác một số tham số như chọn khóa phân đoạn tối ưu có thể tạo ra sự mất cân bằng tải do đó một số phân đoạn kết thúc không thành công.

Giả sử cấu hình được thực hiện đúng, một số trở ngại không thể tránh khỏi như mất điện cũng có thể xảy ra. Để tiếp tục hỗ trợ ứng dụng của bạn với thời gian ngừng hoạt động tối thiểu, hãy xem xét sử dụng ít nhất 3 trung tâm dữ liệu. Nếu một trong những không thành công, những người khác sẽ có sẵn để hỗ trợ các hoạt động đọc nếu chính nằm trong số các thành viên bị ảnh hưởng. Ngoài ra, hãy nâng cấp hệ thống của bạn lên ít nhất là phiên bản 3.4 vì nó hỗ trợ nhiều tính năng hơn.