Re: Replicacion y alta disponibilidad

Roberto Guevara wrote:
> Hola a todos.
> Estamos tratando de migrar una base de datos Ideafix a postgres y
> tenemos que justificar el proyecto frente a la compra de Oracle.
> Les comento como operan hoy:
> La planta tiene dos servers principales IBM, uno primario y otro
> "muleto" al cual se le copian las modificaciones con un rsync.
> Los aplicativos y "base de datos" estan replicados en ambos servers y
> las lineas de produccion ejecutan remotamente al primario las
> aplicaciones. Como esta planta necesita una alta disponibilidad de
> datos porque no puede dejar parada las lineas de corte, encajado, etc.
> necesitamos implementar algo que haga automaticamente los que hacemos
> manualmente hoy. (De por si, si algo le ocurre al primario los
> aplicativos se tienen que reiniciar pero el tema es que lo haga con el
> menor impacto posible).
> Por ahora, y solo por ahora los aplicativos se van a dejar en el mismo
> primario (se replicaran al muleto tambien) y no en un server aparte.
>
> Por lo que vi en post anterior, hay un esquema (habian varios pero
> este me parecio el que mas se adecuaba) que podria reemplazar el
> esquema actual, http://www.linuxjournal.com/article/7834 ,pero del
> cual no tengo noticias si se implemento exitosamente y que performance
> tiene.
>
> Este Lunes fuimos con la gente de sistemas del frigorifico a Oracle
> argentina para que le ofrezcan su producto (yo fui de colado nomas). Y
> vi que les ofrecian RAC junto con DataGuard pero cambiando el esquema
> de trabajo actual a uno con muchos mas equipos(para el RAC) y
> finalmente con un punto de fallo el san, aunque ellos digan que es MUY
> improbable que se caiga el san le ofrecieron dataguard que le les hace
> el switchover/switchfail muy simple. Todo esto como se imaginaran les
> va a costar demasiada mosca, por el tema de los cores del rac y de los
> san ademas de los equipos y el ancho de banda que les consume el RAC, etc.
> Entonces ahi es cuando nuestro proyecto empieza a tomar valor ya que
> en este esquema no tiene una alta carga de consultas lo cual (para mi)
> no es indispensable el cluster y su excesivo consumo de la red. Y en
> lo que contingencias se trate existe como se menciono heartbeat con
> slony que teoricamente anda perfecto.
> Aparte de los casos de exito, benchmarks y demas, les presentamos un
> esquema heartbeat+slony con un caso de exito tendriamos altas
> probabilidades de que nos aprueben el proyecto. Por lo pronto estoy
> tratando de probarlo en los laboratorios pero por escaso tiempo
> todavia no terminamos de hacer las pruebas. y para ganar tiempo antes
> que se tome alguna decision les pedia a ustedes si conocen algun caso
> de exito o benchmarks de este esquema.
> Disculpen por lo extenso del mail y disculpas si me mande alguna (ya
> que Alvaro es demasiado puntilloso con los newbies)
>
> Saludos. y gracias anticipadas
>
Hola, es una decisión dificil y mas ardua es la justificación, ya que
Oracle cuesta U$S 40000(el esquema que te presentaron) y postgres es gratis.
Los puntos a favor de Oracle es que si hay problemas graves, tenes a
quien "caerle", en cambio postgres, todos te podemos ayudar.
Utilizar Postgres con Slony seria lo que tu necesitas y ademas un buen
esquema de respaldo (totales + logs).
En cuanto a los casos de exito no te puedo ayudar, pero escuche que un
supermecado (Importante, con presencia en todo el pais) de Uruguay va a
implementar sus sistemas con Postgres, migrando lo que ya tiene con
cierta base de datos antes nombrada.

Saludos Fernando