Re: Error con logical replication

[Alvaro Herrera]

motum hesa escribió:
> 2017-12-21 14:28 GMT-06:00 Alvaro Herrera :
> 
> >
> > Por alguna razón los procesos se abren y se cierran de inmediato.  Eso
> > es un bug pero falta información para poder depurarlo.

> Entiendo, bueno desgraciadamente no es que pueda hacer más pruebas con
> estos servidores ya que son de producción.
> 
> Voy a tratar de replicar este problema en servidores de prueba (pondré
> Freebsd 11 y 10 como en este casco y utilizaré la misma base de
> datos.) Una vez que tenga este setup de prueba (y replique el error) a
> dónde puedo comunicarme para poder debugear mejor este error?

Lo ideal sería reportar en la lista pgsql-bugs o en el formulario de
reporte de bugs en www.postgresql.org (ambos sólo en inglés).  O en esta
misma lista.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Consulta de tabla con millones de registros

[Edwin De La Cruz]

El 6/2/2018 4:44 PM, "Martín Marqués"  escribió:

El 6 de febrero de 2018, 17:56, Jaime Casanova
 escribió:
> 2018-02-06 6:04 GMT-05:00 Martin Marques :
>>
>> Sería interesante saber cual es el *workaround* para los indices
>> globales. ;)
>>
>
> creas una tabla con todos los valores de la PK de las particiones (la
> mantienes actualizada con triggers) y que los FK apunten ahí

Ahora entiendo la parte de "no que sea bonito". ;)

--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Interesante alternativa a FK en tablas particionadas. Voy a probar.

Re: Duda con Barman

[Daymel Bonne]

El 6 de febrero de 2018, 20:07, Alberto Cardenas Cardenas<
alberto.cardenas.c...@gmail.com> escribió:

> Gracias por la respuesta me quedo muy claro, pero ahora tengo otra duda, y
> es con los respaldos incrementales.
>
> Mi configuracion de barman es la siguiente: ejemplo servidor se llama
> esclavo2 , es un servidor esclavo replicado.
>
> [esclavo2]
>
> description =  "Servidor Esclavo PostgreSQL server"
> conninfo = host=esclavo2 user=barman dbname=postgres
> streaming_conninfo = host=esclavo2 user=streaming_barman
>
> backup_method = rsync
> reuse_backup = link
> backup_options = concurrent_backup
>
> streaming_backup_name = barman_streaming_backup
> streaming_archiver = on
> slot_name = barman
> streaming_archiver_name = barman_receive_wal
>
>
> ;streaming_archiver_batch_size = 50
> ; PATH setting for this server
> path_prefix = "/usr/pgsql-9.6/bin"
>
> retention_policy_mode = auto
> retention_policy = RECOVERY WINDOW OF 1 days
> wal_retention_policy = main
>
> ssh_command = ssh postgres@esclavo2
> archiver = on
> parallel_jobs = 1
>
>
>
> Este es el resultado del barman check
>
> esclavo2:
> PostgreSQL: OK
> is_superuser: OK
> PostgreSQL streaming: OK
> wal_level: OK
> replication slot: OK
> directories: OK
> retention policy settings: OK
> backup maximum age: OK (interval provided: 1 day, latest backup
> age: 1 minute, 30 seconds)
> compression settings: OK
> failed backups: OK (there are 0 failed backups)
> minimum redundancy requirements: OK (have 65 backups, expected at
> least 0)
> ssh: OK (PostgreSQL server)
> archive_mode: OK
> archive_command: OK
> continuous archiving: OK
> pg_receivexlog: OK
> pg_receivexlog compatible: OK
> receive-wal running: OK
> archiver errors: OK
>
>
>
> En el cron tengo la siguiente tarea:
>
> */5 * * * * barman backup --reuse-backup=link esclavo2
>
>
> Este fue el backpu full inicial
>
> esclavo2 20180206T083014 - Tue Feb  6 08:30:21 2018 - Size: 130.3 MiB -
> WAL Size: 102.4 MiB (tablespaces: tbs_indices:/var/lib/pgsql/9.
> 6/data/indices)
>
> Estos son backup Incrementales (supuestamente)
>
> esclavo2 20180206T165503 - Tue Feb  6 16:55:16 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
> esclavo2 20180206T133503 - Tue Feb  6 13:35:08 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
> esclavo2 20180206T133002 - Tue Feb  6 13:30:08 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
> esclavo2 20180206T132502 - Tue Feb  6 13:25:08 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
> esclavo2 20180206T132002 - Tue Feb  6 13:20:08 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
> esclavo2 20180206T131503 - Tue Feb  6 13:15:09 2018 - Size: 2.2 GiB - WAL
> Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
>
>
> Esta es la informacion del ultimo bachup
>
> barman show-backup esclavo2  20180206T165503
> Backup 20180206T165503:
>   Server Name: esclavo2
>   Status : DONE
>   PostgreSQL Version : 90606
>   PGDATA directory   : /var/lib/pgsql/9.6/data
>   Tablespaces:
> tbs_indices: /var/lib/pgsql/9.6/data/indices (oid: 86015)
>
>   Base backup information:
> Disk usage   : 2.2 GiB (2.2 GiB with WALs)
> Incremental size : 135.1 KiB (-99.99%)
> Timeline : 3
> Begin WAL: 00030001003B
> End WAL  : 00030001003B
> WAL number   : 0
> Begin time   : 2018-02-06 16:55:03.947275-08:00
> End time : 2018-02-06 16:55:16.688294-08:00
> Copy time: 2 seconds + 9 seconds startup
> Estimated throughput : 55.6 KiB/s
> Begin Offset : 40
> End Offset   : 152
> Begin LSN   : 1/3B28
> End LSN : 1/3B98
>
>   WAL information:
> No of files  : 0
> Disk usage   : 0 B
> Last available   : None
>
>   Catalog information:
> Retention Policy : VALID
> Previous Backup  : 20180206T133503
> Next Backup  : - (this is the latest base backup)
>
>
>
>
> Lo que no entiendo de todo esto es, porque todos los respaldos
> incrementales pesas 2.2 GB, pesan , si tengo u respaldo full , se supone
> que los incrementales son solo la diferencia del full, o estoy equivocado
>

Por la opción reuse_backup = link, barman reutiliza los ficheros del
respaldo respaldo anterior para hacer los incrementales, y utiliza la
funcionalidad de enlaces duros en linux [1].

El concepto principal es que una copia de seguridad base POSTERIOR
compartirá los archivos que no han cambiados desde la copia de seguridad
ANTERIOR 

Re: Duda con Barman

[Alberto Cardenas Cardenas]

Gracias por la respuesta me quedo muy claro, pero ahora tengo otra duda, y
es con los respaldos incrementales.

Mi configuracion de barman es la siguiente: ejemplo servidor se llama
esclavo2 , es un servidor esclavo replicado.

[esclavo2]

description =  "Servidor Esclavo PostgreSQL server"
conninfo = host=esclavo2 user=barman dbname=postgres
streaming_conninfo = host=esclavo2 user=streaming_barman

backup_method = rsync
reuse_backup = link
backup_options = concurrent_backup

streaming_backup_name = barman_streaming_backup
streaming_archiver = on
slot_name = barman
streaming_archiver_name = barman_receive_wal


;streaming_archiver_batch_size = 50
; PATH setting for this server
path_prefix = "/usr/pgsql-9.6/bin"

retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 1 days
wal_retention_policy = main

ssh_command = ssh postgres@esclavo2
archiver = on
parallel_jobs = 1



Este es el resultado del barman check

esclavo2:
PostgreSQL: OK
is_superuser: OK
PostgreSQL streaming: OK
wal_level: OK
replication slot: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (interval provided: 1 day, latest backup
age: 1 minute, 30 seconds)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 65 backups, expected at
least 0)
ssh: OK (PostgreSQL server)
archive_mode: OK
archive_command: OK
continuous archiving: OK
pg_receivexlog: OK
pg_receivexlog compatible: OK
receive-wal running: OK
archiver errors: OK



En el cron tengo la siguiente tarea:

*/5 * * * * barman backup --reuse-backup=link esclavo2


Este fue el backpu full inicial

esclavo2 20180206T083014 - Tue Feb  6 08:30:21 2018 - Size: 130.3 MiB - WAL
Size: 102.4 MiB (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)

Estos son backup Incrementales (supuestamente)

esclavo2 20180206T165503 - Tue Feb  6 16:55:16 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
esclavo2 20180206T133503 - Tue Feb  6 13:35:08 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
esclavo2 20180206T133002 - Tue Feb  6 13:30:08 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
esclavo2 20180206T132502 - Tue Feb  6 13:25:08 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
esclavo2 20180206T132002 - Tue Feb  6 13:20:08 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)
esclavo2 20180206T131503 - Tue Feb  6 13:15:09 2018 - Size: 2.2 GiB - WAL
Size: 0 B (tablespaces: tbs_indices:/var/lib/pgsql/9.6/data/indices)


Esta es la informacion del ultimo bachup

barman show-backup esclavo2  20180206T165503
Backup 20180206T165503:
  Server Name: esclavo2
  Status : DONE
  PostgreSQL Version : 90606
  PGDATA directory   : /var/lib/pgsql/9.6/data
  Tablespaces:
tbs_indices: /var/lib/pgsql/9.6/data/indices (oid: 86015)

  Base backup information:
Disk usage   : 2.2 GiB (2.2 GiB with WALs)
Incremental size : 135.1 KiB (-99.99%)
Timeline : 3
Begin WAL: 00030001003B
End WAL  : 00030001003B
WAL number   : 0
Begin time   : 2018-02-06 16:55:03.947275-08:00
End time : 2018-02-06 16:55:16.688294-08:00
Copy time: 2 seconds + 9 seconds startup
Estimated throughput : 55.6 KiB/s
Begin Offset : 40
End Offset   : 152
Begin LSN   : 1/3B28
End LSN : 1/3B98

  WAL information:
No of files  : 0
Disk usage   : 0 B
Last available   : None

  Catalog information:
Retention Policy : VALID
Previous Backup  : 20180206T133503
Next Backup  : - (this is the latest base backup)




Lo que no entiendo de todo esto es, porque todos los respaldos
incrementales pesas 2.2 GB, pesan , si tengo u respaldo full , se supone
que los incrementales son solo la diferencia del full, o estoy equivocado


Saludos cordiales

El 6 de febrero de 2018, 6:49, Martin Marques <
martin.marq...@2ndquadrant.com> escribió:

> El 05/02/18 a las 22:22, Alberto Cardenas Cardenas escribió:
> > Hola lista, tengo una duda he leído la documentación de Barman, pero sin
> > embargo no se como poder restaurar archivos respaldados anteriores a
> > cierta ventana de tiempo (retention_policy), me explico.
>
> Todo lo que sacas del servidor de barman (lo que esta fuera de la
> ventana que configuraste para retener respaldos) barman no tiene forma
> de de saber donde está o como usar dichos archivos. Para barman esos
> archivos ya no están (aunque si están en otro lugar).
>
> Queda en vos copiar 

Re: Consulta de tabla con millones de registros

[Martín Marqués]

El 6 de febrero de 2018, 17:56, Jaime Casanova
 escribió:
> 2018-02-06 6:04 GMT-05:00 Martin Marques :
>>
>> Sería interesante saber cual es el *workaround* para los indices
>> globales. ;)
>>
>
> creas una tabla con todos los valores de la PK de las particiones (la
> mantienes actualizada con triggers) y que los FK apunten ahí

Ahora entiendo la parte de "no que sea bonito". ;)

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Re: Consulta de tabla con millones de registros

[Jaime Casanova]

2018-02-06 6:04 GMT-05:00 Martin Marques :
> El 05/02/18 a las 21:04, Jaime Casanova escribió:
>> 2018-01-29 16:27 GMT-05:00 Martin Marques :
>>>
>>> - llaves foráneas que apuntan a una llave primaria particionada (a cual
>>> de la tablas hijo debe direccionar esa referencia)
>>>
>>> - indices globales para garantizar unicidad de la llave primaria de la
>>> partición cuando no se particiona por la llave primaria (muy común)
>>>
>>
>> para ambos casos hay workarounds, no que sea bonito pero funcionan
>
> Sería interesante saber cual es el *workaround* para los indices
> globales. ;)
>

creas una tabla con todos los valores de la PK de las particiones (la
mantienes actualizada con triggers) y que los FK apunten ahí

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: Consulta de tabla con millones de registros

[Lazaro Garcia]

Gracias a todos por sus respuestas, en realidad puede que me haya adelantado a 
un problema pero lo cierto es que la tabla puede tener millones de registros y 
consultarla no debe demorar más de 200 milisegundos, estoy hablando de una 
tabla por precios diarios para tipos de habitación de un hotel por versión de 
tarifario existente, o sea que hay un registro diario por cada tipo habitación, 
versión de tarifario y la búsqueda utiliza los tres criterios de búsqueda 
(fecha, versión de tarifa, tipo de habitación)

Una vez que los datos se insertan, se actualizan muy poco y se puede consultar 
más o menos un millón de veces al día (aunque puede aumentar).

Hice una prueba con Pg10 y particionado declarativo, particionado la tabla 
trimestralmente por fecha y creando un índice único en cada partición 
utilizando los tres criterios. Los resultados obtenidos en una máquina que no 
tiene buenas prestaciones fueron bastante buenos, por lo que espero que en un 
server dedicado y con muchas mejores prestaciones sea aún mejor.

También quiero probar con particionado por herencia porque el declarativo no 
permite crear llaves primarias en la tabla particionada y puede que esta tabla 
sea referenciada desde otra tabla para temas de auditoría.

Gracias a todos por sus consejos. Saludos.

-Mensaje original-
De: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com] 
Enviado el: lunes, 5 de febrero de 2018 07:15 p. m.
Para: Lazaro Garcia
CC: pgsql-es-ayuda
Asunto: Re: Consulta de tabla con millones de registros

2018-01-29 15:17 GMT-05:00 Lazaro Garcia :
>
> Recientemente estoy trabajando en un sistema donde se tendrá una tabla 
> que puede contener millones de tuplas, por encima de los 50 millones y 
> el propósito de la tabla será almacenar precios de un producto por día 
> para cada uno de los clientes existentes. Sobre la tabla se ejecutarán 
> más lecturas que escrituras y las lecturas deben ser bien rápidas.
>

y cual es el problema? o te estás adelantando a la posibilidad de problemas? 
porque si es así recuerda que "la optimización adelantada es la raíz de todos 
los males" (cita de Donald Knuth)

la realidad es que podrías tener problemas, o no... he visto, en el mismo 
sistema, una tabla de más de 700millones de registros que no se ha particionado 
y una tabla de 130millones que tuvo que ser particionada para que el sistema 
funcione.

La pregunta es: como será el uso de la tabla? dices que habrán más escrituras 
que lecturas, eso es lo más común ahora puedes decir cuantas veces se 
actualizará el mismo registro? en que periodo de tiempo? como serán las 
consultas (sobre el PK, se leerá en rangos, rangos grandes o pequeños)? y los 
updates?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services