Replikasyon ve Okuma Replikaları — Yazdım Ama Göremiyorum

Kullanıcı profil adını değiştirdi, “kaydedildi” mesajını gördü ve sayfayı yeniledi: eski ad duruyordu. Tekrar kaydetti, yine eski ad. Destek kaydı açtığında ad çoktan düzelmişti.

Biri yazar, diğerleri kopyalar

Yazmalar tek bir sunucuya, primary’ye gider. Replikalar primary’nin değişiklik günlüğünü alıp aynı değişiklikleri kendilerine uygular. Okumaları replikalara dağıtmak, primary’nin yükünü azaltır.

PostgreSQL’de streaming replication, SQL Server’da Always On availability groups, Oracle’da Data Guard bu işi yapar. Üçünde de varsayılan ya da en yaygın kurulum asenkrondur.

Geriden gelmenin iki bedeli

Replikanın primary’nin gerisinde kaldığı süreye replication lag?Terimin tanımını açreplication lagBir replikanın primary'deki değişiklikleri ne kadar geriden uyguladığı. Bu süre boyunca replikadan yapılan okumalar eski veriyi gösterir.Sözlükte gör → denir. Bu süre boyunca replika eski veriyi gösterir; lag büyürken primary çökerse aradaki yazmalar failover?Terimin tanımını açfailoverPrimary çöktüğünde bir replikanın yeni primary olarak devralması. Asenkron replikasyonda replikaya ulaşmamış yazmalar bu sırada kaybolabilir.Sözlükte gör →’da kaybolur.

Senkron replikasyonun da iki derecesi var. “Replika diske yazsın” kaybı önler ama okumayı tazelemez. “Replika uygulasın” (PostgreSQL’de remote_apply) ikisini de sağlar, ama her commit en çok burada bekler.

Kendin gör

1. Varsayılanla oynat. Okuma replikadan: kullanıcı eski adı görüyor.
2. “Primary çöksün”ü aç. Onaylanmış yazma kayboldu.
3. Replikasyonu “diske yazsın” yap. Kayıp yok, ama okuma hâlâ eski.
4. “Uygulasın” yap. Taze ve güvenli; commit bekledi.
5. Asenkrona dön, okumayı “yazan primary’den okusun” yap. Okuma taze, ama çökme kaybı duruyor.

Kendi yazdığını okumak

Her okuma taze olmak zorunda değil; ama kullanıcının kendi değişikliğini görmesi gereken okumalar vardır. Buna read-your-writes?Terimin tanımını açread-your-writesBir kullanıcının kendi yaptığı değişikliği sonraki okumalarında mutlaka görmesi garantisi. Replikalardan okurken kendiliğinden sağlanmaz.Sözlükte gör → garantisi denir.

• Yazan kullanıcıyı bir süre primary’ye yönlendir: en basit yol; oturumda “son yazma zamanı” tut.
• Yazma konumunu bekle: primary’nin döndürdüğü log konumunu sakla, replika o konumu uygulamadan ondan okuma.
• Kritik okumaları hep primary’den yap: bakiye, stok, ödeme durumu.

Bir mobil bankacılık uygulamasında bu üç yol yan yana nasıl duruyor, birlikte bakalım. Müşteri FAST ile para gönderiyor ve hemen hesap sayfasına dönüyor.

1
@Service
2
class AccountQueryService {
3

4
    private final JdbcClient primary;
5
    private final JdbcClient replica;
6
    private final LastWriteTracker lastWrite;   // TransferService marks the customer after commit
7

8
    AccountQueryService(@Qualifier("primary") JdbcClient primary,
9
                        @Qualifier("replica") JdbcClient replica,
10
                        LastWriteTracker lastWrite) {
11
        this.primary = primary;
12
        this.replica = replica;
13
        this.lastWrite = lastWrite;
14
    }
15

16
    // The balance decides the next transfer, so it always comes from the primary.
17
    BigDecimal balance(String iban) {
18
        return primary.sql("SELECT balance FROM account WHERE iban = :iban")
19
                .param("iban", iban)
20
                .query(BigDecimal.class)
21
                .single();
22
    }
23

24
    // Movements may lag a little, except right after this customer's own transfer.
25
    List<Movement> recentMovements(long customerId, String iban) {
26
        JdbcClient source = lastWrite.wroteWithin(customerId, Duration.ofSeconds(30)) ? primary : replica;
27
        return source.sql("""
28
                SELECT booked_at, amount, currency, description
29
                  FROM account_movement
30
                 WHERE iban = :iban
31
                 ORDER BY booked_at DESC
32
                 LIMIT 20
33
                """)
34
                .param("iban", iban)
35
                .query(Movement.class)
36
                .list();
37
    }
38
}

1
bank:
2
  datasource:
3
    # Bound to two HikariDataSource beans with @ConfigurationProperties.
4
    primary:
5
      # The driver connects to whichever host accepts writes, so a failover needs no config change.
6
      jdbc-url: jdbc:postgresql://pg-a:5432,pg-b:5432/corebank?targetServerType=primary
7
    replica:
8
      jdbc-url: jdbc:postgresql://pg-a:5432,pg-b:5432/corebank?targetServerType=preferSecondary&loadBalanceHosts=true
9
      read-only: true

1
-- On the primary, right after the transfer commits: remember this WAL position
2
-- in the customer's session.
3
SELECT pg_current_wal_lsn();
4

5
-- On a replica, before reading movements: has it replayed at least that far?
6
SELECT pg_last_wal_replay_lsn() >= CAST(:saved_lsn AS pg_lsn) AS caught_up;
7

8
-- On the primary: how far behind each replica is. Alert on replay_lag.
9
SELECT application_name, sync_state, write_lag, flush_lag, replay_lag
10
  FROM pg_stat_replication;

1
@RestController
2
class BalanceController {
3

4
    // A routing DataSource sends readOnly transactions to the replica.
5
    @Transactional(readOnly = true)
6
    @GetMapping("/accounts/{iban}/balance")
7
    BalanceView balance(@PathVariable String iban) {
8
        // Called right after a FAST transfer: the replica may not have the debit yet,
9
        // so the old balance shows up. The customer thinks the transfer failed
10
        // and presses "send" again.
11
        return accounts.findBalance(iban);
12
    }
13
}

Tuzaklar

Replikalar arasında zıplamak. Farklı gecikmeli iki replikadan sırayla okuyan kullanıcı, zamanda geriye gidebilir: yorum görünür, sonra kaybolur.

Senkron replika düşerse. PostgreSQL’de senkron replika yoksa commit’ler bekler; yazmalar durur. Birden çok aday replika ya da bilinçli bir geri düşme planı gerekir.

readOnly ile yönlendirme. Spring’de @Transactional(readOnly = true) okumaları replikaya gönderiyorsa, yazmadan hemen sonra aynı istekte yapılan okuma da oraya gidebilir.

Gecikmeyi izlememek. PostgreSQL’de pg_stat_replication, SQL Server’da redo kuyruğu, Oracle’da apply lag izlenmeli.

Kendini sına