[off-topic] Replicación/sincronización postgresql

[Alberto Curro]

Chema Cortes escribió:
> El 5/02/08, Alberto Curro <acurro en wanadoo.es> escribió:
>
>   
>>   ¿alguien conoce algún sistema que me permita mantener sincronizadas
>> dos o más bases de datos (proyectos y otros) que llevo en mi portátil,
>> con el sistema servidor, con PostgreSQL?
>>
>>     Idealmente, debería basarse en scripts para poder automatizarlo de
>> quererlo en la conexión a la red.
>>     
>
> Supongo que la combinación pg_dump/pg_restore no te sirve. Mírate
> entonces el bucardo (http://bucardo.org), un "Asynchronous Multimaster
> Replication" hecho en perl.
>   
Hola Chema,

He pensado precisamente en una combinación similar. El problema es que 
quiero replicar en ambos sentidos la base de datos, dado que hay datos 
distintos (probabilidad, alta) en ambas bases de datos, y quiero que 
tras la sincronización ambas bases de datos queden de la misma forma.

Como verás, más que una replicación es una sincronización, una forma muy 
similar a una sincronización estacion <-> disco usb.

No estoy hablando de bases de datos temporales o sólo de proyectos o en 
desarrollo. Si voy a trabajar sobre ello y dedicarle tiempo, quiero 
hacerlo para bases de datos en producción y con datos reales... sólo por 
poner un ejemplo, quiero aplicarlo a soluciones con AbanQ que ya tengo 
funcionando, para los portátiles de los comerciales (por ejemplo).

Basándome en esto, pensé en una solución. No tengo mucha experiencia en 
Python, pero me parece que si algo le iría como un guante, sería esto. 
La idea en rasgos generales es la siguiete :

     - Tenemos la fecha de la última replicación (se habrá guardado, 
bien en fichero llave, bien en un registro sqlite o el contenedor 
deseado). Si no hay fecha, entonces se parte desde el principio.

    - Dada esa fecha, obtenemos los datos de ambas bases de datos a 
partir de los datos contenidos en las tablas de sistema del catálogo.

    - Diff entre ambos grupos de elementos.

    - El diff resultante a uno y otro lado arroja los registros nuevos  
para cada par, y los cambiados.

     ¿Problemas inherentes a este diseño?

    1) El diff debe aplicarse teniendo en cuenta que trabajamos con 
registros. Esto es, no me vale una salida diff estándar, sino que debe 
tener en cuenta que trabajamos con registros, y obtener los nuevos de 
uno u otro lado (que se aplicarán en el lado contrario mediante INSERT) 
y los registros que han cambiado, que se aplicarán en ambos lados 
mediante UPDATE... es un ejemplo general, eh?

    2) Si tenemos demasiados datos, el diff sobre ellos podría hacer que 
la cpu se disparase durante el diff de registros. Aunque... ¿qué se 
consideran demasiados datos para una máquina de potencia media actual? 
(pongamos, Athlon XP, 512MB RAM).

    3) Ambas bases de datos han de estar bloqueadas al resto de usuarios 
durante el proceso (no creo que sea difícil, supongo que PostgreSQL 
dispone de funcionalidad para ello).
   
  Prometo que me lo he pensado y diseñado más a fondo pero estoy 
respondiendo de cabeza y escribiendo lo que recuerdo :)

  ¿Ideas? ¿Pros? ¿Contras? Seguro que mi deficitario conocimiento a bajo 
nivel de postgresql hace que esta idea no sea muy buena y muy mejorable ;)

  Saludos

_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes