Couchbase 在生產中的高可用性：XDCR、Kubernetes Operator 和多區域部署

#!/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."

Couchbase備份 CRD（運營商管理）

自治操作員提供用於自動備份管理的 CRD：

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 查詢效能調整

N1QL（JSON 的 SQL++）是 Couchbase 的查詢語言。調整 N1QL 效能需要了解查詢規劃器、索引設計和伺服器端最佳化。

索引策略：GSI 和 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;

查詢最佳化技巧

-- 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};

記憶體管理和儲存桶配置

Couchbase 的記憶體優先架構意味著 RAM 分配直接影響效能。每個服務都有自己的記憶體配額，桶共享資料服務配額。適當的大小可以防止快取驅逐而降低延遲。

# 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 加密和 RBAC

在生產中保護 Couchbase 需要對傳輸中的資料進行加密 (TLS)、基於角色的細粒度訪問控制 (RBAC) 和稽核日誌記錄。

# 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 與證書管理器

# 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

使用 Prometheus 匯出器進行監控

Couchbase 透過其 REST API 公開豐富的指標。couchbase-exporter將這些轉換為 Prometheus 格式以進行全面監控。

# 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

用於監控

• cb_bucket_ops_per_sec— 每個儲存桶每秒的總運算元。確定正常吞吐量的基線並對異常情況發出警報。
• cb_bucket_mem_used_bytes— 儲存桶記憶體使用情況。當接近 RAM 配額時發出警報，以防止驅逐。
• cb_bucket_cache_miss_ratio— 未命中快取且需要磁碟獲取的請求比率。應保持在 2% 以下以獲得最佳效能。
• cb_bucket_disk_queue_items— 磁碟寫入佇列深度。佇列不斷增長表明磁碟 I/O 無法跟上寫入吞吐量。
• cb_xdcr_changes_left— 等待 XDCR 複製的突變數量。表示跨區域複製滯後。
• cb_xdcr_docs_writing— 每秒透過 XDCR 複製的文件。
• cb_node_cpu_utilization_percent— 每個節點 CPU 使用情況。 Couchbase 是 CPU 的壓縮和索引密集型產品。
• cb_bucket_vbucket_active_num— 每個節點的活動 vBucket 數量。資料節點之間應該大致均勻。
• cb_index_num_docs_pending— 文件等待索引更新。表示索引構建滯後。
• cb_n1ql_requests_per_sec— N1QL 查詢吞吐量。結合平均延遲，可以識別查詢效能問題。

Prometheus 警報規則

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 }}"

SDK 連線字串配置

Couchbase SDK 具有拓撲感知能力 - 它們維護內部叢集對映並將操作直接路由到正確的節點。正確的 SDK 配置對於 HA 至關重要，可確保快速故障轉移檢測和針對瞬態錯誤的自動重試。

// 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)
);

Kubernetes 用於 SDK 連線的 DNS 服務

# 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)

Couchbase 用於邊緣部署的移動和同步閘道器

Couchbase Mobile 將 Couchbase 生態系統擴充套件到邊緣裝置和移動應用。Couchbase Lite嵌入在iOS、Android和IoT裝置上執行，而同步閘道器充當Couchbase Lite和Couchbase伺服器之間的同步中介軟體。

// 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

容量規劃和規模調整

正確的容量規劃對於 Couchbase 效能和成本最佳化至關重要。 下表提供了基於工作負載層的規模調整指南：

尺碼公式

# 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 完整生產部署的價值

下面是一個全面的 Helm 值檔案，用於在生產環境中使用 Autonomous Operator 部署 Couchbase：

# 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

結論

Couchbase 伺服器的架構圍繞基於 vBucket 的分片、記憶體優先資料訪問和整合多模型服務構建，為高可用性生產部署提供了獨特的強大基礎。叢集內複製與自動故障轉移的結合可確保透明地處理單節點故障，而 XDCR 將這種彈性擴充套件到全球應用程式的跨地理區域。

Kubernetes 的 Couchbase 自主操作員將複雜的手動操作轉變為宣告式、自我修復部署。伺服器組提供機架/區域感知，操作員在擴充套件事件期間管理重新平衡操作，整合備份 CRD 自動執行災難恢復準備。

本指南的要點：

• 利用多維擴充套件— 將資料、索引、查詢、搜尋、分析和事件服務分離到專用節點池上，以實現獨立擴充套件和資源隔離。
• 配置 XDCR 以實現多區域彈性— 具有基於時間戳的衝突解決功能的雙向 XDCR 支援跨 AWS、Azure 和 GCP 的主動-主動部署。始終確保 NTP 同步。
• 使用伺服器組進行區域感知— 將伺服器組對映到可用區域或機架，以保證活動 vBucket 和副本 vBucket 位於不同的故障域中。
• 仔細調整記憶體大小— Couchbase 的效能與 RAM 中容納的工作集大小直接相關。使用大小調整公式並監控快取未命中率。
• 實施全面監控— 從第一天起就部署 Prometheus 匯出器。 XDCR 複製延遲、快取未命中率、磁碟佇列深度和節點執行狀況是您的關鍵訊號。
• 使用 cbbackupmgr 自動備份— 將完整備份和增量備份與雲快照相結合。定期測試恢復過程。
• 透過 TLS 和 RBAC 實現安全— 啟用節點到節點和客戶端到節點 TLS 加密。為每個應用程式服務帳戶使用細粒度的 RBAC 角色。
• 為 HA配置 SDK — 使用多個引導節點、配置適當的超時、實施副本讀取作為回退，並利用關鍵資料的持久寫入。
• 災難恢復規劃— 記錄並演練單節點、多節點和完整叢集故障場景的故障轉移過程。 XDCR 備用叢集應隨時準備好升級。

有了這個全面的基礎，您就可以在任何基礎設施的高可用性生產環境中部署和操作 Couchbase 伺服器——從 AWS、Azure 和 GCP 上的託管 Kubernetes 到 Rancher 管理的裸機 k3s 叢集。 Couchbase 的本機分散式架構與 Kubernetes 編排相結合，提供了一個滿足現代全球分散式應用程式需求的資料庫平臺。