Re: pg_upgrade

Hola Alvaro

Gracias por responder, le respondo entre lineas tambien

El jue., 19 de jul. de 2018 a la(s) 10:09, Alvaro Hernandez (aht(at)ongres(dot)com)
escribió:

>
> Hola Hellmuth.
>
> Te contesto más abajo :)
>
> On 19/07/18 16:51, Hellmuth Vargas wrote:
>
> Hola Lista
>
> Tengo el siguiente esquema: una máster y 3 replicas Streaming Replication
> (distribuidas geográficamente y con diferentes prestaciones de velocidad de
> disco duro) en PostgreSQL 9.5. Deseo actualizarlas a PostgreSQL 10. Cuando
> realice el procedimiento de la 9.3 a la 9.5 seguí las indicaciones del
> numeral 10 de la documentación oficial de pg_upgrade que indica como debe
> procederse con la actualización de replicas sin necesidad de recrearlas
> desde 0 y todo estuvo muy bien pero tomo mas de 2 horas actualizar todas y
> por lo tanto la máster no pudo operar durante este periodo.
>
>
> ¿Por qué el master no puede operar durante este período? Salvo que sea
> una limitación a nivel de negocio, no hay razón técnica por la que el
> master, una vez upgradeado, esté online mientras se regeneren las réplicas.
>
>
Según la documentación la master debe estar abajo mientras se hace el
proceso de rsync del punto 10 que sincroniza las replicas, el prendido de
la master lo ejecutan en el punto 13

https://www.postgresql.org/docs/10/static/pgupgrade.html

>
> Quería preguntarles si es posible (para no tener que mantener la máster
> tanto tiempo apagada) realizar los siguientes pasos:
>
> - Actualizar la master con pg_upgrade
> - Actualizar una replica (la mas rápida) con el procedimiento descrito en
> el punto 10 de la documentación oficial del pg_upgrade
> -Prender master y replica actualizadas
> - Apagar la replica
> - Actualizar la replicas 9.5 faltantes a partir de la replica 10 empleado
> el mismo procedimiento descrito en el punto 10 de la documentación
> oficial del pg_upgrade. (como si la relpica 10 fuera la master)
>
> Porque no recrear las replicas desde cero, porque la base ya pesa 1.3 TB y
> para algunas replicas la recreación puede tardar 8 o 9 horas (la ultima vez
> que hubo necesidad de hacerlo por un daño de disco)
>
>
> ¿Usas archivado continuo? Si no es el caso, creo que deberías. Y en
> este caso, nada te impide hacer un backup base y tirar de los WALs
> archivados (que pueden estar en local) para generación más rápida de las
> réplicas.
>

La creación de las replicas con pg_basenbackup fue lo que tomo 8 y 9 horas
en algunos casos, no disponemos de los mejores canales de comunicación y
las prestaciones de las discos duros de las replicas remotas no son las
mejores.

>
> Dicho lo cual: si por continuidad de negocio es más grave estar online
> sin réplicas que parados hasta que al menos haya una réplica, entonces
> igual es un problema el tiempo de regenerar la réplica. Pero si no es el
> caso, yo usaría archivado continuo y regeneraría las réplicas.
>

La replicas se emplean para hacer balanceo de carga de los reportes, pero
inicialmente podrían redireccionarse a la master mientras sincronizo las
replicas

>
> También, estando en 9.5, tienes la opción de usar replicación lógica,
> en cuyo caso puedes actualizar versiones en master y réplicas
> independientemente.... (pero no estando en v10 en todos sitios, esto te va
> a suponer más trabajo, o vas a tener que usar pglogical).
>

>
> Saludos,
>
> Álvaro
>
>
> --
>
> Alvaro Hernandez
>
>
> -----------
> OnGres
>
>
>
>
>
> Que opina?? les agradezco sus comentarios.
>
> El link de la documentación de pg_upgrade para PostgreSQL 10.
>
> https://www.postgresql.org/docs/10/static/pgupgrade.html
>
>
> --
> Cordialmente,
>
> Ing. Hellmuth I. Vargas S.
>
>
>
>

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate