El día 13/03/08, marcelo Cortez <jmdc_marcelo(at)yahoo(dot)com(dot)ar> escribió:
>
> Rodriguez
>
>
> En el año 2006 me contrataron del gobierno de la
> ciudad ( de bs as Argentina) para liderar un proyecto
> de migracion a postgres.
> El sistema original estaba en DBII ( IBM) y la
> applicacion cliente en VB.
> La Base de datos era/es bastante grande 173 millones
> de records y los records son bastante amplios porque
> por sobre todas las cosas poseen documentacion.
> El sistema se implemento, la alta disponibilidad esta
> dada por 2 clusters de postgres en un san con esquema
> de replicacion.
> El sistema esta abocado a mantener toda la
> documentacion de las mesas de entrada de todas las
> reparticiones publicas del gobierno de la ciudad.
> En el mismo se cargaron todos los expedientes desde el
> año 1950 aprox. Te daras cuenta que el volumen de los
> datos es bastante importante.
> el esquema de 2 clusters con hearbeat funciono de
> maravillas.
> Luego por razones politicas ( como todo proyecto del
> estado ( en mi pais)) ,me desligue del proyecto,pero
> con el contrato cumplido y con la tarea finalizada.
>
> espero esta referencia te sirva,cualquier otra cosa
> mandame correo a mi casilla o a la lista
> saludos
>
> mdc
>
> --- Rodriguez Fernando <rodriguez(at)ort(dot)edu(dot)uy>
> escribió:
>
>
> > 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
>
> > --
> > TIP 10: no uses HTML en tu pregunta, seguro que
> > quien responda no podrá leerlo
> >
>
>
>
> Tarjeta de crédito Yahoo! de Banco Supervielle.
> Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa.
> www.tuprimeratarjeta.com.ar
>