Re: Postgres 9.4 BDR - Replicazione non funziona

Grazie Giuseppe,
si alla fine grazie a te ho risolto.
Adesso ho un latro problema su /data/pg_xlog/...ma ho aperto un altro topic.

Grazie mille
Francesco

2017-12-11 11:42 GMT+01:00 Giuseppe Broccolo <g(dot)broccolo(dot)7(at)gmail(dot)com>:

> Salve Francesco, perdonami se ti rispondo solo ora, ma immagino tu abbia
> già risolto :)
>
> Il giorno 7 dicembre 2017 18:02, Francesco Andrisani <
> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>
>> Ok. Allora ho eliminato tutto il DB cancellando tutta il contenuto della
>> directory data.
>> - Ho Inizializzato il DB
>> - Ho Modificato i files postgresql.conf e pg_hba.conf.
>> - Ho creato il DB (zabbix) da replicare (vuoto) sul nodo2
>> - Sono entrato sul DB con il comando "/usr/pgsql-9.4/bin/psql -U postgres
>> zabbix"
>> - Ho eseguito in sequenza i comandi:
>>
>> zabbix=# CREATE EXTENSION btree_gist;
>>
>> CREATE EXTENSION
>>
>> zabbix=# CREATE EXTENSION bdr;
>>
>> CREATE EXTENSION
>>
>> zabbix=# SELECT bdr.bdr_group_join(
>>
>> local_node_name := 'zabbix02',
>>
>> node_external_dsn := 'user=postgres password=flycell80pine
>> host=10.200.3.17 port=5432 dbname=zabbix',
>>
>> join_using_dsn := 'user=postgres password=flycell80pine host=10.200.3.19
>> port=5432 dbname=zabbix'
>>
>> );
>>
>> bdr_group_join
>>
>> ----------------
>>
>>
>>
>> (1 row)
>>
>>
>> zabbix=# SELECT bdr.bdr_node_join_wait_for_ready();
>>
>> Mi si blocca su SELECT e dal log (sempre del nodo2) vedo questo:
>>
>> < 2017-12-07 11:54:20.764 EST >LOG: registering background worker "bdr
>> db: zabbix"
>> < 2017-12-07 11:54:20.764 EST >LOG: starting background worker process
>> "bdr db: zabbix"
>> < 2017-12-07 11:54:20.903 EST >LOG: Creating replica with:
>> /usr/pgsql-9.4/bin/bdr_initial_load --snapshot 002E032D-1 --source
>> "user=postgres password=flycell80pine host=10.200.3.19 port=5432
>> dbname=zabbix" --target "user=postgres password=xxxxxxx host=10.200.x.xx
>> port=5432 dbname=zabbix" --tmp-directory "/tmp/postgres-bdr-002E032D-1.31711",
>> --pg-dump-path "/usr/pgsql-9.4/bin/bdr_dump", --pg-restore-path
>> "/usr/pgsql-9.4/bin/pg_restore"
>> Dumping remote database "connect_timeout=30 keepalives=1
>> keepalives_idle=20 keepalives_interval=20 keepalives_count=5
>> user=postgres password=flycell80pine host=10.200.3.19 port=5432
>> dbname=zabbix fallback_application_name='bdr (6496848513654172382,1,16386,):
>> init_replica dump'" with 1 concurrent workers to
>> "/tmp/postgres-bdr-002E032D-1.31711"
>> Restoring dump to local DB "user=postgres password=flycell80pine
>> host=10.200.3.17 port=5432 dbname=zabbix fallback_application_name='bdr
>> (6496848513654172382,1,16386,): init_replica restore' options='-c
>> bdr.do_not_replicate=on -c bdr.permit_unsafe_ddl_commands=on -c
>> bdr.skip_ddl_replication=on -c bdr.skip_ddl_locking=on -c
>> session_replication_role=replica'" with 1 concurrent workers from
>> "/tmp/postgres-bdr-002E032D-1.31711"
>> < 2017-12-07 11:59:01.837 EST >LOG: checkpoints are occurring too
>> frequently (17 seconds apart)
>> < 2017-12-07 11:59:01.837 EST >HINT: Consider increasing the
>> configuration parameter "checkpoint_segments".
>> < 2017-12-07 11:59:04.000 EST >LOG: checkpoints are occurring too
>> frequently (2 seconds apart)
>> < 2017-12-07 11:59:04.000 EST >HINT: Consider increasing the
>> configuration parameter "checkpoint_segments".
>> < 2017-12-07 11:59:05.943 EST >LOG: checkpoints are occurring too
>> frequently (2 seconds apart)
>> < 2017-12-07 11:59:05.943 EST >HINT: Consider increasing the
>> configuration parameter "checkpoint_segments".
>> < 2017-12-07 11:59:08.173 EST >LOG: checkpoints are occurring too
>> frequently (3 seconds apart)
>> < 2017-12-07 11:59:08.173 EST >HINT: Consider increasing the
>> configuration parameter "checkpoint_segments".
>> < 2017-12-07 11:59:10.193 EST >LOG: checkpoints are occurring too
>> frequently (2 seconds apart)
>>
>> Immagino sia cominciata la replicazione?
>>
>
> Come ti dicevo la volta scorsa, l'esecuzione di bdr.bdr_node_join_wait_for_ready()
> resta appesa finché il nodo non è pronto per la replica. In quel momento
> era in corso la copia logica del database dal nodo sorgente (la cui
> conninfo hai configurato nell'esecuzione di bdr.bdr_group_join()), al
> momento in cui la prima copia di sync è terminata e l'istanza è pronta per
> ricevere lo stream di WAL decodificato parte la replica logica.
>
> Un saluto,
> Giuseppe.
>

--
____________________________________________________
*Francesco Andrisani*
mailto:francesco(dot)andrisani(at)acotel(dot)com
*Acotel Spa*
http://www.acotel.com
Via della Valle dei Fontanili, 29
00168 Roma
Tel +390661141200
Fax +39066149936
____________________________________________________

Le informazioni contenute nella comunicazione che precede possono essere
riservate e sono, comunque, destinate esclusivamente alla persona o
all’ente sopraindicati. La diffusione, distribuzione e/o copiatura non
autorizzata del documento trasmesso da parte di qualsiasi soggetto è
proibita. La sicurezza e la correttezza dei messaggi di posta elettronica
non possono essere garantite. Se avete ricevuto questo messaggio per
errore, Vi preghiamo di contattarci immediatamente. Grazie.

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any transmission. If you
receive this message in error, please immediately delete it and all copies
of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Thanks