Perintah dan konteks
Publisher PostgreSQL 18 harus mereplikasi tenant dan kolom terpilih ke subscriber yang digunakan untuk pelaporan dan layanan regional. Jelaskan semantik row-filter dan column-list, apa yang terjadi ketika sebuah UPDATE melintasi batas filter, sinkronisasi awal, perilaku partisi, dan rencana operasi yang aman.
Dokumentasi PostgreSQL menyatakan bahwa row filter menentukan sebelum publikasi apakah suatu baris memenuhi ekspresi, sedangkan column list membatasi kolom yang ditransmisikan tetapi bukan merupakan batasan keamanan. Wawancara ini menguji semantik replikasi, konsistensi, dan tata kelola perubahan alih-alih sekadar menambahkan klausa WHERE ke dalam publikasi.
Apa yang sedang diuji oleh pewawancara
Anda harus menjelaskan bahwa role koneksi replikasi mengevaluasi filter, false atau NULL menyembunyikan (suppress) baris, dan TRUNCATE tidak terpengaruh. Anda harus menjabarkan transformasi UPDATE lama/baru, menangani replica identity, sinkronisasi awal, filter gabungan OR di seluruh publikasi, root partisi, dan evolusi column list, serta menyadari bahwa column list tidak menyediakan kerahasiaan.
Pertanyaan untuk diklarifikasi terlebih dahulu
Target replikasi
Konfirmasikan tenant, operasi, dan kolom yang dibutuhkan oleh subscriber, apakah snapshot awal diizinkan, apakah operasi penulisan bersifat dua arah (bidirectional), dan apakah subscriber menggunakan versi yang lebih lama dari versi 15 atau 18.
Identitas dan pemfilteran
Konfirmasikan replica identity tabel, apakah kolom filter dapat berubah, apakah publikasi root partisi digunakan, dan apakah ada beberapa publikasi yang mencakup tabel yang sama.
Keamanan dan pemulihan
Konfirmasikan apakah kolom sensitif harus benar-benar tidak terlihat, izin role replikasi, isolasi jaringan, prosedur pembangunan ulang (rebuild) subscription, dan batas waktu rollback untuk filter yang keliru.
Jawaban 30 detik
"Row filter menentukan perubahan baris mana yang masuk ke dalam publikasi; false atau NULL membuang perubahan tersebut, sedangkan column list hanya mengurangi kolom yang ditransmisikan dan bukan merupakan batasan keamanan. Sebuah UPDATE mengevaluasi baris lama dan baru: tidak cocok ke cocok menjadi INSERT, cocok ke tidak cocok menjadi DELETE, dan hanya cocok ke cocok yang tetap menjadi UPDATE. Untuk UPDATE atau DELETE, filter dan kolom yang dipublikasikan harus mencakup replica identity. Sebelum peluncuran, saya akan membekukan perubahan publikasi, menguji sinkronisasi awal, partisi, filter gabungan OR, dan perilaku versi lama, sambil melindungi data sensitif dengan hak akses dan view di sisi publisher."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan invarian publikasi
Catat set tenant yang diizinkan, operasi, set kolom, ekspresi filter, dan versi subscriber untuk setiap tabel. Tentukan apakah tujuannya adalah pemangkasan performa, isolasi perilaku, atau keamanan; tujuan keamanan tidak dapat hanya mengandalkan column list saja.
Langkah 2: Rancang row filter
Filter berjalan sebelum publikasi menggunakan role dari koneksi replikasi dan hanya menggunakan ekspresi sederhana yang terdokumentasi. Hasil false atau NULL menyembunyikan baris, dan TRUNCATE tidak terpengaruh. Untuk publikasi yang berisi UPDATE atau DELETE, kolom filter harus dicakup oleh replica identity; publikasi yang hanya berisi INSERT dapat menggunakan kolom lain.
Langkah 3: Jabarkan transformasi UPDATE
Evaluasi filter sebelum dan sesudah pembaruan. Cocok-ke-cocok mengirimkan UPDATE; tidak cocok-ke-tidak cocok tidak mengirimkan apa pun; tidak cocok-ke-cocok mengirimkan INSERT; cocok-ke-tidak cocok mengirimkan DELETE. Oleh karena itu, subscriber merepresentasikan kumpulan baris saat ini yang memenuhi filter alih-alih memutar ulang (replay) setiap UPDATE secara membabi buta.
Langkah 4: Batasi column list
Column list harus mencakup kolom replica identity, dan tabel subscriber harus berisi setidaknya kolom yang dipublikasikan. Urutan daftar tidak memengaruhi replikasi. Mengabaikan daftar akan secara otomatis menyertakan kolom yang ditambahkan nanti; menyebutkan semua kolom saat ini secara eksplisit tidak menyertakan kolom di masa mendatang. Daftar yang berbeda untuk tabel yang sama di seluruh publikasi dapat mencegah subscription untuk dilanjutkan kembali, jadi tinjau daftar tersebut sebelum melakukan perubahan.
CREATE PUBLICATION tenant_eu
FOR TABLE orders (order_id, tenant_id, status, total)
WHERE (tenant_id = 'eu');Langkah 5: Tangani sinkronisasi awal
Sinkronisasi awal menyalin baris yang ada yang memenuhi row filter dan hanya kolom yang ada di dalam daftar. Subscriber yang lebih lama dari versi 15 dapat menyalin seluruh tabel, dan versi yang lebih lama dari 18 memiliki batasan tambahan pada generated column. Periksa matriks versi dan backlog penulisan selama snapshot sebelum mengalihkan lalu lintas (traffic).
Langkah 6: Tangani partisi dan beberapa publikasi
Dengan publish_via_partition_root=true, filter atau column list dari root partitioned table digunakan; dengan pengaturan default false, definisi dari masing-masing partisi digunakan. Row filter untuk tabel dan operasi publikasi yang sama di seluruh publikasi digabungkan dengan operasi OR. Oleh karena itu, publikasi tanpa filter dapat menggagalkan pemangkasan yang diharapkan dari filter lainnya.
Langkah 7: Tambahkan pengaman operasional
Tinjau definisi publikasi sebagai migrasi, dan catat rasio hit filter, lag replikasi, konflik, jumlah baris sinkronisasi awal, dan versi aturan. Uji kasus batas lama/baru pada subscription bayangan (shadow subscription). Jika ada baris yang bocor atau menghilang, jeda subscription, perbaiki publikasi, dan bangun ulang setelah pemeriksaan konsistensi.
Jawaban model
Saya akan memperlakukan row filter sebagai definisi kumpulan data yang dipublikasikan dan column list sebagai pemangkasan transmisi. Role replikasi mengevaluasi filter, sehingga false/NULL dan TRUNCATE memerlukan pengujian eksplisit. UPDATE membandingkan baris lama dan baru serta berubah menjadi INSERT atau DELETE saat melintasi batas; untuk UPDATE/DELETE, filter dan kolom yang dipublikasikan harus mencakup replica identity. Sinkronisasi awal, root partisi, dan publikasi gabungan OR termasuk dalam matriks pengujian. Lindungi data sensitif dengan hak akses publisher, view, atau pipeline redaksi terpisah; gunakan column list untuk performa dan kontrol struktur data.
Kesalahan umum
- Kesalahan: Mengasumsikan bahwa column list mencegah subscriber jahat mendapatkan kolom yang tidak dipublikasikan. → Mengapa ini gagal: Dokumentasi resmi menyatakan bahwa ini bukan mekanisme keamanan. → Perbaikan: Terapkan kerahasiaan dengan hak akses publisher, view, atau redaksi.
- Kesalahan: Mengevaluasi UPDATE hanya pada baris baru. → Mengapa ini gagal: Baris dapat keluar dari atau masuk ke dalam kumpulan yang difilter. → Perbaikan: Evaluasi baris lama dan baru serta terapkan keempat hasil yang mungkin terjadi.
- Kesalahan: Mengabaikan replica identity. → Mengapa ini gagal: UPDATE/DELETE tidak dapat menemukan baris lama dengan aman. → Perbaikan: Periksa cakupan identitas pada filter dan column list.
- Kesalahan: Mengasumsikan beberapa publikasi sempit berarti total aliran data menjadi sempit. → Mengapa ini gagal: Filter untuk operasi publikasi yang sama digabungkan dengan OR. → Perbaikan: Hitung union-nya dan tolak cakupan tanpa filter.
Pertanyaan lanjutan dan tanggapan
Kapan sebaiknya Anda menggunakan row filter dibandingkan dengan publikasi terpisah?
Gunakan row filter ketika batasan tenant atau wilayah bersifat stabil dan ekspresinya sederhana. Publikasi dan subscription terpisah lebih mudah diaudit ketika izin, siklus hidup, dan kepemilikan operasional berbeda. Dalam kedua kasus tersebut, evaluasi biaya sinkronisasi awal dan perubahan.
Bagaimana cara mencegah replikasi kolom baru yang tidak disengaja?
Gunakan column list yang eksplisit dan perbarui melalui peninjauan skema. Jangan samakan menyebutkan setiap kolom saat ini secara eksplisit dengan mengabaikan daftar; pengabaian daftar secara otomatis menyertakan kolom di masa mendatang.
Bagaimana cara menguji UPDATE yang melintasi batas?
Buat empat kasus: lama false/baru true, lama true/baru false, keduanya true, dan keduanya false. Verifikasikan masing-masing menghasilkan INSERT, DELETE, UPDATE, dan tidak ada event pada subscriber.
Bisakah pemfilteran menggantikan isolasi keamanan multi-tenant?
Tidak. Ini hanya memilih data replikasi logis; isolasi tetap memerlukan role publisher dengan hak akses paling rendah (least-privilege), kredensial terpisah, kontrol jaringan, dan redaksi jika diperlukan.