[pgpool-general: 995] Re: Fwd: Timestamp and pgpool-II 3.2

Diego Ayala netdiego81 at gmail.com
Thu Sep 13 23:10:09 JST 2012


Gracias Lazaro, el español es mi idioma, solo que como el foro de pgpool es
ingles, era para que se pueda entender.. gracias por la aclaracion, ahora
entiendo el por que de esta situacion(pensaba que igual debia de tomar el
now() del master, q al comitear se guardaba lo que el master generaba), la
verdad que por las funcionalidades y ventajas del pgpool-II , decidi
usarlo, estamos en etapa de pruebas de funcionamiento justamente, para
poder meterlo a produccion. estuve viendo la funcionalidad del postgresql
con replicacion sincronica, pero no se que tan eficaz sea, tal vez sea por
desconocimiento mio.. A mi entender, el pgpool-II, es mejor, tu utilizas la
replicacion sincronica del Postgres ? que tal es, asi, tambien lo estaria
probando para ver que tal funciona.

una vez mas, gracias por la aclaracion y ayuda.

2012/9/13 Lazáro Rubén García Martínez <lgarciam at vnz.uci.cu>

> Hola Diego, te escribo en español, porque vi que los campos de tu tabla
> están escritos es español y supongo que ese sea tu idioma. Si no es el caso
> me respondes.
>
> Según estuve viendo en tu fichero de configuración, estas utilizando la
> replicación síncrona de pgpool-II mediante el modo replication_mode=on.
>
> Lo que sucede es que los parámetros de fecha tienen un default con la
> funcion now() y cuando a pgpool le llega esta consulta, al esta ser enviada
> a cada nodo, el resultado de now() en cada uno puede ser diferente como es
> el caso, pues cada una se ejecuta en cada servidor de manera independiente.
> Cuando yo estuve utilizando este método de replicación, me sucedía lo mismo
> y el convenio que se utilizó en el desarrollo, era calcular las fechas
> desde la app y pasarlas a la función como parámetro.
>
> Otra alternativa es utilizar streaming replication, de esa forma
> garantizas que todo lo que sea guardado en el master exista identicamente
> en los standby, y como pude apreciar al estar en 9.1 puedes también
> utilizar replicación sincrona nativa de postgres que ya está incluida en
> esa versión.
>
> Saludos.
> ________________________________________
> From: Diego Ayala [netdiego81 at gmail.com]
> Sent: Thursday, September 13, 2012 8:52 AM
> To: Tatsuo Ishii
> Cc: pgpool-general at pgpool.net; Lazáro Rubén García Martínez
> Subject: Re: [pgpool-general: 989] Re: Fwd: Timestamp and pgpool-II 3.2
>
> thanks for replying,
>
> I have my development database that contains the table test. well, to
> insert records, comparing both tables and I see the difference in
> milliseconds that were generated in each server. I need that times are
> exact, since we have a procurement system for auction, which requires the
> milliseconds, and that can make a difference to any bidder wins the bid.
> the truth is that it's random, I went back to try and generate some logs
> me equal, and others have differences in milliseconds
>
> CREATE TABLE test
> (
>   id bigserial NOT NULL,
>   namecharacter varying(200),
>   alta timestamp without time zone DEFAULT now(),
>   mod timestamp with time zone DEFAULT now()
> )
> WITH (
>   OIDS=FALSE
> );
>
>  insert into test(name) values('first test');
>
>
> server 1 : select * from prueba;
>  id |            nombre            |       tiempo        |            alta
>            |              mod
>
> ----+------------------------------+---------------------+----------------------------+-------------------------------
>   1 | diego                        | 2012-09-04 14:23:45 |  2012-09-04
> 14:25:33.040833 |   2012-09-04 14:56:57.631909-04
>   2 | ayala                        | 2012-09-04 14:24:22 |  2012-09-04
> 14:25:33.040833 |   2012-09-04 14:56:57.631909-04
>   3 | pepe                         | 2012-09-04 14:24:28 |  2012-09-04
> 14:25:33.040833 |   2012-09-04 14:56:57.631909-04
>   4 | mujica                       | 2012-09-04 14:24:35 |  2012-09-04
> 14:25:33.040833 |   2012-09-04 14:56:57.631909-04
>   5 | rolo                         | 2012-09-04 14:25:45 |     2012-09-04
> 14:25:45.143966   |    2012-09-04 14:56:57.631909-04
>   6 | chespi                       | 2012-09-04 14:26:00 |   2012-09-04
> 14:25:59.735838 |    2012-09-04 14:56:57.631909-04
>   7 | trifulcio rapado             | 2012-09-04 14:26:26 |  2012-09-04
> 14:26:26.056678 |    2012-09-04 14:56:57.631909-04
>   8 | eraldo                       | 2012-09-04 14:27:45 |     2012-09-04
> 14:27:45.082837 |    2012-09-04 14:56:57.631909-04
>   9 | CORTINAS                     | 2012-09-04 14:53:07 |  2012-09-04
> 14:53:07.086145 |   2012-09-04 14:56:57.631909-04
>  10 | PUERTAS                      | 2012-09-04 14:57:30 |  2012-09-04
> 14:57:30.109121 |   2012-09-04 14:57:30.109121-04
>
>  11 | prueba de desarrollo         | 2012-09-13 09:05:25 |  2012-09-13
> 09:05:25.393988 |   2012-09-13 09:05:25.393988-04
>  12 | segunda prueba de desarrollo | 2012-09-13 09:06:24 |  2012-09-13
> 09:06:24.083936 |   2012-09-13 09:06:24.083936-04
> (12 rows)
>
>
>
> server 2: select * from prueba;
>  id |            nombre            |       tiempo        |            alta
>            |              mod
>
> ----+------------------------------+---------------------+----------------------------+-------------------------------
>   1 | diego                        | 2012-09-04 14:23:45 |   2012-09-04
> 14:25:33.042316 |    2012-09-04 14:56:57.633128-04
>   2 | ayala                        | 2012-09-04 14:24:22 |   2012-09-04
> 14:25:33.042316 |   2012-09-04 14:56:57.633128-04
>   3 | pepe                         | 2012-09-04 14:24:28 |   2012-09-04
> 14:25:33.042316 |   2012-09-04 14:56:57.633128-04
>   4 | mujica                       | 2012-09-04 14:24:35 |   2012-09-04
> 14:25:33.042316 |   2012-09-04 14:56:57.633128-04
>   5 | rolo                         | 2012-09-04 14:25:45 |   2012-09-04
> 14:25:45.144954 |   2012-09-04 14:56:57.633128-04
>   6 | chespi                       | 2012-09-04 14:26:00 |   2012-09-04
> 14:25:59.736717 |   2012-09-04 14:56:57.633128-04
>   7 | trifulcio rapado             | 2012-09-04 14:26:26 |   2012-09-04
> 14:26:26.057284 |   2012-09-04 14:56:57.633128-04
>   8 | eraldo                       | 2012-09-04 14:27:45 |   2012-09-04
> 14:27:45.083635 |    2012-09-04 14:56:57.633128-04
>   9 | CORTINAS                     | 2012-09-04 14:53:07 |   2012-09-04
> 14:53:07.087332 |   2012-09-04 14:56:57.633128-04
>  10 | PUERTAS                      | 2012-09-04 14:57:30 |   2012-09-04
> 14:57:30.110247 |   2012-09-04 14:57:30.110247-04
>
>  11 | prueba de desarrollo         | 2012-09-13 09:05:25 |   2012-09-13
> 09:05:25.393988 |   2012-09-13 09:05:25.393988-04
>  12 | segunda prueba de desarrollo | 2012-09-13 09:06:24 |   2012-09-13
> 09:06:24.083936 |   2012-09-13 09:06:24.083936-04
> (12 rows)
>
>
>
>
> lazaro therefore seen, the watchdog does almost the same as the hearbeat,
> just as enbebido say already in the nucleus of pgPool-II, also, it proves
>
> thanks for the help
>
>
>
>
>
>
>
>
>
>
>
> 2012/9/12 Lazáro Rubén García Martínez <lgarciam at vnz.uci.cu<mailto:
> lgarciam at vnz.uci.cu>>
> The core of pgpool-II 3.2 has a new functionality developed for the high
> availability of pgpool, it is called watchdog. Maybe you could use it
> instead of heartbeat. This is not the case of the problem, this is only one
> recomendation.
>
> Regards.
> ________________________________________
> From: pgpool-general-bounces at pgpool.net<mailto:
> pgpool-general-bounces at pgpool.net> [pgpool-general-bounces at pgpool.net
> <mailto:pgpool-general-bounces at pgpool.net>] On Behalf Of Diego Ayala [
> netdiego81 at gmail.com<mailto:netdiego81 at gmail.com>]
> Sent: Wednesday, September 12, 2012 5:18 PM
> To: Tatsuo Ishii
> Cc: pgpool-general at pgpool.net<mailto:pgpool-general at pgpool.net>
> Subject: [pgpool-general: 989] Re: Fwd: Timestamp and pgpool-II 3.2
>
> this is my config file. forget to mention, I'm also using heartbeat, high
> availability for pgPool-II
>
> 2012/9/12 Tatsuo Ishii <ishii at postgresql.org<mailto:ishii at postgresql.org
> ><mailto:ishii at postgresql.org<mailto:ishii at postgresql.org>>>
> > good afternoon, I have a question, if you could get me out of doubt, to
> have
> > a timestamp() without time zone NOT NULL DEFAULT now (), to replicate,
> > there differences
> > in thousandths between each server. That is a problem or pgPool-II, there
> > is a solution to not happen? I'm using version 3.2 on pgPool REL6-II and
> > PostgreSQL 9.1
> >
> > thanks for the help
> >
> > eg
> > Server 1 =  2012-09-04 14:57:30.109121-04
> > Server 2 =  2012-09-04 14:57:30.110247-04
>
> Please show us pgpool.conf.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
>
> ________________________________
> Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE
> ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
> http://www.antiterroristas.cu
> http://justiciaparaloscinco.wordpress.com
>
> Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE
> ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
> http://www.antiterroristas.cu
> http://justiciaparaloscinco.wordpress.com
>
>
> ________________________________
> Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE
> ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
> http://www.antiterroristas.cu
> http://justiciaparaloscinco.wordpress.com
>
> Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE
> ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU!
> http://www.antiterroristas.cu
> http://justiciaparaloscinco.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20120913/b30f007d/attachment.html>


More information about the pgpool-general mailing list