Couchbase Hoge beschikbaarheid in productie: XDCR, Kubernetes Operator en implementatie in meerdere regio's

Introductie: Waarom Couchbase voor productieworkloads met hoge beschikbaarheid

Couchbase Server is een gedistribueerde NoSQL-database met meerdere modellen, ontworpen voor interactieve toepassingen die op elke schaal consistente prestaties met lage latentie vereisen. In tegenstelling tot databases die gedistribueerde functies als bijzaak toevoegen, is Couchbase vanaf het begin ontworpen rond een peer-to-peer-topologie waarbij niets wordt gedeeld, waarbij elk knooppunt gelijk is en gegevens automatisch over het cluster worden verdeeld met behulp van een deterministisch hashmechanisme genaamdvBuckets. Deze architectonische keuze elimineert afzonderlijke storingspunten in de gegevenslaag en maakt horizontale schaling mogelijk zonder wijzigingen in de applicatie.

Wat Couchbase onderscheidt in het landschap met hoge beschikbaarheid is deCross Data Center Replication (XDCR)– een ingebouwde, asynchrone replicatie-engine die continu mutaties streamt tussen geografisch verspreide clusters. Gecombineerd met automatische failover, rack-/zonebewustzijn en een rijke reeks geïntegreerde services (Data, Index, Query, Search, Analytics en Eventing), biedt Couchbase een uniform platform dat kan dienen als zowel de operationele database als de analytische engine voor moderne applicaties.

In deze uitgebreide handleiding onderzoeken we elk aspect van het draaien van Couchbase Server in productieomgevingen met hoge beschikbaarheid: de interne architectuur die HA mogelijk maakt, XDCR-configuratie voor implementaties in meerdere regio's, de Couchbase Autonomous Operator voor Kubernetes, cloudspecifieke implementatiepatronen voor AWS EKS, Azure AKS en GCP GKE, bare metal k3s-implementaties met Rancher en Longhorn, back-up- en herstelstrategieën, N1QL-queryafstemming, beveiligingsverbetering, monitoring en Couchbase Mobile met Sync Gateway voor edge-implementaties. Aan het einde beschikt u over bruikbare kennis om Couchbase-clusters van productiekwaliteit op elke infrastructuur te implementeren en te exploiteren.

Couchbase-serverarchitectuur: services, vBuckets en automatisch delen

Het begrijpen van de interne architectuur van Couchbase is van cruciaal belang voordat u deze implementeert voor hoge beschikbaarheid. Couchbase maakt gebruik van eenMulti-Dimensional Scaling (MDS)-architectuur waarbij verschillende services onafhankelijk kunnen worden geïmplementeerd en geschaald over clusterknooppunten. Dit geeft operators een nauwkeurige controle over de toewijzing van middelen en prestatie-isolatie.

De zes kerndiensten

Couchbase Server biedt zes geïntegreerde services, die elk een ander type werklast verwerken:

• Data Service (KV)— De kernsleutel-waarde-engine gebouwd op een geheugen-eerste architectuur. Het verwerkt CRUD-bewerkingen, beheert de vBucket-distributie en dient als persistentielaag. Gegevens worden opgeslagen in het geheugen (beheerde cache) en asynchroon bewaard op schijf. Deze service moet op minimaal één knooppunt in elk cluster draaien.
• Index Service (GSI)— Onderhoudt wereldwijde secundaire indexen die N1QL-query's ondersteunen. Indexen worden afzonderlijk van de gegevens opgeslagen, waardoor onafhankelijke schaling mogelijk is. Ondersteunt standaard en geheugengeoptimaliseerde indexopslagmodi.
• Query Service (N1QL)— Voert N1QL-query's (SQL++ voor JSON) uit op het cluster. Staatloos van ontwerp, waardoor horizontaal eenvoudig te schalen is. Coördineert met de Data- en Index-services om queries te plannen en uit te voeren.
• Zoekservice (FTS)— Biedt zoekmogelijkheden in volledige tekst, mogelijk gemaakt door de Bleve-zoekmachine. Ondersteunt fuzzy matching, georuimtelijke zoekopdrachten, facetzoeken en aangepaste analysers. Indexen worden gepartitioneerd en gerepliceerd over zoekknooppunten.
• Analytics Service (CBAS)— Voert complexe analytische queries uit met behulp van een parallelle verwerkingsengine gebaseerd op Apache Asterix. Werkt op een eigen kopie van de gegevens en zorgt ervoor dat analytische werklasten nooit van invloed zijn op de operationele latentie.
• Eventing Service— Voert JavaScript-functies aan de serverzijde uit als reactie op gegevensmutaties. Maakt realtime gegevensverrijking, transformaties, trapsgewijze verwijderingen en integratietriggers mogelijk zonder externe infrastructuur.

vBucket-distributie en automatisch delen

Couchbase distribueert gegevens over het cluster met behulp van1024 vBuckets(virtuele buckets). Elk document wordt toegewezen aan een vBucket met behulp van een CRC32-hash van de documentsleutel modulo 1024. De clusterkaart – onderhouden door elk knooppunt en in de cache opgeslagen door elke SDK-client – ​​wijst elke vBucket toe aan een specifiek knooppunt. Dankzij deze deterministische mapping weten klanten altijd precies op welk knooppunt een bepaald document zich bevindt, waardoor lees- en schrijfbewerkingen in één stap mogelijk zijn met een latentie van minder dan een milliseconde.

Wanneer knooppunten worden toegevoegd of verwijderd, herdistribueert Couchbase vBuckets automatisch via een proces genaamdrebalance. Tijdens het opnieuw in evenwicht brengen verplaatst het cluster vBuckets tussen knooppunten terwijl het volledig operationeel blijft. De herverdeling wordt zorgvuldig georkestreerd om te allen tijde het geconfigureerde aantal replica's te behouden, en clients worden naadloos omgeleid naar de nieuwe vBucket-locaties via clusterkaartupdates.

intraclusterreplicatie en automatische failover

Elke vBucket heeft éénactieve-kopie en maximaal driereplica-kopieën verdeeld over verschillende knooppunten. Wanneer een client een document schrijft, gaat het schrijven naar de actieve vBucket op het verantwoordelijke knooppunt. De Data Service repliceert vervolgens de mutatie naar replica vBuckets op andere knooppunten via de interneDCP (Database Change Protocol)-stream. Standaard configureert Couchbase één replica, maar voor productie-HA-implementaties worden twee replica's aanbevolen:

# Configure bucket with 2 replicas via CLI
/opt/couchbase/bin/couchbase-cli bucket-create \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --bucket production-data \
  --bucket-type couchbase \
  --bucket-ramsize 4096 \
  --bucket-replica 2 \
  --bucket-priority high \
  --bucket-eviction-policy valueOnly \
  --enable-flush 0 \
  --compression-mode active \
  --max-ttl 0 \
  --durability-min-level majorityAndPersistActive

Automatische failoveris het mechanisme van Couchbase voor het automatisch detecteren en herstellen van knooppuntstoringen. Wanneer een knooppunt niet meer reageert, wacht de clusterorkestrator op een configureerbare time-out (minimaal 5 seconden, aanbevolen 30 seconden voor productie) en promoveert vervolgens de replica vBuckets op de overgebleven knooppunten naar de actieve status. Dit gebeurt zonder enige tussenkomst aan de applicatiezijde: SDK-clients ontvangen een bijgewerkte clusterkaart en routeren verzoeken onmiddellijk naar de nieuwe actieve vBuckets.

# Configure auto-failover settings
/opt/couchbase/bin/couchbase-cli setting-autofailover \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --enable-auto-failover 1 \
  --auto-failover-timeout 30 \
  --max-failovers 3 \
  --enable-failover-of-server-groups 1 \
  --failover-on-data-disk-issues 1 \
  --failover-data-disk-period 120 \
  --can-abort-rebalance 1

Belangrijke parameters voor automatische failover:

• automatische failover-time-out— Seconden die moeten worden gewacht voordat failover wordt geactiveerd. Lagere waarden verminderen de downtime, maar verhogen het vals-positieve risico. 30 seconden is de aanbevolen productie-instelling.
• max. failovers— Maximaal aantal opeenvolgende automatische failovers voordat handmatige tussenkomst vereist is. Stel in op 3 voor een cluster met 5 knooppunten (om het quorum te behouden).
• failover-van-servergroepen inschakelen— Maakt failover van een volledige servergroep (rack/zone) mogelijk, essentieel voor zonebewuste implementaties.
• failover-op-data-schijf-problemen— Activeert failover wanneer de Data Service aanhoudende schijf-I/O-fouten detecteert.

XDCR: replicatie tussen datacenters

XDCR is Couchbase's vlaggenschip replicatietechnologie voor meerdere regio's. In tegenstelling tot replicatie op databaseniveau die wordt aangetroffen in traditionele RDBMS-systemen, werkt XDCR op-bucketniveauen streamt individuele documentmutaties tussen onafhankelijke Couchbase-clusters. Elk cluster blijft volledig autonoom: het kan onafhankelijk lees- en schrijfbewerkingen accepteren, waardoor XDCR ideaal is voor actief-actieve implementaties in meerdere regio's waarbij gebruikers toegang met lage latentie nodig hebben vanuit elke geografische locatie.

Unidirectioneel versus bidirectioneel XDCR

Unidirectionele XDCRrepliceert mutaties van een broncluster naar een doelcluster in één richting. Dit is geschikt voor noodherstelscenario's, het lezen van replica's in afgelegen regio's of het invoeren van gegevens van een operationeel cluster naar een analysecluster.

Bidirectionele XDCRcreëert replicatiekoppelingen in beide richtingen tussen twee clusters, waardoor actief-actieve implementaties mogelijk worden waarbij beide clusters schrijfbewerkingen accepteren. Dit is de krachtigste configuratie, maar vereist een zorgvuldige planning van conflictoplossing.

XDCR-replicatie instellen

Het configureren van XDCR omvat het maken van een externe clusterreferentie en het vervolgens definiëren van replicatiekoppelingen op bucketniveau. Hieronder staan de CLI-opdrachten en REST API-oproepen voor een volledige bidirectionele installatie:

# Step 1: Create remote cluster reference on the US-EAST cluster
/opt/couchbase/bin/couchbase-cli xdcr-setup \
  --cluster cb-us-east.example.com:8091 \
  --username Administrator \
  --password password \
  --create \
  --xdcr-cluster-name eu-west-cluster \
  --xdcr-hostname cb-eu-west.example.com:8091 \
  --xdcr-username Administrator \
  --xdcr-password password \
  --xdcr-demand-encryption 1 \
  --xdcr-encryption-type full \
  --xdcr-certificate /path/to/eu-west-ca.pem

# Step 2: Create replication from US-EAST to EU-WEST for the 'app' bucket
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
  --cluster cb-us-east.example.com:8091 \
  --username Administrator \
  --password password \
  --create \
  --xdcr-cluster-name eu-west-cluster \
  --xdcr-from-bucket app \
  --xdcr-to-bucket app \
  --xdcr-replication-mode xmem \
  --enable-compression 1 \
  --filter-expression "" \
  --priority high \
  --network-usage-limit 0

# Step 3: Create the reverse replication on EU-WEST cluster (bidirectional)
/opt/couchbase/bin/couchbase-cli xdcr-setup \
  --cluster cb-eu-west.example.com:8091 \
  --username Administrator \
  --password password \
  --create \
  --xdcr-cluster-name us-east-cluster \
  --xdcr-hostname cb-us-east.example.com:8091 \
  --xdcr-username Administrator \
  --xdcr-password password \
  --xdcr-demand-encryption 1 \
  --xdcr-encryption-type full \
  --xdcr-certificate /path/to/us-east-ca.pem

/opt/couchbase/bin/couchbase-cli xdcr-replicate \
  --cluster cb-eu-west.example.com:8091 \
  --username Administrator \
  --password password \
  --create \
  --xdcr-cluster-name us-east-cluster \
  --xdcr-from-bucket app \
  --xdcr-to-bucket app \
  --xdcr-replication-mode xmem \
  --enable-compression 1

Strategieën voor conflictoplossing

In bidirectionele XDCR kan hetzelfde document gelijktijdig op verschillende clusters worden gewijzigd, waardoor conflicten ontstaan. Couchbase biedt meerdere strategieën voor conflictoplossing:

• Op tijdstempel gebaseerd (LWW — Last Write Wins)— De mutatie met de meest recente tijdstempel wint. Dit is de standaardinstelling en werkt goed voor de meeste gebruikssituaties. Vereist NTP-synchronisatie voor alle clusters (binnen 5 seconden scheefheid). Wordt ingesteld op het moment dat de bucket wordt gemaakt en kan later niet meer worden gewijzigd.
• Op volgnummer gebaseerd— Gebruikt het interne volgnummer (revisie-ID) om de winnaar te bepalen. De mutatie met het hoogste revisieaantal wint. Handig wanneer tijdstempelsynchronisatie onbetrouwbaar is.
• Aangepaste conflictoplossing (Enterprise)— Couchbase Enterprise Edition ondersteunt aangepaste samenvoegfuncties die JavaScript aan de serverzijde uitvoeren om conflicten met applicatiespecifieke logica op te lossen. Dit maakt scenario's mogelijk zoals het samenvoegen van winkelwagenitems uit verschillende regio's of het toepassen van domeinspecifieke regels voor conflictoplossing.

# Create a bucket with timestamp-based conflict resolution
curl -X POST http://localhost:8091/pools/default/buckets \
  -u Administrator:password \
  -d name=app \
  -d ramQuota=4096 \
  -d replicaNumber=2 \
  -d bucketType=couchbase \
  -d conflictResolutionType=lww \
  -d compressionMode=active \
  -d durabilityMinLevel=majorityAndPersistActive

# XDCR advanced settings via REST API
curl -X POST http://localhost:8091/settings/replications/<replication-id> \
  -u Administrator:password \
  -d optimisticReplicationThreshold=256 \
  -d sourceNozzlePerNode=4 \
  -d targetNozzlePerNode=4 \
  -d checkpointInterval=600 \
  -d batchCount=500 \
  -d batchSize=2048 \
  -d failureRestartInterval=10 \
  -d docBatchSizeKb=2048 \
  -d networkUsageLimit=0 \
  -d priority=High

XDCR Filtering

XDCR ondersteunt filteren, zodat u slechts een subset van documenten kunt repliceren. Filters gebruiken reguliere expressies tegen documentsleutels en kunnen ook filteren op basis van het verlopen of verwijderen van documenten:

# Replicate only documents with keys starting with 'user::'
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --create \
  --xdcr-cluster-name remote-cluster \
  --xdcr-from-bucket app \
  --xdcr-to-bucket app-users \
  --filter-expression "^user::" \
  --filter-skip-restream 0

# Replicate documents matching a complex pattern
# (orders from 2026 with specific type)
--filter-expression "REGEXP_CONTAINS(META().id, '^order::2026') AND type='premium'"

Couchbase Autonome operator voor Kubernetes

DeCouchbase Autonomous Operator (CAO)is een Kubernetes-operator op ondernemingsniveau die de implementatie, het beheer, de schaalvergroting en het herstel van Couchbase-serverclusters automatiseert. In tegenstelling tot eenvoudige StatefulSet-implementaties begrijpt de Autonomous Operator de interne topologie van Couchbase: hij beheert herbalanceringsoperaties, coördineert doorlopende upgrades, verzorgt het servergroepbewustzijn en integreert met Kubernetes-planningsprimitieven om een ​​optimale plaatsing van Couchbase-pods te garanderen.

CouchbaseCluster CRD Specificatie

De CouchbaseCluster CRD is de centrale configuratie die de gewenste status van uw Couchbase-implementatie aangeeft. De Autonome Operator brengt dit samen in StatefulSets, Services, PVCs, Secrets en RBAC-bronnen. Hieronder ziet u een productieklare CRD:

apiVersion: couchbase.com/v2
kind: CouchbaseCluster
metadata:
  name: cb-production
  namespace: couchbase
spec:
  image: couchbase/server:7.6.1-enterprise
  antiAffinity: true
  platform: aws
  cluster:
    autoFailoverTimeout: 30s
    autoFailoverMaxCount: 3
    autoFailoverOnDataDiskIssues: true
    autoFailoverOnDataDiskIssuesTimePeriod: 120s
    autoFailoverServerGroup: true
    clusterName: cb-production
    dataServiceMemoryQuota: 8Gi
    indexServiceMemoryQuota: 4Gi
    searchServiceMemoryQuota: 2Gi
    analyticsServiceMemoryQuota: 4Gi
    eventingServiceMemoryQuota: 2Gi
    indexStorageSetting: memory_optimized
    autoCompaction:
      databaseFragmentationThreshold:
        percent: 30
        size: 1Gi
      viewFragmentationThreshold:
        percent: 30
        size: 1Gi
      parallelCompaction: false
      timeWindow:
        start: "02:00"
        end: "06:00"
        abortCompactionOutsideWindow: true
  security:
    adminSecret: cb-admin-credentials
    rbac:
      managed: true
      selector:
        matchLabels:
          cluster: cb-production
    ldap:
      hosts:
      - ldap.example.com
      port: 636
      encryption: TLS
  networking:
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
    exposeAdminConsole: true
    adminConsoleServices:
    - data
    adminConsoleServiceType: NodePort
    exposedFeatures:
    - client
    - xdcr
    exposedFeatureServiceType: NodePort
  buckets:
    managed: true
    selector:
      matchLabels:
        cluster: cb-production
  servers:
  - name: data-zone-a
    size: 2
    services:
    - data
    - index
    serverGroups:
    - zone-a
    pod:
      metadata:
        labels:
          couchbase-service: data-index
        annotations:
          prometheus.io/scrape: "true"
          prometheus.io/port: "9091"
      spec:
        nodeSelector:
          topology.kubernetes.io/zone: us-east-1a
        tolerations:
        - key: couchbase
          operator: Equal
          value: "true"
          effect: NoSchedule
        resources:
          requests:
            cpu: "4"
            memory: 16Gi
          limits:
            cpu: "8"
            memory: 20Gi
    volumeMounts:
      default: couchbase-data
      data: couchbase-data
      index: couchbase-index
  - name: data-zone-b
    size: 2
    services:
    - data
    - index
    serverGroups:
    - zone-b
    pod:
      spec:
        nodeSelector:
          topology.kubernetes.io/zone: us-east-1b
        tolerations:
        - key: couchbase
          operator: Equal
          value: "true"
          effect: NoSchedule
        resources:
          requests:
            cpu: "4"
            memory: 16Gi
          limits:
            cpu: "8"
            memory: 20Gi
    volumeMounts:
      default: couchbase-data
      data: couchbase-data
      index: couchbase-index
  - name: query-search
    size: 2
    services:
    - query
    - search
    serverGroups:
    - zone-a
    - zone-b
    pod:
      spec:
        resources:
          requests:
            cpu: "4"
            memory: 8Gi
          limits:
            cpu: "8"
            memory: 12Gi
    volumeMounts:
      default: couchbase-default
  - name: analytics-eventing
    size: 2
    services:
    - analytics
    - eventing
    serverGroups:
    - zone-c
    pod:
      spec:
        nodeSelector:
          topology.kubernetes.io/zone: us-east-1c
        resources:
          requests:
            cpu: "8"
            memory: 32Gi
          limits:
            cpu: "16"
            memory: 40Gi
    volumeMounts:
      default: couchbase-analytics
      analytics:
      - couchbase-analytics
  serverGroups:
  - zone-a
  - zone-b
  - zone-c
  volumeClaimTemplates:
  - metadata:
      name: couchbase-data
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 100Gi
  - metadata:
      name: couchbase-index
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 50Gi
  - metadata:
      name: couchbase-default
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 20Gi
  - metadata:
      name: couchbase-analytics
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 200Gi

Operatorinstallatie via Helm

# Add Couchbase Helm repository
helm repo add couchbase https://couchbase-partners.github.io/helm-charts/
helm repo update

# Install the Couchbase Autonomous Operator
helm install couchbase-operator couchbase/couchbase-operator \
  --namespace couchbase \
  --create-namespace \
  --set operator.image.repository=couchbase/operator \
  --set operator.image.tag=2.7.1 \
  --set admissionController.enabled=true

# Create the admin credentials secret
kubectl create secret generic cb-admin-credentials \
  --namespace couchbase \
  --from-literal=username=Administrator \
  --from-literal=password=$(openssl rand -base64 24)

# Deploy the CouchbaseCluster CRD
kubectl apply -f couchbase-cluster.yaml

# Verify deployment
kubectl get couchbaseclusters -n couchbase
kubectl get pods -n couchbase -l app=couchbase
kubectl get svc -n couchbase

Servergroepen en rack-/zonebewustzijn

Servergroepen zijn het mechanisme van Couchbase om ervoor te zorgen dat actieve vBuckets en hun replica's in verschillende storingsdomeinen worden geplaatst (beschikbaarheidszones, racks of datacenters). Wanneer servergroepen zijn geconfigureerd, garandeert Couchbase dat geen enkel actief en replicapaar voor dezelfde vBucket zich in dezelfde servergroep bevindt. Dit betekent dat een volledige zonestoring niet tot gegevensverlies zal leiden.

De Autonome Operator wijst servergroepen toe aan Kubernetes-knooppunttopologielabels, waardoor pods automatisch in de juiste zones worden gepland. Gecombineerd met pod-anti-affiniteitsregels zorgt dit ervoor dat Couchbase-pods over de fysieke infrastructuur worden gedistribueerd voor maximale veerkracht.

AWS EKS-implementatie

Amazon EKS vereist een specifieke configuratie voor optimale Couchbase-prestaties. De belangrijkste overwegingen zijn opslag (EBS gp3 voor doorvoer), instancetypen (voor geheugen geoptimaliseerde r6i/r7i voor dataknooppunten) en netwerken (VPC CNI voor netwerken op pod-niveau).

# EBS gp3 StorageClass optimized for Couchbase
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3-couchbase
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "6000"
  throughput: "500"
  encrypted: "true"
  kmsKeyId: "arn:aws:kms:us-east-1:123456789:key/mrk-abcdef"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# Recommended EKS node groups for Couchbase
# Data nodes:     r6i.2xlarge (8 vCPU, 64 GiB) or r7i.2xlarge
# Index/Query:    m6i.2xlarge (8 vCPU, 32 GiB)
# Analytics:      r6i.4xlarge (16 vCPU, 128 GiB)
# Eventing:       m6i.xlarge  (4 vCPU, 16 GiB)

# EKS managed node group with taints for Couchbase
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: couchbase-eks
  region: us-east-1
managedNodeGroups:
- name: cb-data
  instanceType: r6i.2xlarge
  desiredCapacity: 4
  minSize: 4
  maxSize: 8
  volumeSize: 200
  volumeType: gp3
  volumeIOPS: 6000
  volumeThroughput: 500
  availabilityZones: ["us-east-1a", "us-east-1b"]
  labels:
    workload: couchbase-data
  taints:
  - key: couchbase
    value: "true"
    effect: NoSchedule
  iam:
    attachPolicyARNs:
    - arn:aws:iam::policy/AmazonEBSCSIDriverPolicy
- name: cb-query
  instanceType: m6i.2xlarge
  desiredCapacity: 2
  minSize: 2
  maxSize: 4
  availabilityZones: ["us-east-1a", "us-east-1b"]
  labels:
    workload: couchbase-query

Azure AKS-implementatie

Azure AKS maakt gebruik van Premium SSD v2 of Ultra Disk voor de I/O-eisen van Couchbase en Azure Private Link voor veilige XDCR-connectiviteit tussen regio's.

# Azure Premium SSD v2 StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-premium-couchbase
provisioner: disk.csi.azure.com
parameters:
  skuName: PremiumV2_LRS
  DiskIOPSReadWrite: "6000"
  DiskMBpsReadWrite: "500"
  cachingMode: None
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# Ultra Disk StorageClass for high-performance workloads
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-ultra-couchbase
provisioner: disk.csi.azure.com
parameters:
  skuName: UltraSSD_LRS
  DiskIOPSReadWrite: "10000"
  DiskMBpsReadWrite: "1000"
  cachingMode: None
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# AKS recommended VM sizes:
# Data nodes:      Standard_E8s_v5  (8 vCPU, 64 GiB)
# Index/Query:     Standard_D8s_v5  (8 vCPU, 32 GiB)
# Analytics:       Standard_E16s_v5 (16 vCPU, 128 GiB)

GCP GKE-implementatie

Google Kubernetes Engine maakt gebruik van SSD Persistent Disks en Workload Identity voor veilige toegang tot Google Cloud Storage voor back-ups.

# GKE SSD Persistent Disk StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ssd-couchbase
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  provisioned-iops-on-create: "6000"
  provisioned-throughput-on-create: "500"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# GKE Hyperdisk Balanced for cost-effective performance
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: hyperdisk-couchbase
provisioner: pd.csi.storage.gke.io
parameters:
  type: hyperdisk-balanced
  provisioned-iops-on-create: "6000"
  provisioned-throughput-on-create: "500"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

---
# GKE recommended machine types:
# Data nodes:      n2-highmem-8   (8 vCPU, 64 GB)
# Index/Query:     n2-standard-8  (8 vCPU, 32 GB)
# Analytics:       n2-highmem-16  (16 vCPU, 128 GB)

Blank metaal k3s/Rancher met Longhorn

Voor organisaties die volledige infrastructuurcontrole nodig hebben zonder dat ze gebonden zijn aan een cloudleverancier, biedt bare metal k3s met Rancher-beheer en gedistribueerde Longhorn-opslag een uitstekende basis voor Couchbase HA. Deze architectuur is populair in gereguleerde industrieën, edge computing-scenario's en kostengevoelige omgevingen.

# k3s bare metal setup for Couchbase

# Install k3s on master nodes (HA with embedded etcd)
curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init \
  --disable traefik \
  --disable servicelb \
  --write-kubeconfig-mode 644 \
  --node-taint couchbase=true:NoSchedule \
  --node-label topology.kubernetes.io/zone=rack-1

# Join additional server nodes
curl -sfL https://get.k3s.io | sh -s - server \
  --server https://master-1:6443 \
  --token $(cat /var/lib/rancher/k3s/server/node-token) \
  --node-taint couchbase=true:NoSchedule \
  --node-label topology.kubernetes.io/zone=rack-2

# Join agent nodes
curl -sfL https://get.k3s.io | sh -s - agent \
  --server https://master-1:6443 \
  --token $(cat /var/lib/rancher/k3s/server/node-token) \
  --node-taint couchbase=true:NoSchedule \
  --node-label topology.kubernetes.io/zone=rack-3

# Install Longhorn for distributed storage
helm repo add longhorn https://charts.longhorn.io
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.defaultDataPath=/mnt/longhorn \
  --set defaultSettings.guaranteedInstanceManagerCPU=12

# Create Longhorn StorageClass for Couchbase
kubectl apply -f - <

Back-up en herstel met cbbackupmgr

Couchbase biedtcbbackupmgr, een back-uptool voor ondernemingen die volledige, incrementele en differentiële back-ups ondersteunt met optionele compressie en codering. Voor productie-HA-implementaties combineert een robuuste back-upstrategie back-ups op Couchbase-niveau met cloud-snapshotmogelijkheden.

Back-upconfiguratie

# Initialize a backup repository
/opt/couchbase/bin/cbbackupmgr config \
  --archive /backup/couchbase \
  --repo production-backup \
  --include-data production-data \
  --include-data user-profiles \
  --exclude-data _system

# Run a full backup
/opt/couchbase/bin/cbbackupmgr backup \
  --archive /backup/couchbase \
  --repo production-backup \
  --cluster couchbase://localhost \
  --username Administrator \
  --password "$CB_PASSWORD" \
  --threads 4 \
  --no-progress-bar

# Run an incremental backup (only mutations since last backup)
/opt/couchbase/bin/cbbackupmgr backup \
  --archive /backup/couchbase \
  --repo production-backup \
  --cluster couchbase://localhost \
  --username Administrator \
  --password "$CB_PASSWORD" \
  --threads 4

# List available backups
/opt/couchbase/bin/cbbackupmgr list \
  --archive /backup/couchbase \
  --repo production-backup

# Restore from a specific backup
/opt/couchbase/bin/cbbackupmgr restore \
  --archive /backup/couchbase \
  --repo production-backup \
  --cluster couchbase://target-cluster:8091 \
  --username Administrator \
  --password "$CB_PASSWORD" \
  --start 2026-04-12T00_00_00 \
  --end 2026-04-12T14_30_00 \
  --threads 4

Geautomatiseerd back-upscript voor Kubernetes

#!/bin/bash
# couchbase-backup.sh — Automated backup to S3-compatible storage

set -euo pipefail

CLUSTER_HOST="cb-production-srv.couchbase.svc.cluster.local"
BACKUP_DIR="/backup/couchbase"
REPO_NAME="prod-$(date +%Y%m%d)"
S3_BUCKET="s3://couchbase-backups/production"
RETENTION_DAYS=14

log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; }

log "Starting Couchbase backup for cluster: $CLUSTER_HOST"

if [ ! -d "$BACKUP_DIR/$REPO_NAME" ]; then
  log "Configuring new backup repository: $REPO_NAME"
  cbbackupmgr config \
    --archive "$BACKUP_DIR" \
    --repo "$REPO_NAME" \
    --include-data production-data \
    --include-data user-profiles
fi

log "Running incremental backup..."
cbbackupmgr backup \
  --archive "$BACKUP_DIR" \
  --repo "$REPO_NAME" \
  --cluster "couchbase://$CLUSTER_HOST" \
  --username "$CB_USERNAME" \
  --password "$CB_PASSWORD" \
  --threads 4 \
  --no-progress-bar

BACKUP_SIZE=$(du -sh "$BACKUP_DIR/$REPO_NAME" | cut -f1)
log "Backup complete. Size: $BACKUP_SIZE"

log "Syncing to S3: $S3_BUCKET/$REPO_NAME"
aws s3 sync "$BACKUP_DIR/$REPO_NAME" "$S3_BUCKET/$REPO_NAME" \
  --storage-class STANDARD_IA \
  --sse aws:kms

log "Cleaning up backups older than $RETENTION_DAYS days..."
find "$BACKUP_DIR" -maxdepth 1 -name "prod-*" -mtime +"$RETENTION_DAYS" -exec rm -rf {} \;

log "Backup pipeline complete."

CouchbaseBack-up CRD (door operator beheerd)

De Autonome Operator biedt CRD's voor geautomatiseerd back-upbeheer:

apiVersion: couchbase.com/v2
kind: CouchbaseBackup
metadata:
  name: cb-daily-backup
  namespace: couchbase
spec:
  strategy: full_incremental
  full:
    schedule: "0 2 * * 0"   # Full backup every Sunday at 2 AM
  incremental:
    schedule: "0 2 * * 1-6" # Incremental Mon-Sat at 2 AM
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 3
  backOffLimit: 3
  logRetention: 168h
  size: 100Gi
  s3bucket: s3://couchbase-backups/production
---
apiVersion: couchbase.com/v2
kind: CouchbaseBackupRestore
metadata:
  name: cb-restore-pitr
  namespace: couchbase
spec:
  backup: cb-daily-backup
  repo: "20260412"
  start:
    int: 1
  end:
    int: 5
  backOffLimit: 3

N1QL Query-prestaties afstemmen

N1QL (SQL++ voor JSON) is de querytaal van Couchbase. Voor het afstemmen van de N1QL-prestaties is inzicht nodig in de queryplanner, het indexontwerp en de optimalisaties aan de serverzijde.

Indexstrategieën: GSI en FTS

-- Global Secondary Index (GSI) for common query patterns

-- Composite index for user lookups
CREATE INDEX idx_users_email_status
  ON `user-profiles`(email, status)
  WHERE type = 'user'
  WITH {"num_replica": 1, "defer_build": false};

-- Covering index (includes all queried fields to avoid fetch)
CREATE INDEX idx_orders_covering
  ON `production-data`(customer_id, order_date, total_amount, status)
  WHERE type = 'order'
  WITH {"num_replica": 1};

-- Array index for nested documents
CREATE INDEX idx_order_items
  ON `production-data`(DISTINCT ARRAY item.product_id FOR item IN items END)
  WHERE type = 'order'
  WITH {"num_replica": 1};

-- Partial index for active records only
CREATE INDEX idx_active_sessions
  ON `production-data`(user_id, created_at)
  WHERE type = 'session' AND status = 'active'
  WITH {"num_replica": 1};

-- Adaptive index for dynamic query patterns
CREATE INDEX idx_adaptive_products
  ON `production-data`(DISTINCT PAIRS(self))
  WHERE type = 'product'
  WITH {"num_replica": 1};

-- Check index status
SELECT name, state, num_docs_indexed, num_docs_pending
FROM system:indexes
WHERE keyspace_id = 'production-data';

-- Analyze query execution plan
EXPLAIN SELECT u.name, u.email, COUNT(o.id) AS order_count
FROM `user-profiles` u
JOIN `production-data` o ON o.customer_id = u.id
WHERE u.status = 'active' AND o.type = 'order'
GROUP BY u.name, u.email
ORDER BY order_count DESC
LIMIT 100;

-- Use ADVISE to get index recommendations
ADVISE SELECT * FROM `production-data`
WHERE type = 'order'
  AND customer_id = 'cust-12345'
  AND order_date BETWEEN '2026-01-01' AND '2026-04-12'
ORDER BY order_date DESC;

Tips voor het optimaliseren van zoekopdrachten

-- Use PREPARE for frequently executed queries (cached plan)
PREPARE get_user_orders AS
SELECT o.id, o.order_date, o.total_amount, o.status
FROM `production-data` o
WHERE o.type = 'order'
  AND o.customer_id = $customer_id
ORDER BY o.order_date DESC
LIMIT $page_size OFFSET $page_offset;

-- Execute prepared statement
EXECUTE get_user_orders
USING {"customer_id": "cust-12345", "page_size": 20, "page_offset": 0};

-- Use META().id for direct key-value lookups (fastest path)
SELECT META().id, *
FROM `production-data`
USE KEYS ["order::2026-001", "order::2026-002", "order::2026-003"];

-- Correlated subquery with USE KEYS for joins
SELECT u.name,
  (SELECT o.id, o.total_amount
   FROM `production-data` o
   USE KEYS u.order_ids
   WHERE o.status = 'completed') AS completed_orders
FROM `user-profiles` u
WHERE META(u).id = 'user::12345';

-- Use INFER to understand document schema
INFER `production-data` WITH {"sample_size": 10000, "similarity_metric": 0.6};

Geheugenbeheer en bucketconfiguratie

De geheugen-eerste architectuur van de Couchbase betekent dat RAM-toewijzing een directe invloed heeft op de prestaties. Elke service heeft zijn eigen geheugenquotum, en buckets delen het Data Service-quotum. Een juiste dimensionering voorkomt cache-uitzettingen die de latentie verminderen.

# Configure cluster-level memory quotas
/opt/couchbase/bin/couchbase-cli setting-cluster \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --cluster-ramsize 8192 \
  --cluster-index-ramsize 4096 \
  --cluster-fts-ramsize 2048 \
  --cluster-eventing-ramsize 2048 \
  --cluster-analytics-ramsize 4096

# Memory allocation guidelines:
# Data Service:      60% of available node RAM
# Index Service:     20% of available node RAM
# Search Service:    10% of available node RAM
# OS/overhead:       10% reserved

# Bucket memory sizing formula:
# Required RAM = (avg_doc_size * num_docs * 2.5) / num_data_nodes
# The 2.5 multiplier accounts for:
#   - Metadata overhead (~56 bytes per document)
#   - Internal fragmentation
#   - Replica copies in memory

# Create an optimized production bucket
curl -X POST http://localhost:8091/pools/default/buckets \
  -u Administrator:password \
  -d name=production-data \
  -d ramQuota=4096 \
  -d bucketType=couchbase \
  -d replicaNumber=2 \
  -d threadsNumber=8 \
  -d evictionPolicy=valueOnly \
  -d compressionMode=active \
  -d maxTTL=0 \
  -d conflictResolutionType=lww \
  -d flushEnabled=0 \
  -d durabilityMinLevel=majorityAndPersistActive

# Eviction policies:
# valueOnly  - Evicts document values but keeps metadata in RAM
#              Best for workloads where key access patterns are predictable
# fullEviction - Evicts both values and metadata
#                Best for very large datasets that exceed available RAM
# noEviction - (Ephemeral buckets only) Rejects writes when RAM is full
#              Best for caching use cases

TLS-codering en RBAC

Het beveiligen van Couchbase in productie vereist versleuteling van gegevens tijdens de overdracht (TLS), fijnmazige, op rollen gebaseerde toegangscontrole (RBAC) en auditlogboekregistratie.

# Enable TLS for all Couchbase services
/opt/couchbase/bin/couchbase-cli ssl-manage \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --set-node-certificate

# Enforce minimum TLS version
/opt/couchbase/bin/couchbase-cli setting-security \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --set \
  --tls-min-version tlsv1.2 \
  --tls-honor-cipher-order 1 \
  --hsts-max-age 31536000 \
  --hsts-preload-enabled 1

# Create application-specific RBAC users
/opt/couchbase/bin/couchbase-cli user-manage \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --set \
  --rbac-username app-service \
  --rbac-password "$(openssl rand -base64 32)" \
  --rbac-name "Application Service Account" \
  --roles 'data_reader[production-data],data_writer[production-data],query_select[production-data],query_insert[production-data],query_update[production-data],query_delete[production-data]' \
  --auth-domain local

# Create a read-only analytics user
/opt/couchbase/bin/couchbase-cli user-manage \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --set \
  --rbac-username analytics-reader \
  --rbac-password "$(openssl rand -base64 32)" \
  --roles 'data_reader[production-data],query_select[production-data],analytics_reader[production-data]' \
  --auth-domain local

# Enable audit logging
/opt/couchbase/bin/couchbase-cli setting-audit \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --set \
  --audit-enabled 1 \
  --audit-log-path /opt/couchbase/var/lib/couchbase/logs \
  --audit-log-rotate-interval 86400 \
  --audit-log-rotate-size 20971520

Kubernetes TLS met cert-manager

# Certificate for Couchbase server TLS
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: couchbase-server-tls
  namespace: couchbase
spec:
  secretName: couchbase-server-tls
  duration: 8760h   # 1 year
  renewBefore: 720h  # 30 days before expiry
  privateKey:
    algorithm: RSA
    size: 4096
  usages:
  - server auth
  - client auth
  dnsNames:
  - "*.cb-production.couchbase.svc.cluster.local"
  - "*.cb-production.couchbase.svc"
  - "cb-production-srv.couchbase.svc.cluster.local"
  - "localhost"
  issuerRef:
    name: couchbase-ca-issuer
    kind: ClusterIssuer

-bewaking met Prometheus-exporteur

Couchbase biedt rijke statistieken via de REST API. Decouchbase-exportervertaalt deze naar Prometheus-formaat voor uitgebreide monitoring.

# Deploy Couchbase Prometheus Exporter
apiVersion: apps/v1
kind: Deployment
metadata:
  name: couchbase-exporter
  namespace: couchbase
spec:
  replicas: 1
  selector:
    matchLabels:
      app: couchbase-exporter
  template:
    metadata:
      labels:
        app: couchbase-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9091"
    spec:
      containers:
      - name: exporter
        image: couchbase/exporter:1.0.9
        args:
        - --couchbase-address=cb-production-srv.couchbase.svc.cluster.local
        - --couchbase-port=8091
        - --couchbase-username=$(CB_USERNAME)
        - --couchbase-password=$(CB_PASSWORD)
        - --server-address=0.0.0.0:9091
        - --per-node-refresh=5
        env:
        - name: CB_USERNAME
          valueFrom:
            secretKeyRef:
              name: cb-admin-credentials
              key: username
        - name: CB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: cb-admin-credentials
              key: password
        ports:
        - containerPort: 9091
          name: metrics
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: couchbase-monitor
  namespace: couchbase
spec:
  selector:
    matchLabels:
      app: couchbase-exporter
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

Belangrijke Couchbase-statistieken om

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: couchbase-alerts
  namespace: couchbase
spec:
  groups:
  - name: couchbase.rules
    rules:
    - alert: CouchbaseNodeDown
      expr: cb_node_healthy == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Couchbase node {{ $labels.node }} is unhealthy"
    - alert: CouchbaseHighCacheMissRate
      expr: cb_bucket_cache_miss_ratio > 0.05
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Cache miss rate {{ $value | humanizePercentage }} on bucket {{ $labels.bucket }}"
    - alert: CouchbaseXDCRLag
      expr: cb_xdcr_changes_left > 10000
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "XDCR replication lag: {{ $value }} pending mutations"
    - alert: CouchbaseDiskQueueGrowing
      expr: rate(cb_bucket_disk_queue_items[5m]) > 100
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Disk queue growing on bucket {{ $labels.bucket }}"
    - alert: CouchbaseMemoryPressure
      expr: cb_bucket_mem_used_bytes / cb_bucket_mem_quota_bytes > 0.9
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Memory usage at {{ $value | humanizePercentage }} for bucket {{ $labels.bucket }}"

// Node.js SDK configuration for HA
const couchbase = require('couchbase');

const clusterConnStr = 'couchbases://cb-node1.example.com,cb-node2.example.com,cb-node3.example.com';

const cluster = await couchbase.connect(clusterConnStr, {
  username: process.env.CB_USERNAME,
  password: process.env.CB_PASSWORD,
  timeouts: {
    kvTimeout: 2500,           // Key-value operation timeout (ms)
    kvDurableTimeout: 10000,   // Durable write timeout
    queryTimeout: 75000,       // N1QL query timeout
    searchTimeout: 75000,      // FTS search timeout
    analyticsTimeout: 75000,   // Analytics query timeout
    connectTimeout: 10000,     // Initial connection timeout
    managementTimeout: 75000   // Management API timeout
  },
  security: {
    trustStorePath: '/etc/couchbase/ca.pem'
  },
  transactions: {
    durabilityLevel: couchbase.DurabilityLevel.MajorityAndPersistToActive,
    timeout: 15000
  }
});

const bucket = cluster.bucket('production-data');
const collection = bucket.defaultCollection();

// Durable write with observe-based durability
await collection.upsert('order::2026-001', orderDocument, {
  durabilityLevel: couchbase.DurabilityLevel.MajorityAndPersistToActive,
  timeout: 10000
});

// Read with replica fallback for HA
try {
  const result = await collection.get('user::12345');
} catch (err) {
  if (err instanceof couchbase.errors.TimeoutError) {
    const replicaResult = await collection.getAnyReplica('user::12345');
  }
}

# Java SDK configuration for HA
import com.couchbase.client.java.*;
import com.couchbase.client.java.env.*;
import java.time.Duration;

ClusterEnvironment env = ClusterEnvironment.builder()
    .timeoutConfig(TimeoutConfig.builder()
        .kvTimeout(Duration.ofMillis(2500))
        .kvDurableTimeout(Duration.ofSeconds(10))
        .queryTimeout(Duration.ofSeconds(75))
        .connectTimeout(Duration.ofSeconds(10))
        .build())
    .ioConfig(IoConfig.builder()
        .numKvConnections(4)
        .enableMutationTokens(true)
        .enableDnsSrv(true)
        .build())
    .securityConfig(SecurityConfig.builder()
        .enableTls(true)
        .trustCertificate(Paths.get("/etc/couchbase/ca.pem"))
        .build())
    .build();

Cluster cluster = Cluster.connect(
    "couchbases://cb-node1.example.com,cb-node2.example.com",
    ClusterOptions.clusterOptions("username", "password")
        .environment(env)
);

# When using the Autonomous Operator, connect via the headless service:
# couchbase://cb-production-srv.couchbase.svc.cluster.local
#
# The operator creates these services:
# cb-production-srv      - Headless service for SDK auto-discovery
# cb-production-ui       - Web Console (port 8091/18091)
# cb-production-cloud    - External connectivity (NodePort/LoadBalancer)
#
# For external SDK access (outside Kubernetes), use:
# - NodePort with explicit node addresses
# - LoadBalancer with MetalLB (bare metal)
# - Ingress with TCP passthrough for port 11210 (SDK) and 11207 (SDK TLS)

// Sync Gateway configuration for production
{
  "interface": ":4984",
  "adminInterface": "127.0.0.1:4985",
  "logging": {
    "console": {
      "log_level": "info",
      "log_keys": ["HTTP", "Sync", "Auth", "Changes"]
    }
  },
  "databases": {
    "mobile-app": {
      "server": "couchbases://cb-production-srv.couchbase.svc.cluster.local",
      "bucket": "production-data",
      "username": "sync-gateway",
      "password": "${SG_PASSWORD}",
      "enable_shared_bucket_access": true,
      "import_docs": true,
      "num_index_replicas": 1,
      "delta_sync": {
        "enabled": true,
        "rev_max_age_seconds": 86400
      },
      "cache": {
        "channel_cache": {
          "max_number": 50000,
          "compact_high_watermark_pct": 80,
          "compact_low_watermark_pct": 60
        },
        "rev_cache": {
          "size": 5000,
          "shard_count": 16
        }
      },
      "users": {
        "GUEST": {"disabled": true}
      },
      "sync": "function(doc, oldDoc) { if (doc.type === 'user-data') { channel(doc.channels); requireAccess(doc.channels); } else { channel('public'); } }"
    }
  }
}

# Deploy Sync Gateway on Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sync-gateway
  namespace: couchbase
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sync-gateway
  template:
    metadata:
      labels:
        app: sync-gateway
    spec:
      containers:
      - name: sync-gateway
        image: couchbase/sync-gateway:3.1.4-enterprise
        args: ["/etc/sync-gateway/config.json"]
        ports:
        - containerPort: 4984
          name: public
        - containerPort: 4985
          name: admin
        resources:
          requests:
            cpu: "2"
            memory: 4Gi
          limits:
            cpu: "4"
            memory: 8Gi
        volumeMounts:
        - name: config
          mountPath: /etc/sync-gateway
      volumes:
      - name: config
        configMap:
          name: sync-gateway-config

# Data Service RAM sizing
# Required RAM per node = (num_documents * (doc_metadata_size + avg_value_size)) / num_data_nodes * (1 + num_replicas)
# doc_metadata_size = 56 bytes (fixed overhead per document)
# Include 25% headroom for fragmentation and growth

# Example: 100M documents, 1KB avg size, 3 data nodes, 1 replica
# RAM = (100,000,000 * (56 + 1024)) / 3 * 2 = ~72 GB per node
# With 25% headroom: ~90 GB per node

# Index Service RAM sizing (memory-optimized)
# RAM = total_index_size * 3 (for build/merge overhead)
# Use system:indexes to check current index sizes

# Disk sizing
# Disk = (num_documents * avg_doc_size * (1 + num_replicas)) * 3 (compaction headroom)
# Use SSD/NVMe with provisioned IOPS for predictable performance

# Auto-failover handles single node failures automatically.
# Verify failover occurred:
/opt/couchbase/bin/couchbase-cli server-list \
  --cluster localhost:8091 \
  --username Administrator \
  --password password

# After replacing the failed node, add and rebalance:
/opt/couchbase/bin/couchbase-cli server-add \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --server-add new-node.example.com:8091 \
  --server-add-username Administrator \
  --server-add-password password \
  --services data,index

/opt/couchbase/bin/couchbase-cli rebalance \
  --cluster localhost:8091 \
  --username Administrator \
  --password password

# Scenario: Primary region (US-EAST) completely lost

# Step 1: Verify XDCR target cluster (EU-WEST) has latest data
# Check XDCR replication status before failure
curl -s http://eu-west-node:8091/pools/default/remoteClusters \
  -u Administrator:password | jq .

# Step 2: Pause XDCR replications pointing to the failed cluster
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
  --cluster cb-eu-west.example.com:8091 \
  --username Administrator \
  --password password \
  --pause \
  --xdcr-replicator <replication-id>

# Step 3: Update application connection strings to EU-WEST cluster
# (via DNS update, service mesh, or environment variable change)

# Step 4: Scale up EU-WEST cluster if needed to handle full production load
# In Kubernetes, update the CouchbaseCluster CRD:
kubectl patch couchbasecluster cb-eu-west -n couchbase --type merge \
  -p '{"spec":{"servers":[{"name":"data-zone-a","size":4}]}}'

# Step 5: After US-EAST cluster is restored, re-establish XDCR
# and perform a full resync from EU-WEST back to US-EAST

# Graceful failover (for maintenance, drains data before removal)
/opt/couchbase/bin/couchbase-cli failover \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --server-failover node-to-remove.example.com:8091

# Recovery (re-add the node after maintenance)
/opt/couchbase/bin/couchbase-cli recovery \
  --cluster localhost:8091 \
  --username Administrator \
  --password password \
  --server-recovery node-to-recover.example.com:8091 \
  --recovery-type delta

# Delta recovery re-synchronizes only the changed data,
# which is much faster than full recovery.
# Full recovery rebuilds the node from scratch.

# Rebalance to complete the recovery
/opt/couchbase/bin/couchbase-cli rebalance \
  --cluster localhost:8091 \
  --username Administrator \
  --password password

# helm-values-production.yaml
couchbase-operator:
  operator:
    image:
      repository: couchbase/operator
      tag: 2.7.1
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
      limits:
        cpu: "1"
        memory: 1Gi
  admissionController:
    enabled: true
    resources:
      requests:
        cpu: 100m
        memory: 128Mi

cluster:
  image: couchbase/server:7.6.1-enterprise
  antiAffinity: true
  autoFailoverTimeout: 30s
  autoFailoverMaxCount: 3
  autoFailoverOnDataDiskIssues: true
  autoFailoverServerGroup: true
  security:
    adminSecret: cb-admin-credentials
  networking:
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
    exposeAdminConsole: true
    adminConsoleServiceType: NodePort
  buckets:
    managed: true
  servers:
    data:
      size: 4
      services:
      - data
      - index
      serverGroups:
      - zone-a
      - zone-b
      resources:
        requests:
          cpu: "4"
          memory: 16Gi
        limits:
          cpu: "8"
          memory: 20Gi
      volumeMounts:
        default: couchbase-data
        data: couchbase-data
        index: couchbase-index
    query:
      size: 2
      services:
      - query
      - search
      resources:
        requests:
          cpu: "4"
          memory: 8Gi
        limits:
          cpu: "8"
          memory: 12Gi
      volumeMounts:
        default: couchbase-default
    analytics:
      size: 2
      services:
      - analytics
      - eventing
      serverGroups:
      - zone-c
      resources:
        requests:
          cpu: "8"
          memory: 32Gi
        limits:
          cpu: "16"
          memory: 40Gi
      volumeMounts:
        default: couchbase-analytics
        analytics:
        - couchbase-analytics
  serverGroups:
  - zone-a
  - zone-b
  - zone-c
  volumeClaimTemplates:
  - metadata:
      name: couchbase-data
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 100Gi
  - metadata:
      name: couchbase-index
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 50Gi
  - metadata:
      name: couchbase-default
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 20Gi
  - metadata:
      name: couchbase-analytics
    spec:
      storageClassName: ebs-gp3-couchbase
      resources:
        requests:
          storage: 200Gi