Halaman ini menampilkan dokumentasi untuk AlloyDB Omni versi 15.7.0.
Buka versi dokumentasi AlloyDB Omni untuk memilih versi yang berbeda.

Halaman ini diterjemahkan oleh Cloud Translation API.

Switchover dan failover dengan replikasi pglogical

Halaman ini memberikan informasi tentang cara melakukan pengalihan dan failover dengan replika pglogical.

Sebelum memulai

Setelah replikasi pglogical disiapkan dan ada solusi ketersediaan tinggi (HA) dan disaster recovery (DR) yang layak, dan menyadari bahwa replikasi logis tidak menyediakan true dan replikasi komprehensif dari semua objek database, Anda harus menguji konfigurasi ini sebelum mulai menggunakannya.

Untuk mengetahui informasi selengkapnya tentang ekstensi pglogical, lihat Tentang pglogical.

Untuk informasi tentang replikasi data menggunakan pglogical, lihat Mereplikasi data antara Google Cloud AlloyDB dan AlloyDB Omni serta Mereplikasi data antara AlloyDB Omni dan database lainnya.

Beralih dengan replikasi pglogical

Pengalihan adalah proses terkontrol yang digunakan untuk mengalihkan peran antara database penyedia dan pelanggan. Saat Anda melakukan pengalihan, peran kedua database, penyedia dan pelanggan, akan dibalik. Penyedia menjadi pelanggan dan pelanggan menjadi penyedia.

Kemampuan pengalihan ini penting untuk upgrade sistem operasi, upgrade PostgreSQL, atau pengujian failover.

Untuk mencapai hal ini dalam konfigurasi replikasi searah, Anda harus menyiapkan hubungan penyedia/pelanggan baru dan menghapus hubungan penyedia/pelanggan lama.

Membuat konfigurasi penyedia/pelanggan baru

Hentikan aplikasi agar tidak menulis ke sistem penyedia untuk mencegah perubahan database lebih lanjut, dan periksa jeda replikasi untuk memastikan semua transaksi diputar ulang di node pelanggan:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Jika semua kolom jeda menampilkan nol, berarti replikasi sudah yang terbaru dan database siap untuk beralih.

Outputnya mirip dengan hal berikut ini:

-[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

Konversikan database pelanggan ke database penyedia:
1. Hentikan langganan pelanggan yang ada.
2. Tambahkan set replikasi, jika diperlukan.
3. Tambahkan tabel yang diperlukan ke dalam kumpulan replikasi.
4. Buat langganan pelanggan baru di database pelanggan baru.
5. Alihkan aplikasi ke penyedia baru.
Hentikan langganan di database pelanggan yang ada, yang menjadi penyedia baru:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Opsional) Buat set replikasi yang cocok dengan definisi database penyedia asli. Hal ini tidak diperlukan jika Anda menggunakan set replika default:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Tambahkan tabel ke set replikasi tersebut:
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
Ganti kode berikut:
- REPLICATION_SET_NAME: Nama set replikasi.
- TABLE_NAME: Nama tabel pemilik skema. Misalnya, ARRAY['public'].`

Di database pelanggan baru, yang sebelumnya merupakan database penyedia, buat langganan baru dengan opsi synchronize_data ditetapkan ke false untuk mencegah pemuatan tabel awal:

SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

Periksa apakah langganan berfungsi di node penyedia:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Jika replikasi berfungsi, ubah string koneksi aplikasi untuk menggunakan database penyedia baru dan mulai ulang tingkat aplikasi.

Jika Anda mengubah data di node penyedia lama setelah pelanggan dihentikan, perubahan ini tidak akan direplikasi dan akan mengakibatkan hilangnya data. Jika ada perubahan data yang tidak direplikasi di database penyedia asli atau jika penyedia asli, yang merupakan pelanggan baru, tidak dalam status yang konsisten dengan database penyedia baru, yang merupakan pelanggan lama, Anda harus membuat database pelanggan baru sepenuhnya.

Menghapus penyedia dan langganan lama

Jika menginginkan replikasi searah, Anda harus menghapus konfigurasi penyedia/pelanggan lama.

Hapus langganan lama di penyedia baru:

SELECT pglogical.drop_subscription('<subscription name>')

Hapus set replikasi di pelanggan baru atau hapus semua tabel dari set replikasi:

SELECT pglogical.drop_replication_set('<replication set name>')

SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

Replikasi dua arah

Untuk beralih tanpa mengalami periode nonaktif, atau untuk memastikan tidak ada data yang hilang karena perubahan data yang tidak direncanakan, Anda harus menggunakan replikasi dua arah. Saat Anda menerapkan replikasi dua arah, pertimbangkan resolusi konflik kecuali jika kontrol ketat diterapkan untuk mencegah akses tulis ke kedua node secara bersamaan.

Anda dapat menyiapkan konfigurasi penyelesaian konflik menggunakan setelan pglogical.conflict_resolution berikut:

error: pelanggan berhenti saat konflik terdeteksi.
apply_remote: selalu menerapkan perubahan yang masuk, terlepas dari data di database pelanggan. Ini adalah setelan default.
keep_local: selalu abaikan data masuk yang bertentangan dan hapus perubahan yang bertentangan.
last_update_wins: versi data dengan stempel waktu commit terbaru adalah data yang di-commit
first_update_wins: versi data dengan stempel waktu terlama adalah data yang di-commit

Untuk menyiapkan replikasi dua arah, siapkan penyedia dan pelanggan sehingga replikasi terjadi dua arah. Pelanggan asli juga menjadi penyedia dengan kumpulan replika yang sama dengan penyedia asli. Lihat Membuat tabel dan menambahkannya ke set replikasi default di database penyedia Google Cloud AlloyDB untuk membuat set replikasi yang menduplikasi set replikasi asli di database penyedia awal.

Di penyedia asli, Anda harus menambahkan pelanggan baru. Lihat Membuat node dan langganan di database pelanggan AlloyDB Omni untuk membuat pelanggan baru yang memastikan bahwa parameter synchronize_data untuk perintah pglogical.create_subscription ditetapkan ke false. Hal ini menghindari salinan tabel awal data.

Failover dengan replikasi pglogical

Failover terjadi saat database penyedia tidak tersedia karena alasan apa pun, dan Anda harus mengalihkan aplikasi untuk menggunakan database pelanggan.

Untuk mencegah data duplikat diterapkan secara tidak sengaja ke database pelanggan yang gagal, Anda harus menonaktifkan langganan. Hal ini memastikan bahwa perubahan dari penyedia yang dipulihkan tidak diterapkan secara tidak sengaja saat penyedia tersedia lagi.

Hentikan pelanggan, test_sub_1:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Pastikan status disetel ke disabled:

SELECT pglogical.show_subscription_status('test_sub_1');