Tôi đã giải quyết vấn đề này trong nhiều tuần nay.
Tôi có kịch bản sau đây:
couchdb2.3.1-A <===> couchdb2.3.1-B <===> couchdb3.1.1-A <===> couchdb3.1.1-B
ở đâu <===> đại diện cho hai bản sao kéo, một bản sao được định cấu hình ở mỗi bên. tức là: couchdb1 lấy từ couchdb2 và ngược lại.
Couchdb đang chạy trong docker container
Nếu một ghi được thực hiện tại đi văngdb2.3.1-A, nó phải đi qua tất cả các máy chủ cho đến khi đến couchdb3.1.1-B.
Tất cả họ đều có một ổ cứng độc quyền. Couchdb không chia sẻ đĩa với bất kỳ dịch vụ nào khác.
đi văngdb2.3.1 Một và b không có vấn đề gì.
couchdb3.1.1-A dần dần bắt đầu tăng độ trễ của đĩa theo thời gian. Vì vậy, chúng tôi ngừng viết yêu cầu cho nó và bắt đầu chỉ nói chuyện với couchdb3.1.1-B. couchdb3.1.1-A vẫn nhận được ghi nhưng chỉ bằng giao thức sao chép. Độ trễ của đĩa không thay đổi.
Những thay đổi chúng tôi đã thực hiện kể từ khi sự cố bắt đầu:
- Hạt nhân được nâng cấp từ
4.15.0-55-chung đến 5.4.0-88-chung
- Nâng cấp Ubuntu từ
18.04 đến 20.04
- Đã xóa
_global_changes cơ sở dữ liệu từ couchdb3.1.1-A
Thêm thông tin:
- Couchdb đang sử dụng khối lượng duy trì cục bộ docker.
- Đĩa là WD Purple cho
2.3.1 couchdbs và WD Black cho 3.1.1 couchdbs.
- Chúng tôi chỉ có một cơ sở dữ liệu về
88GiB và 2 lượt xem: một trong số 22GB và một chút của 30MB (cập nhật cao)
thống kê docker cho thấy couchdb3.1.1 sử dụng nhiều bộ nhớ hơn so với 2.3.1:
3,5GiB cho couchdb3.1.1-A (không nhận được yêu cầu ghi trực tiếp)8.0GiB cho couchdb3.1.1-A (nhận cả yêu cầu đọc và ghi)226MiB cho 2.3.1-A552MiB cho 2.3.1-B
- Nén cơ sở dữ liệu được chạy vào ban đêm. Sự cố chỉ xảy ra trong ngày, khi hầu hết các thao tác ghi được thực hiện.
- Hầu hết các cấu hình là mặc định.
Biểu đồ độ trễ từ giám sát munin:
độ trễ đĩa
Bất kỳ trợ giúp được đánh giá cao.
