Lo nuevo en PostgreSQL 9.1: Replicación sincrónica

Tema: 

Como saben estamos en etapa beta de PostgreSQL 9.1, así que estoy empezando a chequear algunas de las nuevas características. Y como es natural, debido a que 2ndQuadrant es quien la auspicio, empece con "replicación sincrónica".

Hay varios motivos para querer replicación sincrónica: porque suena bonito, porque otros lo tienen pero la más importante es "por durabilidad de los datos". Así es, la replicación sincrónica es esencialmente una extensión de la protección provista por el "commit" en una transacción. Pero, por supuesto, nada es gratis... y en este caso el costo es una reducción en el rendimiento del maestro, esto es porque al hacer commit no solo debe asegurarse de que se escriba el registro del WAL, que asegurara la durabilidad de la transacción, en el disco sino que además debe asegurarse de transmitirlo a una maquina remota (que idealmente no debería estar en el mismo centro de computo).

La implementación actual permite tener una lista de standbys sincrónicos (a traves de la variable synchronous_standby_names) sin embargo solo es necesario transmitir de forma sincrónica a uno de ellos (normalmente al primero de la lista que este conectado y replicando). Proximas versiones implementarán otras técnicas como "quorum commit" que implica transmitir al menos a la mitad de los servidores sincrónicos.

Una innovación, unica en PostgreSQL, es que este nuevo nivel de "durabilidad" podemos definirlo por transacción a traves de la variable synchronous_commit (que ahora acepta ademas de on y off el valor local). Al indicar en una transacción que queremos "synchronous_commit = local" le decimos que no se preocupe de replicar de inmediato (literalmente, desactivamos la replicación sincrónica para esa transacción) y si esta en "on" entonces el commit solo se reportará en el cliente como completado cuando la replica confirme que se ha transmitido los registros de WAL correspondientes.

Hay otras cosas relacionadas con replicación que se han mejorado; por ejemplo, ahora la replica reporta su status al maestro (si se activa el parametro hot_standby_feedback) este parametro ayuda a reducir el numero de cancelaciones de consultas en la replica, tambien podemos indicarle cada que tiempo queremos que reporte el status (wal_receiver_status_interval).

Para la siguiente ronda de pruebas creo que haré un combo de replicación: pg_basebackup y pg_ctl... funcionarán tan bien como repmgr? ya veremos...