Fehler in der Replikation

Konfiguration des PostgreSQL Datenbankservers.
Antworten
minimike
Benutzer
Beiträge: 52
Registriert: Mo 1. Mär 2010, 22:46

Fehler in der Replikation

Beitrag von minimike »

Hi

Ich habe die Tage zum ersten Mal einen Replication-Cluster aufgesetzt. Zwei mal RHEL 6.4 mit PostgreSQL 9.1- Der Master ist Echtblech und der Slave ist eine VM. Ich bekomme jetzt aber auf dem Slave folgende Meldungen in den Logs

Code: Alles auswählen

Oct 31 19:19:49 pg-replication postgres[30439]: [2-3] 2013-10-31 19:19:49 CET [30439]: [3-1] STATEMENT:  COPY public.jiraaction (id, issueid, author, actiontype, actionlevel, rolelevel, actionbody, created, updateauthor, updated, actionnum) TO stdout;
Oct 31 19:21:42 pg-replication postgres[30636]: [2-1] 2013-10-31 19:21:42 CET [30636]: [1-1] ERROR:  canceling statement due to conflict with recovery
Oct 31 19:21:42 pg-replication postgres[30636]: [2-2] 2013-10-31 19:21:42 CET [30636]: [2-1] DETAIL:  User query might have needed to see row versions that must be removed.
Oct 31 19:21:42 pg-replication postgres[30636]: [2-3] 2013-10-31 19:21:42 CET [30636]: [3-1] STATEMENT:  COPY public.changeitem (id, groupid, fieldtype, field, oldvalue, oldstring, newvalue, newstring) TO stdout;
Oct 31 19:27:45 pg-replication postgres[31226]: [2-1] 2013-10-31 19:27:45 CET [31226]: [1-1] ERROR:  canceling statement due to conflict with recovery
Oct 31 19:27:45 pg-replication postgres[31226]: [2-2] 2013-10-31 19:27:45 CET [31226]: [2-1] DETAIL:  User query might have needed to see row versions that must be removed.
Oct 31 19:27:45 pg-replication postgres[31226]: [2-3] 2013-10-31 19:27:45 CET [31226]: [3-1] STATEMENT:  COPY public.jiraaction (id, issueid, author, actiontype, actionlevel, rolelevel, actionbody, created, updateauthor, updated, actionnum) TO stdout;
Oct 31 19:27:46 pg-replication postgres[31232]: [2-1] 2013-10-31 19:27:46 CET [31232]: [1-1] ERROR:  canceling statement due to conflict with recovery
Oct 31 19:27:46 pg-replication postgres[31232]: [2-2] 2013-10-31 19:27:46 CET [31232]: [2-1] DETAIL:  User query might have needed to see row versions that must be removed.
Oct 31 19:27:46 pg-replication postgres[31232]: [2-3] 2013-10-31 19:27:46 CET [31232]: [3-1] STATEMENT:  COPY public.bodycontent (bodycontentid, body, contentid, bodytypeid) TO stdout;
Oct 31 19:27:46 pg-replication postgres[31248]: [2-1] 2013-10-31 19:27:46 CET [31248]: [1-1] FATAL:  terminating connection due to conflict with recovery
Oct 31 19:27:46 pg-replication postgres[31248]: [2-2] 2013-10-31 19:27:46 CET [31248]: [2-1] DETAIL:  User query might have needed to see row versions that must be removed.
Oct 31 19:27:46 pg-replication postgres[31248]: [2-3] 2013-10-31 19:27:46 CET [31248]: [3-1] HINT:  In a moment you should be able to reconnect to the database and repeat your command.


Frage kann ich jetzt davon ausgehen das die Daten auf dem Slave nun Müll sind? Und wie könnte ich das optimieren? So das es nicht mehr auftritt

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

Re: Fehler in der Replikation

Beitrag von akretschmer »

minimike hat geschrieben:Hi

Ich habe die Tage zum ersten Mal einen Replication-Cluster aufgesetzt. Zwei mal RHEL 6.4 mit PostgreSQL 9.1- Der Master ist Echtblech und der Slave ist eine VM. Ich bekomme jetzt aber auf dem Slave folgende Meldungen in den Logs

Frage kann ich jetzt davon ausgehen das die Daten auf dem Slave nun Müll sind? Und wie könnte ich das optimieren? So das es nicht mehr auftritt


Nein, sind sie nicht. Die Daten sind konsistent. In dem Fall: sogar zu konsistent...


Das Problem ist:

- auf dem master läuft ein Vacuum, welches Rows, die auf dem Master gelöscht sind, dann auch wirklich löscht
- das wird auf den Slave repliziert, auch dort werden die Rows gelöscht
- dummerweise laufen aber auf dem Slave noch Transaktionen, welche die Rows, die inzwischen gelöscht wurden, noch sehen wollen

Es gibt keinen Mechanismus, welcher vom Slave zum Master sagt: halt, auch wenn das schon gelöscht ist, mir egal, ich will das noch sehen.

Was Du machen kannst: vacuum_defer_cleanup_age hochsetzen. Dazu aber bitte auch die Doku lesen. Aber das hilft, eigene Erfahrung bei einem Kunden, der nächste Woche zur pgconf.de einen Vortrag (vielleicht auch darüber?) halten wird ;-)

Andreas

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

Re: Fehler in der Replikation

Beitrag von akretschmer »

akretschmer hat geschrieben:
minimike hat geschrieben:Was Du machen kannst: vacuum_defer_cleanup_age hochsetzen. Dazu aber bitte auch die Doku lesen. Aber das hilft, eigene Erfahrung bei einem Kunden, der nächste Woche zur pgconf.de einen Vortrag (vielleicht auch darüber?) halten wird ;-)

Andreas


Nachtrag: keine eigene Erfahrung habe ich mit hot_standby_feedback, das wäre aber auch noch ein Kandidat.

minimike
Benutzer
Beiträge: 52
Registriert: Mo 1. Mär 2010, 22:46

Re: Fehler in der Replikation

Beitrag von minimike »

Besser spät als nie. Vielen lieben Dank. Ich werde das diese und nächste Woche nebenbei beheben

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

Re: Fehler in der Replikation

Beitrag von akretschmer »

minimike hat geschrieben:Besser spät als nie. Vielen lieben Dank. Ich werde das diese und nächste Woche nebenbei beheben


Berichte dann bitte. Das sind so Dinge, die schwer greifbar sind, wo man kein allgemeines Rezept hat.
Ich bin da ganz froh, daß ich (für unseren Kunden) das relativ schnell so wie geschildert beheben konnte. Aber das war auch a bissl Glück, vermutlich...

Antworten