Re: Replicacion?

muy bien, perdon por la ignorancia....

muchas gracias nuevamente....

saludos pablo

El mié, 01-09-2004 a las 17:53, cbeltran escribió:
> "transaction tracking" se refiere al control de transaccion es decir:
>
> BEGIN TRANSACTION
> .
> .
> ROLLBACK (CUANDO HAY FALLAS)
> O
> COMMIT (CIERRE EXITOSO DE TRANSACCION)
>
>
>
> ----- Original Message -----
> From: "Pablo Marrero" <pablo(dot)marrero(at)bancaqm(dot)com(dot)uy>
> To: "cbeltran" <cbeltran(at)roldan(dot)net>
> Cc: "AyudaPostgres" <pgsql-es-ayuda(at)postgresql(dot)org>
> Sent: Wednesday, September 01, 2004 9:41 AM
> Subject: Re: [pgsql-es-ayuda] Replicacion?
>
>
> primero que nada MUCHAS GRACIAS por sus comentarios....
>
> estaba pensando en hacer algo parecido a lo que ustedes me comentan,
> pero las ideas que ustedes me dan estan buenas!!!
> Voy a ver si implemento sus comentarios....
>
> tengo una duda, tal vez por mi poco experiencia, a que se refieren
> cuando dicen "transaction tracking"......
>
> muchas gracias nuevamente.....
>
> saludos pablo
>
> El mié, 01-09-2004 a las 10:33, cbeltran escribió:
> > Pablo
> >
> > Nos agrada encontrar a alguien que tenga una necesidad similar a la
> nuestra.
> > Despues de haber hecho pruebas con Rserv y Erserv concluimos, al igual que
> > usted, que este tipo de herramientas esta hecho para replicar un master
> > versus multiples esclavos.
> >
> > Actualmente, tenemos una base de datos de diseño identico en cada uno de
> los
> > 10 servers en diferentes ciudades de Colombia que deben replicar a un
> server
> > Central y la solución en prueba consiste en:
> >
> > 1- Definir las tablas que deben replicar (no son todas).
> > 2- Definir una tabla de control que almacena apuntadores a cada una de las
> > lineas que hayan sido insertadas o actualizadas o borradas en las tablas a
> > replicar.
> >
> > CREATE SEQUENCE tablas_replica_id_seq start XX0000001 increment 1 maxvalue
> > 999999999 minvalue 1 cache 1 ;
> > CREATE TABLE tablas_replica (
> > tablas_replica_id integer DEFAULT
> > nextval('tablas_replica_id_seq'::text) NOT NULL,
> > tabla_nombre_replica char(90) NOT NULL,
> > Constraint PK_tablas_replica Primary Key (tablas_replica_id)
> > );
> >
> > CREATE SEQUENCE control_replica_id_seq start XX0000000000000001 increment
> 1
> > maxvalue 999999999999999999 minvalue 1 cache 1 ;
> > CREATE TABLE control_replica (
> > control_replica_id bigint DEFAULT
> > nextval('control_replica_id_seq'::text) NOT NULL,
> > tablas_replica_id integer NOT NULL,
> > linea_tabla_replica_id bigint NOT NULL,
> > operacion char(1), -- (Update, Insert, Delete)
> > Constraint PK_control_replica Primary Key (control_replica_id),
> > CONSTRAINT FK_tablas_replica_id1 FOREIGN KEY (tablas_replica_id)
> > REFERENCES tablas_replica(tablas_replica_id) ON DELETE CASCADE ON UPDATE
> > CASCADE
> > );
> >
> > Nota: los IDs con prefijo XX corresponden a las tablas de cada una de las
> > oficinas de las diferentes ciudades ejemplo XX = 02 Barranquilla, 03
> > Buenaventura, .., 18 Bogota-El Dorado. Este diseño permite que la base
> union
> > de las bases operativas identifique la base de la oficina donde se insertó
> > una linea de la tabla replicada y que no se choquen los primaries keys en
> la
> > base de datos del servidor central.
> >
> > En tablas_replica se deben agregar el nombre de las tablas a replicar de
> las
> > bases de datos de las oficinas operativas (masters).
> >
> > 3- Definir tres triggers con sus respectivas tres funciones en PL/pgsql
> para
> > cada una de las tablas definidas en tablas_replica en cada una de las
> bases
> > de datos de las oficinas operativas (a replicar). Por ejemplo para una
> tabla
> > llamada terceros (en replica en la oficina 18) se debe definir:
> >
> > CREATE FUNCTION "rpi_terceros"() RETURNS TRIGGER AS '
> > BEGIN
> > INSERT INTO control_replica (tablas_replica_id, linea_tabla_replica_id,
> > operacion) VALUES (180000001, NEW.terceros_id, ''I'');
> > RETURN NEW;
> > END;
> > ' LANGUAGE 'plpgsql';
> > CREATE TRIGGER tgi_terceros AFTER INSERT ON terceros FOR EACH ROW EXECUTE
> > PROCEDURE rpi_terceros();
> >
> > CREATE FUNCTION "rpu_terceros"() RETURNS TRIGGER AS '
> > BEGIN
> > INSERT INTO control_replica (tablas_replica_id, linea_tabla_replica_id,
> > operacion) VALUES (180000001, NEW.terceros_id, ''U'');
> > RETURN NEW;
> > END;
> > ' LANGUAGE 'plpgsql';
> > CREATE TRIGGER tgu_terceros AFTER UPDATE ON terceros FOR EACH ROW EXECUTE
> > PROCEDURE rpu_terceros();
> >
> >
> > CREATE FUNCTION "rpd_terceros"() RETURNS TRIGGER AS '
> > BEGIN
> > INSERT INTO control_replica (tablas_replica_id, linea_tabla_replica_id,
> > operacion) VALUES (180000001, OLD.terceros_id, ''D'');
> > RETURN OLD;
> > END;
> > ' LANGUAGE 'plpgsql';
> > CREATE TRIGGER tgd_terceros AFTER DELETE ON terceros FOR EACH ROW EXECUTE
> > PROCEDURE rpd_terceros();
> >
> > Nota: Es decir la tablas de control_replica tiene el movimiento de
> > Inserciones, actualizaciones y borrados de las tablas de la operación en
> > replica. Por supuesto los scripts de operacion deben tener transaction
> > tracking para los tres tipos de operaciones antes mencionados.
> >
> > 4- Dado que en los 3 puntos anteriores se definió la estructura de control
> > en la base de datos de cada oficina operativa, se debe definir un script
> (en
> > nuestro caso está en PHP con DB de PEAR) en el server Central, que recorra
> > los diferentes servidores via IP y previa conexión a la base local,
> conecte
> > a cada una de las oficinas obteniendo la primera linea de la tabla
> > control_replica para luego direccionar el contenido de la linea de la
> tabla
> > en replica (para I y U) o simplemente el ID (para D) y luego efectuar
> dicha
> > operacion en la respectiva tabla de la base Central. Una vez efectuada la
> > operacion en la base central se debe borrar la linea respectiva de
> > control_replica. Es recomendable generar transaction tracking tanto en la
> > operacion en base central, asi como en la operacion de borrado de
> > control_replica en la base de la ciudad operativa. Este anidado debe
> hacerse
> > para todas las lineas de la tabla control_replica. Este script debe ser
> > activado via crond con la frecuencia deseada, implicando esto la demora
> > entre la union de todas las bases operativas y la operacion real en cada
> una
> > de las oficinas operativas.
> >
> > Espero que le sirvan estos comentarios de un desarrollo real que ha hecho
> > muchos intentos y esta parece la solución mejor hasta el momento.
> >
> >
> >
> > ----- Original Message -----
> > From: "Pablo Marrero" <pablo(dot)marrero(at)bancaqm(dot)com(dot)uy>
> > To: "AyudaPostgres" <pgsql-es-ayuda(at)postgresql(dot)org>
> > Sent: Tuesday, August 31, 2004 2:41 PM
> > Subject: [pgsql-es-ayuda] Replicacion?
> >
> >
> > Hola, los molesto a ver si me pueden ayudar.....
> > Tengo dos bases de datos, operativas las dos, pero con datos distintos,
> > es decir, son dos agencias de la misma empresa. Ahora, necesito tener
> > además de esas dos una con los datos de las dos juntas para hacer
> > consultas........
> >
> > estuve provando con slony-1 pero por lo que vi es para replicar una base
> > en 1 o mas "esclavas"....
> >
> >
> > tienen alguna idea de como lo puedo solucionar......??
> >
> > muchas gracias de antemano....
> >
> > saludos pablo
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: No hagas 'kill -9' a postmaster
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: ¿Has leído nuestro extenso FAQ?
> >
> > http://www.postgresql.org/docs/faqs/FAQ.html
> --
> A/C Pablo Marrero
> Departamento de Desarrollo
> Banca de Quinielas de Montevideo
> Tel: 924-64-05 int 195-196
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: no olvides aumentar la configuración del "free space map"
--
A/C Pablo Marrero
Departamento de Desarrollo
Banca de Quinielas de Montevideo
Tel: 924-64-05 int 195-196
"Work like you don't need the money,
love like you've never been hurt,
and dance like no one is watching"
Satchel Paige