Re: Replicación multimaestro.

Hola.

Necesito algo de ayuda para ver cual de los varios proyectos de
replicación debería estudiar. Por lo que he visto los que están
activos son Slony, postgres-r y pgcluster. Describo el uso pretendido:

Vamos a tener 5-15 sitios geográficamente distribuidos. Cada uno de
ellos tiene su propia base de datos, para poder operar de forma
autónoma. Esto ya está funcionando (en 5). Nuestra intención es
permitir que cada sitio tenga acceso a unas pocas tablas (3 o 4) de
los demás, para poder hacer cosas como recibir pagos de servicios
contratados en otra ubicación. Es importante que si estas
transacciones ocurren se vean reflejadas adecuadamente, pero no es
crítico que se puedan hacer en todo momento (es decir, si le tengo que
decir al cliente "lo siento, no puedo recibir ese pago por que no hay
red" no pasa nada, lo que no es aceptable decirle "no puedo recibir un
pago *local*", por eso no puedo simplemente poner un servidor central
en Internet y conectarlos a todos ahí). Tampoco es importantísimo que
se reflejen en tiempo real. En principio deberían haber pocos o nulos
conflictos, y es perfectamente aceptable que la replicación sea
"visible" a la aplicación (por ejemplo, no importa si tengo que poner
las tablas "externas" en un esquema, o usar otra conexión a la base de
datos o cosas así).

Nuestro flujo de transacciones es bastante bajo, del orden de 20
operaciones de escritura por hora por sitio. Aún no sé cuantas de
lectura, pero no muchisimas más.

Creo que lo que estoy describiendo es replicación parcial multimaestro
asíncrona, ¿cierto? En tal caso, ninguno de los proyectos que existen
parece ser lo adecuado, pero parece que pgcluster puede
acercarse. ¿Alguien de ustedes lo ha usado? ¿Saben que tan confiable
resulte?

Si ninguno de estos proyectos va por ahí, ¿alguien tiene idea de por
dónde buscarle?

Muy agradecido,

--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28

On Wed, Aug 01, 2007 at 02:32:43PM -0700, "L.S.C. Zorobabel Vega Díaz" wrote:
> Luis Rodrigo Gallardo Cruz escribió:
>> Vamos a tener 5-15 sitios geográficamente distribuidos. Cada uno de
>> ellos tiene su propia base de datos, para poder operar de forma
>> autónoma.
>
> Entiendo que si no hay linea no recibiras el pago? Entonces por que no
> generar un programa que conecte remotamente al servidor destinatario? para
> validar la info y registrar el pago directamente al lugar donde debe
> registrarse?

No es mala idea. Voy a revisar las demás implicaciones (¿cómo notifico
a todos los sitios las direcciones de los demás? ¿cómo aseguro las
conexiones?), quizá me funcione.

¡Gracias!

--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28

Luis Rodrigo Gallardo Cruz escribió:

> Necesito algo de ayuda para ver cual de los varios proyectos de
> replicación debería estudiar. Por lo que he visto los que están
> activos son Slony, postgres-r y pgcluster. Describo el uso pretendido:

Una cosa que hay que tener en cuenta es que Slony define
"maestro/esclavo" con granularidad de tablas, es decir, un servidor A
puede ser maestro de una tabla T1 y esclavo de la tabla T2 a la vez que
el servidor B puede ser maestro de la tabla T2 a la vez que esclavo de
la tabla T1.

En particular se puede tener una tabla padre P, y tablas hijas H1 y H2.
El servidor A es maestro para la tabla H1 y esclavo para H2, y el
servidor B es maestro para H2 y esclavo para H1. Entonces, cada
servidor puede ingresar datos en la tabla que le corresponde y luego al
examinar la tabla P va a obtener los datos consolidados, independiente
de en cual de los dos servidores la consultes.

Con un esquema como este me parece que siempre puedes aceptar un pago,
tanto local como remoto. ¿Nadie sería tan torpe de pagar dos veces en
dos sucursales distintas aprovechando que no hay red, verdad? (El caso
complicado ocurre cuando _tu_ tienes que pagar algo, y alguien lo cobra
en la sucursal 1 y despues en la 2 aprovechando que no hay red).

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)

Luis Rodrigo Gallardo Cruz escribió:
> Vamos a tener 5-15 sitios geográficamente distribuidos. Cada uno de
> ellos tiene su propia base de datos, para poder operar de forma
> autónoma. Esto ya está funcionando (en 5). Nuestra intención es
> permitir que cada sitio tenga acceso a unas pocas tablas (3 o 4) de
> los demás, para poder hacer cosas como recibir pagos de servicios
> contratados en otra ubicación. Es importante que si estas
> transacciones ocurren se vean reflejadas adecuadamente, pero no es
> crítico que se puedan hacer en todo momento (es decir, si le tengo que
> decir al cliente "lo siento, no puedo recibir ese pago por que no hay
> red" no pasa nada, lo que no es aceptable decirle "no puedo recibir un
> pago *local*", por eso no puedo simplemente poner un servidor central
> en Internet y conectarlos a todos ahí). Tampoco es importantísimo que
> se reflejen en tiempo real. En principio deberían haber pocos o nulos
> conflictos, y es perfectamente aceptable que la replicación sea
> "visible" a la aplicación (por ejemplo, no importa si tengo que poner
> las tablas "externas" en un esquema, o usar otra conexión a la base de
> datos o cosas así).
Entiendo que si no hay linea no recibiras el pago? Entonces por que no
generar un programa que conecte remotamente al servidor destinatario?
para validar la info y registrar el pago directamente al lugar donde
debe registrarse?

Esto podrias hacerlo modificando tu programa y hay varias alternativas
entre las que se me ocurren de primera instancia:

1) Conectar directamente al servidor remoto por el puerto de PGSQL
2) Utilizar alguna aplicacion web que reciba los parametros del pago y
regrese un resultado mediante XML (si tu app es web podrias revisar con
AJAX) si tu app es DESKTOP ya tendrias que ver como recuperar el
resultado arrojado por la plataforma web.

Saludos
--

P.D. Los acentos fueron removidos intencionalmente de este correo
electronico por alguna posible incompatibilidad con algun cliente de email.
------------------------------------------------------------------------
*L.S.C. Zorobabel Vega Díaz.*
*DASI Desarrollos S.A. de C.V.*
Los Mochis, Sinaloa.
Tel. 01 (668) 817 3293
http://www.dasi.com.mx

On Wed, Aug 01, 2007 at 04:35:10PM -0700, "L.S.C. Zorobabel Vega Díaz" wrote:
> Luis Rodrigo Gallardo Cruz escribió:
> "Asegurar las conexiones" es decir garantizarlas?

Es decir hacerlas seguras, como en "no espiables".

> P.D. Los acentos fueron removidos intencionalmente de este correo
> electronico por alguna posible incompatibilidad con algun cliente de email.

No deberías hacer eso, de verdad. La gente que en 2007 todavía usa
clientes de correo que no pueden ver acentos se lo tienen bien merecido.

--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28

Luis Rodrigo Gallardo Cruz escribió:

> No es mala idea. Voy a revisar las demás implicaciones (¿cómo notifico
> a todos los sitios las direcciones de los demás? ¿cómo aseguro las
> conexiones?), quizá me funcione.

Postgres tiene un modo SSL nativo para las comunicaciones. Si pones
"hostssl" en el pg_hba.conf (en lugar de "host") entonces la conexion
solo sera aceptada por el servidor si viene en SSL.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Luis Rodrigo Gallardo Cruz escribió:
> On Wed, Aug 01, 2007 at 02:32:43PM -0700, "L.S.C. Zorobabel Vega Díaz" wrote:
>> Luis Rodrigo Gallardo Cruz escribió:
>>> Vamos a tener 5-15 sitios geográficamente distribuidos. Cada uno de
>>> ellos tiene su propia base de datos, para poder operar de forma
>>> autónoma.
>> Entiendo que si no hay linea no recibiras el pago? Entonces por que no
>> generar un programa que conecte remotamente al servidor destinatario? para
>> validar la info y registrar el pago directamente al lugar donde debe
>> registrarse?
>
> No es mala idea. Voy a revisar las demás implicaciones (¿cómo notifico
> a todos los sitios las direcciones de los demás? ¿cómo aseguro las
> conexiones?), quizá me funcione.

Te sugiero alguno de los dominios dinamicos gratuitos DynDSN, NoIP, etc.
por cuestion de tiempo y costo, ahora si falla no tienes a quien
reclamarle que no resuelva correctamente.

Otra opcion seria crear tu propio servidor de dominios dinamicos basado
en BIND u otro servidor de correos (requeriras un sitio con IP publica).

"Asegurar las conexiones" es decir garantizarlas? esto no puedes hacerlo
ni a nivel LAN siempre hay factores que pudieran impedir la conexion,
pero partiendo de tu idea de que se trabajaria online si existe linea si
no no se puede creo que te puede bastar con esto.

Saludos

--

P.D. Los acentos fueron removidos intencionalmente de este correo
electronico por alguna posible incompatibilidad con algun cliente de email.
------------------------------------------------------------------------
*L.S.C. Zorobabel Vega Díaz.*
*DASI Desarrollos S.A. de C.V.*
Los Mochis, Sinaloa.
Tel. 01 (668) 817 3293
http://www.dasi.com.mx

Luis Rodrigo Gallardo Cruz escribió:
> On Wed, Aug 01, 2007 at 04:35:10PM -0700, "L.S.C. Zorobabel Vega Díaz" wrote:
>> Luis Rodrigo Gallardo Cruz escribió:
>> "Asegurar las conexiones" es decir garantizarlas?
>
> Es decir hacerlas seguras, como en "no espiables".
>
Ok si es directo a PGSQL u otra db y tu server es Linux/UNIX/Similar
podrias revisar los tunneles de SSH, otra alternativa que creo que
tambien te funcionaria con windows es STUNNEL.

Si lo vas a hacer mediante app web metes apache+sll y ya tienes tu app
con el trafico encriptado.

Saludos

--

P.D. Los acentos fueron removidos intencionalmente de este correo
electronico por alguna posible incompatibilidad con algun cliente de email.
------------------------------------------------------------------------
*L.S.C. Zorobabel Vega Díaz.*
*DASI Desarrollos S.A. de C.V.*
Los Mochis, Sinaloa.
Tel. 01 (668) 817 3293
http://www.dasi.com.mx