Saltar al contenido
Iniciar un proyecto

Artículo

Upgrade rolling de Couchbase Server bajo CAO (ritmo + puerta de pausa)

Runbook copiar/pegar para soporte y equipos SRE: preflight, swap-rebalance nodo a nodo, estrategia XDCR, disparadores de rollback y comprobaciones de cierre

  • 2 min de lectura
  • Base de datos
  • Kubernetes
  • DevOps
  • SRE
En esta página

Los upgrades son donde se demuestra o se rompe la fiabilidad de la base de datos. Este artículo ofrece un runbook ritmado y amigable para soporte para actualizar Couchbase Server bajo el Couchbase Autonomous Operator (CAO), usando el campo nativo spec.paused para controlar el progreso entre nodos. Resultado: un nodo a la vez, ventana de estabilización entre swaps, señales más claras y una ventana de rollback mayor.

Topología de referencia

Topología típica de Couchbase en AKS

El bucle de upgrade ritmado

Bucle de upgrade ritmado

Objetivos

  • Actualizar Couchbase Server con riesgo mínimo.
  • Mantener una ventana deliberada de pausa + estabilizar + comprobación de salud entre nodos.
  • Conservar opciones de rollback el mayor tiempo práctico.

Lista previa al upgrade (no omitir)

  • Todo en verde: fase del clúster Available, sin rebalance activo, sin eventos de advertencia.
  • Backups actuales y restaurables: backup completo terminado; drill de restore hecho o tiempo entendido.
  • Etiqueta de rollback registrada: verificar que la imagen antigua aún existe y se puede tirar.
  • Decisión XDCR registrada: desactivar durante upgrades de prod para señal limpia (recomendado), o mantener en pre-prod para ejercitar el comportamiento.

Comandos rápidos de verificación

export ENV=dev
export REGION=west
export NS=couchbase-${ENV}-${REGION}

kubectl -n "$NS" get couchbasecluster -o wide
kubectl -n "$NS" get pods -l app=couchbase
kubectl -n "$NS" get events --field-selector type=Warning | tail -20
kubectl -n "$NS" get couchbasecluster "$NS" -o jsonpath='paused={.spec.paused} phase={.status.phase} rebalance={.status.rebalanceProgress}{"\n"}'

Rutas de ejecución

  • Preferida: ejecutar el upgrade desde su workflow de CI (dry-run primero, luego ejecución real).
  • Alternativa: ejecutar el script de upgrade ritmado desde una workstation (dry-run primero, luego real).

Señales de monitorización (qué debe vigilar soporte)

  • Imágenes de pods: paso de antigua → nueva; un swap a la vez es ideal.
  • Estado de pausa: spec.paused pasa a true durante la estabilización; nunca dejarlo true sin atención.
  • Rebalance: vuelve a none entre swaps; investigar rebalances persistentes.
  • XDCR: changes_left sube durante el rebalance y drena en estabilización; no drenar es señal de incidente.
  • Reinicios: cualquier reinicio inesperado post-swap es bandera roja.

Disparadores de rollback

  • El nodo no se pone sano dentro de la ventana de timeout.
  • El rebalance falla y no se resuelve con un solo reintento tras investigación.
  • La tasa de error de la aplicación supera la tolerancia acordada.
  • XDCR no se recupera tras la ventana de recuperación acordada.
  • Cualquier bucket no disponible (vbuckets faltantes) — tratar como P1.

Validación post-upgrade (cierre)

  • Todos los pods en la imagen objetivo
  • Fase del clúster Available
  • Sin nuevos eventos de advertencia durante 30+ minutos
  • Backup exitoso tras el upgrade
  • XDCR en estado estable recuperado (si se usa)
  • Dashboards de aplicación en verde durante 30+ minutos

Consejo: Si quiere primero una versión narrativa más corta, empiece por el resumen del blog: Upgrades de Couchbase con puertas de pausa CAO.

Más artículos técnicos