Re: Consulta Pyreplica

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/

In response to

Browse pgsql-es-ayuda by date

  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