Hola. Desde el punto de vista de streaming replication, el hardware no es importante. Pueden tener distinto hardware. Es decir, ambos equipos (master y standby) pueden tener diferente hardware: distintas cpus, distinta memoria, etc.
La arquitectura sí es importante. Debe ser la misma arquitectura. Es decir, ambos tienen que ser 32 bits o ambos 64 bits. Además, las major version de Postgres deben ser iguales. Para el caso de 9.3 y 9.6, son distintas major version. Por lo tanto, no es posible según la documentación https://www.postgresql.org/docs/9.6/warm-standby.html Te pongo el texto y a continuación una traducción libre de un trozo del link anterior. Hardware need not be exactly the same, but experience shows that maintaining two identical systems is easier than maintaining two dissimilar ones over the lifetime of the application and system. In any case the hardware architecture must be the same — shipping from, say, a 32-bit to a 64-bit system will not work. In general, log shipping between servers running different major PostgreSQL release levels is not possible. It is the policy of the PostgreSQL Global Development Group not to make changes to disk formats during minor release upgrades, so it is likely that running different minor release levels on primary and standby servers will work successfully. El hardware no necesita ser exactamente el mismo, aunque la experiencia muestra que mantener dos sistemas idénticos es más fácil que mantener dos distintos durante toda la vida de la aplicación y el sistema. En cualquier caso la arquitectura hardware debe ser la misma - el envío desde, por ejemplo, un sistema 32 bits a un sistema 64 bits no funcionará. En general, el envío de log de transacciones entre servidores corriendo diferentes niveles mayores de versiones de Postgres no es posible. Es la política del PostgreSQL Global Development Group no hacer cambios a los formatos en disco durante actualizaciones de versiones menores, así que es probable que ejecutar diferentes niveles de versiones menores en servidores primario y esclavo funcionará correctamente. Espero que te sea de ayuda. On Tue, Mar 5, 2019 at 6:33 PM Carlos T. Groero Carmona <cton...@gmail.com> wrote: > Hola lista, > > Tengo la necesidad de mover mi BD de producion a otro servidor con mejoras > de hardware considerables. > > Estoy pensando en usar streaming replication para lograr el minimo tiempo > posible de shootdown, el problema con eso es que segun la bibliografia > consultada hasta el momento el harware deberia ser igual y las versiones de > postgres deverian ser con un minimo de diferencia. Debo comentar que si > tienen la misma arquitectura de hardware x86_64. > > En el servidor actual y master (Serv_1) tengo: > Postgres: 9.3.23 > CPU: 24 > RAM: 512 > DISK: SAN (2.5TB) > > Tambien tengo un SR a un servidor slave (Hot Standby Serv_2) > Ser_2 es exactamente igual a mi servidor 1 > > Nuevo Servidor (Ser_3): > Postgres: 9.6.9 > CPU: 36 > RAM: 512 > DISK: 5TB SSD inertno > > Y tengo un servidor (Serv_4) que es exactamente igual a mi servidor 3. > > Mi plan es poner a Serv_3 como Slave (hot standby) de Serv_1, y hacer un > cascade SR hasta Serv_4, Despues eliminar serv_1, y dejar mi Serv_3 como > master y 2 slave (serv_2 y serv_4) > > Pero antes de reconfigurar mi serv_2, le hara una actualizacion a 9.6 > > Donde veo el principal problema, es donde les tengo dos preguntas: > 1. Esposible hacer SR o cualquier otro typo de asyncronic replication > (tool) con hardwares similares pero no iguales. > 2. Creo que esta pregunta esta relacionada con la anterior, es posible una > vez que yo upgrade mi postgres a 9.6 en my serv_2 funcione esta replica? > > El problema es que necesito user serv_2 porque es mi disaster recovery, > Los servidores 1, 3 y 4 estan en la misma zona (norte del pais) y servidor > 2 es el unico que esta en el sur del pais. > > Lo peor de esta situacion es que es indispensable para el buen desempeno > de nuestras app/services tener listo esta migracion antes del viernes (2 > days), el tamano de mi base de datos es de 2TB. > > Una vez mas muchas gracias por cualquier sugerencia, > Carlos. > > >
