Memantau replikasi pglogical di AlloyDB Omni

Pilih versi dokumentasi:

Halaman ini memberikan informasi tentang cara memantau dan memecahkan masalah penerapanpglogical dengan memeriksa dan memvalidasi database penyedia dan pelanggan.

Sebelum memulai

Sebelum Anda mulai memantau dan memecahkan masalah penerapan pglogical, periksa database penyedia dan pelanggan, pahami penerapan pglogical, dan validasi cara konfigurasinya.

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.

Periksa setelan parameter pglogical, replikasi, dan AlloyDB Omni

Sejumlah parameter konfigurasi memengaruhi pengoperasian ekstensi pglogical, dan Anda dapat memeriksanya di database penyedia dan pelanggan. Perhatikan bahwa nilai parameter dapat bervariasi.

  1. Menampilkan setelan saat ini dari parameter khusus pglogical:

    SELECT name,
    setting,
    source,
    short_desc
FROM pg_catalog.pg_settings
WHERE name LIKE '%pglogical%' AND name NOT LIKE '%alloydb%'
ORDER BY category, name;

  2. Tampilkan parameter terkait replikasi logis lainnya:

    SELECT name,
    setting,
    source,
    short_desc
FROM pg_catalog.pg_settings
WHERE name IN ('wal_level',
             'max_worker_processes',
             'max_replication_slots',
             'max_wal_senders',
             'shared_preload_libraries',
             'track_commit_timestamp')
ORDER BY name;

  3. Tampilkan parameter khusus AlloyDB Omni:

    SELECT name,
    setting,
    source,
    short_desc
FROM pg_catalog.pg_settings
WHERE name LIKE '%alloydb%'
ORDER BY category, name;

Mencantumkan node dalam konfigurasi

  1. Mencantumkan node lokal dan jarak jauh dalam konfigurasi replikasi pglogical:

    SELECT node_id,
    if_nodeid AS node_id,
    if_name AS node_name,
    if_dsn AS dsn
FROM pglogical.node_interface
LEFT JOIN pglogical.local_node ON (node_id = if_nodeid AND node_local_interface = if_id)
ORDER BY node_name;

    Jika kolom node_id adalah NOT NULL, berarti itu adalah node lokal.

  2. Tinjau informasi dsn secara mendetail. Informasi string koneksi yang salah atau sudah tidak berlaku dapat menyebabkan kegagalan replikasi. Untuk mengetahui informasi tentang pemecahan masalah dsn, lihat Memecahkan masalah replikasi langganan.

Periksa status langganan dan titik replikasi tabel

Status langganan selalu diverifikasi dari database pelanggan. Langganan menampilkan status initializing atau replicating". Langganan juga menampilkan status down. Untuk mengetahui informasi selengkapnya tentang status down, lihat Memecahkan masalah replikasi langganan.

  1. Mencantumkan langganan, status dan setelannya saat ini, dalam database saat ini:

    SELECT s.sub_name AS subscription_name,
    n1.node_name AS origin_name,
    n2.node_name AS target_name,
    x.status,
    sub_slot_name,
    sub_replication_sets,
    sub_forward_origins,
    sub_apply_delay,
    sub_force_text_transfer,
    sub_enabled AS enabled
FROM pglogical.subscription s,
    (SELECT subscription_name, status FROM pglogical.show_subscription_status()) AS x,
    pglogical.node n1,
    pglogical.node n2
WHERE s.sub_origin = n1.node_id
AND s.sub_target = n2.node_id
AND s.sub_name = x.subscription_name
ORDER BY s.sub_name;

    Outputnya mirip dengan hal berikut ini:

    -[ RECORD 1 ]-----------+--------------------------------------
subscription_id         | 3072625608
subscription_name       | test_sub_1
origin_name             | provider
target_name             | subscriber
status                  | replicating
sub_slot_name           | pgl_my_test_db_provider_test_sub_1
sub_replication_sets    | {default,default_insert_only,ddl_sql}
sub_forward_origins     | {all}
sub_apply_delay         | 00:00:00
sub_force_text_transfer | f
enabled                 | t
my_test_db=#

  2. Mencantumkan tabel yang saat ini direplikasi dan nomor urut log (LSN) saat ini berdasarkan langganan:

    SELECT sync_nspname||'.'||sync_relname AS table_name,
    sync_status,
    sync_statuslsn
FROM pglogical.local_sync_status
WHERE sync_relname IS NOT NULL
ORDER BY table_name;

    Outputnya mirip dengan hal berikut ini:

      table_name      | sync_status | sync_statuslsn
---------------------+-------------+----------------
public.test_table_1 | r           | 0/B891BC0
(1 row)

my_test_db=#

    Kolom sync_statuslsn menunjukkan LSN tempat tabel disinkronkan. Anda dapat membandingkannya dengan LSN di database penyedia untuk mengukur jeda replikasi.

  3. Periksa status replikasi untuk tabel tertentu:

    SELECT * FROM pglogical.show_subscription_table('test_sub_1','test_table_1');

Memverifikasi detail set replikasi di penyedia

  1. Buat daftar set replikasi saat ini di database penyedia dan periksa item yang direplikasi:

    SELECT set_name,
    node_name,
    replicate_insert,
    replicate_update,
    replicate_delete,
    replicate_truncate
FROM pglogical.replication_set
JOIN pglogical.node ON set_nodeid = node_id
ORDER BY set_name, node_name;

  2. Mencantumkan tabel dan urutan yang direplikasi:

    -- Table details:
SELECT set_name,
    set_reloid AS table_name,
    set_att_list,
    set_row_filter
FROM pglogical.replication_set
NATURAL JOIN pglogical.replication_set_table
ORDER BY set_name, table_name;

-- Sequence details:
SELECT set_name,
    set_seqoid AS sequence_name
FROM pglogical.replication_set
NATURAL JOIN pglogical.replication_set_seq
ORDER BY set_name, sequence_name;

Periksa informasi replikasi dan keterlambatan slot pada penyedia

  1. Periksa status setiap pelanggan dengan membuat tampilan pg_stat_replication di database 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;

    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

my_test_db=#

  2. Perhatikan kolom reply_delay, yang menampilkan waktu saat menerima pembaruan terakhir dari database pelanggan.

  3. Pantau jeda replikasi slot replikasi di penyedia karena pglogical membuat slot replikasi di database penyedia:

    SELECT slot_name,
    slot_type,
    database,
    active,
    COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn),0) AS restart_lag,
    COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(),confirmed_flush_lsn),0) AS confirmed_flush_lag
FROM pg_replication_slots
WHERE plugin like '%pglogical%'
ORDER BY slot_name;

    Outputnya mirip dengan hal berikut ini:

    -[ RECORD 1 ]-------+-----------------------------------
slot_name           | pgl_my_test_db_provider_test_sub_1
slot_type           | logical
database            | my_test_db
active              | t
restart_lag         | 56
confirmed_flush_lag | 0

my_test_db=#

Memecahkan masalah replikasi langganan

Langganan yang diperiksa di database pelanggan harus menunjukkan status replicating atau initializing jika langganan baru dibuat. Jika statusnya down, berarti terjadi masalah.

Status down biasanya ditampilkan setelah replikasi mencoba memulai, tetapi gagal. Hal ini disebabkan oleh masalah konektivitas yang disebabkan oleh setelan dsn, atau izin database yang tidak ada, baik di penyedia maupun pelanggan.

Gunakan Log Explorer dan periksa file log PostgreSQL di Google Cloud saat Google Cloud AlloyDB adalah salah satu endpoint, untuk mendapatkan informasi tambahan yang mungkin menunjukkan penyebab masalah. File log memberikan detail masalah, termasuk detail spesifik tentang izin yang tidak ada.

  1. Periksa log PostgreSQL di server AlloyDB Omni Anda:

    Docker 

    docker logs CONTAINER_NAME

    Ganti CONTAINER_NAME dengan nama yang Anda tetapkan ke container AlloyDB Omni saat Anda menginstalnya.

    Podman 

    podman logs CONTAINER_NAME

    Ganti CONTAINER_NAME dengan nama yang Anda tetapkan ke container AlloyDB Omni saat Anda menginstalnya.

  2. Pecahkan masalah setelan dsn dan pastikan konektivitas jaringan bukan sumber masalahnya:

    1. Salin string koneksi dsn dan coba koneksi manual menggunakan psql dan string yang sama. Jika sesi psql tidak dapat terhubung, hal ini menunjukkan hal berikut:
      • Masalah jaringan.
      • Alamat IP, nama pengguna, atau sandi salah.
      • Firewall pemblokir.
      • File pg_hba.conf cluster lain tidak dikonfigurasi dengan benar.

  3. Menyinkronkan ulang tabel jika Anda tidak ingin menghapus dan membuat ulang langganan setelah melakukan tindakan perbaikan:

    SELECT pglogical.alter_subscription_resynchronize_table(subscription_name := 'test_sub_1',relation := 'table_name');

  4. Atau, batalkan langganan Anda dan buat ulang:

    SELECT pglogical.drop_subscription(subscription_name := 'test_sub_1');

Langkah berikutnya