Re: [MASSMAIL]Re: Pregunta acerca de Streaming Replication

From: Lucas Luengas <lucasluengas(at)gmail(dot)com>
To: gilberto(dot)castillo(at)etecsa(dot)cu
Cc: "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com>, Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: [MASSMAIL]Re: Pregunta acerca de Streaming Replication
Date: 2019-03-05 22:47:28
Message-ID: CAHxAJ-KpciGJjj5d2HNR1UX5OPL7QptO4QBudSTsyj-Gj050Dw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Hola Carlos.
Sobre postgres_fdw no te puedo ayudar. No lo he usado nunca. Lo siento.
Sobre streaming replication, creo que sí que funcionaría. En cualquier
caso, quizás te ayude hacer un pequeño piloto con máquinas virtuales.
Podrías preparar 4 máquinas pequeñas virtuales por ejemplo con Virtual Box.
Posiblemente en las máquinas virtuales no puedas tener restaurada la base
de datos de producción, pero te permitirá probar que el entorno nuevo
funcionará y hacer el proceso antes de hacerlo realmente en producción.
Puedes familiarizarte y valorarlo. La idea de las máquinas virtuales creo
que te podría servir para valorar la opción que se adecua mejor a tu
entorno, sea streaming replication o postgers_fdw. Puedes ver cuál será más
fácil, más rápida, más adecuada para tu aplicación, etc. Así puedes ver lo
que mejor te funcionaría o incluso si hay algún problemas antes de
enfrentarte a hacerlo en producción.
Saludos.

En cualquier caso,

On Tue, Mar 5, 2019 at 11:00 PM <gilberto(dot)castillo(at)etecsa(dot)cu> wrote:

> Carlos,
>
> Al menos mientras esperar ya tienes casi listo s3 y s4 usando
> postgres_fdw. de hecho los puedes usar para consultas y demás en caso de
> algún problema.
>
>
>
> El 2019-03-05 16:35, Carlos T. Groero Carmona escribió:
> > Lucas, basicamente entonces solo debo:
> > 1. tener todos las versiones de postgres lo mas iguales posible
> > a) Bajar de postgres 9.6.9 a 9.3.25
> >
> > 2. Tengo la misma arquitectura x86_64 en todos mis servidores.
> >
> > 3. Esta situacion de un harware diferente en mi servidor 2 (diferente
> > a mi servidor 3 y 4 pero que necesito por mi disaster recovery) solo
> > seria temporal hasta que se ordene una actualizacion de hardware que
> > normalmente requiere al menos 30 dias, asi que supon que solo tendre
> > esta diferencia de hardware por 3 meses maximo.
> >
> > En este entorno, entonces stream replicacion funcionaria?
> >
> > Porque estaba pensando en usar postgres_fdw como me recomendo un
> > colega.
> >
> > Saludos,
> > Carlos
> >
> > On Tue, Mar 5, 2019 at 2:49 PM Lucas Luengas <lucasluengas(at)gmail(dot)com>
> > wrote:
> >
> >> Hola.
> >> Desde el punto de vista de streaming replication, el hardware no es
> >> importante. Pueden tener distinto hardware. Es decir, ambos equipos
> >> (master y standby) pueden tener diferente hardware: distintas cpus,
> >> distinta memoria, etc.
> >>
> >> La arquitectura sí es importante. Debe ser la misma arquitectura.
> >> Es decir, ambos tienen que ser 32 bits o ambos 64 bits.
> >>
> >> Además, las major version de Postgres deben ser iguales. Para el
> >> caso de 9.3 y 9.6, son distintas major version. Por lo tanto, no es
> >> posible según la documentación
> >> https://www.postgresql.org/docs/9.6/warm-standby.html
> >>
> >> Te pongo el texto y a continuación una traducción libre de un
> >> trozo del link anterior.
> >>
> >> Hardware need not be exactly the same, but experience shows that
> >> maintaining two identical systems is easier than maintaining two
> >> dissimilar ones over the lifetime of the application and system. In
> >> any case the hardware architecture must be the same — shipping
> >> from, say, a 32-bit to a 64-bit system will not work.
> >> In general, log shipping between servers running different major
> >> PostgreSQL release levels is not possible. It is the policy of the
> >> PostgreSQL Global Development Group not to make changes to disk
> >> formats during minor release upgrades, so it is likely that running
> >> different minor release levels on primary and standby servers will
> >> work successfully.
> >>
> >> El hardware no necesita ser exactamente el mismo, aunque la
> >> experiencia muestra que mantener dos sistemas idénticos es más
> >> fácil que mantener dos distintos durante toda la vida de la
> >> aplicación y el sistema. En cualquier caso la arquitectura hardware
> >> debe ser la misma - el envío desde, por ejemplo, un sistema 32 bits
> >> a un sistema 64 bits no funcionará.
> >> En general, el envío de log de transacciones entre servidores
> >> corriendo diferentes niveles mayores de versiones de Postgres no es
> >> posible. Es la política del PostgreSQL Global Development Group no
> >> hacer cambios a los formatos en disco durante actualizaciones de
> >> versiones menores, así que es probable que ejecutar diferentes
> >> niveles de versiones menores en servidores primario y esclavo
> >> funcionará correctamente.
> >>
> >> Espero que te sea de ayuda.
> >>
> >> On Tue, Mar 5, 2019 at 6:33 PM Carlos T. Groero Carmona
> >> <ctonetg(at)gmail(dot)com> wrote:
> >>
> >>> Hola lista,
> >>>
> >>> Tengo la necesidad de mover mi BD de producion a otro servidor con
> >>> mejoras de hardware considerables.
> >>>
> >>> Estoy pensando en usar streaming replication para lograr el minimo
> >>> tiempo posible de shootdown, el problema con eso es que segun la
> >>> bibliografia consultada hasta el momento el harware deberia ser
> >>> igual y las versiones de postgres deverian ser con un minimo de
> >>> diferencia. Debo comentar que si tienen la misma arquitectura de
> >>> hardware x86_64.
> >>>
> >>> En el servidor actual y master (Serv_1) tengo:
> >>> Postgres: 9.3.23
> >>> CPU: 24
> >>> RAM: 512
> >>> DISK: SAN (2.5TB)
> >>>
> >>> Tambien tengo un SR a un servidor slave (Hot Standby Serv_2)
> >>> Ser_2 es exactamente igual a mi servidor 1
> >>>
> >>> Nuevo Servidor (Ser_3):
> >>> Postgres: 9.6.9
> >>> CPU: 36
> >>> RAM: 512
> >>> DISK: 5TB SSD inertno
> >>>
> >>> Y tengo un servidor (Serv_4) que es exactamente igual a mi
> >>> servidor 3.
> >>>
> >>> Mi plan es poner a Serv_3 como Slave (hot standby) de Serv_1, y
> >>> hacer un cascade SR hasta Serv_4, Despues eliminar serv_1, y dejar
> >>> mi Serv_3 como master y 2 slave (serv_2 y serv_4)
> >>>
> >>> Pero antes de reconfigurar mi serv_2, le hara una actualizacion a
> >>> 9.6
> >>>
> >>> Donde veo el principal problema, es donde les tengo dos preguntas:
> >>> 1. Esposible hacer SR o cualquier otro typo de asyncronic
> >>> replication (tool) con hardwares similares pero no iguales.
> >>> 2. Creo que esta pregunta esta relacionada con la anterior, es
> >>> posible una vez que yo upgrade mi postgres a 9.6 en my serv_2
> >>> funcione esta replica?
> >>>
> >>> El problema es que necesito user serv_2 porque es mi disaster
> >>> recovery, Los servidores 1, 3 y 4 estan en la misma zona (norte
> >>> del pais) y servidor 2 es el unico que esta en el sur del pais.
> >>>
> >>> Lo peor de esta situacion es que es indispensable para el buen
> >>> desempeno de nuestras app/services tener listo esta migracion
> >>> antes del viernes (2 days), el tamano de mi base de datos es de
> >>> 2TB.
> >>>
> >>> Una vez mas muchas gracias por cualquier sugerencia,
> >>> Carlos.
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Carlos T. Groero Carmona 2019-03-06 06:01:27 Re: El rendimiento de postgres puede ser afectado por checkpoint_segments?
Previous Message gilberto.castillo 2019-03-05 22:00:17 Re: [MASSMAIL]Re: Pregunta acerca de Streaming Replication