Re: Probleme Replikation aufzusetzen

This is a multi-part message in MIME format.
--------------5B26E94D7F3DF1704F9E8215
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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@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]@[unknown] LOG:  connection 
received: host=[local]
2018-01-30 22:52:27.532 CET [18376] postgres@postgres WARNING: 
canceling wait for synchronous replication due to user request
2018-01-30 22:52:27.532 CET [18376] postgres@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

--------------5B26E94D7F3DF1704F9E8215
Content-Type: text/x-vcard; charset=utf-8;
 name="thiemo.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="thiemo.vcf"

begin:vcard
fn:Thiemo Kellner
n:Kellner;Thiemo
adr:;;Landstr. 34;Weilheim-Bannholz;BW;79809;Deutschland
email;internet:[email protected]
tel;work:+49 1578 772 37 37
tel;cell:+41 78 947 36 21
note;quoted-printable:Auf Gelassene Pferde kann man bauen!=0D=0A=
	+49 (0)1578-772 37 37 (Mo, Di)=0D=0A=
	+41 (0)78 947 36 21 (Mi - Fr)=0D=0A=
	sip: [email protected]=0D=0A=
	Skype: thiemo.kellner=0D=0A=
	http://www.gelassene-pferde.biz=0D=0A=
	Mitglied bei http://www.keep-it-natural.org=0D=0A=
	=C3=96ffentlicher PGP-Schl=C3=BCssel: http://pgp.mit.edu/pks/lookup?op=3D=
	get&search=3D0x8F70EFD2D972CBEF
x-mozilla-html:FALSE
url:http://www.gelassene-pferde.biz
version:2.1
end:vcard


--------------5B26E94D7F3DF1704F9E8215--