Hot Standby -->Ausschluß von Tabellen in der Replication

Konfiguration des PostgreSQL Datenbankservers.
The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Mi 21. Feb 2018, 16:18

Hallo Zusammen

Leider bin ich totaler Anfänger bezüglich PostgreSQL.
Ich habe eine Wissenslücke bezüglich des Ausschlusses von Tabellen in der Hot Standby Replication.

Ich habe erfolgreiche einen Master bzw. Slave eingerichtet (beide auf DEBIAN 9.3 und Posgresql 9.6)
Die Systemdatenbank und meine Applikation Datenbank werden erfolgreich synchronisiert. (hoffe ich :))


Nun möchte ich aber mehrere Tabellen der Applikation Datenbank ausschließen.
Um später die ReadOnly Beschränkung auf diese Tabellen (auf dem Slave) wieder aufzuheben.

Wie gehen ich es an:
- kann ich eine Art Filter bauen
- wo hinterlege ich diesen Filter
- und wie hebe ich die ReadOnly Beschränkung richtig wieder auf

Über Tipps würde ich mich sehr freuen, leider konnte ich nichts Konkretes finden.

Sonnige Grüße ins Forum

akretschmer
Erfahrener Benutzer
Beiträge: 7513
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von akretschmer » Mi 21. Feb 2018, 16:28

Das geht nicht native. Das geht ab 9.4 und pg_logical sowie ab 10 direct in-core mit logical replication.
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Do 22. Feb 2018, 09:54

Hallo
Danke für die schnelle Antwort.
Scheint aber nicht so einfach zu sein.
Konnte bis jetzt auch nur die Seite von 2ndquadrant finden.
Hat jemand noch eine anderen Link der pg_logical dokumentiert.

Oder ist ein upgrade auf 10 vielleicht die schnellere Lösung???

castorp
Erfahrener Benutzer
Beiträge: 1070
Registriert: Sa 27. Jun 2009, 22:24
Wohnort: Bayern

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von castorp » Do 22. Feb 2018, 10:09

The2Zlives hat geschrieben:
Do 22. Feb 2018, 09:54
Oder ist ein upgrade auf 10 vielleicht die schnellere Lösung???
Mit Sicherheit
A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

akretschmer
Erfahrener Benutzer
Beiträge: 7513
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von akretschmer » Do 22. Feb 2018, 10:12

The2Zlives hat geschrieben:
Do 22. Feb 2018, 09:54

Konnte bis jetzt auch nur die Seite von 2ndquadrant finden.
Wenig verwunderlich ;-)
Oder ist ein upgrade auf 10 vielleicht die schnellere Lösung???
Ja.
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Do 22. Feb 2018, 10:17

akretschmer hat geschrieben:
Do 22. Feb 2018, 10:12
Wenig verwunderlich ;-)
Ich weiß :)
akretschmer hat geschrieben:
Do 22. Feb 2018, 10:12
Ja.
OK Danke. :)

The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Di 27. Feb 2018, 12:17

Hallo
Nach den kurzen aber aussagekräftigen Beiträgen.
Habe ich mich entschieden auf 10.2 upzugraden um eine Logical Replication durch zu führen.

Natürlich funktioniert es nicht so wie von mir erwartet. :mad:

Was Habe ich gemacht:

Master Datenbank Server
- PUBLICATION zabbixpub eingerichtet in meiner Applikations-Datenbank
CREATE PUBLICATION zabbixpub FOR ALL TABLES WITH (publish = 'insert');

Slave Datenbank Server
- Alle Datenbanken vom Master auf den Slave kopiert mit:
pg_basebackup -h 254.198.61.26 -U postgres -D /var/lib/postgresql/10/main -P -X fetch

- Datenbank Service gestartet (ohne Fehler)
und die PUBLICATION wieder gelöscht

- SUBSCRIPTION zabbixsub eingerichtet in meiner Applikations-Datenbank
CREATE SUBSCRIPTION zabbixsub CONNECTION 'host=254.198.61.26 port=5432 user=postgres password=XYZ dbname=zabbix' PUBLICATION zabbixpub;


Es scheint aber das ich der SUBSCRIPTION nicht die richtigen Parametern übergeben habe, siehe Log Slave Datenbank Server:

2018-02-27 11:39:07.226 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 16856 (PID 288$
2018-02-27 11:39:07.240 CET [28890] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $
2018-02-27 11:39:07.249 CET [28889] ERROR: duplicate key value violates unique constraint "item_condition_pkey"
2018-02-27 11:39:07.249 CET [28889] DETAIL: Key (item_conditionid)=(1) already exists.
2018-02-27 11:39:07.249 CET [28889] CONTEXT: COPY item_condition, line 1
2018-02-27 11:39:07.256 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 17838 (PID 288$
2018-02-27 11:39:07.274 CET [28891] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $
2018-02-27 11:39:07.290 CET [28890] ERROR: duplicate key value violates unique constraint "operations_pkey"
2018-02-27 11:39:07.290 CET [28890] DETAIL: Key (operationid)=(1) already exists.
2018-02-27 11:39:07.290 CET [28890] CONTEXT: COPY operations, line 1
2018-02-27 11:39:07.296 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 16845 (PID 288$
2018-02-27 11:39:07.314 CET [28892] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $
2018-02-27 11:39:07.326 CET [28891] ERROR: duplicate key value violates unique constraint "opgroup_pkey"
2018-02-27 11:39:07.326 CET [28891] DETAIL: Key (opgroupid)=(1) already exists.
2018-02-27 11:39:07.326 CET [28891] CONTEXT: COPY opgroup, line 1
2018-02-27 11:39:07.333 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 16914 (PID 288$
2018-02-27 11:39:07.349 CET [28893] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $
2018-02-27 11:39:07.374 CET [28892] ERROR: duplicate key value violates unique constraint "items_applications_pkey"
2018-02-27 11:39:07.374 CET [28892] DETAIL: Key (itemappid)=(4653) already exists.
2018-02-27 11:39:07.374 CET [28892] CONTEXT: COPY items_applications, line 1
2018-02-27 11:39:07.382 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 17144 (PID 288$
2018-02-27 11:39:07.402 CET [28893] ERROR: duplicate key value violates unique constraint "optemplate_pkey"
2018-02-27 11:39:07.402 CET [28893] DETAIL: Key (optemplateid)=(1) already exists.
2018-02-27 11:39:07.402 CET [28893] CONTEXT: COPY optemplate, line 1
2018-02-27 11:39:07.408 CET [20888] LOG: worker process: logical replication worker for subscription 18809 sync 16921 (PID 288$
2018-02-27 11:39:08.420 CET [28894] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $
2018-02-27 11:39:08.439 CET [28895] LOG: logical replication table synchronization worker for subscription "zabbixsub", table $

Jetzt möchte ich natürlich die Synchronisation wieder herstellen.
Mit welchen Parameter müsste ich meine Aufrufe ausführen?
Oder war mein erster Arbeitsschritt schon falsch? Wie kann ich die vorherigen Werte überschreiben?

Verzweifelte, sonnige Grüße aus dem Norden

akretschmer
Erfahrener Benutzer
Beiträge: 7513
Registriert: So 29. Okt 2006, 13:35
Wohnort: Kaufbach, Sachsen, Germany, Germany
Kontaktdaten:

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von akretschmer » Di 27. Feb 2018, 12:39

Dein Vorgehen ist falsch. Lösche die DB vom Standby, mache auf dem Master einen Schema-Only-Dump (also keine Daten, nur die CREATE TABLE-Sachen etc) und richte die logische Replikation neu ein.

Warum?

Im ersten Step der logischen Replikation werden die Inhalte der Tabellen via COPY übertragen. Es gibt IMHO auch noch die Option, diesen Schritt zu übergehen, schau mal in die Doku, no-data-sync oder so.

(bin grad knapp mit der Zeit, sitze bei einem Kunden in Berlin ...)
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Di 27. Feb 2018, 12:45

Hey
Super vielen lieben Dank akretschmer.
Hab jetzt wieder was zum Nachdenken das reicht mir erst mal.

The2Zlives
Neuer Benutzer
Beiträge: 7
Registriert: Mi 21. Feb 2018, 15:45

Re: Hot Standby -->Ausschluß von Tabellen in der Replication

Beitrag von The2Zlives » Di 27. Feb 2018, 16:29

Hallo

Habe es jetzt mit einem Dump probiert:

Was Habe ich gemacht:

Master Datenbank Server
- DROP PUBLICATION zabbixpub ;
- Überprüft das kein Slot mehr aktiv war
- pg_dump zabbix -s > dump_zabbix_db.sql
- PUBLICATION zabbixpub eingerichtet in meiner Applikations-Datenbank
CREATE PUBLICATION zabbixpub FOR ALL TABLES;

Slave Datenbank Server
- Alte Datenbank gelöscht und neu erstellt
- Den Dump eingefahren (ohne Fehlermeldung)
- CREATE SUBSCRIPTION zabbixsub CONNECTION 'host=254.198.61.26 port=5432 user=postgres password=XYZ dbname=zabbix' PUBLICATION zabbixpub;


Die Instanz auf dem Slave funktionierte einwandfrei bis ich auf dem Master mit der Applikation was geändert habe :
2018-02-27 15:56:50.809 CET [7714] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.825 CET [7716] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.835 CET [7715] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.852 CET [7717] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.868 CET [7716] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.884 CET [7718] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.894 CET [7717] LOG: logical replication table synchronization w$
2018-02-27 15:56:50.924 CET [7718] LOG: logical replication table synchronization w$
2018-02-27 15:57:28.272 CET [7605] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:28.272 CET [7605] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:28.280 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:28.283 CET [7735] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:28.309 CET [7735] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:28.309 CET [7735] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:28.314 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:33.328 CET [7736] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:33.354 CET [7736] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:33.354 CET [7736] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:33.359 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:38.373 CET [7738] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:38.400 CET [7738] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:38.400 CET [7738] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:38.405 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:43.419 CET [7739] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:43.441 CET [7739] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:43.441 CET [7739] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:43.446 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:48.458 CET [7743] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:48.485 CET [7743] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:48.485 CET [7743] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:48.490 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:53.504 CET [7745] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:53.531 CET [7745] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:53.531 CET [7745] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:53.537 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:57:58.555 CET [7760] LOG: logical replication apply worker for subscr$
2018-02-27 15:57:58.590 CET [7760] ERROR: duplicate key value violates unique const$
2018-02-27 15:57:58.590 CET [7760] DETAIL: Key (auditid)=(15) already exists.
2018-02-27 15:57:58.598 CET [6641] LOG: worker process: logical replication worker $
2018-02-27 15:58:03.613 CET [7762] LOG: logical replication apply worker for subscr$
2018-02-27 15:58:03.642 CET [7762] ERROR: duplicate key value violates unique const$

Was meinst du damit genau:
Es gibt IMHO auch noch die Option, diesen Schritt zu übergehen, schau mal in die Doku, no-data-sync oder so.
Woran könnte ich noch drehen? :mad:

Schönen Abend.

Antworten