Re: Información

On 20/03/2020 12:22 pm, Pablo Ramirez wrote:
> Saludos.
>
> Muchas gracias por la información estoy leyendo todas revisando cual
> me puede funcionar.  El esquema que necesito montar de replicacion 
> son dos:
>
> caso  1. El sistema por temas de rendimiento para no colapsar el
> servidor principal de Base de datos ya que es un sistema ERP permite
> que toda la reportera se pueda consultar en otro servidor de BD  por
> lo tanto el segundo servidor tiene que ser una replica. "esto según he
> consultado con ustedes y leído se puede hacer con archivos wal o
> hot-standby " (según he leído estas replicas solo sirven para consultas)
>
> caso 2. Un tercer servidor el cual se esta levantando diariamente un
> respaldo de la mayoría de las tablas transaccionales. dicho servidor
> de BD es consultado por un tercer sistema. pero esto no funciona del
> todo porque estamos hablando de un base de datos que puede llegar a
> pesar mas de 90 GB tarda horas en terminar a veces no levanta y con un
> dia de retraso.

90G no es nada, Yo administraba el registro civil de Chile y eran 10
Teras de datos.

Lo que debes hacer es revisar que estas haciendo que se esta demorando
tanto, ( red, copias usando rsync por ssh  usando una encriptación que
consume muchos recursos ), si tienes un NFS, revisa cuantos path (rutas)
tienes y asegurate de usar todas las tarjetas de red que puedas.

sí estas replicando por ssh ( revisa cuanto se demora con compresión ),
es mejor usar llaves y agregas la compresión en el archivo config
$HOME/.ssh/config

Ejemplo de una entrada con un cifrado liviano para mover datos ( solo
para mover archivos grandes ).

Host gentux2
  hostname localhost.localdomain.com
  port 2222
  Compression yes
  CompressionLevel 7
  Cipher blowfish
  User root

>   por lo que ya no es viable pero este sistema inserta información
> "Entonces el caso anterior no se puede aplicar aqui " necesito que
> actualice solo algunas tablas. " ahora he leído de la replicacion
> logica en la cual se tiene control de que tablas se van a actualizar
> pero creo que tampoco seria la solución por replica nativa de postgres
> en este caso no se que consultar"
>
> Sistema operativo Ubuntu server, postgres 12.2.

Si quieres usar reportes en una maquina y tener la maquina sincronizada
creo que esto puede ser mejor.

1.- Maquina de destino ( copias los archivos a un directori ocon
replicación  de postgresql ).

2.- Clonas ese directorio a una instancia nueva de postgresql ( ejemplo
/var/lib/pgsql/12/data2 ).

3.- abres la base de datos en data2 (para consultas o lo que quieras )
de esa forma tienen un DR operativo esperando que falle la base
principal y tienes en la maquina de DR una base abierta para consultas o
lo que quieras que refrescas cuando quieras, no solo en la noche, por
que el refresco se saca de la data en /var/lib/pgsql/12/data

4.- haces un script que te cambie el puerto en el postgresql.conf cada
que clones ( o con el rsync creas una excepción que no clone los
archivos que no quieras refrescar, esta ultima es mejor opción, pero
debes acordarte que esta esa opción de lo contrario cuando hagas un
clone completo para partir de cero vas a tener problemas si no te
acuerdas de este cambio ).

Hay varias formas para hacer la misma cosa, revisa las que te tomas mas
tiempo y revisa una alternativa para que sea rápida la copia.

PS: Sí te preocupa mucho el espacio usar OCFS o ZFS que tienen
deduplicación y sí copias las cosas un flag especial la misma dada no
usa más espacio, OCFS trae eso y me gusta OCFS por esa caracteristica
muy util a la hora de clonar cosas.

>
> El jue., 19 de mar. de 2020 a la(s) 05:58, Lucas Luengas
> (lucasluengas(at)gmail(dot)com <mailto:lucasluengas(at)gmail(dot)com>) escribió:
>
> Hola Pablo.
> Mi opinión es que lo mejor es que evalúes la réplica nativa
> (streaming replication, que se basa en WAL) de Postgres. Yo la uso.
> Pero tienes que ver si es lo que se adecua a tu caso. Hay mucha
> documentación, está probada y funciona.
> Puedes hacer una prueba en unas máquinas virtuales y
> familiarizarte con el proceso antes de ponerlo en producción.
> Además, se pueden tener varios servidores replicados como indicas.
> No sé en qué sistema operativo lo tienes ni la versión de
> Postgres. Aquí unos enlaces en Linux. Pero en Windows funciona igual.
>
> https://www.howtoforge.com/tutorial/postgresql-replication-on-ubuntu-15-04/
>
>
> https://blog.vpscheap.net/how-to-setup-replication-for-postgresql-in-centos-7/
>
>
>  Espero haberte ayudado.
>
>
>
> On Thu, Mar 19, 2020 at 3:21 AM Horacio Miranda
> <hmiranda(at)gmail(dot)com <mailto:hmiranda(at)gmail(dot)com>> wrote:
>
>
> On 19/03/2020 3:03 pm, Ramón Alberto Bruening González wrote:
>>
>> On 18/03/2020 2:34 pm, Ramón Alberto Bruening González wrote:
>>
>> No se si sea la forma mas correcta de realizar una replicación,
>>
>> Depende, hay replicaciones para tener datos de solo lectura y
>> hay replicaciones para tener un DR listo para una falla.
>>
>> Que es lo que andas buscando ? Lo que se busca es tener listo
>> la BD de respaldo por si falla el principal, pero seria con
>> un dia de atraso de pero funcional.
>>
> De hecho eso lo puedes mejorar de dos formas.
>
> Forma A).
>
> De forma fisica con DRDB
> (https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device)
>
> Esto lo hice con Oracle Standard usando dos servidores ( donde
> se replican los bloques a nivel de Storage ) la gracia es
> tener un script que desmonte el filesystem pasivo y monte el
> filesystem activo ( funciona super bien y es equivalente a
> apagar el servidor a la mala en el caso de un DR ).
>
> Forma B) por software, Postgresql soporta replicación Lógica y
> física ( con los PITR).
>
> Dado que estas haciendo un rsync, me enfoco en replicación
> física. (WAL),
>
> Pegale una mirada a esto.
>
> https://cloud.google.com/community/tutorials/setting-up-postgres-hot-standby
>
>>
>> pero en mi caso tengo un script en Linux que se ejecuta por
>> las noches, utilizando el comando rsync para sincronizar la
>> base de datos a nivel de filesystem. Bajo el servicio de
>> postgres en ambos servidores y corro el rsync, se sincroniza
>> con los cambios del dia, y al terminar se vuelven a levantar
>> los servicios. Hasta ahora me funciona, pero me gustaría
>> saber como hacer en tiempo real también.
>>
>> Esto es útil para bases chicas y que puedes bajar, para bases
>> grandes o que no puedes bajar puedes ver una alternativa como
>> snap-clone de HP o algo que saque una foto al Filesystem, que
>> Filesystem tienes? Ext4 utilizando LVM para la carpeta donde
>> esta la data de la BD.
>>
>> *De:* Horacio Miranda <hmiranda(at)gmail(dot)com>
>> <mailto:hmiranda(at)gmail(dot)com>
>> *Enviado el:* miércoles, 18 de marzo de 2020 18:16
>> *Para:* Ramón Alberto Bruening González
>> <albertobruening(at)hotmail(dot)com>
>> <mailto:albertobruening(at)hotmail(dot)com>; Pablo Ramirez
>> <depablos804(at)gmail(dot)com> <mailto:depablos804(at)gmail(dot)com>;
>> pgsql-es-ayuda(at)postgresql(dot)org
>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>
>> *Asunto:* Re: Información
>>
>> On 18/03/2020 2:34 pm, Ramón Alberto Bruening González wrote:
>>
>> No se si sea la forma mas correcta de realizar una
>> replicación,
>>
>> Depende, hay replicaciones para tener datos de solo lectura y
>> hay replicaciones para tener un DR listo para una falla.
>>
>> Que es lo que andas buscando ?
>>
>> pero en mi caso tengo un script en Linux que se ejecuta
>> por las noches, utilizando el comando rsync para
>> sincronizar la base de datos a nivel de filesystem. Bajo
>> el servicio de postgres en ambos servidores y corro el
>> rsync, se sincroniza con los cambios del dia, y al
>> terminar se vuelven a levantar los servicios. Hasta ahora
>> me funciona, pero me gustaría saber como hacer en tiempo
>> real también.
>>
>> Esto es útil para bases chicas y que puedes bajar, para bases
>> grandes o que no puedes bajar puedes ver una alternativa como
>> snap-clone de HP o algo que saque una foto al Filesystem, que
>> Filesystem tienes?
>>
>> *De:* Pablo Ramirez <depablos804(at)gmail(dot)com>
>> <mailto:depablos804(at)gmail(dot)com>
>> *Enviado el:* martes, 17 de marzo de 2020 22:32
>> *Para:* pgsql-es-ayuda(at)postgresql(dot)org
>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>
>> *Asunto:* Información
>>
>> Buen dia.
>>
>> Saludos a todos.
>>
>> Quería consultar de acuerdo a la experiencia de ustedes
>> respecto a replicación a BD en postgres alguna
>> documentación clara de  consejos así como  herramienta
>> que conozcan al respecto. Necesito crear réplicas en
>> diferentes servidores.
>>
>> Consulto por aquí debido a que la información que e
>> consultado del tema no es un poco confusa. Y busco el
>> mejor método.
>>
>> Gracias.
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>
>>
>> Virus-free. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus