From: | "Ricardo Martin Gomez" <rimartingomez(at)hotmail(dot)com> |
---|---|
To: | listas(at)soft-com(dot)es |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: Sincronizacion simultanea de datos |
Date: | 2007-03-16 11:38:12 |
Message-ID: | BAY111-F29367FB6CF4E57C4D998C6A3710@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
>From: Oswaldo Hernández <listas(at)soft-com(dot)es>
>CC: pgsql-es-ayuda(at)postgresql(dot)org
>Subject: Re: [pgsql-es-ayuda] Sincronizacion simultanea de datos
>Date: Fri, 16 Mar 2007 11:46:30 +0100
>
>Independientemente de la respuesta que te de Alvaro, ahí van algunos
>comentarios:
>
>
>Ricardo Martin Gomez escribió:
>>Buenas Listeros y buenas Alvaro
>>Estuve leyendo la pagina que me mandaste sobre alta disponibilidad y
>>quisiera que me contestes o contesten un par de dudas sobre estos tipos ya
>>que me parecen que son que mas se acercan a la realidad del proyecto en el
>>cual estoy embarcado.
>>
>>Un dato a tener en cuenta es que en todos los servidores la BD va a tener
>>la misma estructura.
>>
>
>Esto es esencial, pero ten en cuenta que las estructuras suele ser
>necesario cambiarlas con el tiempo, tienes que tener previsto que vas a
>hacer cuando necesites hacer alguna modificación.
>
>>Replicacion sincronica multi-maestro: Cuales son los recursos minimos que
>>se necesitan para que esto ande bien. Por lo que lei una transaccíon no se
>>confirma si no se confirma en todos los servidores, si este es el caso:
>>¿que pasa si se cae un enlace a entre los servidores?
>>
>Recursos: Evidentemente un enlace muy rápido.
>Caidas: En el mejor de los casos los equipos que dependan de ese enlace no
>deben funcionar hasta que se restablezca la comunicación y se
>resincronicen. En el peor, imaginatelo ;)
>
>>Replicacion asincronica multi-maestro: Para este tipo, la cuestion es que
>>los conflictos se resuelven o por un usuario o por reglas definidas. Que
>>habria que tener en cuenta? Podria tener perdidas de datos y entonces no
>>tendria alta disponibilidad. Tambien como hago para que los Id's sean
>>iguales si cada servidor opera en forma independiente. Tambien lei que
>>esta solucion aun no es soportada por PostegreSQL.
>>
>El tema de los conflictos es muy delicado, hay que tener muy claras las
>reglas para resolverlos, y sobre todo, diseñar una organización en la que
>la posibilidad de conflicto se mínima.
>
>Evidentemente para los id ya no te vale un nextval(secuencia), hay que
>echarle un poco de imaginación al asunto: añadir otro valor que distinga
>unos id de otros, como un identificador del servidor; establecer un rango
>de id para cada servidor (con cuidado que no se sobrepasen); ...
>
>
>>Replicacion de sentencias en middleware: Esta podria ser una buena
>>implementacion en cuanto a performance y consistencia de datos, pero no me
>>quedo claro como mantener iguales los numeros de secuencias y los id's.
>>
>No te lo recomiendo. Aunque replicar datos sea mas pesado que replicar
>sentencias, es mas fiable.
>
>
>>Otra solucion que vi por ahi dando vueltas e investigando es tener una BD
>>local en y utilizar Slony-I para mantener en forma local los datos de las
>>otras sucursales. Este tambien se podria considerar solo que seria un poco
>>mas engorroso programar las consultas, segun me da la impresion.
>>
>Esto unicamente te soluciona el transporte de los datos desde las
>sucursales a la central, pero sigues teniendo los problemas de conflictos e
>ids.
>
>Pueden ser una solucion dependiendo de las necesidades reales y de la
>estructura de tu aplicación.
>
>
>>Me gustaria tener algunas sugerencias o mas datos sobre estas soluciones
>>para ver si estoy bien encaminado en el tema.
>>
>
>La replicacion master-master es algo bastante personalizado, require un
>buen analisis y mas que posible de cambios o de modificaciones importantes
>de la aplicación.
>
>Mi recomendacion es que contrates asesoramiento especializado.
Para este caso yo seria el personal especializado, ouchhhh!!!. Es por eso
que solicito ayuda a la lista.
>
>Saludos,
>
>--
>*****************************************
>Oswaldo Hernández
>oswaldo (@) soft-com (.) es
>*****************************************
>
>
>
>>Desde ya muchas gracias a todos y especialmente a vos Alvaro
>>
>>Saludos
>>Martin.
>>
>>
>>
>>
>>
>>>From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
>>>To: Ricardo Martin Gomez <rimartingomez(at)hotmail(dot)com>
>>>CC: pgsql-es-ayuda(at)postgresql(dot)org
>>>Subject: Re: [pgsql-es-ayuda] Sincronizacion simultanea de datos
>>>Date: Tue, 13 Mar 2007 16:11:49 -0400
>>>
>>>Ricardo Martin Gomez escribió:
>>> > Hola mis amigos listeros, ante todo buenas tardes para todos
>>> >
>>> > Estoy metido en un pryecto y no le encuentro la vuelta a la siguiente
>>> > situacion.
>>> > Una lista de servidores los cuales deben poseer todos la misma
>>>estructura y
>>> > datos.
>>> >
>>> > El problema viene dado cuando se realiza una transaccion (insercion,
>>> > actualizacion, delete) como hago para que la misma sea reflejada en
>>>todos
>>> > los servidores.
>>> >
>>> > La solucion debe ser a nivel de datos y directa. Estuve viendo algo de
>>> > Slony-I pero me parece que no me resuelve el problema por que no poseo
>>>la
>>> > estructura master-slave ya que todos son maestro y esclavos a la vez.
>>> > Ademas la aplicacion debe llevar bien un control de stock y con el
>>>mismo
>>> > debe ser posible saber en que local se encuentra el ultimo articulo en
>>>el
>>> > sistema.
>>>
>>>Por favor lee lo siguiente. Una vez que lo hayas leido podemos seguir
>>>conversando respecto a que es exactamente lo que quieres:
>>>
>>>http://www.postgresql.org/docs/8.2/static/high-availability.html
>>>
>>>--
>>>Alvaro Herrera
>>>http://www.CommandPrompt.com/
>>>The PostgreSQL Company - Command Prompt, Inc.
>>>
>>>---------------------------(fin del mensaje)---------------------------
>>>TIP 8: explain analyze es tu amigo
>>
>>_________________________________________________________________
>>Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
>>http://astrocentro.msn.es/
>>
>>
>>---------------------------(fin del mensaje)---------------------------
>>TIP 4: No hagas 'kill -9' a postmaster
>>
>
>
>---------------------------(fin del mensaje)---------------------------
>TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
Saludos
Martin.-
_________________________________________________________________
Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
http://astrocentro.msn.es/
From | Date | Subject | |
---|---|---|---|
Next Message | Gabriel Colina | 2007-03-16 12:01:49 | Re: cambio Encoding en Cliente en ems manager |
Previous Message | Javier Estévez CIFA Córdoba | 2007-03-16 10:49:59 | Script desde PosgreSQL a SQL SERVER |