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