Re: Postgres 9.4 BDR - Replicazione non funziona

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