Re: Dudas con la replicacion SR o SR +HS

From: Kernel <jucabapa(at)gmail(dot)com>
To: Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Dudas con la replicacion SR o SR +HS
Date: 2012-12-20 16:40:12
Message-ID: 50D33F6C.1030706@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

El 20/12/2012 15:12, Jaime Casanova escribió:
> 2012/12/17 Kernel <jucabapa(at)gmail(dot)com>:
>> si la opción SR ya me esta sincronizando, ¿ para que necesito copiar los
>> ficheros wal de una maquina a otra ?, supongo que algo aportara pero no lo
>> veo
>>
> no lo necesitas
>
>> ¿deberia utilizar solo Streaming replication?
>>
> depende
>
>> ¿que pasa si el servidor de respaldo no tiene conexión con el principal ?
>>
>> ¿ Guarda el servidor principal las transacciones que no han sido
>> replicadas?
>>
> ah! y entramos a analizar las circunstancias...
> si y no.
> es responsabilidad del servidor de respaldo pedir lo que necesita, el
> principal tiene su propia agenda lo que incluye limpiar los registros
> muertos que ya nadie necesita... eventualmente el principal
> reutilizará los ficheros wal y perderás esa información.
>
> cuando el servidor de respaldo se conecte, pedira lo que necesita pero
> podria ocurrir que ya no esta disponible.
>
> tienes 2 soluciones a ese problema:
>
> 1) wal_keep_segments. si seteas este parametro a un valor > 0 se
> guardaran los ultimos $(wal_keep_segments) ficheros wal aun cuando el
> principal ya no los necesite. si lo seteas a un valor muy alto tu
> servidor de respaldo podria estar abajo varias horas, un día o mas...
> pero dependerá de que tan rápido se consumen ficheros wal (nivel de
> transaccionalidad) en el principal.
> por ejemplo, en un cliente se generan 5000 ficheros wal cada 2 horas,
> asi que poniendo ese parametro en 5000 se aseguran de poder tener el
> servidor de respaldo abajo hasta 2 horas (cosa que no hacen)...lo malo
> es que guardar 5000 ficheros wal en el principal significa tener 80gb
> de espacio ocupado permanentemente.
>
> 2) archivado de ficheros wal. si en cambio archivas los ficheros wal
> (ya sea en un directorio en el principal o un directorio en el
> servidor de respaldo o, lo ideal, en una tercera maquina) y seteas
> restore_command en el archivo recovery.conf en el servidor de
> respaldo. Entonces al volverse a conectar y darse cuenta que el
> principal ya no tiene la información que necesita, el servidor de
> respaldo empezará a copiar ficheros wal del archivo hasta estar en una
> posición en que el principal pueda empezar a proveer la información
> registro a registro nuevamente
>
>> cuando se estabilice la conexión ¿ sigue por donde lo dejo?
>>
> tratara
>
>> Si el servidor de respaldo no tiene conexión , ¿ralentiza de alguna manera
>> al principal?
>>
> no a menos que hayas pedido replicación sincrónica, en ese caso el
> principal esperará a que el servidor de respaldo reaparezca... ¿como
> sino habría sincronía?
> asi que si vez que puede existir ese problema usa solo replicación
> asincrónica (que es el predeterminado)
>
> --
> Jaime Casanova www.2ndQuadrant.com
> Professional PostgreSQL: Soporte 24x7 y capacitación
> Phone: +593 4 5107566 Cell: +593 987171157
>
OK, muchas gracias por tu tiempo , despues de releer la documentacion y
lo que me has enviado lo he visto mas claro,lo he dejado con los dos,
SR+HS, segun el ejemplo y la verdad es que va fenomenal.

Ahora me preocupa la seguridad, he abierto el puerto ssh del esclavo
para la ip del maestro para copiar los wal y he abierto el puerto 5432
para el esclavo , pero no estoy utililizando ssl.

por lo que leido la conexion ssl utiliza el mismo puerto.
¿me vale el mismo certificado del apache?, ¿alguna guía sencilla?

Gracias

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Juan 2012-12-20 16:56:45 Re: configuracion del postgres.
Previous Message Juan 2012-12-20 16:19:26 Re: configuracion del postgres.