Skip site navigation (1) Skip section navigation (2)

Re: Sincronizacion simultanea de datos

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 (view raw or flat)
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/


In response to

pgsql-es-ayuda by date

Next:From: Gabriel ColinaDate: 2007-03-16 12:01:49
Subject: Re: cambio Encoding en Cliente en ems manager
Previous:From: Javier Estévez CIFA CórdobaDate: 2007-03-16 10:49:59
Subject: Script desde PosgreSQL a SQL SERVER

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group