Halaman ini diterjemahkan oleh Cloud Translation API.

Switchover dan failover dengan replikasi pglogical

Pilih versi dokumentasi:

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

Sebelum memulai

Setelah replikasi pglogical disiapkan dan ada solusi ketersediaan tinggi (HA) dan pemulihan bencana (DR) yang layak, serta 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 mengetahui informasi tentang replikasi data menggunakan pglogical, lihat Mereplikasi data antara AlloyDB untuk PostgreSQL dan AlloyDB Omni dan Mereplikasi data antara AlloyDB Omni dan database lain.

Pengalihan 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 mencapainya dalam konfigurasi replikasi satu arah, Anda harus menyiapkan hubungan penyedia/pelanggan baru dan menghapus hubungan penyedia/pelanggan lama.

Buat 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, replikasi sudah terbaru dan database siap untuk pengalihan.

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

Mengonversi database pelanggan menjadi 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 akan 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 replikasi 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 yang 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 menyebabkan kehilangan data. Jika ada perubahan data yang belum direplikasi pada 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 Anda menginginkan replikasi satu arah, 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 melakukan pengalihan tanpa menimbulkan 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 mengabaikan data masuk yang bertentangan dan membatalkan 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 di kedua arah. Pelanggan asli juga menjadi penyedia dengan set replikasi yang sama seperti penyedia asli. Lihat Membuat tabel dan menambahkannya ke set replikasi default di database penyedia AlloyDB for PostgreSQL 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 parameter synchronize_data untuk perintah pglogical.create_subscription disetel ke false. Tindakan ini menghindari penyalinan data tabel awal.

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 di-failover, Anda harus menonaktifkan langganan. Hal ini memastikan bahwa perubahan dari penyedia yang dipulihkan tidak diterapkan secara keliru saat penyedia tersedia kembali.

Hentikan pelanggan, test_sub_1:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Periksa apakah status disetel ke disabled:

SELECT pglogical.show_subscription_status('test_sub_1');