Replicacion y alta disponibilidad

From: "Roberto Guevara" <cygnus2k(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Replicacion y alta disponibilidad
Date: 2008-03-12 20:31:31
Message-ID: 57650fe50803121331u65e4ebd3k1f022692f8c05dd2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Gabriel Hermes Colina Zambra 2008-03-13 03:13:16 Re: Funcion SQL mas lenta que un SQL
Previous Message MIGUEL CANCHAS 2008-03-12 18:11:08 RE: Error con el COPY ???????????