როგორ დააპროექტებთ multi-region DB-ს HA-სა და DR-სთვის?

Question

IT Interview Practice · Accepted Answer

Replicate გააკეთეთ database region-ებზე და აირჩიეთ topology საჭიროებით: **active-passive** (ერთი writer, warm standby, რომელიც failover-ზე იღებს) სიმარტივისა და strong consistency-სთვის, ან **active-active** (მრავალი writer) დაბალი write latency-სთვის conflict resolution-ის ფასად — შემდეგ აირჩიეთ **sync vs async replication** durability-ს latency-ს წინააღმდეგ, და განსაზღვრეთ ცხადი **RPO/RTO** მიზნები failover-ისთვის.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive**-ს ჰყავს ერთი primary, რომელიც write-ებს ამუშავებს, და standby-ები, რომლებიც მხოლოდ read-ს აკეთებენ; ჩავარდნისას standby-ს **დააწინაურებთ (promote)**. ის მარტივია და write conflict-ებს არიდებს, მაგრამ passive capacity უქმად დგას და failover-ს ხარვეზი აქვს. **Active-active** ყოველ region-ს write-ის მიღების საშუალებას აძლევს ლოკალური latency-სთვის და failover promotion-ის გარეშე — მაგრამ ორ region-ს ერთდროულად შეუძლია ერთი მწკრივის რედაქტირება, ამიტომ *უნდა* გადაწყვიტოთ conflict-ები (last-write-wins, CRDT-ები, ან app-დონის merge). გუნდების უმეტესობა active-passive-ით იწყებს; active-active გლობალური write latency-სთვისაა, რომელსაც სხვაგვარად ვერ აკმაყოფილებთ.

## Sync vs async replication

ეს არის ბირთვის durability/latency ტრეიდ-ოფი. **Synchronous:** primary ელოდება remote replica-ს acknowledge-ს commit-ამდე — **RPO = 0** (failover-ზე მონაცემი არ იკარგება), მაგრამ ყოველი write cross-region round-trip latency-ს იხდის (~ათეული ms), და თუ replica მიუწვდომელია, write-ები ჩერდება. **Asynchronous:** primary ლოკალურად commit-ს აკეთებს და ცვლილებებს შემდეგ აგზავნის — სწრაფი write-ები, მაგრამ region-ის დაკარგვამ შეიძლება ბოლო რამდენიმე წამი დაკარგოს (**RPO > 0**). cross-region sync ხშირად ძალიან ნელია, ამიტომ ბევრი async-ს უშვებს და პატარა RPO-ს იღებს.

## Failover, RPO და RTO

- **RPO (Recovery Point Objective):** რამდენ მონაცემს გაუძლებთ დაკარგვას — დგინდება sync vs async-ით.
- **RTO (Recovery Time Objective):** რამდენ ხანში დაბრუნდებით — დგინდება იმით, რამდენად სწრაფად აღმოაჩენთ ჩავარდნას და დააწინაურებთ.
- Failover = detect (health check-ები) → promote standby → repoint traffic (DNS/global LB). ავტომატიზეთ, მაგრამ დაიცავით **split-brain**-ისგან (ორივე region ფიქრობს, რომ primary-ია) quorum/fencing token-ით.

## ინტერვიუს პერსპექტივა

შემოწმება: გესმით თუ არა, რომ HA/DR არის **ტრეიდ-ოფი consistency-ს, latency-სა და მონაცემის დაკარგვას შორის** — არა "უბრალოდ დაამატე replica". კარგი: active-passive standby-ით. შესანიშნავი: აცხადებთ RPO/RTO-ს, sync-vs-async იმპლიკაციებს და split-brain რისკს. ხაფანგი: მტკიცება, რომ async ნულოვან მონაცემის დაკარგვას იძლევა, ან ვარაუდი, რომ failover მყისიერი და უდანაკარგოა.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **Split-brain:** network partition ორ primary-ს აწინაურებს → განსხვავებული მონაცემი. გამოიყენეთ quorum, fencing, ან witness region.
- **Failback რთულია:** ძველი primary-ის დაბრუნების შემდეგ განსხვავებული write-ების შეჯერება ხელით და შეცდომებისკენ მიდრეკილია.
- **ღირებულება:** ნამდვილი multi-region დაახლოებით აორმაგებს infra-ს და cross-region egress bandwidth ხარჯებს ამატებს.
- **დაუტესტავი failover ვერ მუშაობს:** DR, რომელიც არასდროს გავარჯიშებულა, ნამდვილ outage-ზე ვერ იმუშავებს — გაუშვით game-day-ები.

Active-passive vs active-active

Sync vs async replication

Failover, RPO და RTO

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები