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
(a...@ongres.com <mailto:a...@ongres.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
