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
(lucasluen...@gmail.com <mailto:lucasluen...@gmail.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
<hmira...@gmail.com <mailto:hmira...@gmail.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 <hmira...@gmail.com>
<mailto:hmira...@gmail.com>
*Enviado el:* miércoles, 18 de marzo de 2020 18:16
*Para:* Ramón Alberto Bruening González
<albertobruen...@hotmail.com>
<mailto:albertobruen...@hotmail.com>; Pablo Ramirez
<depablos...@gmail.com> <mailto:depablos...@gmail.com>;
pgsql-es-ay...@postgresql.org
<mailto:pgsql-es-ay...@postgresql.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 <depablos...@gmail.com>
<mailto:depablos...@gmail.com>
*Enviado el:* martes, 17 de marzo de 2020 22:32
*Para:* pgsql-es-ay...@postgresql.org
<mailto:pgsql-es-ay...@postgresql.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
