Menggunakan replikasi lintas-data center

Pilih versi dokumentasi:

Halaman ini menjelaskan cara menggunakan replikasi lintas pusat data dengan membuat dan menggunakan cluster database sekunder di Kubernetes.

Untuk ringkasan konseptual replikasi lintas pusat data, lihat Tentang replikasi lintas pusat data.

Sebelum memulai

  • Pastikan Anda memiliki konektivitas jaringan yang andal dan berlatensi rendah antara pusat data utama dan sekunder, yang sangat penting agar replikasi lintas pusat data berfungsi secara efektif.
  • Instal versi terbaru operator AlloyDB Omni untuk men-deploy AlloyDB Omni di cluster Kubernetes di pusat data utama dan cluster Kubernetes di pusat data sekunder. Replikasi lintas pusat data didukung di operator AlloyDB Omni versi 1.5.0 dan yang lebih baru.
  • Buat cluster database AlloyDB Omni di cluster Kubernetes di pusat data utama.
  • Pastikan server database utama dan standby di cluster database utama Anda memiliki ruang Write-Ahead Logging (WAL) yang memadai yang dapat mengakomodasi file WAL yang diperlukan untuk replikasi ke cluster sekunder. Setiap data yang belum direplikasi ke cluster sekunder disimpan di cluster primer sebagai file WAL. Bergantung pada kecepatan koneksi antara cluster utama dan sekunder, Anda mungkin memerlukan kapasitas disk tambahan untuk tujuan ini.
  • Perhatikan informasi berikut tentang standby ketersediaan tinggi database sekunder (Pratinjau): jika versi operator AlloyDB Omni dan versi agen bidang kontrol adalah 1.7.0 atau yang lebih baru, cluster database sekunder dapat mendukung standby ketersediaan tinggi (HA).

    Tidak seperti standby HA di cluster database utama, standby HA di cluster database sekunder bersifat asinkron hingga cluster database sekunder dipromosikan menjadi database utama. Standby HA otomatis menjadi sinkron atau asinkron jika peran cluster database diubah selama peralihan.

Membuat cluster database sekunder

Untuk membuat cluster database sekunder AlloyDB Omni dan mengaktifkan replikasi dari cluster database utama Anda, ikuti langkah-langkah berikut:

  1. Pastikan konektivitas eksternal diaktifkan di cluster database utama AlloyDB Omni Anda. Jika konektivitas eksternal tidak diaktifkan, tambahkan kode berikut ke bagian spesifikasi manifes cluster database:

    ...
    spec:
      ...
      allowExternalIncomingTraffic: true
     
  2. Untuk menggunakan replikasi lintas pusat data dengan cluster database utama yang mengaktifkan ketersediaan tinggi (HA), pastikan kolom replayReplicationSlotsOnStandbys diaktifkan di cluster database utama:

    ...
    spec:
      ...
      availability:
        ...
        replayReplicationSlotsOnStandbys: true
     

    Mengaktifkan kolom ini, bersama dengan logReplicationSlots yang dijelaskan pada langkah berikut, akan menyinkronkan slot replikasi yang digunakan oleh cluster database sekunder ke semua standby dengan ketersediaan tinggi (HA). Konfigurasi ini membantu database utama HA yang baru mempertahankan file Write-Ahead Logging (WAL) yang belum digunakan oleh cluster database sekunder setelah failover atau pengalihan, sehingga cluster database sekunder dapat melanjutkan replikasi tanpa gangguan.

  3. Untuk mengaktifkan replikasi di cluster database utama, terapkan manifes yang mirip dengan berikut ini ke cluster Kubernetes di pusat data utama:

    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-DB_CLUSTER_NAME
      namespace: DB_CLUSTER_NAMESPACE
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: REPLICATION_NAME
      namespace: DB_CLUSTER_NAMESPACE
    spec:
      dbcluster:
        name: DB_CLUSTER_NAME
      upstream:
        password:
          name: ha-rep-pw-DB_CLUSTER_NAME
        logReplicationSlot: true

    Ganti kode berikut:

    • DB_CLUSTER_NAME: Nama cluster database—misalnya, dbc-1.
    • ENCODED_PASSWORD: Sandi untuk pengguna database yang akan digunakan untuk replikasi dari database sekunder, yang dienkode sebagai string base64—misalnya, Q2hhbmdlTWUxMjM= for ChangeMe123. Nilai defaultnya adalah alloydbreplica.
    • REPLICATION_NAME: Nama replikasi—misalnya, replication-1.
    • LOG_REPLICATION_SLOT: Mencatat data slot replikasi ke file WAL. Untuk mengaktifkan opsi ini, tetapkan nilainya ke true. Nilai defaultnya adalah false.

    Sebaiknya aktifkan opsi logReplicationSlot dengan cluster database utama yang mengaktifkan ketersediaan tinggi (HA) untuk memastikan replikasi dapat terus berfungsi setelah failover atau peralihan.

    Tunggu hingga status replikasi siap.

  4. Untuk mendapatkan informasi koneksi upstream yang digunakan untuk mengonfigurasi replikasi di cluster database sekunder, jalankan perintah berikut:

    kubectl get replication REPLICATION_NAME
    kubectl get replication REPLICATION_NAME -o json | jq .status.upstream

    Contoh output terlihat mirip dengan berikut ini:

      {
        "host": "35.230.32.36",
        "password": {
          "name": "ha-rep-pw-dbc-1"
        },
        "port": 5432,
        "replicationSlotName": "dbc_1_replication_1",
        "username": "alloydbreplica"
      }
      
  5. Catat outputnya karena Anda memerlukannya untuk mengaktifkan replikasi di cluster database sekunder pada langkah berikut.
  6. Buat cluster AlloyDB Omni di cluster Kubernetes Anda di pusat data sekunder dengan konfigurasi yang sama dengan cluster database utama Anda.
  7. Memastikan konektivitas eksternal diaktifkan di cluster database sekunder AlloyDB Omni Anda
  8. Jika konektivitas eksternal tidak diaktifkan, tambahkan kode berikut ke bagian spesifikasi manifesnya:

    ...
    spec:
      ...
      allowExternalIncomingTraffic: true
  9. Untuk mengaktifkan replikasi di cluster database sekunder, terapkan manifes yang mirip dengan berikut ini ke cluster Kubernetes Anda di pusat data sekunder:
    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
      namespace: SECONDARY_DB_CLUSTER_NAMESPACE
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: SECONDARY_REPLICATION_NAME
      namespace: SECONDARY_DB_CLUSTER_NAMESPACE
    spec:
      dbcluster:
        name: SECONDARY_DB_CLUSTER_NAME
      downstream:
        host: PRIMARY_HOST
        port: PRIMARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
        replicationSlotName: PRIMARY_REPLICATION_SLOT
        control: setup

    Ganti kode berikut:

    • SECONDARY_DB_CLUSTER_NAME: nama cluster database sekunder—misalnya, dbc-2.
    • ENCODED_PASSWORD: sandi untuk pengguna database yang akan digunakan untuk replikasi dari cluster database utama, yang dienkode sebagai string base64—misalnya, Q2hhbmdlTWUxMjM= for ChangeMe123. Nilai defaultnya adalah alloydbreplica.
    • SECONDARY_REPLICATION_NAME: nama replikasi—misalnya, `replication-2`.
    • PRIMARY_HOST: endpoint koneksi cluster database utama dari output di langkah 4 yang dapat diakses oleh database sekunder untuk replikasi.
    • PRIMARY_PORT: port koneksi cluster database utama dari output di langkah 4 yang dapat diakses oleh database sekunder untuk replikasi.
    • PRIMARY_REPLICATION_SLOT: nama slot replikasi di cluster database utama dari output di langkah 4 yang dapat digunakan database sekunder untuk replikasi.

Melihat replikasi di cluster database sekunder

Untuk melihat informasi mendetail tentang cluster database sekunder AlloyDB Omni dan status replikasinya, jalankan perintah berikut:

kubectl get dbcluster SECONDARY_DB_CLUSTER_NAME
kubectl get replication SECONDARY_REPLICATION_NAME

Setelah cluster database sekunder berhasil disiapkan dan memiliki replikasi streaming dari cluster database utama, status replikasi akan siap dan responsif.

Mempromosikan cluster database sekunder

Saat mempromosikan cluster database sekunder, Anda harus terlebih dahulu memverifikasi bahwa cluster database sekunder menerapkan semua transaksi yang diterima dari cluster database utama.

  1. Untuk memverifikasi bahwa cluster sudah siap dan responsif, periksa status replikasi cluster database sekunder.
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Hentikan semua penulisan ke cluster database utama. Jalankan checkpoint di cluster database utama, lalu jalankan kueri berikut di cluster database utama Anda untuk memeriksa jeda replikasi database sekunder. Pastikan hasilnya menunjukkan jeda minimal.
    1. Jalankan checkpoint untuk mengosongkan memori ke disk.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Periksa jeda replikasi. Nilai jeda 0 adalah optimal. Jika jeda lebih besar dari 0, Anda masih dapat mempromosikan cluster database sekunder. Namun, ada risiko kehilangan transaksi terbaru yang sudah di-commit di cluster database utama.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'

  3. Promosikan cluster database sekunder menjadi cluster database utama dengan memperbarui kolom control manifes replikasi cluster database sekunder Anda menjadi promote. Kemudian, terapkan manifes replikasi yang telah diupdate di cluster Kubernetes Anda di pusat data sekunder.

    apiVersion: v1
    kind: Secret
    metadata:
      name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
      namespace: SECONDARY_DB_CLUSTER_NAMESPACE
    type: Opaque
    data:
      rep-user-pw: "ENCODED_PASSWORD"
    ---
    apiVersion: alloydbomni.dbadmin.goog/v1
    kind: Replication
    metadata:
      name: SECONDARY_REPLICATION_NAME
      namespace: SECONDARY_DB_CLUSTER_NAMESPACE
    spec:
      dbcluster:
        name: SECONDARY_DB_CLUSTER_NAME
      downstream:
        host: PRIMARY_HOST
        port: PRIMARY_PORT
        username: alloydbreplica
        password:
          name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
        replicationSlotName: PRIMARY_REPLICATION_SLOT
        control: promote

Melakukan peralihan

Sebelum melakukan peralihan, pastikan cluster database utama dan sekunder yang dimiliki oleh kedua pusat data sedang online dan cluster database dalam kondisi baik.

Untuk menerapkan konsistensi data cluster database utama dan sekunder selama pengalihan, lakukan langkah-langkah berikut untuk memverifikasi bahwa cluster database sekunder telah menerapkan semua transaksi yang diterima dari cluster database utama:

  1. Periksa status replikasi cluster database sekunder, untuk memverifikasi bahwa cluster tersebut siap dan responsif.
    kubectl get replication SECONDARY_REPLICATION_NAME
  2. Hentikan semua penulisan ke cluster database utama. Jalankan checkpoint di cluster database utama, lalu jalankan kueri berikut di cluster database utama Anda untuk memeriksa jeda replikasi database sekunder.
    1. Jalankan checkpoint untuk mengosongkan memori ke disk.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Pastikan hasilnya menunjukkan nilai jeda 0.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag FROM pg_stat_replication;'
  3. Untuk mempromosikan cluster sekunder menjadi cluster utama, ikuti langkah-langkah berikut:

    1. Untuk mengonversi cluster database sekunder AlloyDB Omni menjadi cluster database utama, perbarui manifes replikasinya di cluster Kubernetes Anda di pusat data sekunder sebagai berikut:

      apiVersion: v1
      kind: Secret
      metadata:
        name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME
        namespace: SECONDARY_DB_CLUSTER_NAMESPACE
      type: Opaque
      data:
        rep-user-pw: "ENCODED_PASSWORD"
      ---
      apiVersion: alloydbomni.dbadmin.goog/v1
      kind: Replication
      metadata:
        name: SECONDARY_REPLICATION_NAME
        namespace: SECONDARY_DB_CLUSTER_NAMESPACE
      spec:
        dbcluster:
          name: SECONDARY_DB_CLUSTER_NAME
        upstream:
          password:
            name: ha-rep-pw-SECONDARY_DB_CLUSTER_NAME

      Ganti SECONDARY_DB_CLUSTER_NAME, yang merupakan nama cluster database sekunder Anda—misalnya, dbc-2.

      Tunggu hingga status replikasi siap.

    2. Untuk mendapatkan informasi koneksi upstream untuk replikasi, jalankan perintah berikut:

      kubectl get replication SECONDARY_REPLICATION_NAME
      kubectl get replication SECONDARY_REPLICATION_NAME -o json | jq .status.upstream

      Contoh output terlihat mirip dengan berikut ini:

        {
          "host": "34.23.207.137",
          "password": {
            "name": "ha-rep-pw-dbc-2"
          },
          "port": 5432,
          "replicationSlotName": "dbc_2_replication_2",
          "username": "alloydbreplica"
        }
      
    3. Untuk mengonversi cluster database utama AlloyDB Omni menjadi cluster database sekunder, perbarui manifes replikasinya di cluster Kubernetes Anda di pusat data utama seperti berikut:

      apiVersion: v1
      kind: Secret
      metadata:
        name: ha-rep-pw-DB_CLUSTER_NAME
      type: Opaque
      data:
        rep-user-pw: "ENCODED_PASSWORD"
      ---
      apiVersion: alloydbomni.dbadmin.goog/v1
      kind: Replication
      metadata:
        name: REPLICATION_NAME
      spec:
        dbcluster:
          name: DB_CLUSTER_NAME
        downstream:
          host: SECONDARY_HOST
          port: SECONDARY_PORT
          username: alloydbreplica
          password:
            name: ha-rep-pw-DB_CLUSTER_NAME
          replicationSlotName: SECONDARY_REPLICATION_SLOT
          control: rewind

      Tunggu hingga status replikasi menjadi siap dan responsif.

    4. Untuk memverifikasi status replikasi, jalankan perintah berikut:

      kubectl get replication REPLICATION_NAME

Melakukan pemulihan dari bencana (disaster recovery) yang tidak direncanakan

Jika Anda mengalami failover DR, ikuti langkah-langkah berikut:

  1. Untuk mengonversi cluster database sekunder AlloyDB Omni menjadi cluster database utama, perbarui manifes replikasi cluster tersebut di cluster Kubernetes Anda di pusat data sekunder. Untuk mengetahui informasi selengkapnya, lihat Langkah 3a. di Melakukan pengalihan.
  2. Untuk mengonversi cluster database utama sebelumnya menjadi cluster database sekunder yang mereplikasi dari database utama baru (pembalikan peran), tunggu hingga database utama asli tersedia. Gunakan kontrol rewind dalam konfigurasi replikasi downstream untuk menentukan apakah konversi berfungsi seperti yang diharapkan. Jika Anda mengalami masalah, gunakan kontrol setup.