High Availability

Giriş

Tuning your PostgreSQL for High Performance yazısına bakılabilir

Sanırım 3 tane temel senaryo var. Bunlar şöyle

1. Running PostgreSQL Outside of Kubernetes

Şeklen şöyle

Açıklaması şöyle

The PostgreSQL cluster consists of a Master Node and a Standby Node. In case the Master Node failed for some reason (e.g., hardware or network defect) the standby server can overtake the role of the master. The PG-Bouncer in this picture is a component from Postgres and acts as a kind of reverse proxy server. In case of a failure, the switch from the Master to the Standby node can be done by an administrator or can be automated by scripts. From the view of a client, this switch is transparent.

Açıklaması şöyle. Master ve replica arasında senkronizasyon kopsa bile Postgred replica devralabilir. Bir miktar veri kaybı olsa bile

PostgreSQL'de otomatik failover'ı açmak için replikasyonu senkron moda almak zorunda değilsiniz. Asenkron bir yapıda bile, primary çöktüğünde bir replica otomatik olarak terfi edebilir. Yani "biraz veri kaybı olabilir ama sistem kendi kendine ayağa kalksın" senaryosuna izin verir.

SQL Server tarafında ise durum farklı. Always On'da otomatik failover'ın devreye girebilmesi için replica'nın senkron modda olması ŞART. Asenkron bir replica otomatik failover hedefi olamaz. Siz veri kaybını göze alsanız bile sistem buna kendiliğinden izin vermez; ancak force allow data loss diyerek, bilinçli ve manuel bir müdahaleyle failover yapabilirsiniz.

Aradaki fark aslında bir tasarım felsefesi farkı. SQL Server "otomatik bir karar asla veri kaybına yol açmamalı, veri kaybı ancak insanın bilerek onayıyla olur" diyor. PostgreSQL ise "kayıp riskini kabul edip etmemek senin kararın, otomasyonu buna göre kur" diyor. İkisi de savunulabilir, ama aynı problemi farklı yerden çözüyorlar.

2. Running PostgreSQL Inside of Kubernetes

Örnek

Deployment şöyledir

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
  namespace: spring-keycloak-demo
spec:
  selector:
    matchLabels:
      app: postgres
  replicas: 1
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:latest
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: postgres
            - name: POSTGRES_USER
              value: postgres
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: spring-keycloak-secrets
                  key: postgres-pass

service şöyledir

apiVersion: v1
kind: Service
metadata:
  name: postgres-service
  namespace: spring-keycloak-demo
  labels:
    app: postgres
spec:
  selector:
    app: postgres
  ports:
    - port: 5432
  type: NodePort

Örnek

Şöyle yaparız. storageClassName is specific to Kubernetes cluster

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
  labels:
    component: postgres
spec:
  selector:
    matchLabels:
      component: postgres
  serviceName: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:11
          ports:
            - containerPort: 5432
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgres-data
          env:
            - name: POSTGRES_DB
              value: postgres
            - name: POSTGRES_USER
              value: postgres
            - name: POSTGRES_PASSWORD
              value: postgres
  volumeClaimTemplates:
    - metadata:
        name: postgres-data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: hostpath
        resources:
          requests:
            storage: 5Gi

Service olarak şöyle yaparız

apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    component: postgres
spec:
  selector:
    component: postgres
  ports:
    - port: 5432

3. Running PostgreSQL on a Distributed Block Storage