Esta sección describe el protocolo de replicación lógica, que es el flujo de
mensajes iniciado por el comando de replicación START_REPLICATION
SLOT slot_name
LOGICAL.
El protocolo de replicación lógica en flujo se basa en las primitivas del protocolo de replicación física en flujo.
La decodificación lógica de PostgreSQL admite plugins de
salida. pgoutput es el estándar utilizado para
la replicación lógica integrada.
Utilizando el comando START_REPLICATION,
pgoutput acepta las siguientes opciones:
Versión del protocolo. Actualmente se admiten las versiones 1, 2,
3 y 4. Se requiere una versión
válida.
La versión 2 se admite solo para la versión 14 del servidor
y posteriores, y permite la transmisión de transacciones grandes en curso (in-progress).
La versión 3 se admite solo para la versión 15 del servidor
y posteriores, y permite la transmisión de confirmaciones en dos fases (two-phase commits).
La versión 4 se admite solo para la versión 16 del servidor
y posteriores, y permite que las transmisiones de transacciones grandes en curso se
apliquen en paralelo.
Lista separada por comas de nombres de publicaciones a las que suscribirse (recibir cambios). Los nombres de publicaciones individuales se tratan como nombres de objetos estándar y se pueden entrecomillar de la misma manera según sea necesario. Se requiere al menos un nombre de publicación.
Opción booleana para utilizar el modo de transferencia binaria. El modo binario es más rápido que el modo texto pero ligeramente menos robusto.
Opción booleana para habilitar el envío de los mensajes que son escritos
por pg_logical_emit_message.
Opción para habilitar la transmisión de transacciones en curso. Los valores válidos son
off (por defecto), on y
parallel. La configuración parallel
permite enviar información adicional con algunos mensajes para ser utilizada con fines de
paralelización. Se requiere como mínimo la versión 2 del protocolo para establecerla en
on. Se requiere como mínimo la versión 4 del protocolo para el
valor parallel.
Opción booleana para habilitar transacciones en dos fases. Se requiere como mínimo la versión 3 del protocolo para activarla.
Opción para enviar cambios según su origen. Los valores posibles son
none para enviar únicamente los cambios que no tienen un origen
asociado, o any
para enviar los cambios independientemente de su origen. Esto se puede utilizar
para evitar bucles (replicación infinita de los mismos datos) entre los
nodos de replicación.
Los mensajes individuales del protocolo se analizan en las siguientes subsecciones. Los mensajes individuales se describen en Section 54.9.
Todos los mensajes de protocolo de nivel superior comienzan con un byte de tipo de mensaje. Aunque se representa en el código como un carácter, se trata de un byte con signo sin codificación asociada.
Dado que el protocolo de replicación en flujo proporciona una longitud de mensaje, no es necesario que los mensajes del protocolo de nivel superior incorporen una longitud en su cabecera.
Con la excepción del comando START_REPLICATION y
los mensajes de progreso de reproducción, toda la información fluye únicamente desde el servidor (backend)
hacia el cliente (frontend).
El protocolo de replicación lógica envía las transacciones individuales una por una. Esto significa que todos los mensajes entre un par de mensajes Begin y Commit pertenecen a la misma transacción. Del mismo modo, todos los mensajes entre un par de mensajes Begin Prepare y Prepare pertenecen a la misma transacción. También envía los cambios de transacciones grandes en curso entre un par de mensajes Stream Start y Stream Stop. El último flujo de dicha transacción contiene un mensaje Stream Commit o Stream Abort.
Cada transacción enviada contiene cero o más mensajes DML (Insert, Update, Delete). In caso de una configuración en cascada, también puede contener mensajes de Origin. El mensaje origin indica que la transacción se originó en un nodo de replicación diferente. Dado que un nodo de replicación en el ámbito del protocolo de replicación lógica puede ser prácticamente cualquier cosa, el único identificador es el nombre del origen. Es responsabilidad del nodo receptor (downstream) manejar esto según sea necesario (si es necesario). El mensaje Origin siempre se envía antes de cualquier mensaje DML en la transacción.
Cada DML mensaje contiene un OID de relación, que identifica la relación del publicador sobre la que se actuó. Antes del primer mensaje DML para un determinado OID de relación, se enviará un mensaje Relation que describe el esquema de esa relación. Posteriormente, se enviará un nuevo mensaje Relation si la definición de la relación ha cambiado desde que se envió el último mensaje Relation para ella. (El protocolo asume que el cliente es capaz de recordar estos metadatos para tantas relaciones como sea necesario).
Los mensajes Relation identifican los tipos de columnas por sus OID. En el caso de un tipo integrado (built-in), se asume que el cliente puede buscar ese OID de tipo localmente, por lo que no se necesitan datos adicionales. Para un OID de tipo no integrado, se enviará un mensaje Type antes del mensaje Relation para proporcionar el nombre del tipo asociado con ese OID. Por lo tanto, un cliente que necesite identificar específicamente los tipos de columnas de relación debe almacenar en caché el contenido de los mensajes Type, y consultar primero esa caché para ver si el OID de tipo está definido allí. Si no es así, buscar el OID de tipo localmente.