Bagaimana cara mereplikasi hanya INSERT bukan DELETE/UPDATE di Slony Slave Node?

Untuk memenuhi persyaratan ini, kita harus membuat beberapa jenis filter seperti TRIGGER/ATURAN pada Slave Node sehingga menghindari menyampaikan pernyataan DELETE dan UPDATE. Karena kita berurusan dengan Slony-I, ia tidak memiliki mekanisme bawaan untuk memfilter DML saat memutar ulangnya di node slave meskipun telah mengumpulkan semua peristiwa dari node Master. (AFAIK Mysql,Oracle,SQL Server mendukung filter ).

Untuk meluruskan ini, cara tradisional Slony-I mempertahankan keunikan baris di semua node dengan konsep inti tabel harus memiliki kunci utama. Dalam desain arsitektur seperti itu, sulit untuk mengecualikan pernyataan DELETE/UPDATE, ambil contoh kolom primary key “orderid” dari tabel “orders” memiliki pernyataan INSERT pertama dengan nilai 100 dan telah direplikasi sebagai bentuk pertama pada Slave Node yang difilter. Kemudian pernyataan DELETE dieksekusi untuk “orderid=100” dan baris yang dihapus, sekarang jika ada pernyataan INSERT atau UPDATE yang mencoba menggunakan “orderid=100” maka node Slave terkena dengan pelanggaran kunci duplikat dan dengan mudah mematahkan replikasi.

ERROR:  duplicate key value violates unique constraint "reptest_pkey"
DETAIL:  Key (id)=(2) already exists.
CONTEXT:  SQL statement "INSERT INTO "public"."reptest" ("id", "name") VALUES ($1, $2);"
.....
or
....
CONTEXT:  SQL statement "UPDATE ONLY "public"."reptest" SET "id" = $1 WHERE "id" = $2;"
2014-11-17 23:18:53 PST ERROR  remoteWorkerThread_1: SYNC aborted

Dengan demikian, penerapan aturan bukan merupakan masalah, tetapi seseorang harus sangat berhati-hati saat diterapkan. Namun pada kenyataannya menerapkan filter ini pada node budak Slony-I sangat rapuh, terutama aplikasi/pengembang harus selalu mengingat hal ini setiap entri duplikat baris oleh INSERT OR UPDATE dapat merusak replikasi.

Karena aturan DML tidak mungkin dilakukan sendirian dengan Slony-I, kita dapat menggunakan PostgreSQL CREATE RULE…ON DELETE/ON UPDATE DO INSTEAD NOTHING dan terapkan RULE itu di atas tabel dengan ALTER TABLE…ENABLE REPLICA RULE untuk membatalkan pernyataan DELETE/UPDATE. Menggunakan opsi ini membutuhkan banyak disiplin, sehingga Anda dapat memastikan aplikasi dan anggota staf Anda benar-benar mengikuti aturan ini.

Untuk melanjutkan langkah-langkah, Anda harus memiliki pengaturan slony, jika Anda perlu mengatur Anda dapat merujuk ke posting saya sebelumnya di sini.

Langkah-langkah pada Slave Node (Master DB:postgres, Slave DB:demo, Port:5432):

1. Hentikan daemon slon
2. Buat aturan ON DELETE dan ON UPDATE DO INSTEAD NOTHING

demo=# CREATE RULE void_delete AS ON DELETE TO reptest DO INSTEAD NOTHING;
CREATE RULE
demo=# CREATE RULE void_update AS ON UPDATE TO reptest DO INSTEAD NOTHING;
CREATE RULE

3. Terapkan RULE di atas meja

demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_delete;
ALTER TABLE
demo=# ALTER TABLE reptest ENABLE REPLICA RULE void_update ;
ALTER TABLE

4. Mulai daemon Slon

Sekarang, Anda dapat melihat di bawah bahwa UPDATE/DELETE tidak berdampak pada Slave Node:

postgres=# delete from reptest where id =2;
DELETE 1
postgres=# update reptest set id=2 where id=1;
UPDATE 1

--On Master
postgres=# select * from reptest ;
 id |    name
----+------------
  2 | A
(1 row)

--On Slave
demo=# select * from reptest ;
 id |    name
----+------------
  1 | A
  2 | C
(2 rows)

Jika pernyataan INSERT dieksekusi dengan nilai 1 maka akan memutus replikasi. Perhatikan…!!

Ingat, ada cara lain untuk memenuhi permintaan ini seperti dblinks, Pemicu seperti BEFORE DELETE…mengembalikan nilai NULL dari fungsi, tapi saya yakin cara yang paling efisien adalah menggunakan RULE/ENABLE REPLICA RULE saat Anda bekerja dengan replikasi Slony.

Saat ini Anda mungkin telah membaca banyak blog tentang fitur baru slot Replikasi Decoding Logis di PostgreSQL 9.4, berharap di masa mendatang fitur ini dapat menyertakan konsep filter DML pada Slave.

Terima kasih telah berkunjung.