From: | Thiemo Kellner <thiemo(at)gelassene-pferde(dot)biz> |
---|---|
To: | pgsql-de-allgemein(at)lists(dot)postgresql(dot)org |
Subject: | Re: Probleme Replikation aufzusetzen |
Date: | 2018-01-30 21:58:28 |
Message-ID: | 74d7974d-9589-1333-0389-baed5f1110fa@gelassene-pferde.biz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-de-allgemein |
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
Attachment | Content-Type | Size |
---|---|---|
thiemo.vcf | text/x-vcard | 693 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Gunnar "Nick" Bluth | 2018-01-30 22:34:29 | Re: Probleme Replikation aufzusetzen |
Previous Message | Andreas Kretschmer | 2018-01-30 17:10:54 | Re: Probleme Replikation aufzusetzen |