3. У нас, как я уже писал, рабочая схема предполагает храненние всех данных бакета в памяти, если происходит их выгрузка (например, при росте очереди записи на диск и нехватке выделенной бакету памяти), то это нештатная ситуация. В некоторых случаях достаточно хранения лишь части данных в памяти, и допускается, что некоторые запросы будут выполняться значительно дольше остальных, если запрошенные данные на диске. Интересно как у вас? Все данные бакета помещаются в памяти?
Кстати, какое общее кол-во бакетов?
Мониторинг реализован через API Couchbase, snmp и самописный миб
Интересное решение. В открытый доступ не планировали выложить?
Если я правильно понимаю, то в этом случае возможно восстановить только строго такую же конфигурацию кластера с ровно таким же кол-вом нод, а объем памяти серверов должен быть не меньше чем в исходном кластере. Т.е. не получится развернуть эти данные, например, на упрощенном тестовом кластере? (Вы, похоже, в т.ч. для этих целей используете XDCR)
2. Мы не выводим основной кластер из эксплуатации(простоя нет)
Ясно, спасибо за развернутый ответ.
выводим сервер через gracefull, и делаем ребаланс
Похоже, на этом шаге операцию gracefull можно заменить на remove с тем же эффектом.
3. С прогревом сталкивались только при падении нод
Ваша схема бакетов допускает падение active docs resident ниже 100%?
Напишу коллегам из CouchBase
Спасибо!
А как мониторинг метрик couchbase у вас реализован?
Спасибо за статью. Позвольте разузнать больше деталей.
1. Как именно у вас реализован бекап? Утилитами cbbackup/cbbackupmgr непосредственно на серверах кластера? На мастер или слейв кластере? Или как-то ещё? В моем эксперементе с помощью cbbackup удалось достичь скокрость всего в 5-7 МБ/с, что безусловно медленно для больших баз.
2. Как производится обновление серверов кластера? Ведь при отключении одной ноды, статус кластера меняется на unhealthy, а ребалансировка требует времени. На этот период используется только слейв кластер в режиме RO?
3. Можно ли как-то форсировать «прогрев» бакет в боевом кластере без перезапуска ноды? Иногда случается превышение high watermark и данные выгружаются из памяти, что недопустимо для некоторых бакетов в нашей архитектуре.
Кстати, какое общее кол-во бакетов?
Интересное решение. В открытый доступ не планировали выложить?
Если я правильно понимаю, то в этом случае возможно восстановить только строго такую же конфигурацию кластера с ровно таким же кол-вом нод, а объем памяти серверов должен быть не меньше чем в исходном кластере. Т.е. не получится развернуть эти данные, например, на упрощенном тестовом кластере? (Вы, похоже, в т.ч. для этих целей используете XDCR)
Ясно, спасибо за развернутый ответ.
Похоже, на этом шаге операцию gracefull можно заменить на remove с тем же эффектом.
Ваша схема бакетов допускает падение active docs resident ниже 100%?
Спасибо!
А как мониторинг метрик couchbase у вас реализован?
1. Как именно у вас реализован бекап? Утилитами
cbbackup/cbbackupmgrнепосредственно на серверах кластера? На мастер или слейв кластере? Или как-то ещё? В моем эксперементе с помощьюcbbackupудалось достичь скокрость всего в 5-7 МБ/с, что безусловно медленно для больших баз.2. Как производится обновление серверов кластера? Ведь при отключении одной ноды, статус кластера меняется на unhealthy, а ребалансировка требует времени. На этот период используется только слейв кластер в режиме RO?
3. Можно ли как-то форсировать «прогрев» бакет в боевом кластере без перезапуска ноды? Иногда случается превышение high watermark и данные выгружаются из памяти, что недопустимо для некоторых бакетов в нашей архитектуре.