Postgres 9.4 BDR - Replicazione non funziona

Buongiorno,
sto provando a creare un Cluster Master Master usando Postgres-9.4 BDR su
due nodi.
Sul primo nodo il DB già esiste ed è bello grosso (più di 3Gb).
Nell'aggiungere il secondo nodo (ho popolato il DB con un dump fatto dal
primo nodo), dopo aver configurato tutto (primo e secondo nodo) seguendo la
guida ufficiale (http://bdr-project.org/docs/stable/quickstart.html)
nell'eseguire l'ultimo step (
http://bdr-project.org/docs/stable/quickstart-enabling.html) sul nodo 2,
resto bloccato su "SELECT bdr.bdr_node_join_wait_for_ready();" ed il nodo2
stampa a log questo:

< 2017-12-07 09:33:15.781 EST >LOG: starting background worker process
"bdr db: zabbix"
< 2017-12-07 09:33:15.793 EST >ERROR: previous init failed, manual cleanup
is required
< 2017-12-07 09:33:15.793 EST >DETAIL: Found bdr.bdr_nodes entry for bdr
(6496055908800323183,1,16386,) with state=i in remote bdr.bdr_nodes
< 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
and slots corresponding to this node from the init target node then drop
and recreate this database and try again
< 2017-12-07 09:33:15.795 EST >LOG: worker process: bdr db: zabbix (PID
26818) exited with exit code 1

Non riesco a venirne a capo.
Sul primo nodo se eseguo :
zabbix=# select * from bdr.bdr_nodes;
node_sysid | node_timeline | node_dboid | node_status | node_name
| node_local_dsn
| node_init_from_dsn | node_read_only | node_seq_id
---------------------+---------------+------------+-------------+-----------+-------------------------------------------------------------------------------+--------------------+----------------+-------------
6494544977234587558 | 1 | 16386 | r | zabbix01
| user=postgres password=xxxxxxxx host=10.200.x.xx port=5432 dbname=zabbix
| | f |
(1 row)"

Vedo solo il primo nodo ma non il secondo.
Come devo proseguire?
Grazie a tutti
--
____________________________________________________
*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

Ciao Francesco,

Il giorno 7 dicembre 2017 16:35, Francesco Andrisani <
francesco(dot)andrisani(at)acotel(dot)com> ha scritto:

> Buongiorno,
> sto provando a creare un Cluster Master Master usando Postgres-9.4 BDR su
> due nodi.
> Sul primo nodo il DB già esiste ed è bello grosso (più di 3Gb).
> Nell'aggiungere il secondo nodo (ho popolato il DB con un dump fatto dal
> primo nodo), dopo aver configurato tutto (primo e secondo nodo) seguendo la
> guida ufficiale (http://bdr-project.org/docs/stable/quickstart.html)
> nell'eseguire l'ultimo step (http://bdr-project.org/docs/
> stable/quickstart-enabling.html) sul nodo 2, resto bloccato su "SELECT
> bdr.bdr_node_join_wait_for_ready();" ed il nodo2 stampa a log questo:
>
> < 2017-12-07 09:33:15.781 EST >LOG: starting background worker process
> "bdr db: zabbix"
> < 2017-12-07 09:33:15.793 EST >ERROR: previous init failed, manual
> cleanup is required
> < 2017-12-07 09:33:15.793 EST >DETAIL: Found bdr.bdr_nodes entry for bdr
> (6496055908800323183,1,16386,) with state=i in remote bdr.bdr_nodes
> < 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
> and slots corresponding to this node from the init target node then drop
> and recreate this database and try again
> < 2017-12-07 09:33:15.795 EST >LOG: worker process: bdr db: zabbix (PID
> 26818) exited with exit code 1
>

L'aggiunta del secondo nodo al cluster BDR tramite la funzione
bdr.bdr_group_join è asincrona. bdr.bdr_node_join_wait_for_ready serve
proprio per attendere che l'aggiunta del secondo nodo avvenga con successo.
L'errore allegato si riferisce infatti all'esecuzione della prima funzione.

Non riesco a venirne a capo.
> Sul primo nodo se eseguo :
> zabbix=# select * from bdr.bdr_nodes;
> node_sysid | node_timeline | node_dboid | node_status |
> node_name | node_local_dsn
> | node_init_from_dsn | node_read_only | node_seq_id
> ---------------------+---------------+------------+---------
> ----+-----------+-------------------------------------------
> ------------------------------------+--------------------+--
> --------------+-------------
> 6494544977234587558 | 1 | 16386 | r | zabbix01
> | user=postgres password=xxxxxxxx host=10.200.x.xx port=5432 dbname=zabbix
> | | f |
> (1 row)"
>
> Vedo solo il primo nodo ma non il secondo.
> Come devo proseguire?
>

Anzitutto, potresti precisare la versione di BDR usata? Che pacchetti hai
usato?

Precisato questo: molto probabilmente quando hai creto il cluster BDR nel
primo nodo di origine tramite la funzione bdr.bdr_group_create non hai
atteso che l'esecuzione fosse finita (anche in questo caso, il comando
ritorna, ma l'esecuzione è asincrona), quindi l'aggiunta del secondo nodo è
fallita (notare lo stato "i" riscontrato nel primo nodo). Adesso dal
secondo output che hai allegato sembra che il primo nodo è correttamente
definito nel cluster (stato "r"). Puoi riaggiungere il secondo nodo,
seguendo l'hint del log:

< 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
and slots corresponding to this node from the init target node then drop
and recreate this database and try again

ovvero riportandoti ad un secondo nodo pulito pronto per essere
riaggiunto (bdr.bdr_group_join
si prende cura di rieffettuare un nuovo pg_dump/pg_restore del nodo
originale).

Giuseppe.

Ciao Giuseppe,
sto lavorando su due servers linux CentOs 7.4.1708.
La versione di Postgres BDR è 9.4. Ho installato:

- yum install
http://packages.2ndquadrant.com/postgresql-bdr94-2ndquadrant/yum-repo-rpms/postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch.rpm
- yum install postgresql-bdr94-bdr

Ok.
Provo ad eliminare tutto il DB dal secondo nodo, ricrearlo dal dump
precedente e a riproporre la procedura di aggiunta del secondo
nodo...questa volta senza gfare nulla sul primo.

Vi aggiorno appena terminato la procedura.

Grazie

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

> Ciao Francesco,
>
> Il giorno 7 dicembre 2017 16:35, Francesco Andrisani <
> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>
>> Buongiorno,
>> sto provando a creare un Cluster Master Master usando Postgres-9.4 BDR su
>> due nodi.
>> Sul primo nodo il DB già esiste ed è bello grosso (più di 3Gb).
>> Nell'aggiungere il secondo nodo (ho popolato il DB con un dump fatto dal
>> primo nodo), dopo aver configurato tutto (primo e secondo nodo) seguendo la
>> guida ufficiale (http://bdr-project.org/docs/stable/quickstart.html)
>> nell'eseguire l'ultimo step (http://bdr-project.org/docs/s
>> table/quickstart-enabling.html) sul nodo 2, resto bloccato su "SELECT
>> bdr.bdr_node_join_wait_for_ready();" ed il nodo2 stampa a log questo:
>>
>> < 2017-12-07 09:33:15.781 EST >LOG: starting background worker process
>> "bdr db: zabbix"
>> < 2017-12-07 09:33:15.793 EST >ERROR: previous init failed, manual
>> cleanup is required
>> < 2017-12-07 09:33:15.793 EST >DETAIL: Found bdr.bdr_nodes entry for bdr
>> (6496055908800323183,1,16386,) with state=i in remote bdr.bdr_nodes
>> < 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
>> and slots corresponding to this node from the init target node then drop
>> and recreate this database and try again
>> < 2017-12-07 09:33:15.795 EST >LOG: worker process: bdr db: zabbix (PID
>> 26818) exited with exit code 1
>>
>
> L'aggiunta del secondo nodo al cluster BDR tramite la funzione
> bdr.bdr_group_join è asincrona. bdr.bdr_node_join_wait_for_ready serve
> proprio per attendere che l'aggiunta del secondo nodo avvenga con successo.
> L'errore allegato si riferisce infatti all'esecuzione della prima funzione.
>
> Non riesco a venirne a capo.
>> Sul primo nodo se eseguo :
>> zabbix=# select * from bdr.bdr_nodes;
>> node_sysid | node_timeline | node_dboid | node_status |
>> node_name | node_local_dsn
>> | node_init_from_dsn | node_read_only | node_seq_id
>> ---------------------+---------------+------------+---------
>> ----+-----------+-------------------------------------------
>> ------------------------------------+--------------------+--
>> --------------+-------------
>> 6494544977234587558 | 1 | 16386 | r |
>> zabbix01 | user=postgres password=xxxxxxxx host=10.200.x.xx port=5432
>> dbname=zabbix | | f |
>> (1 row)"
>>
>> Vedo solo il primo nodo ma non il secondo.
>> Come devo proseguire?
>>
>
> Anzitutto, potresti precisare la versione di BDR usata? Che pacchetti hai
> usato?
>
> Precisato questo: molto probabilmente quando hai creto il cluster BDR nel
> primo nodo di origine tramite la funzione bdr.bdr_group_create non hai
> atteso che l'esecuzione fosse finita (anche in questo caso, il comando
> ritorna, ma l'esecuzione è asincrona), quindi l'aggiunta del secondo nodo è
> fallita (notare lo stato "i" riscontrato nel primo nodo). Adesso dal
> secondo output che hai allegato sembra che il primo nodo è correttamente
> definito nel cluster (stato "r"). Puoi riaggiungere il secondo nodo,
> seguendo l'hint del log:
>
> < 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
> and slots corresponding to this node from the init target node then drop
> and recreate this database and try again
>
> ovvero riportandoti ad un secondo nodo pulito pronto per essere riaggiunto
> (bdr.bdr_group_join si prende cura di rieffettuare un nuovo
> pg_dump/pg_restore del nodo originale).
>
> 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

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?

2017-12-07 17:18 GMT+01:00 Francesco Andrisani <
francesco(dot)andrisani(at)acotel(dot)com>:

> Ciao Giuseppe,
> sto lavorando su due servers linux CentOs 7.4.1708.
> La versione di Postgres BDR è 9.4. Ho installato:
>
> - yum install http://packages.2ndquadrant.com/postgresql-bdr94-
> 2ndquadrant/yum-repo-rpms/postgresql-bdr94-2ndquadrant-
> redhat-1.0-2.noarch.rpm
> - yum install postgresql-bdr94-bdr
>
> Ok.
> Provo ad eliminare tutto il DB dal secondo nodo, ricrearlo dal dump
> precedente e a riproporre la procedura di aggiunta del secondo
> nodo...questa volta senza gfare nulla sul primo.
>
> Vi aggiorno appena terminato la procedura.
>
> Grazie
>
> 2017-12-07 17:12 GMT+01:00 Giuseppe Broccolo <g(dot)broccolo(dot)7(at)gmail(dot)com>:
>
>> Ciao Francesco,
>>
>> Il giorno 7 dicembre 2017 16:35, Francesco Andrisani <
>> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>>
>>> Buongiorno,
>>> sto provando a creare un Cluster Master Master usando Postgres-9.4 BDR
>>> su due nodi.
>>> Sul primo nodo il DB già esiste ed è bello grosso (più di 3Gb).
>>> Nell'aggiungere il secondo nodo (ho popolato il DB con un dump fatto dal
>>> primo nodo), dopo aver configurato tutto (primo e secondo nodo) seguendo la
>>> guida ufficiale (http://bdr-project.org/docs/stable/quickstart.html)
>>> nell'eseguire l'ultimo step (http://bdr-project.org/docs/s
>>> table/quickstart-enabling.html) sul nodo 2, resto bloccato su "SELECT
>>> bdr.bdr_node_join_wait_for_ready();" ed il nodo2 stampa a log questo:
>>>
>>> < 2017-12-07 09:33:15.781 EST >LOG: starting background worker process
>>> "bdr db: zabbix"
>>> < 2017-12-07 09:33:15.793 EST >ERROR: previous init failed, manual
>>> cleanup is required
>>> < 2017-12-07 09:33:15.793 EST >DETAIL: Found bdr.bdr_nodes entry for
>>> bdr (6496055908800323183,1,16386,) with state=i in remote bdr.bdr_nodes
>>> < 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
>>> and slots corresponding to this node from the init target node then drop
>>> and recreate this database and try again
>>> < 2017-12-07 09:33:15.795 EST >LOG: worker process: bdr db: zabbix (PID
>>> 26818) exited with exit code 1
>>>
>>
>> L'aggiunta del secondo nodo al cluster BDR tramite la funzione
>> bdr.bdr_group_join è asincrona. bdr.bdr_node_join_wait_for_ready serve
>> proprio per attendere che l'aggiunta del secondo nodo avvenga con successo.
>> L'errore allegato si riferisce infatti all'esecuzione della prima funzione.
>>
>> Non riesco a venirne a capo.
>>> Sul primo nodo se eseguo :
>>> zabbix=# select * from bdr.bdr_nodes;
>>> node_sysid | node_timeline | node_dboid | node_status |
>>> node_name | node_local_dsn
>>> | node_init_from_dsn | node_read_only | node_seq_id
>>> ---------------------+---------------+------------+---------
>>> ----+-----------+-------------------------------------------
>>> ------------------------------------+--------------------+--
>>> --------------+-------------
>>> 6494544977234587558 | 1 | 16386 | r |
>>> zabbix01 | user=postgres password=xxxxxxxx host=10.200.x.xx port=5432
>>> dbname=zabbix | | f |
>>> (1 row)"
>>>
>>> Vedo solo il primo nodo ma non il secondo.
>>> Come devo proseguire?
>>>
>>
>> Anzitutto, potresti precisare la versione di BDR usata? Che pacchetti hai
>> usato?
>>
>> Precisato questo: molto probabilmente quando hai creto il cluster BDR nel
>> primo nodo di origine tramite la funzione bdr.bdr_group_create non hai
>> atteso che l'esecuzione fosse finita (anche in questo caso, il comando
>> ritorna, ma l'esecuzione è asincrona), quindi l'aggiunta del secondo nodo è
>> fallita (notare lo stato "i" riscontrato nel primo nodo). Adesso dal
>> secondo output che hai allegato sembra che il primo nodo è correttamente
>> definito nel cluster (stato "r"). Puoi riaggiungere il secondo nodo,
>> seguendo l'hint del log:
>>
>> < 2017-12-07 09:33:15.793 EST >HINT: Remove all replication identifiers
>> and slots corresponding to this node from the init target node then drop
>> and recreate this database and try again
>>
>> ovvero riportandoti ad un secondo nodo pulito pronto per essere
>> riaggiunto (bdr.bdr_group_join si prende cura di rieffettuare un nuovo
>> pg_dump/pg_restore del nodo originale).
>>
>> 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
>

--
____________________________________________________
*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

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.

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