Re: checkpoints y disaster recovery anatomy

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>
Cc: Richardson Hinestroza <richardhinestroza(at)gmail(dot)com>, POSTGRES <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: checkpoints y disaster recovery anatomy
Date: 2015-10-13 15:37:51
Message-ID: 20151013153750.GR4405@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Jaime Casanova escribió:
> 2015-10-12 11:29 GMT-05:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:

> > No se bloquean transacciones. Lo que se hace es que se hace un primer
> > recorrido sobre todos los buffers, marcando todos los que están DIRTY
> > con un flag CHECKPOINT_NEEDED (sin escribir nada a disco); luego se
> > empieza la escritura a disco haciendo un segundo recorrido que escribe a
> > disco todos los buffers que tienen ese flag.
>
> De hecho CreateCheckPoint() dice que si bloqueamos transacciones o al
> menos llamamos a WALInsertLockAcquireExclusive(), que según entiendo
> evitará que se escriba nuevo WAL (lo que en esencia bloquea las
> operaciones/transacciones de escritura).
> Aunque es periodo de tiempo muy corto, parece que solo el necesario
> para calcular el próximo punto de redo para que a partir de ahí se inserten
> los siguientes registros del WAL.

No es lo mismo --- eso bloquea sólo el "período crítico de commit" de la
transacción, que como tú dices es muy corto.

> > Si un segundo proceso modifica el buffer después del primer recorrido,
> > no se hace nada especial: la versión que se escriba en disco será la
> > versión modificada.
>
> según entiendo del comentario en BufferSync(), este segundo proceso,
> al ver el flag BM_CHECKPOINT_NEEDED, de hecho se encargaría de escribir
> el buffer a disco y sacarlo de shared_buffers, estoy en lo correcto?
> """
> * Whenever a page with BM_CHECKPOINT_NEEDED is written out,
> either by us
> * later in this function, or by normal backends or the
> bgwriter cleaning
> * scan, the flag is cleared. Any buffer dirtied after this point won't
> * have the flag set.
> """

Esto significa que todos los buffers con BM_CHECKPOINT_NEEDED tienen que
ser escritos, "ya sea por nosotros mismos" (es decir el proceso
checkpointer) o bien "por cualquier otro backend", o bien por el
bgwriter, y que la bandera se limpia una vez que la escritura ocurre.
El que salga o no de shared buffers (evict) va a depender de si lo
escribe el checkpointer o bgwriter (se queda en shared buffers) o lo
escribe un backend (sale de s.b., porque lo que el backend necesita es
el buffer para poder leer otra página). Finalmente, indica que
cualquier buffer que sea "dirtied" a partir de ese momento no va a tener
la bandera BM_CHECKPOINT_NEEDED y por lo tanto no necesitará escribirse
para completar el checkpoint.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Richardson Hinestroza 2015-10-13 17:18:41 Re: checkpoints y disaster recovery anatomy
Previous Message Horacio Miranda 2015-10-13 15:12:13 Re: Re: [pgsql-es-ayuda] Select con agregacion por períodos