Re: Directory data/pg_xlog enorme!

Buongiorno,
sto notando che la directory del mio postgresql 9.4 BDR ha raggiunto la
dimensione di 80 Gb. Che posso fare?
Ho letto che non posso cancellare questi files? Corretto? Ma quindi come
posso risolvere per ricavare un po di spazio sul mio server?

Grazie

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

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

> Buongiorno,
> sto notando che la directory del mio postgresql 9.4 BDR ha raggiunto la
> dimensione di 80 Gb. Che posso fare?
>

Questo sta accadendo su tutti i nodi del cluster BDR? In oggetto alla mail
hai precisato che si tratta della pg_xlog/, la subdirectory dove vengono
generati i WAL file di PostgreSQL.

> Ho letto che non posso cancellare questi files? Corretto? Ma quindi come
> posso risolvere per ricavare un po di spazio sul mio server?
>

I WAL sono fondamentali per la persistenza del dato in PostgreSQL, e
vitali in caso di crash recovery del database. Tali file vengono
opportunamente ruotati da PostgreSQL stesso, sulla base dei checkpoint
eseguiti. E solo PostgreSQL, a regime, libera spazio una volta che i WAL
non sono più utili, per far spazio a quelli nuovamente generati.

Per ricavare spazio devi capire cosa sta bloccando la rimozione/rotazione
dei file. Questo può accadere per vari motivi: nei casi di replica, in
presenza di replication slot, potrebbe trattarsi di WAL mantenuti in pancia
da replication slot non più attivi (cosa che si può venire a creare in caso
di fallimenti durante il setup della replica).

Puoi controllare lo stato dei replication slot in uso con la seguente query:

SELECT * FROM pg_replication_slots;

i replication slot non più attivi (perché non usati) possono essere rimossi
tramite il comando SQL:

SELECT
pg_drop_replication_slot('<repl_slot_name>');

Ti consiglio di leggere maggiori info su WAL e replication slot in
dettaglio nella documentazione di PostgreSQL (generalmente molto ben
fatta), così che puoi capire meglio il problema con cui ti stai
confrontando.

Un saluto,
Giuseppe.

Grazie mille.
Sempre molto disponibile.

Francesco

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

> Salve Francesco,
>
> Il giorno 11 dicembre 2017 11:17, Francesco Andrisani <
> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>
>> Buongiorno,
>> sto notando che la directory del mio postgresql 9.4 BDR ha raggiunto la
>> dimensione di 80 Gb. Che posso fare?
>>
>
> Questo sta accadendo su tutti i nodi del cluster BDR? In oggetto alla mail
> hai precisato che si tratta della pg_xlog/, la subdirectory dove vengono
> generati i WAL file di PostgreSQL.
>
>
>> Ho letto che non posso cancellare questi files? Corretto? Ma quindi come
>> posso risolvere per ricavare un po di spazio sul mio server?
>>
>
> I WAL sono fondamentali per la persistenza del dato in PostgreSQL, e
> vitali in caso di crash recovery del database. Tali file vengono
> opportunamente ruotati da PostgreSQL stesso, sulla base dei checkpoint
> eseguiti. E solo PostgreSQL, a regime, libera spazio una volta che i WAL
> non sono più utili, per far spazio a quelli nuovamente generati.
>
> Per ricavare spazio devi capire cosa sta bloccando la rimozione/rotazione
> dei file. Questo può accadere per vari motivi: nei casi di replica, in
> presenza di replication slot, potrebbe trattarsi di WAL mantenuti in pancia
> da replication slot non più attivi (cosa che si può venire a creare in caso
> di fallimenti durante il setup della replica).
>
> Puoi controllare lo stato dei replication slot in uso con la seguente
> query:
>
> SELECT * FROM pg_replication_slots;
>
> i replication slot non più attivi (perché non usati) possono essere
> rimossi tramite il comando SQL:
>
> SELECT pg_drop_replication_slot('<
> repl_slot_name>');
>
> Ti consiglio di leggere maggiori info su WAL e replication slot in
> dettaglio nella documentazione di PostgreSQL (generalmente molto ben
> fatta), così che puoi capire meglio il problema con cui ti stai
> confrontando.
>
> 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

Ciao,
questo è lo stato attuale

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

> Salve Francesco,
>
> Il giorno 11 dicembre 2017 11:17, Francesco Andrisani <
> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>
>> Buongiorno,
>> sto notando che la directory del mio postgresql 9.4 BDR ha raggiunto la
>> dimensione di 80 Gb. Che posso fare?
>>
>
> Questo sta accadendo su tutti i nodi del cluster BDR? In oggetto alla mail
> hai precisato che si tratta della pg_xlog/, la subdirectory dove vengono
> generati i WAL file di PostgreSQL.
>
>
>> Ho letto che non posso cancellare questi files? Corretto? Ma quindi come
>> posso risolvere per ricavare un po di spazio sul mio server?
>>
>
> I WAL sono fondamentali per la persistenza del dato in PostgreSQL, e
> vitali in caso di crash recovery del database. Tali file vengono
> opportunamente ruotati da PostgreSQL stesso, sulla base dei checkpoint
> eseguiti. E solo PostgreSQL, a regime, libera spazio una volta che i WAL
> non sono più utili, per far spazio a quelli nuovamente generati.
>
> Per ricavare spazio devi capire cosa sta bloccando la rimozione/rotazione
> dei file. Questo può accadere per vari motivi: nei casi di replica, in
> presenza di replication slot, potrebbe trattarsi di WAL mantenuti in pancia
> da replication slot non più attivi (cosa che si può venire a creare in caso
> di fallimenti durante il setup della replica).
>
> Puoi controllare lo stato dei replication slot in uso con la seguente
> query:
>
> SELECT * FROM pg_replication_slots;
>
> i replication slot non più attivi (perché non usati) possono essere
> rimossi tramite il comando SQL:
>
> SELECT pg_drop_replication_slot('<
> repl_slot_name>');
>
> Ti consiglio di leggere maggiori info su WAL e replication slot in
> dettaglio nella documentazione di PostgreSQL (generalmente molto ben
> fatta), così che puoi capire meglio il problema con cui ti stai
> confrontando.
>
> 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

Ciao,
questo è lo stato attuale -bash-4.2$ /usr/pgsql-9.4/bin/psql -U postgres
psql (9.4.15)
Type "help" for help.

postgres=# SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid |
database | active | xmin | catalog_xmin | restart_lsn
-----------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
bdr_16386_6494206846520473005_1_19300__ | bdr | logical | 16386 |
zabbix | f | | 17888 | 1/B1C3B180
bdr_16386_6495995985626938154_1_16385__ | bdr | logical | 16386 |
zabbix | f | | 1763147 | B/3897EB18
bdr_16386_6496055908800323183_1_16386__ | bdr | logical | 16386 |
zabbix | f | | 1838957 | B/8EE9D140
slot_1 | | physical | |
| f | | |
bdr_16386_6496841362602882552_1_16386__ | bdr | logical | 16386 |
zabbix | f | | 3009147 | 10/711606D0
bdr_16386_6496848513654172382_1_16386__ | bdr | logical | 16386 |
zabbix | t | | 4153974 | 14/F7414A18
(6 rows)

Immagino che potrò eliminare quelli contrassegnati con "f" giusto?

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

> Salve Francesco,
>
> Il giorno 11 dicembre 2017 11:17, Francesco Andrisani <
> francesco(dot)andrisani(at)acotel(dot)com> ha scritto:
>
>> Buongiorno,
>> sto notando che la directory del mio postgresql 9.4 BDR ha raggiunto la
>> dimensione di 80 Gb. Che posso fare?
>>
>
> Questo sta accadendo su tutti i nodi del cluster BDR? In oggetto alla mail
> hai precisato che si tratta della pg_xlog/, la subdirectory dove vengono
> generati i WAL file di PostgreSQL.
>
>
>> Ho letto che non posso cancellare questi files? Corretto? Ma quindi come
>> posso risolvere per ricavare un po di spazio sul mio server?
>>
>
> I WAL sono fondamentali per la persistenza del dato in PostgreSQL, e
> vitali in caso di crash recovery del database. Tali file vengono
> opportunamente ruotati da PostgreSQL stesso, sulla base dei checkpoint
> eseguiti. E solo PostgreSQL, a regime, libera spazio una volta che i WAL
> non sono più utili, per far spazio a quelli nuovamente generati.
>
> Per ricavare spazio devi capire cosa sta bloccando la rimozione/rotazione
> dei file. Questo può accadere per vari motivi: nei casi di replica, in
> presenza di replication slot, potrebbe trattarsi di WAL mantenuti in pancia
> da replication slot non più attivi (cosa che si può venire a creare in caso
> di fallimenti durante il setup della replica).
>
> Puoi controllare lo stato dei replication slot in uso con la seguente
> query:
>
> SELECT * FROM pg_replication_slots;
>
> i replication slot non più attivi (perché non usati) possono essere
> rimossi tramite il comando SQL:
>
> SELECT pg_drop_replication_slot('<
> repl_slot_name>');
>
> Ti consiglio di leggere maggiori info su WAL e replication slot in
> dettaglio nella documentazione di PostgreSQL (generalmente molto ben
> fatta), così che puoi capire meglio il problema con cui ti stai
> confrontando.
>
> 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

Ciao Francesco,

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

> Ciao,
> questo è lo stato attuale -bash-4.2$ /usr/pgsql-9.4/bin/psql -U postgres
> psql (9.4.15)
> Type "help" for help.
>
> postgres=# SELECT * FROM pg_replication_slots;
> slot_name | plugin | slot_type | datoid |
> database | active | xmin | catalog_xmin | restart_lsn
> -----------------------------------------+--------+---------
> --+--------+----------+--------+------+--------------+-------------
> bdr_16386_6494206846520473005_1_19300__ | bdr | logical | 16386 |
> zabbix | f | | 17888 | 1/B1C3B180
> bdr_16386_6495995985626938154_1_16385__ | bdr | logical | 16386 |
> zabbix | f | | 1763147 | B/3897EB18
> bdr_16386_6496055908800323183_1_16386__ | bdr | logical | 16386 |
> zabbix | f | | 1838957 | B/8EE9D140
> slot_1 | | physical | |
> | f | | |
> bdr_16386_6496841362602882552_1_16386__ | bdr | logical | 16386 |
> zabbix | f | | 3009147 | 10/711606D0
> bdr_16386_6496848513654172382_1_16386__ | bdr | logical | 16386 |
> zabbix | t | | 4153974 | 14/F7414A18
> (6 rows)
>
> Immagino che potrò eliminare quelli contrassegnati con "f" giusto?
>

Sì, direi che è un punto di partenza, se confronti il restart_lsn di ogni
replication slot con quello attuale ti rendi conto di quanti WAL siano
correntemente mantenuti in pancia dal singolo replication slot. A questo
punto fai un check completo sul cluster, e cerca di capire bene l'origine
di questi replication slot non più usati.

Un saluto,
Giuseppe.