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 latensi rendah antara pusat data utama dan sekunder, yang sangat penting agar replikasi lintas pusat data berfungsi secara efektif.
  • Instal operator AlloyDB Omni versi terbaru 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 menampung file WAL yang diperlukan untuk replikasi ke cluster sekunder. Data apa pun yang belum direplikasi ke cluster sekunder disimpan di cluster utama sebagai file WAL. Bergantung pada kecepatan koneksi antara the primary and secondary clusters, Anda mungkin memerlukan kapasitas disk tambahan untuk this purpose.
  • Perhatikan informasi berikut tentang standby ketersediaan tinggi (HA) 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 ke 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, ikuti langkah-langkah berikut:

  1. Pastikan konektivitas eksternal diaktifkan di cluster database utama AlloyDB Omni Anda. Jika konektivitas eksternal tidak diaktifkan, tambahkan yang berikut ke bagian spec 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 HA. Konfigurasi ini membantu HA utama yang baru mempertahankan file Write-Ahead Logging (WAL) yang belum digunakan oleh cluster database sekunder setelah failover atau peralihan, 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: Data slot replikasi log 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 akan terlihat mirip seperti berikut:

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

    ...
    spec:
      ...
      allowExternalIncomingTraffic: true
  9. Untuk mengaktifkan replikasi di cluster database sekunder, terapkan manifes yang mirip dengan berikut ini ke cluster Kubernetes 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 oleh 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

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

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 siap dan sehat, 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 untuk memeriksa latensi replikasi database sekunder. Pastikan hasilnya menunjukkan latensi minimal.
    1. Jalankan checkpoint untuk mengosongkan memori ke disk.
      psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
    2. Periksa latensi replikasi. Nilai latensi 0 adalah yang optimal. Jika latensi 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 ke cluster database utama dengan memperbarui kolom control manifes replikasi cluster database sekunder ke promote. Kemudian, terapkan manifes replikasi yang diperbarui di cluster Kubernetes 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 termasuk dalam kedua pusat data sedang online dan cluster database dalam keadaan sehat.

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

  1. Periksa status replikasi cluster database sekunder, untuk memverifikasi bahwa statusnya siap dan sehat.
    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 untuk memeriksa latensi 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 latensi 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 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 akan terlihat mirip seperti berikut:

        {
          "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 di pusat data utama yang mirip dengan berikut ini:

      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 sehat.

    4. Untuk memverifikasi status replikasi, jalankan perintah berikut:

      kubectl get replication REPLICATION_NAME

Melakukan pemulihan bencana 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 di pusat data sekunder. Untuk mengetahui informasi selengkapnya, lihat Langkah 3a. di Melakukan peralihan.
  2. Untuk mengonversi cluster database utama sebelumnya menjadi cluster database sekunder yang mereplikasi dari utama baru (pembalikan peran), tunggu hingga 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 sebagai gantinya.