*Hola Martin*

> Hola Martin
> >
> > No, si me refería a la replica, porque en alguna oportunidad una Master
> se
> > "corrompio" (mas bien el sistema de archivos de Linux, faltas de
> corriente
> > recurrentes y fallas en la UPS... el paraiso en pocas palabras!!!!) y
> cuando
> > entro a operar la replica como master nos dimos cuenta que tenia  tablas
> con
> > paginas invalidas.. afortunadamente teníamos otra replica en otro
> servidor
> > completamente independiente la cual se encontraba  bien, pero en
> principio
> > estábamos confiados en que supuestamente la replica estaba bien.. por eso
>
> Como puede estar bien un replica si el maestro esta corrupto? Creo que
> es mejor si tratan de monitorear mejor los problemas de los servidores
> (usar SMART por ejemplo para ver corrupcion de FS)
>

>


> > preguntaba que si para mejorar la confiabilidad de las replicas se puede
> > implementar en ellas  page checksum pues estas generalmente no tiene
> tanta
> > carga de I/O ni compromiso en respuesta agil como sucede con las Master
>
> Habría que ver como se corrompió esa replica. O sea, porque esa
> replica estaba corrompida y la otra no. No será que tomaste un
> basebackup sobre datos en disco ya corrupto?
>
> Saludos,
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>



-- 

*Pues, la situación fue diferente en cada caso:*

*- La master, por apagados  abruptos, se corrompio el sistema de archivos
(linux, ext4)*
*- La replica 1 resulto con un  problema de segmentos de paginas invalidas,
(problema también de disco? sistema de archivos?) finalmente no lo
determinamos Pero eso no significa (ni implica) que los WAL sincronizados
 estuviesen corruptos ni mucho menos. Pues la prueba esta en que la replica
2 se encontraba en perfectas condiciones. Ambas replicas fueron generadas
al mismo tiempo después  una actualización de versión de la Master (9.1 a
9.3).*

*Muchas Gracias*




Cordialmente,

Ing. Hellmuth I. Vargas S.

Responder a