Re: recovery_min_apply_delay y WAL

El 11 de abril de 2018, 15:09, Hellmuth Vargas <hivs77(at)gmail(dot)com> escribió:

> Hola Geraldo
>
> Gracias por la respuesta, pero si para ponerla al día se necesita los WAL
> archivados entonces no seria el escenario 1, precisamente lo que quieres
> saber es si la replica retrasada va guardando los WAL que genera la master
> y esta los va aplicando a medida que van cumpliendo el criterio del delay,
> por lo tanto si uno la promueve a master esta se pondría a dia pues tendría
> todos los WAL necesarios para eso.
>
>
> El 11 de abril de 2018, 11:20, Gerardo Herzig<gerardo(dot)herzig(at)ayres(dot)io>
> escribió:
>
>>
>>
>> El 11 de abril de 2018, 12:21, Hellmuth Vargas <hivs77(at)gmail(dot)com>
>> escribió:
>>
>>> Hola Lista
>>>
>>> Tengo configurado un Cluster PostgreSQL 9.6 con dos Replicas
>>> asincronicas una de ellas con el parámetro recovery_min_apply_delay
>>> (recovery.conf) en 300min, lo que significa que esta replica esta
>>> retrasada 5 horas con respecto a la master, pero tengo una duda con
>>> respecto al comportamiento de los archivos WAL:
>>>
>>> 1. La replica 'retrasada' solicita y mantiene los WAL que va generando
>>> la master y va aplicando estos WAL en la replica? ó
>>>
>>> 2. La replica va solicitando los WAL de hace 5 horas las master y los va
>>> aplicando?
>>>
>>> Porque la duda, si la master y la otra replica se dañaran y la replica
>>> retrasada se comportara como el caso 1, pues podría promoverla a master y
>>> esta se debería poner 'al día' con las transacciones que alcanzo a generar
>>> la master. Pero si se comporta como el escenario 2, pues tendría solo una
>>> copia de hace 5 horas antes del incidente.
>>>
>>> Muchas Gracias Lista
>>>
>>>
>>>
>>>
>>> --
>>> Cordialmente, ta
>>>
>>> Ing. Hellmuth I. Vargas S.
>>>
>>
>>
>> El delay se da en el "apply", o sea, la respuesta es "numero 1". Me
>> parece, de todos modos, que para "ponerla al dia" lo habitual es hacer
>> archiving, lo cual te serviria para cualquiera de las replicas.
>>
>> HTH
>> Gerardo
>> --
>> --
>> Gerardo Herzig
>> Principal Consultant at Ayres Data Team
>> root at Via Postgres Argentina
>>
>
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
> Esp. Telemática y Negocios por Internet
> Oracle Database 10g Administrator Certified Associate
> EnterpriseDB Certified PostgreSQL 9.3 Associate
>
>

Entiendo, por eso intente aclarar que lo del archiving es una repuesta para
el caso mas general, de poner al dia cualquier replica.

Saludos
--
--
Gerardo Herzig
Principal Consultant at Ayres Data Team
root at Via Postgres Argentina