RE: Replicacion y alta disponibilidad

Creo que ese caso es super interesante. Seria bueno, si se puede, que nos pueda docuemntar a todos sobre mas detalles de esta implementacion y mas especificamente con Heratbeat. Seria un buen empiezo para postgresql.cl

> Date: Thu, 13 Mar 2008 11:49:33 -0200
> From: jmdc_marcelo(at)yahoo(dot)com(dot)ar
> Subject: Re: [pgsql-es-ayuda] Replicacion y alta disponibilidad
> To: rodriguez(at)ort(dot)edu(dot)uy; cygnus2k(at)gmail(dot)com
> CC: pgsql-es-ayuda(at)postgresql(dot)org
>
> 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
> 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
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

_________________________________________________________________
Get your fix of news, sports, entertainment and more on MSN Mobile
http://www.msnmobilefix.com/Default.aspx