Re: pg_upgrade

    Hola de nuevo.

    Más comentarios abajo:

On 19/07/18 08:12, Hellmuth Vargas wrote:
>
> 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 <mailto: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

    No, eso no es lo que dice la documentación. Que en este caso
concreto se proponga levantar el master en el punto 13, no quiere decir
que no puedas generar una réplica con el master online. De hecho, sería
inaceptable que no pudiera hacerse eso. Revisa la doc de pg_basebackup:
https://www.postgresql.org/docs/current/static/app-pgbasebackup.html :

"pg_basebackup is used to take base backups of a running PostgreSQL
database cluster. These are taken without affecting other clients to the
database"

    Luego es online y no afecta a otros clientes.

>>
>> 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.

    Pero como lo puedes hacer con el master online, el único efecto que
tiene es una redundancia reducida durante esas 8-9 horas, pero no un
tiempo de parada del servicio.

>
>
>     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

    Entonces aún más claro aún :)

    Saludos,

    Álvaro

--

Alvaro Hernandez

-----------
OnGres