Re: [gelöst] Probleme Replikation aufzusetzen

Hallo

Ich versuche, Replication zum Laufen zu bekommen. Ich habe Debian 9 mit
PostreSQL 10. Ich habe zwei Knoten in einem Cluster und bin mir bewusst,
dass
dies leicht zum Deadlock des Masters führen kann und dass es sinnlos ist,
Replikation auf demselben Blech zu machen - außer es geschieht, um die
Replikation zu lernen - es sei denn, Replikation im selben Knoten
funtioniert
ohnehin nicht.

Ich bin mir nicht sicher, ob ich das Passwort in primary_conninfo
Klartext sein
muss oder dessen md5-Wert. Die Doku ist mir da nicht klar. Ich habe beides
versucht und bin zu keinem Ergebnis gekommen.

Ich konnte mit diesem Setup nicht fest stellen, dass der Standby
versucht hat,
sich mit dem Master zu verbinden.

Unten meine Konfigurationen

LG Thiemo

== Hot standby ==

/etc/postgresql/10/main2/pg_hba.conf
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5
local replication repuser peer
host replication repuser 0.0.0.1/0 md5
host replication repuser ::1/0 md5

/etc/postgresql/10/main2/postgresql.conf
wal_level = replica
max_replication_slots = 12
synchronous_standby_names = 'main,main2'
hot_standby = on
log_min_messages = debug1
log_connections = on
log_statement = 'ddl'
log_replication_commands = on
lc_messages = 'C.utf-8'

/etc/postgresql/10/main2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=localhost user=repuser port=5432 password=<md5
value or
plain text?>'

== master ==
/etc/postgresql/10/main/pg_hba.conf
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5
local replication repuser peer
host replication repuser 0.0.0.1/0 md5
host replication repuser ::1/0 md5

/etc/postgresql/10/main/postgresql.conf
wal_level = replica
archive_mode = off
max_wal_senders = 12
max_replication_slots = 12
synchronous_standby_names = 'main2,main'
hot_standby = on
wal_receiver_timeout = 60s
log_min_messages = debug1
log_connections = on
log_statement = 'ddl'
log_replication_commands = on
lc_messages = 'C.utf-8'

/etc/postgresql/10/main/recovery.conf
standby_mode = 'off'
primary_conninfo = 'host=localhost user=repuser port=5433 password=<md5
value or
plain text?>'

-- Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 28.01.2018 um 23:25 schrieb Thiemo Kellner:
> Hallo
>
> Ich versuche, Replication zum Laufen zu bekommen. Ich habe Debian 9 mit
> PostreSQL 10. Ich habe zwei Knoten in einem Cluster und bin mir
> bewusst, dass
> dies leicht zum Deadlock des Masters führen kann und dass es sinnlos ist,
> Replikation auf demselben Blech zu machen - außer es geschieht, um die
> Replikation zu lernen - es sei denn, Replikation im selben Knoten
> funtioniert
> ohnehin nicht.
>
> Ich bin mir nicht sicher, ob ich das Passwort in primary_conninfo
> Klartext sein
> muss oder dessen md5-Wert. Die Doku ist mir da nicht klar. Ich habe
> beides
> versucht und bin zu keinem Ergebnis gekommen.

Klartext. Du kannst auch eine .pgpass - Datei nutzen. Diese Antwort hast
Du aber mittlerweile schon in der engl. Mailingliste bekommen.

>
> Ich konnte mit diesem Setup nicht fest stellen, dass der Standby
> versucht hat,
> sich mit dem Master zu verbinden.

Hast Du überhaupt ein Basebackup erstellt, um daraus einen Standby zu
machen?

>
> Unten meine Konfigurationen
>
> LG Thiemo
>
>
> == Hot standby ==
>
> /etc/postgresql/10/main2/pg_hba.conf
> host    replication     all             127.0.0.1/32 md5
> host    replication     all             ::1/128 md5
> local   replication     repuser peer
> host    replication     repuser         0.0.0.1/0 md5
> host    replication     repuser         ::1/0 md5
>

die eine local-Verbindung irritiert mehr als daß sie sinnvoll ist.

> /etc/postgresql/10/main2/postgresql.conf
> wal_level = replica
> max_replication_slots = 12
> synchronous_standby_names = 'main,main2'

setze mal das auf '1(main, main2)'

> hot_standby = on
> log_min_messages = debug1
> log_connections = on
> log_statement = 'ddl'
> log_replication_commands = on
> lc_messages = 'C.utf-8'
>
> /etc/postgresql/10/main2/recovery.conf
> standby_mode = 'on'
> primary_conninfo = 'host=localhost user=repuser port=5432
> password=<md5 value or
> plain text?>'
>

Hinweise wie oben, und:

> == master ==
> /etc/postgresql/10/main/pg_hba.conf
> host    replication     all             127.0.0.1/32 md5
> host    replication     all             ::1/128 md5
> local   replication     repuser peer
> host    replication     repuser         0.0.0.1/0 md5
> host    replication     repuser         ::1/0 md5
>
> /etc/postgresql/10/main/postgresql.conf
> wal_level = replica
> archive_mode = off
> max_wal_senders = 12
> max_replication_slots = 12
> synchronous_standby_names = 'main2,main'
> hot_standby = on
> wal_receiver_timeout = 60s
> log_min_messages = debug1
> log_connections = on
> log_statement = 'ddl'
> log_replication_commands = on
> lc_messages = 'C.utf-8'
>
> /etc/postgresql/10/main/recovery.conf

KEINE (!) recovery.conf

>
> standby_mode = 'off'
> primary_conninfo = 'host=localhost user=repuser port=5433
> password=<md5 value or
> plain text?>'
>
>
> -- Öffentlicher PGP-Schlüssel:
> http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Gegen den Versuch, die Replikation manuell aufzusetzen, ist nichts
einzuwenden (Lerneffekt), ich würde Dir aber dennoch empfehlen, Dir
unseren repmgr anzuschauen.

https://repmgr.org/

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Thiemo Kellner wrote:
> Ich versuche, Replication zum Laufen zu bekommen. Ich habe Debian 9 mit
> PostreSQL 10. Ich habe zwei Knoten in einem Cluster und bin mir bewusst,
> dass
> dies leicht zum Deadlock des Masters führen kann und dass es sinnlos ist,
> Replikation auf demselben Blech zu machen - außer es geschieht, um die
> Replikation zu lernen - es sei denn, Replikation im selben Knoten
> funtioniert
> ohnehin nicht.
>
> Ich bin mir nicht sicher, ob ich das Passwort in primary_conninfo
> Klartext sein
> muss oder dessen md5-Wert. Die Doku ist mir da nicht klar. Ich habe beides
> versucht und bin zu keinem Ergebnis gekommen.
>
> Ich konnte mit diesem Setup nicht fest stellen, dass der Standby
> versucht hat,
> sich mit dem Master zu verbinden.

Die Interessante Information fehlt, nämlich das Log-File.

Auch auf der -general-Liste findet sich der wesentliche Teil nicht.

Bitte *alle* Log-Messages von Serverstart bis zum Zeitpunkt, wo
Verbindungen akzeptiert werden.

Liebe Grüße,
Laurenz Albe

Am 28.01.2018 um 23:25 schrieb Thiemo Kellner:
> Hallo
>
> Ich versuche, Replication zum Laufen zu bekommen. Ich habe Debian 9 mit
> PostreSQL 10. Ich habe zwei Knoten in einem Cluster und bin mir
> bewusst, dass
>
>
> == Hot standby ==
>
>
>
> /etc/postgresql/10/main2/recovery.conf
>

Debian ist da etwas verwirrend. Die 'normalen' Configs irgendwo unter
/etc, dort sucht sie Postgres dann auch (Debian-spezifisch), aber die
recovery.conf
wird von PostgreSQL im data_directory gesucht.

Ich bevorzuge mehr Redhat-based Systeme für PostgreSQL, da sind alle
configs im data_directory. Das vereinfacht auch die Einrichtung der
Replikation.
Davon abgesehen habe ich noch die Vermutung, daß Du gar kein Basebackup
durchgeführt hast. Weiteres Problem ist, daß Du keine WAL-Archivierung hast,
Du solltest dann zumindest ausreichen Wal's aufheben (keep_wal_segments
oder so ähnlich)

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Zitat von Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>:

> Die Interessante Information fehlt, nämlich das Log-File.
>
Verzeihung und danke für den Hinweis.

== Master log of start gives me ==

2018-01-29 05:55:39.996 CET [1307] DEBUG: registering background
worker "logical replication launcher"
2018-01-29 05:55:39.996 CET [1307] LOG: listening on IPv6 address
"::1", port 5432
2018-01-29 05:55:39.996 CET [1307] LOG: listening on IPv4 address
"127.0.0.1", port 5432
2018-01-29 05:55:40.027 CET [1307] LOG: listening on Unix socket
"/var/run/postgresql/.s.PGSQL.5432"
2018-01-29 05:55:40.061 CET [1307] DEBUG: mmap(148897792) with
MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2018-01-29 05:55:40.153 CET [1308] LOG: database system was shut down
at 2018-01-29 05:50:37 CET
2018-01-29 05:55:40.154 CET [1308] DEBUG: checkpoint record is at 0/1649758
2018-01-29 05:55:40.155 CET [1308] DEBUG: redo record is at
0/1649758; shutdown TRUE
2018-01-29 05:55:40.155 CET [1308] DEBUG: next transaction ID: 0:583;
next OID: 16398
2018-01-29 05:55:40.156 CET [1308] DEBUG: next MultiXactId: 1; next
MultiXactOffset: 0
2018-01-29 05:55:40.156 CET [1308] DEBUG: oldest unfrozen transaction
ID: 548, in database 1
2018-01-29 05:55:40.156 CET [1308] DEBUG: oldest MultiXactId: 1, in
database 1
2018-01-29 05:55:40.156 CET [1308] DEBUG: commit timestamp Xid
oldest/newest: 0/0
2018-01-29 05:55:40.156 CET [1308] DEBUG: transaction ID wrap limit
is 2147484195, limited by database with OID 1
2018-01-29 05:55:40.156 CET [1308] DEBUG: MultiXactId wrap limit is
2147483648, limited by database with OID 1
2018-01-29 05:55:40.156 CET [1308] DEBUG: starting up replication slots
2018-01-29 05:55:40.158 CET [1308] DEBUG: MultiXactId wrap limit is
2147483648, limited by database with OID 1
2018-01-29 05:55:40.158 CET [1308] DEBUG: MultiXact member stop limit
is now 4294914944 based on MultiXact 1
2018-01-29 05:55:40.212 CET [1312] DEBUG: autovacuum launcher started
2018-01-29 05:55:40.213 CET [1307] DEBUG: starting background worker
process "logical replication
launcher"
2018-01-29 05:55:40.216 CET [1307] LOG: database system is ready to
accept connections
2018-01-29 05:55:40.217 CET [1314] DEBUG: logical replication
launcher started
2018-01-29 05:55:40.822 CET [1315] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:40.822 CET [1315] [unknown](at)[unknown] LOG:
incomplete startup packet
2018-01-29 05:55:41.344 CET [1318] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:41.349 CET [1318] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres
2018-01-29 05:55:41.900 CET [1321] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:41.905 CET [1321] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres
2018-01-29 05:55:42.440 CET [1324] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:42.447 CET [1324] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres

== Standby log gives me ==

2018-01-29 05:55:47.724 CET [1333] DEBUG: registering background
worker "logical replication launcher"
2018-01-29 05:55:47.724 CET [1333] LOG: listening on IPv6 address
"::1", port 5433
2018-01-29 05:55:47.725 CET [1333] LOG: listening on IPv4 address
"127.0.0.1", port 5433
2018-01-29 05:55:47.759 CET [1333] LOG: listening on Unix socket
"/var/run/postgresql/.s.PGSQL.5433"
2018-01-29 05:55:47.793 CET [1333] DEBUG: mmap(148897792) with
MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2018-01-29 05:55:47.887 CET [1334] LOG: database system was shut down
at 2018-01-29 05:50:37 CET
2018-01-29 05:55:47.887 CET [1334] DEBUG: checkpoint record is at 0/1636408
2018-01-29 05:55:47.889 CET [1334] DEBUG: redo record is at
0/1636408; shutdown TRUE
2018-01-29 05:55:47.889 CET [1334] DEBUG: next transaction ID: 0:556;
next OID: 16385
2018-01-29 05:55:47.889 CET [1334] DEBUG: next MultiXactId: 1; next
MultiXactOffset: 0
2018-01-29 05:55:47.889 CET [1334] DEBUG: oldest unfrozen transaction
ID: 548, in database 1
2018-01-29 05:55:47.889 CET [1334] DEBUG: oldest MultiXactId: 1, in
database 1
2018-01-29 05:55:47.889 CET [1334] DEBUG: commit timestamp Xid
oldest/newest: 0/0
2018-01-29 05:55:47.889 CET [1334] DEBUG: transaction ID wrap limit
is 2147484195, limited by database with OID 1
2018-01-29 05:55:47.889 CET [1334] DEBUG: MultiXactId wrap limit is
2147483648, limited by database with OID 1
2018-01-29 05:55:47.889 CET [1334] DEBUG: starting up replication slots
2018-01-29 05:55:47.890 CET [1334] DEBUG: MultiXactId wrap limit is
2147483648, limited by database with OID 1
2018-01-29 05:55:47.890 CET [1334] DEBUG: MultiXact member stop limit
is now 4294914944 based on MultiXact 1
2018-01-29 05:55:47.943 CET [1338] DEBUG: autovacuum launcher started
2018-01-29 05:55:47.944 CET [1333] DEBUG: starting background worker
process "logical replication launcher"
2018-01-29 05:55:47.945 CET [1333] LOG: database system is ready to
accept connections
2018-01-29 05:55:47.945 CET [1340] DEBUG: logical replication
launcher started
2018-01-29 05:55:48.470 CET [1341] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:48.471 CET [1341] [unknown](at)[unknown] LOG:
incomplete startup packet
2018-01-29 05:55:48.994 CET [1344] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:48.999 CET [1344] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres
2018-01-29 05:55:49.545 CET [1347] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:49.551 CET [1347] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres
2018-01-29 05:55:50.088 CET [1350] [unknown](at)[unknown] LOG:
connection received: host=[local]
2018-01-29 05:55:50.093 CET [1350] postgres(at)postgres LOG: connection
authorized: user=postgres database=postgres

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0x8F70EFD2D972CBEF

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Thiemo Kellner schrieb:
> Zitat von Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>:
>
> > Die Interessante Information fehlt, nämlich das Log-File.
>
> Verzeihung und danke für den Hinweis.
>
> == Standby log gives me ==
>
> 2018-01-29 05:55:47.887 CET [1334] LOG: database system was shut down at 2018-01-29 05:50:37 CET
> 2018-01-29 05:55:47.887 CET [1334] DEBUG: checkpoint record is at 0/1636408
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: redo record is at 0/1636408; shutdown TRUE
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: next transaction ID: 0:556; next OID: 16385
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: oldest unfrozen transaction ID: 548, in database 1
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: oldest MultiXactId: 1, in database 1
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: commit timestamp Xid oldest/newest: 0/0
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: transaction ID wrap limit is 2147484195, limited by database with OID 1
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
> 2018-01-29 05:55:47.889 CET [1334] DEBUG: starting up replication slots
> 2018-01-29 05:55:47.890 CET [1334] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
> 2018-01-29 05:55:47.890 CET [1334] DEBUG: MultiXact member stop limit is now 4294914944 based on MultiXact 1
> 2018-01-29 05:55:47.943 CET [1338] DEBUG: autovacuum launcher started
> 2018-01-29 05:55:47.944 CET [1333] DEBUG: starting background worker process "logical replication launcher"
> 2018-01-29 05:55:47.945 CET [1333] LOG: database system is ready to accept connections

Das heißt, im Working Directory wurde kein "recovery.conf" gefunden, oder
es konnte nicht zum Lesen geöffnet werden.

Ich nehme an, 1334 ist die Prozeß-ID des Postmaster-Prozesses.

Dann sieht man das Current Working Directory auf Linux so:

ls -l /proc/1334/cwd

Dort sollte "recovery.conf" sein.

Liebe Grüße,
Laurenz Albe

Zitat von Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>:

Vielen Dank für die Antwort.

>> 2018-01-29 05:55:47.945 CET [1333] LOG: database system is ready
>> to accept connections
>
> Das heißt, im Working Directory wurde kein "recovery.conf" gefunden, oder
> es konnte nicht zum Lesen geöffnet werden.

Ich nehme an, dass Du Dich darauf beziehst, dass Standby bereit
meldet, Verbindungen anzunehmen.

> Ich nehme an, 1334 ist die Prozeß-ID des Postmaster-Prozesses.
>
> Dann sieht man das Current Working Directory auf Linux so:
>
> ls -l /proc/1334/cwd
>
> Dort sollte "recovery.conf" sein.

Oh, das war, wie mir einfällt, auch noch eine Unklarheit. Ich hatte
recovery.conf am selben Ort abgelegt, wie die anderen
Konfigurationsdateien (/etc/postgresql/...) und dann im
Data-Verzeichnis der Nodes entsprechende Symlinks auf die
recovery.conf-Dateien gelegt. Ich hoffe, ich kann heute abend Deinen
Hinweis ausprobieren und melde mich mit dem Resultat.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Thiemo Kellner wrote:
> > > 2018-01-29 05:55:47.945 CET [1333] LOG: database system is ready
> > > to accept connections
> >
> > Das heißt, im Working Directory wurde kein "recovery.conf" gefunden, oder
> > es konnte nicht zum Lesen geöffnet werden.
>
> Ich nehme an, dass Du Dich darauf beziehst, dass Standby bereit
> meldet, Verbindungen anzunehmen.

Nein; es müßten vorher noch andere Meldungen kommen, die
anzeigen, daß der Server in den Recovery-Modus geht.

Liebe Grüße,
Laurenz Albe

Ok, recovery.conf wurde zu recovery.done umbenannt. Nachdem ich es
zurück umbenannt habe, hat ein Reload nicht geholfen, es musste ein
Restart sein. Mit einem simples Passwort wie abc kann Standby nun mit
Master verbinden, wenn ich aber das angedachte komplizierte nehme,
klappt es nicht; d. h., ich kann zwar mit psql als repuser anmelden,
aber Standby kann es nicht.

Muss ich jedesmal, wenn der Standby runter gefahren wird, recovery.done
in recovery.conf zurück umbenennen?

Weiss jemand, welche Sonderzeichen in einem Passwort bei der
Standby-Authentifizierung am Master Probleme bereiten?

Thiemo Kellner schrieb:
> Ok, recovery.conf wurde zu recovery.done umbenannt. Nachdem ich es
> zurück umbenannt habe, hat ein Reload nicht geholfen, es musste ein
> Restart sein. Mit einem simples Passwort wie abc kann Standby nun mit
> Master verbinden, wenn ich aber das angedachte komplizierte nehme,
> klappt es nicht; d. h., ich kann zwar mit psql als repuser anmelden,
> aber Standby kann es nicht.
>
> Muss ich jedesmal, wenn der Standby runter gefahren wird, recovery.done
> in recovery.conf zurück umbenennen?
>
> Weiss jemand, welche Sonderzeichen in einem Passwort bei der
> Standby-Authentifizierung am Master Probleme bereiten?

Wenn "recovery.conf" zu "recovery.done" umbenannt wurde, hat
"standby_mode = 'on'" gefehlt.

Recovery ist fertig geworden, eine neue Timeline wurde eröffnet,
und die Datenbank ist normal hochgekommen.

Diese Datenbank kann nicht mehr als Replication Standby
verwendet werden.

Man muß entweder mit "pg_basebackup" ein neues Backup ziehen
oder "pg_rewind" den Cluster zurückspulen, dann kann er wieder
als Standby verwendet werden.

Liebe Grüße,
Laurenz Albe

On 01/30/18 14:25, Laurenz Albe wrote:
>> Weiss jemand, welche Sonderzeichen in einem Passwort bei der
>> Standby-Authentifizierung am Master Probleme bereiten?

Ein 40-Zeichenpasswort ohne Sonderzeichen funktioniert jedenfalls. Das
andere könnte ich wohl austesten.

> Wenn "recovery.conf" zu "recovery.done" umbenannt wurde, hat
> "standby_mode = 'on'" gefehlt.

Müsste eigentlich immer vorhanden gewesen sein.

> Recovery ist fertig geworden, eine neue Timeline wurde eröffnet,
> und die Datenbank ist normal hochgekommen.
>
> Diese Datenbank kann nicht mehr als Replication Standby
> verwendet werden.
>
> Man muß entweder mit "pg_basebackup" ein neues Backup ziehen
> oder "pg_rewind" den Cluster zurückspulen, dann kann er wieder
> als Standby verwendet werden.

Hmpf, schau mer mal. Muss erst mal noch folgendes Problem lösen:
"database system identifier differs between the primary and standby"

Ein Post aus 2011
(/message-id/CAO0A+LivTxSR+OdvC2d2ZcNfP0b8vh=sCXF+mtZMA4reyruA1w@mail.gmail.com)
sprach davon, dass die Host-Information in recovery.conf falsch sei oder
grundsätzlich ein Fehler in besagter Datei. S. Riggs referenziert sein
Buch, das ich habe und nicht sehr schlau daraus geworden bin. Besagtes
Buch hat in primary_conninfo host = 192.168.0.1 bzw. alpha. Ich habe bei
mir localhost und 127.0.0.1 ausprobiert. Wie kann ich fest stellen, als
welcher Host sich der Master wähnt?

Mein recovery.conf sieht z. Z. so aus:
standby_mode = 'on'
primary_conninfo = 'host=localhost user=repuser port=5432 password=<da
stünde es, wenn ich es nicht weg gemacht hätte>'

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 30.01.2018 um 17:33 schrieb Thiemo Kellner:
>
>> Wenn "recovery.conf" zu "recovery.done" umbenannt wurde, hat
>> "standby_mode = 'on'" gefehlt.
>

oder die DB ist zum Master promoted worden...

> Hmpf, schau mer mal. Muss erst mal noch folgendes Problem lösen:
> "database system identifier differs between the primary and standby"

wie ist der standby erstellt worden? Via pg_basebackup?

>
> Ein Post aus 2011
> (/message-id/CAO0A+LivTxSR+OdvC2d2ZcNfP0b8vh=sCXF+mtZMA4reyruA1w@mail.gmail.com)
> sprach davon, dass die Host-Information in recovery.conf falsch sei
> oder grundsätzlich ein Fehler in besagter Datei. S. Riggs referenziert
> sein Buch, das ich habe und nicht sehr schlau daraus geworden bin.
> Besagtes Buch hat in primary_conninfo host = 192.168.0.1 bzw. alpha.
> Ich habe bei mir localhost und 127.0.0.1 ausprobiert. Wie kann ich
> fest stellen, als welcher Host sich der Master wähnt?
>
> Mein recovery.conf sieht z. Z. so aus:
> standby_mode = 'on'
> primary_conninfo = 'host=localhost user=repuser port=5432 password=<da
> stünde es, wenn ich es nicht weg gemacht hätte>'
>

Die conninfo ist schon korrekt:

2018-01-29 05:55:39.996 CET [1307] LOG:  listening on IPv4 address
"127.0.0.1", port 5432

localhost sollte ja auf 127.0.0.1 auflösen.

Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

On 01/30/18 18:10, Andreas Kretschmer wrote:
>>> Wenn "recovery.conf" zu "recovery.done" umbenannt wurde, hat
>>> "standby_mode = 'on'" gefehlt.
>
> oder die DB ist zum Master promoted worden...

Hoppala, die letzte Antwort ging nicht an die Liste. Hat sich wegen
unten erledigt. Was immer der Grund war, ich kann es nicht mehr
nachvollziehen.

>> Hmpf, schau mer mal. Muss erst mal noch folgendes Problem lösen:
>> "database system identifier differs between the primary and standby"
>
> wie ist der standby erstellt worden? Via pg_basebackup?

Ich hatte einfach zwei leere Datenbanken gemacht und die eine in die
andere versucht zu synchronisieren. Ich habe nicht gedacht, dass die
Empfänger-DB ein Klon sein muss.

Die Synchronisation funktioniert nun nach dem Base-Backup ein bisschen.
D. h., das erste Kommando wird übertragen, aber dann klemmt es und ich
muss das Testskript mittels ctrl-c abbrechen.

Ich versuche mal, die Kommandos auf der Kommandozeile einzeln abzusetzen.

Das Anlegen eines Test-Schemas wurde nicht synchronisiert und hat genau
so blockiert, wie zuvor. War die Datenbank vorhanden? Nein, das
Synchronisieren hat - abgesehen vom Blockieren - funktioniert.

Verhalten hat sich bestätigt. Die Datenbank wurde angelegt und
repliziert, aber aus irgend einem Grund hat Master nicht mitbekommen,
dass die Replikation erfolgreich war - auch wenn in
synchronous_standby_names nur der jeweils andere eingetragen war.

Logs
==> /var/log/postgresql/postgresql-10-main.log <==
2018-01-30 22:51:31.053 CET [748] LOG: parameter
"synchronous_standby_names" changed to "main2"
2018-01-30 22:51:44.602 CET [18376] postgres(at)postgres LOG: statement:
create database test;
2018-01-30 22:51:44.650 CET [991] DEBUG: performing replication slot
checkpoint
2018-01-30 22:51:45.185 CET [991] DEBUG: performing replication slot
checkpoint
2018-01-30 22:52:27.531 CET [18401] [unknown](at)[unknown] LOG: connection
received: host=[local]
2018-01-30 22:52:27.532 CET [18376] postgres(at)postgres WARNING:
canceling wait for synchronous replication due to user request
2018-01-30 22:52:27.532 CET [18376] postgres(at)postgres DETAIL: The
transaction has already committed locally, but might not have been
replicated to the standby.

==> /var/log/postgresql/postgresql-10-main2.log <==
2018-01-30 22:51:31.048 CET [18162] LOG: received SIGHUP, reloading
configuration files
2018-01-30 22:52:40.151 CET [18164] DEBUG: performing replication slot
checkpoint

Öhm, weswegen sehe ich den neuen Wert für synchronous_standby_name nur
beim Master?

Test-Skript:
create database test;

\connect test

create schema test;

create table test(id numeric);

\l test

\dn test

\dS test

select pg_last_wal_receive_lsn()
, g_last_wal_receive_lsn();

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 30.01.2018 um 22:58 schrieb Thiemo Kellner:
> On 01/30/18 18:10, Andreas Kretschmer wrote:
>>>> Wenn "recovery.conf" zu "recovery.done" umbenannt wurde, hat
>>>> "standby_mode = 'on'" gefehlt.
>>
>> oder die DB ist zum Master promoted worden...
>
> Hoppala, die letzte Antwort ging nicht an die Liste. Hat sich wegen
> unten erledigt. Was immer der Grund war, ich kann es nicht mehr
> nachvollziehen.
>
>>> Hmpf, schau mer mal. Muss erst mal noch folgendes Problem lösen:
>>> "database system identifier differs between the primary and standby"
>>
>> wie ist der standby erstellt worden? Via pg_basebackup?
>
> Ich hatte einfach zwei leere Datenbanken gemacht und die eine in die
> andere versucht zu synchronisieren. Ich habe nicht gedacht, dass die
> Empfänger-DB ein Klon sein muss.

Ohne despektierlich wirken zu wollen, hast du vor deinen Versuchen _ein
wenig_ in die Doku geschaut...?

Da (/docs/current/static/warm-standby.html)
steht z.B. "Take a base backup as described in Section 25.3.2 to
bootstrap the standby server."

> Die Synchronisation funktioniert nun nach dem Base-Backup ein bisschen.
> D. h., das erste Kommando wird übertragen, aber dann klemmt es und ich
> muss das Testskript mittels ctrl-c abbrechen.

Auf dieser Basis wird gar nichts davon funktionieren...

Eigentlich ist das alles nicht wirklich kompliziert. Wenn du eine knappe
Stunde Zeit hast (was riecht hier so komisch?):
https://archive.fosdem.org/2017/schedule/event/postgresql_backup/

Tip: ab und zu mal bei www.packtpub.com reinschauen, die haben öfter mal
die diversen PG-Bücher als Ebooks für ganz kleines Geld (3-5€) im Sale
(auch das von Simon & Co.).

Gruß,
--
Gunnar "Nick" Bluth
RHCE/SCLA

Mobil +49 172 8853339
Email: gunnar(dot)bluth(at)pro-open(dot)de
_____________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX.
Ten years later they are choosing Windows over UNIX.
What part of that message aren't you getting? - Tom Payne

On 01/30/18 23:34, Gunnar "Nick" Bluth wrote:
> Ohne despektierlich wirken zu wollen, hast du vor deinen Versuchen _ein
> wenig_ in die Doku geschaut...?

Verzeihung, aber wie kann ich so weit oder eben nicht gekommen sein, so
viel halbgares gemacht haben, wenn ich die Doku nicht gelesen hätte?

> Da (/docs/current/static/warm-standby.html)
> steht z.B. "Take a base backup as described in Section 25.3.2 to
> bootstrap the standby server."

Verzeihung, steht da auch, dass es für hot-standby dasselbe ist?
Abgesehen davon, was heisst bootstrap genau? Ich habe niergends in der
Doku gesehen, dass es für jeden PostgreSQL-Node einen Unique-Identifier
gibt und dass der des Master gleich denen der Standbys sein muss. Naiv
wie ich bin, habe ich angenommen, dass es bei einer Replikatioin darauf
ankommt, dass die DB-Objekte identisch sind, nicht der Node als solches
(von mir im letzten Post als Klon bezeichnet).

>> Die Synchronisation funktioniert nun nach dem Base-Backup ein bisschen.
>> D. h., das erste Kommando wird übertragen, aber dann klemmt es und ich
>> muss das Testskript mittels ctrl-c abbrechen.
>
> Auf dieser Basis wird gar nichts davon funktionieren...

Nicht hilfreich...

> Eigentlich ist das alles nicht wirklich kompliziert. Wenn du eine knappe
> Stunde Zeit hast (was riecht hier so komisch?):
> https://archive.fosdem.org/2017/schedule/event/postgresql_backup/

Werde ich gerne rein schauen, danke. Ne jetzt, mir vorwerfen, ich würde
nicht in die Doku rein schauen, aber einen Vortrag gehalten haben, zu
dem eingeleitet wird mit "The PostgreSQL documentation explains in
detail how to do backup and replication, maybe too detailed for
beginners or "part-time" DBAs."? Ich werde es mir trotzdem durchsehen,
aber nicht mehr heute abend.

> Tip: ab und zu mal bei www.packtpub.com reinschauen, die haben öfter mal
> die diversen PG-Bücher als Ebooks für ganz kleines Geld (3-5€) im Sale
> (auch das von Simon & Co.).

Tip: Ab und zu mal die ganzen Posts lesen. Dann wüsstest Du, dass ich
Herrn Riggs Buch schon besitze - für 5 $. Offenbar habe ich Mühe mit dem
Recipe-Aufbau, und falls mein Gefühl richtig ist, dass Herr Riggs auch
stark an dem Teil der offiziellen Doku mitgeschrieben hat, ist es auch
nicht so erstaunlich, dass es mir nicht viele neue Erkenntnisse
geliefert hat.

Liebe Grüsse Thiemo

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 31.01.2018 um 00:00 schrieb Thiemo Kellner:
> On 01/30/18 23:34, Gunnar "Nick" Bluth wrote:
>> Ohne despektierlich wirken zu wollen, hast du vor deinen Versuchen _ein
>> wenig_ in die Doku geschaut...?
>
> Verzeihung, aber wie kann ich so weit oder eben nicht gekommen sein, so
> viel halbgares gemacht haben, wenn ich die Doku nicht gelesen hätte?

Ich meinte das wirklich nicht despektierlich!
Ich bin halt selber jemand, der gerne mal Abschnitte überspringt... Und
mache das (Replikation aufsetzen) so oft, dass ich gerne mal vergesse,
wie ich mir bei meinen ersten Versuchen vor 'zig Jahren einen
abgebrochen habe.

Mal sehen, ich könnte mir vorstellen, dass aus dieser Geschichte ein
Patch für die Doku entsteht...

>> Auf dieser Basis wird gar nichts davon funktionieren...
>
> Nicht hilfreich...

Ich denke schon; es spart dir Zeit mit weiteren Fehlversuchen?

>> Eigentlich ist das alles nicht wirklich kompliziert. Wenn du eine knappe
>> Stunde Zeit hast (was riecht hier so komisch?):
>> https://archive.fosdem.org/2017/schedule/event/postgresql_backup/
>
> Werde ich gerne rein schauen, danke. Ne jetzt, mir vorwerfen, ich würde
> nicht in die Doku rein schauen, aber einen Vortrag gehalten haben, zu
> dem eingeleitet wird mit "The PostgreSQL documentation explains in
> detail how to do backup and replication, maybe too detailed for
> beginners or "part-time" DBAs."? Ich werde es mir trotzdem durchsehen,
> aber nicht mehr heute abend.

Die Doku ist gut, aber eben kein Lehrbuch. Die Balance zwischen "zu
kurz" und "zu lang" ist halt nicht einfach zu finden...

Aber man könnte da mal an prominenter Stelle einen Hinweis anbringen,
dass physikalische Replikation immer eine 1:1-Kopie erzeugt.

>> Tip: ab und zu mal bei www.packtpub.com reinschauen, die haben öfter mal
>> die diversen PG-Bücher als Ebooks für ganz kleines Geld (3-5€) im Sale
>> (auch das von Simon & Co.).
>
> Tip: Ab und zu mal die ganzen Posts lesen. Dann wüsstest Du, dass ich
> Herrn Riggs Buch schon besitze - für 5 $. Offenbar habe ich Mühe mit dem

Ich hatte "das ich _nicht_ habe" in Erinnerung. Mea culpa.

Schau dir den Talk mal an. Schneller bekommst du das "Rezept" nicht,
denke ich (ich habe die Folien auch mal einen ganzen Tag lang benutzt ;-).

Gruß,
--
Gunnar "Nick" Bluth
RHCE/SCLA

Mobil +49 172 8853339
Email: gunnar(dot)bluth(at)pro-open(dot)de
_____________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX.
Ten years later they are choosing Windows over UNIX.
What part of that message aren't you getting? - Tom Payne

Moin,

Am 30.01.2018 um 22:58 schrieb Thiemo Kellner:
>
>
>>> Hmpf, schau mer mal. Muss erst mal noch folgendes Problem lösen:
>>> "database system identifier differs between the primary and standby"
>>
>> wie ist der standby erstellt worden? Via pg_basebackup?
>
> Ich hatte einfach zwei leere Datenbanken gemacht und die eine in die
> andere versucht zu synchronisieren. Ich habe nicht gedacht, dass die
> Empfänger-DB ein Klon sein muss.

Nun haben wir die Ursache. Passiert. Bitte schreibe noch in der engl.
Mailingliste, daß das Thema gelöst ist - nicht alle von *dort* lesen
auch *hier* mit.

Mit Deinem Vorgehen zeigst Du, daß das Grundprinzip der streaming
Replication (die besser physical replication sich nennen sollte) nicht
völlig verstanden ist. Hier ist wichtig zu verstehen, was im
Transaktionslog (bis einschl. 9.6 pg_xlog, ab PG10 pg_wal) steht. Da
stehen eben nicht logische Befehle (Insert hier, delete dort), sondern
rein binäre Änderungen an den Dateien im Filesystem.
Deine 'Vermutung', einfach mit zwei leeren datenbanken zu arbeiten,
würde mit einer logischen Replikation (die trigger-basierten wie Slony,
londiste, bucardo) sowie mit logical replication in PG10 sowie mit
pg_logical & BDR am 9.4 stimmen, nicht aber mit physical (streaming)
replication. Mit dieser Replikation (physical oder streaming) wird alles
übertragen, einschließlich Vacuum-Änderungen.

>
> Die Synchronisation funktioniert nun nach dem Base-Backup ein
> bisschen. D. h., das erste Kommando wird übertragen, aber dann klemmt
> es und ich muss das Testskript mittels ctrl-c abbrechen.

Hier passiert das, was ich schon sagte: mit synchr. physical replication
muß der Master warten, bis der Standby die Transaktion bestätigt hat.
Offenbar erkennt der Master nicht den Standby als 'main2'.

Setze mal im connection-string des Standbys noch name=main2, damit der
Master erkennen kann, daß sich dieser da connected.

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Thiemo Kellner wrote:
> > Ohne despektierlich wirken zu wollen, hast du vor deinen Versuchen _ein
> > wenig_ in die Doku geschaut...?
>
> Verzeihung, aber wie kann ich so weit oder eben nicht gekommen sein, so
> viel halbgares gemacht haben, wenn ich die Doku nicht gelesen hätte?

Nicht jammern, lesen.

Bei vielen Programmen ist es eine Gemeinheit, Leute kommentarlos an die
Dokumentation zu verweisen, aber die von PostgreSQL ist so gut, daß es
gut investierte 30-60 Minuten wären.

Liebe Grüße,
Laurenz Albe

Am 31.01.2018 um 09:03 schrieb Laurenz Albe:
> Thiemo Kellner wrote:
>>> Ohne despektierlich wirken zu wollen, hast du vor deinen Versuchen _ein
>>> wenig_ in die Doku geschaut...?
>> Verzeihung, aber wie kann ich so weit oder eben nicht gekommen sein, so
>> viel halbgares gemacht haben, wenn ich die Doku nicht gelesen hätte?
> Nicht jammern, lesen.

Hehe ;-)

>
> Bei vielen Programmen ist es eine Gemeinheit, Leute kommentarlos an die
> Dokumentation zu verweisen, aber die von PostgreSQL ist so gut, daß es
> gut investierte 30-60 Minuten wären.

Die Doku von PG ist gut, keine Frage. Aber sie ist eher eine Referenz
als ein Lehrbuch. Für Einsteiger, die etwas lernen wollen, sind IMHO
eher diverse Blogs etc. geeignet.
Vor vielen Jahren war z.B. http://www.varlena.com/GeneralBits/ sehr gut,
aber Elein macht das (leider) nicht mehr weiter. http://paquier.xyz/ und
https://www.depesz.com/ stellen regelmäßig neue Features vor,
lesenswert. Es gibt massig Bücher (mittlerweile), und Google kennt
Tonnen von Anleitungen (die manchmal aber auch grobe Fehler haben ...
(Beispiel
https://www.digitalocean.com/community/tutorials/how-to-back-up-restore-and-migrate-postgresql-databases-with-barman-on-centos-7
, das ist gut geschrieben, aber Step 11 enthält einen massiven Fehler.
Hab den Autor schon vor Monaten gebeten, das zu korrigieren... wer ihn
findet, darf den Fehler gern behalten ...)

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Vielen Dank an Andreas Kretschmer und die anderen der Liste, die mir
geholfen haben. Ich habe unten nun die funkntionierenden Abweichungen
von den Standardeinstellungen aufgeführt.

Zunächst war mein Fehler, dass ich nicht begriffen habe, dass jeder
Standby eines Streaming-Masters ein Klon sein muss (z. B. über
pg_basebackup), zwei logisch gleiche Datenbanken, z. B. zwei
jungfräuliche Initialisierungen, funktioniert nicht. Das Master-Log
zeigt dann einen Fehler, dass die Identifier nicht übereinstimmen. Die
Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
Standbys kopiert. Ob dies nur im Falle frisch initialisierter
Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist mir
nicht klar geworden.

Es ist wichtig, dass nicht nur in
postgres.config-synchronous_standby_names für jeden Standby ein
Applikationsname eingetragen wird, sondern auch dass in jeweils einer
dieser Applikationsnamen in recovery.conf-primary_conninfo im Parameter
application_name geführt wird - für jeden Standby ein eigener. Nur so
ist es Master möglich, die Erfolgsmeldungen der Standbys zuzuordnen.

Zum Schluss hatte ich noch das Problem, dass ich nicht alle
synchronisierten Datenbank-Objekte im Standby gefunden hatte. Beim
Anlegen auf Master hatte ich nicht das neue Schema und die neue DB
angegeben, aber in diesen auf Standby gesucht.

Liebe Grüße

Thiemo

== Hot standby ==

/etc/postgresql/10/main2/pg_hba.conf
host replication all ::1/128 md5
host replication all 127.0.0.1/32 md5
host replication repuser ::1/0 md5
host replication repuser 0.0.0.1/0 md5
local replication repuser peer

/etc/postgresql/10/main2/postgresql.conf
wal_level = replica
#synchronous_commit = on
max_replication_slots = 12
synchronous_standby_names = 'main'
hot_standby = on
log_min_messages = warning
log_connections = on
log_statement = 'ddl'
log_replication_commands = on
lc_messages = 'C.utf-8'

/etc/postgresql/10/main2/recovery.conf
standby_mode = 'on'
primary_conninfo = 'application_name=main2 host=localhost user=repuser
port=5432 password=<plain text>'

== master ==
/etc/postgresql/10/main/pg_hba.conf
host replication all ::1/128 md5
host replication all 127.0.0.1/32 md5
host replication repuser ::1/0 md5
host replication repuser 0.0.0.1/0 md5
local replication repuser peer

/etc/postgresql/10/main/postgresql.conf
wal_level = replica
#synchronous_commit = on
archive_mode = off
max_wal_senders = 12
max_replication_slots = 12
synchronous_standby_names = 'main2'
hot_standby = on
wal_receiver_timeout = 60s
log_min_messages = warning
log_connections = on
log_statement = 'ddl'
log_replication_commands = on
lc_messages = 'C.utf-8'

/etc/postgresql/10/main/recovery.conf
standby_mode = 'off'
primary_conninfo = 'application_name=main host=localhost user=repuser
port=5433 password=<plain text>'

Erratum: Meldung zum Identifier-Unterschied ist im Standby-Log

On 01/31/18 16:21, Thiemo Kellner wrote:
> Vielen Dank an Andreas Kretschmer und die anderen der Liste, die mir
> geholfen haben. Ich habe unten nun die funkntionierenden Abweichungen
> von den Standardeinstellungen aufgeführt.
>
> Zunächst war mein Fehler, dass ich nicht begriffen habe, dass jeder
> Standby eines Streaming-Masters ein Klon sein muss (z. B. über
> pg_basebackup), zwei logisch gleiche Datenbanken, z. B. zwei
> jungfräuliche Initialisierungen, funktioniert nicht. Das Master-Log
> zeigt dann einen Fehler, dass die Identifier nicht übereinstimmen. Die
> Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
> Standbys kopiert. Ob dies nur im Falle frisch initialisierter
> Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist mir
> nicht klar geworden.
>
> Es ist wichtig, dass nicht nur in
> postgres.config-synchronous_standby_names für jeden Standby ein
> Applikationsname eingetragen wird, sondern auch dass in jeweils einer
> dieser Applikationsnamen in recovery.conf-primary_conninfo im Parameter
> application_name geführt wird - für jeden Standby ein eigener. Nur so
> ist es Master möglich, die Erfolgsmeldungen der Standbys zuzuordnen.
>
> Zum Schluss hatte ich noch das Problem, dass ich nicht alle
> synchronisierten Datenbank-Objekte im Standby gefunden hatte. Beim
> Anlegen auf Master hatte ich nicht das neue Schema und die neue DB
> angegeben, aber in diesen auf Standby gesucht.
>
> Liebe Grüße
>
> Thiemo
>
> == Hot standby ==
>
> /etc/postgresql/10/main2/pg_hba.conf
> host    replication     all             ::1/128                 md5
> host    replication     all             127.0.0.1/32            md5
> host    replication     repuser         ::1/0                   md5
> host    replication     repuser         0.0.0.1/0               md5
> local   replication     repuser                                 peer
>
> /etc/postgresql/10/main2/postgresql.conf
> wal_level = replica
> #synchronous_commit = on
> max_replication_slots = 12
> synchronous_standby_names = 'main'
> hot_standby = on
> log_min_messages = warning
> log_connections = on
> log_statement = 'ddl'
> log_replication_commands = on
> lc_messages = 'C.utf-8'
>
> /etc/postgresql/10/main2/recovery.conf
> standby_mode = 'on'
> primary_conninfo = 'application_name=main2 host=localhost user=repuser
> port=5432 password=<plain text>'
>
> == master ==
> /etc/postgresql/10/main/pg_hba.conf
> host    replication     all             ::1/128                 md5
> host    replication     all             127.0.0.1/32            md5
> host    replication     repuser         ::1/0                   md5
> host    replication     repuser         0.0.0.1/0               md5
> local   replication     repuser                                 peer
>
> /etc/postgresql/10/main/postgresql.conf
> wal_level = replica
> #synchronous_commit = on
> archive_mode = off
> max_wal_senders = 12
> max_replication_slots = 12
> synchronous_standby_names = 'main2'
> hot_standby = on
> wal_receiver_timeout = 60s
> log_min_messages = warning
> log_connections = on
> log_statement = 'ddl'
> log_replication_commands = on
> lc_messages = 'C.utf-8'
>
> /etc/postgresql/10/main/recovery.conf
> standby_mode = 'off'
> primary_conninfo = 'application_name=main host=localhost user=repuser
> port=5433 password=<plain text>'
>

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 31.01.2018 um 16:21 schrieb Thiemo Kellner:
> Vielen Dank an Andreas Kretschmer und die anderen der Liste, die mir
> geholfen haben. Ich habe unten nun die funkntionierenden Abweichungen
> von den Standardeinstellungen aufgeführt.
>
> Zunächst war mein Fehler, dass ich nicht begriffen habe, dass jeder
> Standby eines Streaming-Masters ein Klon sein muss (z. B. über
> pg_basebackup), zwei logisch gleiche Datenbanken, z. B. zwei
> jungfräuliche Initialisierungen, funktioniert nicht. Das Master-Log
> zeigt dann einen Fehler, dass die Identifier nicht übereinstimmen. Die
> Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
> Standbys kopiert. Ob dies nur im Falle frisch initialisierter
> Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist mir
> nicht klar geworden.

Das Grundprinzip ist immer so, ja.
Am einfachsten machst du pg_basebackup direkt in dein neues
Ziel-Directory (und mit "-X stream -R"), dann hast du auch schon eine
rudimentäre recovery.conf und weißt direkt, ob die Replikation danach
funktionieren wird.

Vielleicht bekommen wir das ja mal deutlicher in der Doku ausgewiesen...

> Es ist wichtig, dass nicht nur in
> postgres.config-synchronous_standby_names für jeden Standby ein
> Applikationsname eingetragen wird, sondern auch dass in jeweils einer
> dieser Applikationsnamen in recovery.conf-primary_conninfo im Parameter
> application_name geführt wird - für jeden Standby ein eigener. Nur so
> ist es Master möglich, die Erfolgsmeldungen der Standbys zuzuordnen.

Wenn du keine genaue Bestimmung haben willst, kannst du auch alle gleich
benennen ("einer der 'main'-Secondarys soll synchron sein").
Du könntest in deinem Fall auch beide "main" nennen. Im Echtbetrieb (mit
2 Knoten) würde ich das auch so machen, da ist das Risiko der
Verzettelung geringer...

Gruß,
--
Gunnar "Nick" Bluth
RHCE/SCLA

Mobil +49 172 8853339
Email: gunnar(dot)bluth(at)pro-open(dot)de
_____________________________________________________________
In 1984 mainstream users were choosing VMS over UNIX.
Ten years later they are choosing Windows over UNIX.
What part of that message aren't you getting? - Tom Payne

On 01/31/18 16:49, Gunnar "Nick" Bluth wrote:
> Das Grundprinzip ist immer so, ja.
> Am einfachsten machst du pg_basebackup direkt in dein neues
> Ziel-Directory (und mit "-X stream -R"), dann hast du auch schon eine
> rudimentäre recovery.conf und weißt direkt, ob die Replikation danach
> funktionieren wird.
>
> Wenn du keine genaue Bestimmung haben willst, kannst du auch alle gleich
> benennen ("einer der 'main'-Secondarys soll synchron sein").
> Du könntest in deinem Fall auch beide "main" nennen. Im Echtbetrieb (mit
> 2 Knoten) würde ich das auch so machen, da ist das Risiko der
> Verzettelung geringer...

Danke für die Erleuchtungen. :-)

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC

Am 31.01.2018 um 16:21 schrieb Thiemo Kellner:
> Die Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
> Standbys kopiert. Ob dies nur im Falle frisch initialisierter
> Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist
> mir nicht klar geworden.

Also, um das noch mal zu erklären:

pg_basebackup kann einen laufenden Server sichern. Auf diesem kann
durchauch richtig viel Traffic sein. Und diese DB kann auch groß sein.
Stelle Dir 10TB vor. Die spannende Frage ist: ist denn so ein basebackup
überhaupt konsistent? Nein, ist es nicht, denn die Datenbank arbeitet
und schreibt fleißig in die Datendateien - während diese kopiert werden.

Daher besteht so ein physisches Backup immer aus 2 Teilen: die Kopie des
Datenordners UND den während des kopierens angefallenen
Transaktionslogs. Wenn der Clone dann hochfährt, muß er irgendwie an die
Transaktionsdateien kommen. Dafür gibt es mehrere Möglichkeiten:

* pg_basebackup kann die automatisch mit streamen. Das ist sogar der
Default (in aktuellen Versionen)
* pg_basebackup kann die nach dem Basebackup holen. Riskant, denn der
Master überschreibt diese Dateien nach 2 Checkpoints (ab PG11 evtl.
schon nach 1 Checkpoint)
* man hantiert mit Replication Slots
* man hantiert mit archive_command / restore_command
* man set wal_keep_segments hinreichend groß (wie groß? Gute Frage,
schätzen sie mal ...)
* man nutzt Barman (Werbung muß sein!)

Versuche, den ganzen Mechanismus zu verstehen, also was diese komischen
WAL's machen, zusammenspiel Shared Buffers, Checkpoints, Transaction Log
etc. Es ist wichtig, das zu verstehen. Das ist Grundlage der Robustheit
von PostgreSQL (es ist crash-safe!), es ist Grundlage der streaming
replication (und auch der logischen Replikation ab PG 10, BDR & Co), es
ist Grundlage für Point-In-Time-Recovery.

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

Das werde ich mir noch zu Gemüte führen. Danke.

On 01/31/18 17:00, Andreas Kretschmer wrote:
>
>
> Am 31.01.2018 um 16:21 schrieb Thiemo Kellner:
>> Die Dateien des Base-Backup habe ich einfach ins Datenverzeichnis des
>> Standbys kopiert. Ob dies nur im Falle frisch initialisierter
>> Datenbanken funktioniert oder ob dies das reguläre Vorgehen ist, ist
>> mir nicht klar geworden.
>
> Also, um das noch mal zu erklären:
>
> pg_basebackup kann einen laufenden Server sichern. Auf diesem kann
> durchauch richtig viel Traffic sein. Und diese DB kann auch groß sein.
> Stelle Dir 10TB vor. Die spannende Frage ist: ist denn so ein basebackup
> überhaupt konsistent? Nein, ist es nicht, denn die Datenbank arbeitet
> und schreibt fleißig in die Datendateien - während diese kopiert werden.
>
> Daher besteht so ein physisches Backup immer aus 2 Teilen: die Kopie des
> Datenordners UND den während des kopierens angefallenen
> Transaktionslogs. Wenn der Clone dann hochfährt, muß er irgendwie an die
> Transaktionsdateien kommen. Dafür gibt es mehrere Möglichkeiten:
>
> * pg_basebackup kann die automatisch mit streamen. Das ist sogar der
> Default (in aktuellen Versionen)
> * pg_basebackup kann die nach dem Basebackup holen. Riskant, denn der
> Master überschreibt diese Dateien nach 2 Checkpoints (ab PG11 evtl.
> schon nach 1 Checkpoint)
> * man hantiert mit Replication Slots
> * man hantiert mit archive_command / restore_command
> * man set wal_keep_segments hinreichend groß (wie groß? Gute Frage,
> schätzen sie mal ...)
> * man nutzt Barman (Werbung muß sein!)
>
> Versuche, den ganzen Mechanismus zu verstehen, also was diese komischen
> WAL's machen, zusammenspiel Shared Buffers, Checkpoints, Transaction Log
> etc. Es ist wichtig, das zu verstehen. Das ist Grundlage der Robustheit
> von PostgreSQL (es ist crash-safe!), es ist Grundlage der streaming
> replication (und auch der logischen Replikation ab PG 10, BDR & Co), es
> ist Grundlage für Point-In-Time-Recovery.
>
>
> Andreas
>

--
+49 (0)1578-772 37 37
+41 (0)78 947 36 21
SIP/iptel.org: thiemo.kellner
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu/pks/lookup?op=get&search=0xCA167FB0E717AFFC