Tema representativo de entrevista

Entrevista de Backend: ¿Cómo utilizarías de forma segura los filtros de fila y las listas de columnas en la replicación lógica de PostgreSQL?

BackendDifícil
Equipo editorial de Offer.ccPublicado Actualizado

Pregunta

Un publicador de PostgreSQL debe replicar solo inquilinos y columnas seleccionados a un suscriptor. Explica la semántica de los filtros de fila y las listas de columnas, las transformaciones de límites de UPDATE, la sincronización inicial, el comportamiento de las particiones y un plan de operaciones seguro.

Prompt y contexto

Un publicador de PostgreSQL 18 debe replicar inquilinos y columnas seleccionados a un suscriptor utilizado para informes y servicios regionales. Explica la semántica de los filtros de fila y las listas de columnas, qué sucede cuando un UPDATE cruza el límite del filtro, la sincronización inicial, el comportamiento de las particiones y un plan de operaciones seguro.

PostgreSQL documenta que un filtro de fila decide antes de la publicación si una fila satisface una expresión, mientras que una lista de columnas reduce las columnas transportadas pero no es un límite de seguridad. La entrevista evalúa la semántica de replicación, la consistencia y el gobierno de cambios en lugar de simplemente agregar una cláusula WHERE a una publicación.

Qué está evaluando el entrevistador

Debes explicar que el rol de la conexión de replicación evalúa el filtro, false o NULL suprime una fila y TRUNCATE no se ve afectado. Debes deducir las transformaciones de UPDATE para valores antiguos/nuevos, manejar la identidad de réplica, la sincronización inicial, los filtros combinados mediante OR entre publicaciones, las raíces de particiones y la evolución de listas de columnas, además de reconocer que las listas de columnas no proporcionan confidencialidad.

Preguntas para aclarar primero

Objetivo de replicación

Confirma los inquilinos, operaciones y columnas que necesita el suscriptor, si se permite una instantánea (snapshot) inicial, si las escrituras son bidireccionales y si el suscriptor es anterior a la versión 15 o 18.

Identidad y filtrado

Confirma la identidad de réplica de la tabla, si las columnas del filtro pueden cambiar, si se utiliza la publicación desde la raíz de partición y si múltiples publicaciones cubren la misma tabla.

Seguridad y recuperación

Confirma si las columnas sensibles deben ser completamente invisibles, los permisos del rol de replicación, el aislamiento de red, los procedimientos de reconstrucción de suscripciones y la ventana de reversión (rollback) ante un filtro erróneo.

Una respuesta de 30 segundos

“Un filtro de fila define qué cambios de fila entran en una publicación; false o NULL descarta el cambio, mientras que una lista de columnas solo reduce las columnas transportadas y no constituye un límite de seguridad. Un UPDATE evalúa tanto la fila antigua como la nueva: de no coincidencia a coincidencia se convierte en INSERT, de coincidencia a no coincidencia se convierte en DELETE, y solo de coincidencia a coincidencia permanece como UPDATE. Para UPDATE o DELETE, el filtro y las columnas publicadas deben cubrir la identidad de réplica. Antes del despliegue congelaría los cambios de publicación, probaría la sincronización inicial, las particiones, los filtros combinados con OR y el comportamiento en versiones antiguas, protegiendo al mismo tiempo los datos sensibles con privilegios y vistas del lado del publicador.”

Respuesta detallada paso a paso

Paso 1: Definir las invariantes de la publicación

Registra el conjunto de inquilinos permitidos, operaciones, conjunto de columnas, expresión de filtro y versión del suscriptor para cada tabla. Decide si el objetivo es recorte de rendimiento, aislamiento de comportamiento o seguridad; un objetivo de seguridad no puede depender únicamente de una lista de columnas.

Paso 2: Diseñar el filtro de fila

El filtro se ejecuta antes de la publicación utilizando el rol de la conexión de replicación y solo las expresiones simples documentadas. Un resultado false o NULL suprime la fila, y TRUNCATE no se ve afectado. Para publicaciones que contienen UPDATE o DELETE, las columnas del filtro deben estar cubiertas por la identidad de réplica; las publicaciones solo de INSERT pueden usar otras columnas.

Paso 3: Deducir las transformaciones de UPDATE

Evalúa el filtro antes y después de la actualización. Coincidencia a coincidencia envía UPDATE; no coincidencia a no coincidencia no envía nada; no coincidencia a coincidencia envía INSERT; coincidencia a no coincidencia envía DELETE. Por lo tanto, el suscriptor representa el conjunto actual de filas que satisfacen el filtro en lugar de reproducir ciegamente cada UPDATE.

Paso 4: Restringir la lista de columnas

La lista de columnas debe incluir las columnas de identidad de réplica, y la tabla del suscriptor debe contener al menos las columnas publicadas. El orden de la lista no afecta la replicación. Omitir una lista incluye automáticamente las columnas agregadas posteriormente; nombrar explícitamente todas las columnas actuales no incluye columnas futuras. Listas diferentes para la misma tabla en distintas publicaciones pueden impedir que una suscripción se reanude, por lo que deben revisarse antes de cambiarlas.

sql
CREATE PUBLICATION tenant_eu
  FOR TABLE orders (order_id, tenant_id, status, total)
  WHERE (tenant_id = 'eu');

Paso 5: Gestionar la sincronización inicial

La sincronización inicial copia las filas existentes que satisfacen los filtros de fila y solo las columnas de la lista. Un suscriptor anterior a la versión 15 puede copiar la tabla completa, y las versiones anteriores a la 18 tienen limitaciones adicionales con columnas generadas. Verifica la matriz de versiones y el backlog de escritura durante la instantánea antes de desviar el tráfico.

Paso 6: Manejar particiones y múltiples publicaciones

Con publish_via_partition_root=true, se utiliza el filtro o la lista de columnas de la tabla particionada raíz; con el valor predeterminado false, se utiliza la definición de cada partición. Los filtros de fila para la misma tabla y operación de publicación entre publicaciones se combinan con OR. Por lo tanto, una publicación sin filtrar puede anular el filtrado esperado de otros filtros.

Paso 7: Agregar medidas de seguridad operativas

Revisa las definiciones de publicación como migraciones y registra la tasa de aciertos del filtro, el retraso de replicación (lag), los conflictos, los recuentos de filas de sincronización inicial y las versiones de las reglas. Prueba los casos límite antiguos/nuevos en una suscripción paralela (shadow). Si se filtran o desaparecen filas, pausa la suscripción, corrige la publicación y reconstruye tras las comprobaciones de consistencia.

Respuesta modelo

Trataría el filtro de fila como la definición del conjunto publicado y la lista de columnas como el recorte de transporte. El rol de replicación evalúa el filtro, por lo que false/NULL y TRUNCATE necesitan pruebas explícitas. UPDATE compara las filas antiguas y nuevas y se convierte en INSERT o DELETE al cruzar el límite; para UPDATE/DELETE, el filtro y las columnas publicadas deben cubrir la identidad de réplica. La sincronización inicial, las raíces de particiones y las publicaciones combinadas con OR pertenecen a la matriz de pruebas. Protege los datos sensibles con privilegios del publicador, vistas o un pipeline de redacción independiente; utiliza listas de columnas para el rendimiento y el control de estructura.

Errores comunes

  • Error: Asumir que una lista de columnas impide que un suscriptor malicioso obtenga columnas no publicadas. → Por qué falla: La documentación oficial indica que no es un mecanismo de seguridad. → Solución: Aplica confidencialidad con privilegios del publicador, vistas o redacción.
  • Error: Evaluar un UPDATE solo en la fila nueva. → Por qué falla: Una fila puede salir o entrar del conjunto filtrado. → Solución: Evalúa tanto la fila antigua como la nueva y aplica los cuatro resultados posibles.
  • Error: Ignorar la identidad de réplica. → Por qué falla: UPDATE/DELETE no pueden localizar de forma segura la fila antigua. → Solución: Comprueba la cobertura de identidad en el filtro y la lista de columnas.
  • Error: Asumir que varias publicaciones reducidas implican un flujo total reducido. → Por qué falla: Los filtros para la misma operación de publicación se combinan con OR. → Solución: Calcula la unión y rechaza la cobertura sin filtros.

Preguntas de seguimiento y respuestas

¿Cuándo deberías usar un filtro de fila frente a publicaciones separadas?

Usa un filtro de fila cuando los límites de inquilino o región sean estables y las expresiones sean simples. Las publicaciones y suscripciones separadas son más fáciles de auditar cuando difieren los permisos, el ciclo de vida y la propiedad operativa. En ambos casos, evalúa los costos de sincronización inicial y de cambios.

¿Cómo evitas la replicación accidental de una nueva columna?

Usa una lista de columnas explícita y actualízala mediante revisión de esquema. No confundas nombrar explícitamente cada columna actual con omitir la lista; la omisión incluye automáticamente columnas futuras.

¿Cómo pruebas un UPDATE que cruza el límite?

Crea cuatro casos: antiguo falso/nuevo verdadero, antiguo verdadero/nuevo falso, ambos verdaderos y ambos falsos. Verifica INSERT, DELETE, UPDATE y la ausencia de eventos en el suscriptor, respectivamente.

¿Puede el filtrado reemplazar el aislamiento de seguridad multiinquilino?

No. Selecciona datos de replicación lógica; el aislamiento aún requiere roles de publicador con privilegios mínimos, credenciales separadas, controles de red y redacción donde sea necesario.

Fuentes públicas

Preguntas relacionadas