У меня есть настройка CouchDB (CouchDB 2.1.1) для моего приложения, которая сильно зависит от целостности репликации.Мы используем подход «один дБ на пользователя» с дополнительным уровнем «роли» db: s, который группирует пользователей, как показано на рисунке ниже.
Недавно, увеличив число бета-тестеров, мы обнаружили, чтонекоторые документы не были воспроизведены должным образом.Мы не можем увидеть какой-либо шаблон по размеру документа, времени создания / обновления, пользователю или другому.Ошибки кажутся случайными, с 2-3 успешно реплицированными документами, за которыми следуют 4-6 без репликации документов.
Сервер отвечает {"error":"not_found","reason":"missing"} на эти документы.
Большая часть (но не все) пользовательских документов была реплицирована в соответствующую Ролевую БД, но очень немногие сделали это полностьюМастер БД.Этого никогда не случалось при тестировании с <100 документами (сейчас у нас 1000-1200 документов в БД). </p>
Я обнаружил проблему с настройкой "max open files", упомянутой в главе "Производительность "в документах и исправил его, но не реплицированные документы все еще не реплицируются.Если я открою документ и сохраню его, он будет реплицирован.
Это моя текущая теория:
- Процесс репликации пытался копировать новые документы, когда пользователь вышел в сеть
- Процесс записи не удался из-за пика "max_open_files" в Linux
- Основная БД по-прежнему считает, что репликация прошла успешно
- При более поздней репликации главная БД игнорирует эти старые документы и только пытаетсякопировать новые
Может ли это быть правильным?И могу ли я как-нибудь заставить сервер CouchDB "дважды проверить" все документы и целостность предыдущих копий?
Спасибо за ваше время и любые полезные комментарии!
