Fehler in der Replikation

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

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

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 :wink:

Andreas

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

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…