Esperando 8.5 - hot standby -- WAITING FOR 8.5 – HOT STANDBY

Esta entrada es una traducción de https://www.depesz.com/2010/01/08/waiting-for-8-5-hot-standby/
La traducción puede contener errores.
This entry is a translation of  https://www.depesz.com/2010/01/08/waiting-for-8-5-hot-standby/
The translation may contain errors.

El 19 de diciembre (se refiere al 19 de diciembre de 2009) Simon Riggs subió un parche que probablemente será el cambio más hablado en PostgreSQL 8.5.

Log Message:
-----------
Allow read only connections during recovery, known as Hot Standby.


Enabled by recovery_connections = on (default) and forcing archive recovery
using a recovery.conf. Recovery processing now emulates the original
transactions as they are replayed, providing full locking and MVCC behaviour
for read only queries. Recovery must enter consistent state before
connections are allowed, so there is a delay, typically short, before
connections succeed. Replay of recovering transactions can conflict and in
some cases deadlock with queries during recovery; these result in query
cancellation after max_standby_delay seconds have expired. Infrastructure
changes have minor effects on normal running, though introduce four new
types of WAL record.

New test mode "make standbycheck" allows regression tests of
static command behaviour on a standby server while in recovery. Typical and
extreme dynamic behaviours have been checked via code inspection and manual
testing. Few port specific behaviours have been utilised, though primary
testing has been on Linux only so far.


This commit is the basic patch. Additional changes will follow in this
release to enhance some aspects of behaviour, notably improved handling of
conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL
are also required.

Simon Riggs, with significant and lengthy review by Heikki Linnakangas,
including streamlined redesign of snapshot creation and two-phase commit.

Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure,
Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas,
Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other
community members.

Yo asumo que sabes que puedes tener configuración warm standby con PostgreSQL desde hace algún tiempo. Si bien esto es estupendo para failover, tiene el inconveniente de no permitirte adecuadamente usar tu hardware - tiene que estar "sin uso", y después es usado sólo cuando el problema ocurre.

Ahora, con el parche de Simon no se da más el caso - nosotros podemos tener consultas ejecutándose en la base de datos slave (esclava).

Veamos cómo funciona.

He configurado 2 instancias de Postgres, con replicación WAL (si no sabes cómo hacerlo - está muy descrito en la documentación, y este post es sobre la nueva características así que salteré las instrucciones sobre cómo hacer funcionar la replicación WAL).

Instancia #1 - master (maestra), tiene directorio de datos /home/pgdba/data y puerto 5850.
Instancia #1 - slave (esclava), tiene directorio de datos /home/pgdba/data2 y puerto 5851.

Yo ejecuté un generador de carga en el master, que hace escrituras todo el tiempo - haciendo que el master genere nuevos segmentos WAL aproximadamente 1 segmento cada 12 segundos.

Lo estupendo es que "los select en el esclavo" ("selects on slave") están habilitados por defecto. Así que puedo

=$ psql -p 5851 -c "select count(*) from test01";

 count

-------

 72523

(1 row)

Y funiona 🙂

Podemos ver que hay un diferencia (lag) en la replicación:

=$ psql -p 5850 -c "select count(*) from test01"; psql -p 5851 -c "select count(*) from test01";

 count

-------

 73578

(1 row)



 count

-------

 73390
(1 row)

(Mi generador de carga sólo inserta nuevos datos)

Así que generalmente funciona

Hay algunas limitaciones siguiera - 3 parámetros:

max_connections
max_prepared_transactions
max_locks_per_transaction

Tienen que ser configurados para ser al menos los mismos como en el maestro - y diría que preferiblemente más altos.

Ahora. ¿Cuáles so las limitaciones? Bueno, de forma simple - si se escribe algo, tú no puedes usarlo. La lista completa de lo que es posible, y lo que no está en los documentos de Hot Standby - también compruébalo para conseguir mayor control sobre cómo funciona, y cuáles son las advertencias.

Para mí, sólo este cambio significa que para un montón de sitios yo sé que Slony (y otros motores de replicación basados en triggers) han perdido el terreno. Hay aún casos de uso donde la repliación basada en disparadores (trigger) irá bien (por ejemplo cuando quieres replicar únicamente sólo algunas tablas o bases de datos desde una sola instancia de PostgreSQL), pero para casos donde tú tienes un servidor de base de datos dedicado para una única (o un par, aunque relacionadas estrechamente) base de datos - Hot Standby es mejor en prácticamente todas las formas imaginables. Y esto es una victoria estupenda.

Gracias Simon, y a todos los demás quienes ayudaron con este logro. Ahora, si hubiéramos podido conseguir streamed replication ;-P