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:
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
Untuk menggunakan replikasi lintas pusat data dengan cluster database utama yang mengaktifkan ketersediaan tinggi (HA), pastikan kolom
replayReplicationSlotsOnStandbysdiaktifkan di cluster database utama:... spec: ... availability: ... replayReplicationSlotsOnStandbys: true
Mengaktifkan kolom ini, bersama dengan
logReplicationSlotsyang 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.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 adalahalloydbreplica.REPLICATION_NAME: Nama replikasi—misalnya,replication-1.LOG_REPLICATION_SLOT: Data slot replikasi log ke file WAL. Untuk mengaktifkan opsi ini, tetapkan nilainya ketrue. Nilai defaultnya adalahfalse.
Sebaiknya aktifkan opsi
logReplicationSlotdengan cluster database utama yang mengaktifkan ketersediaan tinggi (HA) untuk memastikan replikasi dapat terus berfungsi setelah failover atau peralihan.Tunggu hingga status replikasi siap.
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" }- Catat output-nya karena Anda memerlukannya untuk mengaktifkan replikasi di cluster database sekunder pada langkah berikut.
- Buat cluster AlloyDB Omni di cluster Kubernetes di pusat data sekunder dengan konfigurasi yang identik dengan cluster database utama Anda.
- Pastikan konektivitas eksternal diaktifkan di cluster database sekunder AlloyDB Omni Anda
Jika konektivitas eksternal tidak diaktifkan, tambahkan yang berikut ke bagian spec manifesnya:
... spec: ... allowExternalIncomingTraffic: true
- 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 adalahalloydbreplica.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.
- Untuk memverifikasi bahwa cluster siap dan sehat, periksa status replikasi cluster database sekunder.
kubectl get replication SECONDARY_REPLICATION_NAME
- 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.
-
Jalankan checkpoint untuk mengosongkan memori ke disk.
psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
- Periksa latensi replikasi. Nilai latensi
0adalah yang optimal. Jika latensi lebih besar dari0, 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;'
-
Jalankan checkpoint untuk mengosongkan memori ke disk.
-
Promosikan cluster database sekunder ke cluster database utama dengan memperbarui kolom
controlmanifes replikasi cluster database sekunder kepromote. 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:
- Periksa status replikasi cluster database sekunder, untuk memverifikasi bahwa statusnya siap dan sehat.
kubectl get replication SECONDARY_REPLICATION_NAME
- 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.
-
Jalankan checkpoint untuk mengosongkan memori ke disk.
psql -h PRIMARY_HOST -U postgres -d postgres -c 'CHECKPOINT;'
-
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;'
-
Jalankan checkpoint untuk mengosongkan memori ke disk.
-
Untuk mempromosikan cluster sekunder menjadi cluster utama, ikuti langkah-langkah berikut:
-
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.
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" }-
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.
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:
- 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.
- Untuk mengonversi cluster database utama sebelumnya menjadi cluster database sekunder yang mereplikasi dari utama baru (pembalikan peran), tunggu hingga utama asli tersedia. Gunakan kontrol
rewinddalam konfigurasi replikasi downstream untuk menentukan apakah konversi berfungsi seperti yang diharapkan. Jika Anda mengalami masalah, gunakan kontrolsetupsebagai gantinya.