Модернизация Couchbase с помощью шлюзов паузы CAO: обзор для удобной поддержки

Если вы поддерживаете платформу Couchbase (или вы тот человек, который получает уведомление, когдане ведет себя), обновления могут ощущаться как выбор между «невмешательством и надеждой» и «ручным и рискованным». В этом посте представлен прагматичный компромисс: контролируемоепоследовательное обновлениедля сервера Couchbase, работающего под управлением автономного оператораCouchbase (CAO), в сочетании с собственным полемspec.pausedдля CAO.

Для кого это

• Техническая поддержка / специалисты по реагированию на инциденты:, как выглядит «нормально» во время перебалансировки подкачки и что следует рассматривать как красный флаг.
• SRE / инженеры платформы: повторяемая процедурас предполетными проверками, шлюзами и триггерами отката.
• Инженеры баз данных:перебалансирует ожидания, поведение XDCR и проверку после обновления.
• Разработчики:, что ваша платформа делает во время периода обслуживания (и о чем следует предупреждать).

Типичная топология под управлением CAO (концептуальная)

На диаграмме ниже представлена ​​мысленная карта для Runbook: где сидит оператор, чем управляетCouchbaseClusterCR и какие сигналы следует сопоставлять во время обновления.

Большая идея: ускорить CAO с помощью шлюза паузы

CAO выполняет последовательное обновление посредством перебалансировки подкачки. Runbook добавляет преднамеренный барьер безопасности: приостановить согласование между узлами, стабилизировать, проверить работоспособность, а затем возобновить. Таким образом, если узел N ведет себя неправильно после замены, вы поймаете егодо того, как запустится узелN+1.

Почему ворота паузы того стоят

• Меньше сюрпризов:изолирует симптомы до изменения одного узла.
• Чистые сигналы:соотносит задержку, частоту ошибок, состояние ребалансировки и задержку XDCR с одним свопом.
• Более безопасное развертывание:быстро останавливает «конвейер», удерживаяspec.paused=trueво время расследования.

Как выглядит «хорошо» во время обновления

• Образы подов:старый → постепенно новый; в идеале по одному обмену за раз.
• Фаза кластера:часто возвращается кAvailableмежду заменами; ожидаются короткие переходы во время ребалансировки.
• XDCR (если включен):changes_leftповышается во время ребалансировки, затем снижается во время стабилизации.
• Перезапуск: новые модулиначинаются сRESTARTS=0. Любое увеличение является сигналом к ​​паузе и исследованию.

Предварительная проверка, которая спасет вас позже

Прежде чем что-либо трогать, убедитесь, что кластер зеленый (нет активной ребалансировки, нет событий предупреждений), резервные копии являются текущимии восстанавливаемыми, а также вы записали тег образа отката. Заранее определите стратегию XDCR: отключите ее во время обновления, чтобы обеспечить более тихий сигнал в рабочей среде, продолжайте работать в предварительной версии для проверки реального поведения или используйте третий резервный кластер для стратегических переключений.

Проверка реальности отката

Неудобная истина, которую зрелые Runbook говорят вслух: откатвозможен только в том случае, если хотя бы один узел остается на старой версии. После замены каждого модуля и полной ребалансировки кластера «понижение предыдущей версии» может стать «восстановлением из резервной копии». Вот почему темп имеет значение: он держит окно отката открытым дольше.

Следующие шаги

• Прочтите полное руководство по эксплуатации:Couchbase Последовательное обновление сервера под CAO (шаг + пауза)
• Связанные сведения:Высокая доступность Couchbase в производстве (оператор XDCR + Kubernetes)