El 11 de abril de 2018, 15:09, Hellmuth Vargas <hiv...@gmail.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.her...@ayres.io> > escribió: > >> >> >> El 11 de abril de 2018, 12:21, Hellmuth Vargas <hiv...@gmail.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
