From: | Mariano Reingart <reingart(at)gmail(dot)com> |
---|---|
To: | Javier Fritz Alsite <jfritz(dot)aliste(at)gmail(dot)com> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Consulta Pyreplica |
Date: | 2009-11-03 15:56:08 |
Message-ID: | 5aebd8250911030756g745cb0d4t3ed15cc2a9badd04@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
2009/11/3 Javier Fritz Alsite <jfritz(dot)aliste(at)gmail(dot)com>
> Estimados.
>
> Estoy utilizando esta solución (pyreplica) y esta bastante estable, pero
> tengo el siguiente problema. Tengo tres servidores cada uno es maestro de
> los otros dos, debido a esto se producen cientos de bloqueos en la tabla de
> replicación, a pesar de ello en unos poco segundos las bases son
> sincronizadas en ambos esclavos (aprox. 10 seg, muy optimo, considerando en
> la replicación de 500 querys por internet). Hasta aqui todo bien.
>
> El problema que esta apareciendo ahora es que cada algun tiempo (10hrs ó
> mas) el hilo de replicación se suspende, no se detiene, de echo el
> "keepalive" continua enviando datos al log, pero los query's simplemente no
> se ejecutan en el destino, no se envian correos del error y en el log solo
> aparecen los keepalive del hilo. ¿alguna pista?, ¿quedo a la espera de
> alguna consulta?¿algun timeout no respetado?, se ajustaron todos a 3 seg, en
> las configuraciones de PyReplica.
>
>
Por algún motivo se debe estar bloqueando, hace un SELECT FOR UPDATE que es
muy costoso, mas si tenes varios esclavos.
> Por ahora al detectar una acumulación importante de datos pendientes, se
> reinicia el esclavo de pyreplica y se normaliza la situación, asi como
> tambien en algunos casos el bloqueo es tal que la la petición de una
> consulta demora muchisimo y ha sido necesario un restart al pgsql.
>
> Quizas el problema pase por ajustes al mismo motor, esto pensando en un
> timeout u otro parametro que ayude a "soltar" consultas que toman demasiado
> tiempo o que provoquen bloqueos prolongados, y asi no bloquear el servicio
> para el resto de los usuarios del motor.
>
>
El problema es el SELECT FOR UPDATE, habría que utilizar los id de
transacción (txid).
En ves de hacer:
SELECT id,sql FROM replica_log
WHERE NOT replicated
ORDER BY id ASC FOR UPDATE
Habría que hacer:
SELECT id, sql FROM replica_log
WHERE txid > mayor_txid_replicada OR txid IN (lista_de_txid_pendientes)
y obviamente se elimina la necesidad de marcar las filas replicadas en el
maestro:
UPDATE replica_log SET replicated=TRUE WHERE NOT replicated
Con lo que se eliminarían los bloqueos y actualizaciones en el maestro.
El tema es como almacenar la lista de txid pendientes en el esclavo, con la
función txid_current_snapshot():
http://www.postgresql.org/docs/8.4/interactive/functions-info.html
Sds
Mariano
http://www.arpug.com.ar/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-11-03 16:10:15 | Re: [pgsql-es-ayuda] Re: [arpug] Re: [arpug] Traducción al español del manual oficial |
Previous Message | Mariano Reingart | 2009-11-03 15:42:01 | Re: [arpug] Re: [arpug] Re: [arpug] Traducción al español del manual oficial |