| From: | Javier Fritz Alsite <jfritz(dot)aliste(at)gmail(dot)com> |
|---|---|
| To: | pgsql-es-ayuda(at)postgresql(dot)org |
| Subject: | Re: Consulta PyReplica |
| Date: | 2009-10-13 20:02:03 |
| Message-ID: | 4AD4DCBB.50003@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-es-ayuda |
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hola.<br>
<br>
Como ya he comentado estoy instalando un "cluster de replicacion"
basado en PyReplica, creo que todo va bastante bien, ahora estoy
ajustando algunos valores para mejorar la performance. El punto que
busco solucionar ahora es el tiempo desde que ocurre un error,
normalmente por concurrencia, hasta que se reintenta la ejecución.<br>
<br>
<br>
<br>
Buscando en los archivos de PyReplica encontre un valor que se
pueden manejar para mejorar el tiempo de respuesta: time out entre
selects, lo ajuste a 3 seg, funciona mucho mejor, por defecto viene con
60 segs, pensando que estos servidores son exclusivos para el servicio
de postgres, y atienden a 5 usuarios mas 2 esclavos de PyReplica. El
problema principal sucede cuando dos nodos esclavos intentan leer el
mismo registro de forma concurrente, es un error conocido y se acepta
su condicion, pero el problema es el tiempo que demora en reintetar la
ejecución del query, a pesar de mejorar el rendimiento con el cambio
mencionado, creo que aun es lenta la reacción del servidor esclavo en
reintentar la ejecución, demora mucho mas de tres segundos.<br>
<br>
Ejemplo: <br>
<br>
A 15:57:07 - 3 inserts a una tabla en replicación (con trigger
py_log_replica), <br>
<blockquote>
<blockquote>
<blockquote>
<blockquote>
<blockquote>son ejecutados sin errores, en el maestro y sin
errores en el primer nodo, (el que leyo primero el cambio esta OK):</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<blockquote>
<blockquote>
<blockquote>insert into sys_tablas (tab_codtabla,<br>
tab_desctabla,tab_tipo,tab_codigo, tab_desc) <br>
values (1,'Vend','U','0006','abcdef');<br>
insert into sys_tablas (tab_codtabla,<br>
tab_desctabla,tab_tipo,tab_codigo, tab_desc) <br>
values (1,'Vend','U','0007','abcdef');<br>
insert into sys_tablas (tab_codtabla,<br>
tab_desctabla,tab_tipo,tab_codigo, tab_desc) <br>
values (1,'Vend','U','0008','abcdef');<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
B 15:57:54 - Envia correo electronico avisando de error
(Concurrencia)<br>
C 15:59:06 - Reestablece replicación.<br>
D 15:59:08 - Se completa la replicación, satisfactoriamente<br>
<br>
<br>
Como puede apreciarse el tiempo que transcurre entre que se detecta el
error "B" y el inició de la replicación "C" es al rededor de 1 minuto.
Pensando que solo se estan realizando 3 inserts, el tiempo tomado en la
replicación es mucho.<br>
<br>
<br>
Existe algun otro ajuste que pueda realizarse a los valores por
defectos de PyReplica.<br>
<br>
<br>
Otros: <br>
Sevidores:<br>
Tengo 3 servidores iguales:<br>
CPU : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz<br>
RAM :4 Gb.<br>
HD : 234 Gb.<br>
Conexion:<br>
4Mbps, con telefonica. (nada es perfecto)<br>
<br>
Javier Fritz Alsite wrote:
<blockquote cite="mid:4AC9F085(dot)90203(at)gmail(dot)com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Saludos.<br>
<br>
Revisando en las entreñas de las tablas involucradas he decubierto
lo que explica el problema. Los campos de tipo "serial" son creados
como "integer" el problema es que los valores asinados a la sequence
(MAXVALUE), no son soportador por este tipo de dato.<br>
<br>
<br>
Valor por defecto para una sequence:<br>
<pre wrap="">MAXVALUE 9223372036854775807</pre>
<br>
Maximo en un campo integer:<br>
2147483647<br>
<br>
Solucion: cambiar los campos afectado por la sequence a "bigint", o al
crear la tabla usar "bigserial" en vez de "serial"<br>
<br>
<br>
;)<br>
<br>
Atento a sus comentarios.<br>
<br>
<br>
Javier Fritz Alsite wrote:
<blockquote cite="mid:4AC94F8C(dot)60908(at)gmail(dot)com" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
Hola<br>
<br>
Con el cambio que propuso Mariano mejoro el panorama, con las
indicaciones dadas el query generado si es correcto y al ejecutarse el
query la "L" desaparece ;).<br>
<br>
El problema ahora esta en el trigger pero del esclavo, al hacer el
cambio en el maestro, el trigger genera ok el query en el replica_log
(maestro), este es capturado por el esclavo (que a su vez es maestro),
lo ejecuta y el triger captura el cambio en la tabla, pero al insertar
el registro en replica_log envia el siguiente mensaje:<br>
<br>
<pre wrap="">Traceback (most recent call last):
File "/usr/local/pyreplica/daemon.py", line 74, in run
debug = self.debug)
File "/usr/local/pyreplica/pyreplica.py", line 154, in main_loop
replicate(cur0, cur1, skip_user, slave_field, debug)
File "/usr/local/pyreplica/pyreplica.py", line 92, in replicate
cur1.execute(sql)
DataError: el entero está fuera de rango
CONTEXT: sentencia SQL: «INSERT INTO replica_log (sql) VALUES ($1)»
Buscando en el log de pyreplica en el esclavo encontre el query que se trae del maestro y al ejecutarlo manualmente sobre el esclavo envia:
WARNING: plpython: in function py_log_replica:
DETAIL: plpy.Error: Unknown error in PLy_spi_execute_plan
ERROR: el entero está fuera de rango
CONTEXT: sentencia SQL: «INSERT INTO replica_log (sql) VALUES ($1)»
********** Error **********
ERROR: el entero está fuera de rango
SQL state: 22003
Context: sentencia SQL: «INSERT INTO replica_log (sql) VALUES ($1)»
$1 corresponde al query que se ha ejecutado sobre una de las tablas del sistema, y segun la definición de la tabla el unico campo que puede dar este problema corresponde a "id" ya que es un serial. La seq. relacionada es
CREATE SEQUENCE replica_log_id_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 3223372036854776031
CACHE 1;
el valor dudoso es start, pero fue dado en base a las recomendaciones del manejo de sequencias para pyreplica (no se excluyo a replica_log) a este esclavo le corresponderia trabajar en el segundo tercio del rango.
Por ahora se me ocurre vaciar el replica log del esclavo y restablecer la seq.
atento a sus comentarios.
Saludos.
</pre>
<br>
<br>
<br>
Javier Fritz Alsite wrote:
<blockquote cite="mid:4AC67168(dot)9050109(at)gmail(dot)com" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
lo estoy probando en este instante te cuento el resultado<br>
Gracias :)<br>
<br>
<br>
<br>
Mariano Reingart wrote:
<blockquote
cite="mid:5aebd8250910021428q5fd1e675r136ab24fa854a0e8(at)mail(dot)gmail(dot)com"
type="cite">2009/10/2 Javier Fritz Aliste <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:javier(dot)fritz(at)lanix(dot)cl">javier(dot)fritz(at)lanix(dot)cl</a>></span><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Hola.<br>
<br>
Como estan, hace algun tiempo pedi ayuda sobre una solución de
replicación, he optado por PyReplica , y tengo el siguiente
problema.quizas de simple la solución, <br>
<br>
Tengo 3 servidores, cada uno tiene conexión con dos maestros
remotos, funciona aceptablemente bien, esta montado en servidores con
salida a internet con un trafico aun de prueba.<br>
<br>
Al grano, al realizar una insercion en una tabla que posee un
campo bigint, el triger esta capturando el query pero para el valor de
este campo lo concatena con "L", no se si esto es correcto, ya que al
ejectuar este query, se por el esclavo pyreplica o extrayendolo
manualmente y ejecutandolo sobre la base genera el error.<br>
<br>
</div>
</blockquote>
<div><br>
Hola Javier, parece ser un tema de conversión entre postgresql y
python, una solucion podria ser modificar el código del disparador en
plpython para que detecte los bigint de pg (long en python) y no le
agregue la L al convertirlos para el query sql:<br>
<br>
# function to convert value from python to postgres representation<br>
def mogrify(v):<br>
if v is None: return 'NULL' <br>
<span style="color: rgb(0, 153, 0);"> if isinstance(v,long):
return str(v) # no agregar L a long (bigint)</span><br>
if isinstance(v,basestring): <br>
r = repr(v)<br>
if not r.startswith('\"'):<br>
return r<br>
else:<br>
# postgres doesn't support ", replace and escape '<br>
return "'%s'" % r.replace("'","\\'")[1:-1]<br>
return "'%s'" % repr(v) # to get rid of bool that are passed as
ints (solved in pg8.3)<br>
<br>
Lo que hay que agregar es la linea verde despues de if v is None..
(respetando la identación):<br>
<span style="color: rgb(0, 153, 0);"><span
style="color: rgb(0, 0, 0);">if isinstance(v,long): return str(v)</span><br>
<br>
</span>No lo probé pero tendría que funcionar, cualquier cosa
avisame<br>
Sds<br>
Mariano<br>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
| Attachment | Content-Type | Size |
|---|---|---|
| unknown_filename | text/html | 10.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ing. Marcos Ortíz Valmaseda | 2009-10-13 20:13:37 | Errores de compilación de PgAdmin3-1.10 en Ubuntu 9.04 |
| Previous Message | Alvaro Herrera | 2009-10-13 19:52:41 | Re: Ordenar resultados complicados [Solucionado] |