Hola Alvaro Mmm claro, no había caído en cuenta! Gracias
El 17 ago. 2017 4:09 PM, "Alvaro Herrera" <alvhe...@2ndquadrant.com> escribió: Hellmuth Vargas escribió: > Hola Lista > > Si cierto!, yo tengo bases de datos que tiene tamaño de Teras y si no es > por pg_upgrade jamas podría haber actualizado a una versión superior, pues > la tarea con pg_upgrade se completa en minutos (el tiempo depende de > velocidad de disco, cpu, entre otros factores) máxime cuando se tratan de > bases 7x24, los tiempos de downtime deben ser mínimos.. eso si, no he > podido adoptar data-checksums pues solo se pueden establecer en la creación > de cluster (initdb) y esto no estaba disponible en la versión 9.1 en la > cual estaba originalmente una de las bases que gestiono y que ya se > encuentra en 9.6. Para implementar ese tipo de cambios puedes usar pglogical, donde tienes un segundo servidor replicando todo lo del primero. Como la replicación es lógica, no física, las diferencias en el storage no son importantes, así que puedes activar data checksums e implementar cualquier otro cambio que quieras. Se demora un tiempo en hacer la copia de datos, pero tu sistema primario sigue online durante ese tiempo; en cuando haya completado puedes hacer un failover y luego borrar el original y apuntar tu producción al sistema nuevo. Si pones un pgbouncer enfrente del servidor, entiendo que puedes hacerlo apuntar al servidor original, y cuando estés listo para el failover le das PAUSE, lo apuntas al servidor nuevo, le dices que continúe y listo -- las aplicaciones apenas se dan cuenta del cambio y no necesitas reconfigurar nada más que el pgbouncer mismo. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
