PostgreSQL માં replication કેવી રીતે કાર્ય કરે છે?

Question

Accepted Answer

**Replication** એ પ્રાથમિક ડેટાબેસમાંથી એક અથવા વધુ **replica** (standby) સર્વર્સમાં ડેટાને નકલ કરે છે — ઉચ્ચ ઉપલબ્ધતા (primary failure પર failover) અને read scaling (read queries વितરિત કરવા) માટે. PostgreSQL મુખ્યત્વે **streaming replication** (physical) વાપરે છે જે write-ahead log (WAL) પર આધારિત છે.

## Streaming (physical) replication

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

Primary તેનો **WAL** (write-ahead log — દરેક પરિવર્તનનો રેકોર્ડ) replicas ને stream કરે છે, જે સમન્વયિત રહેવા માટે તેને લાગુ કરે છે. Replicas એ read-only નકલો છે જે read queries પૂરી કરી શકે છે.

## લાભો: HA અને read scaling

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Synchronous વિરુદ્ધ asynchronous replication

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Logical replication (એક અલગ મોડેલ)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## વ્યવહારમાં high availability

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## તે શા માટે મહત્વપૂર્ણ છે

Replication એ **અત્યંત-ઉપલબ્ધ અને scalable** PostgreSQL deployments બનાવવા માટે મહત્વપૂર્ણ છે, તેથી તેને સમજવું senior-level જ્ઞાન છે production database architecture માટે.

બે મુખ્ય લાભો નિર્ણાયક છે serious applications માટે: **high availability** (જો primary database fail થાય તો, એક replica ને પદોન્નત કરી શકાય છે તેના સ્થાને, downtime ન્યૂનતમ કરીને — essential સિસ્ટમ્સ માટે જે ઉપલબ્ધ રહેવા જોઈએ) અને **read scaling** (read-only queries ને replicas ને routing કરવું primary ને unload કરે છે, જે સિસ્ટમને ખૂબ વધુ read traffic સંભાળવા દે છે — valuable read-heavy workloads માટે).

**Streaming replication** (primary તેનો WAL replicas ને stream કરે છે જે સમન્વયિત રહે છે અને reads પૂરી કરી શકે છે) સમજવું આધાર છે.

**Synchronous વિરુદ્ધ asynchronous** trade-off જાણવું મહત્વપૂર્ણ છે: asynchronous (ડિફોલ્ટ — faster writes પણ failover પર potential data loss ની નાની window) વિરુદ્ધ synchronous (કોઈ data loss નહીં પણ slower writes) — durability-vs-performance નિર્ણય જે reliability ને અસર કરે છે.

**Logical replication** (specific tables ને pub/sub દ્વારા replicate કરવું, migrations, cross-version, અને partial/selective replication માટે useful) સમજવું વિકલ્પોને વ્યાપક બનાવે છે.

જાણવું કે **HA tooling** (Patroni, repmgr, managed cloud Postgres) failover ને automate કરે છે, અને read/write routing traffic ને યોગ્ય રીતે નિર্દેશિત કરે છે, તે practical architectural knowledge છે.

Karण high availability અને scalability production database systems માટે essential requirements છે, અને replication (તેના HA failover, read scaling, sync/async durability trade-off, અને flexibility માટે logical replication સાથે) તે primary mechanism છે જે PostgreSQL તેમ માટે આપે છે, replication સમજવું important senior-level knowledge છે reliable, scalable Postgres deployments architect કરવા માટે — frequently-relevant concern production systems માટે અને topic જે database availability અને scaling ની સમજ દર્શાવે છે જે senior database/backend roles માટે expected છે.