Couchbase ความพร้อมใช้งานสูงในการผลิต: XDCR, Kubernetes Operator และการปรับใช้หลายภูมิภาค

# 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

สคริปต์สำรองข้อมูลอัตโนมัติสำหรับ 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."

CouchbaseBackup CRD (จัดการโดยผู้ดำเนินการ)

ผู้ดำเนินการอัตโนมัติมอบ CRDs สำหรับการจัดการการสำรองข้อมูลอัตโนมัติ:

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 (SQL++ สำหรับ JSON) เป็นภาษาคิวรีของ 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 APIcouchbase-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

คีย์เมตริก Couchbase เพื่อตรวจสอบ

• 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_write— เอกสารที่จำลองต่อวินาทีผ่าน XDCR
• cb_node_cpu_utilization_percent— การใช้งาน CPU ต่อโหนด Couchbase มีความเข้มข้น CPU สำหรับการบดอัดและการจัดทำดัชนี
• cb_bucket_vbucket_active_num— จำนวน vBuckets ที่ใช้งานอยู่ต่อโหนด ควรจะเท่ากันทั่วทั้งโหนดข้อมูล
• 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 สำหรับ HA

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 บริการ DNS สำหรับการเชื่อมต่อ SDK

# 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 อุปกรณ์เคลื่อนที่และเกตเวย์การซิงค์สำหรับการปรับใช้ Edge

Couchbase Mobile ขยายระบบนิเวศ Couchbase ไปยังอุปกรณ์ Edge และแอปพลิเคชันมือถือCouchbase Liteทำงานแบบฝังบนอุปกรณ์ iOS, Android และ IoT ในขณะที่Sync Gatewayทำหน้าที่เป็นมิดเดิลแวร์การซิงโครไนซ์ระหว่าง 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 ที่ครอบคลุมสำหรับการปรับใช้ Couchbase กับ Autonomous Operator ในสภาพแวดล้อมการใช้งานจริง:

# 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 ขยายความยืดหยุ่นนี้ไปทั่วภูมิภาคทางภูมิศาสตร์สำหรับแอปพลิเคชันระดับโลก

Couchbase Autonomous Operator สำหรับ Kubernetes แปลงสิ่งที่จะเป็นการดำเนินการด้วยตนเองที่ซับซ้อนให้กลายเป็นการปรับใช้ที่ประกาศและซ่อมแซมตัวเองได้ กลุ่มเซิร์ฟเวอร์ให้การรับรู้แร็ค/โซน ผู้ปฏิบัติงานจัดการการดำเนินการปรับสมดุลระหว่างเหตุการณ์การปรับขนาด และการสำรองข้อมูล CRD ที่ผสานรวมทำให้การเตรียมการกู้คืนความเสียหายเป็นอัตโนมัติ

ประเด็นสำคัญจากคู่มือนี้:

• ใช้ประโยชน์จาก Multi-Dimensional Scaling— แยกบริการข้อมูล ดัชนี การสืบค้น การค้นหา การวิเคราะห์ และ Eventing ไปยัง Node Pool เฉพาะเพื่อการปรับขนาดที่เป็นอิสระและการแยกทรัพยากร
• กำหนดค่า XDCR สำหรับความยืดหยุ่นในหลายภูมิภาค— XDCR แบบสองทิศทางพร้อมการแก้ไขข้อขัดแย้งตามการประทับเวลา ช่วยให้สามารถปรับใช้แบบแอ็กทีฟแอคทีฟทั่วทั้ง AWS, Azure และ GCP ตรวจสอบให้แน่ใจว่ามีการซิงโครไนซ์ NTP เสมอ
• ใช้กลุ่มเซิร์ฟเวอร์สำหรับการรับรู้โซน— แมปกลุ่มเซิร์ฟเวอร์กับโซนความพร้อมใช้งานหรือชั้นวางเพื่อรับประกันว่า vBuckets ที่ใช้งานอยู่และจำลองอยู่ในโดเมนความล้มเหลวที่แตกต่างกัน
• ปรับขนาดหน่วยความจำอย่างระมัดระวัง— ประสิทธิภาพของ Couchbase เชื่อมโยงโดยตรงกับจำนวนชุดการทำงานที่เหมาะกับ RAM ใช้สูตรการกำหนดขนาดและตรวจสอบอัตราส่วนการพลาดแคช
• ใช้การตรวจสอบที่ครอบคลุม— ปรับใช้ผู้ส่งออก Prometheus ตั้งแต่วันแรก ความล่าช้าในการจำลอง XDCR, อัตราส่วนแคชที่พลาด, ความลึกของคิวดิสก์ และสภาพของโหนดเป็นสัญญาณที่สำคัญของคุณ
• สำรองข้อมูลอัตโนมัติด้วย cbbackupmgr— รวมการสำรองข้อมูลทั้งหมดและการสำรองข้อมูลส่วนเพิ่มเข้ากับสแน็ปช็อตบนคลาวด์ ทดสอบขั้นตอนการกู้คืนอย่างสม่ำเสมอ
• ปลอดภัยด้วย TLS และ RBAC— เปิดใช้งานการเข้ารหัส TLS แบบโหนดต่อโหนดและไคลเอ็นต์ต่อโหนด ใช้บทบาท RBAC แบบละเอียดสำหรับบัญชีบริการแอปพลิเคชันทุกรายการ
• กำหนดค่า SDK สำหรับ HA— ใช้โหนดบูทสแตรปหลายโหนด กำหนดค่าการหมดเวลาที่เหมาะสม ใช้การอ่านแบบจำลองเป็นทางเลือกสำรอง และใช้ประโยชน์จากการเขียนที่คงทนสำหรับข้อมูลที่สำคัญ
• แผนสำหรับการกู้คืนความเสียหาย— จัดทำเอกสารและซ้อมขั้นตอนเฟลโอเวอร์สำหรับสถานการณ์ความล้มเหลวของโหนดเดียว หลายโหนด และคลัสเตอร์ทั้งหมด คลัสเตอร์สแตนด์บาย XDCR ควรพร้อมสำหรับการโปรโมตตลอดเวลา

ด้วยรากฐานที่ครอบคลุมนี้ คุณพร้อมที่จะปรับใช้และใช้งานเซิร์ฟเวอร์ Couchbase ในสภาพแวดล้อมการผลิตที่มีความพร้อมใช้งานสูงในทุกโครงสร้างพื้นฐาน ตั้งแต่ Kubernetes ที่มีการจัดการบน AWS, Azure และ GCP ไปจนถึงคลัสเตอร์ Bare Metal k3s ที่จัดการโดย Rancher การผสมผสานสถาปัตยกรรมแบบกระจายดั้งเดิมของ Couchbase เข้ากับการจัดการ Kubernetes ทำให้เกิดแพลตฟอร์มฐานข้อมูลที่ตอบสนองความต้องการของแอปพลิเคชันสมัยใหม่ที่กระจายไปทั่วโลก