Compartir a través de

Mensajes de error comunes

Al trabajar con bases de datos distribuidas de Citus, es posible que encuentre mensajes de error relacionados con conexiones, transacciones, restricciones y operaciones distribuidas. En esta guía de referencia se proporcionan explicaciones y resoluciones para los errores más comunes detectados durante el uso de desarrollo y producción. Comprender estos errores le ayuda a solucionar problemas y a crear aplicaciones distribuidas sólidas.

No se pudieron recibir los resultados de la consulta

Este error se produce cuando el nodo de coordinación no se puede conectar a un nodo de trabajo.

SELECT 1 FROM companies WHERE id = 2928;

ERROR: error al conectarse al nodo remoto localhost:5432 con el siguiente error: no se pudo conectar al servidor: ¿Se ha rechazado la conexión¿Se ejecuta el servidor en el host "localhost" (127.0.0.1) y acepta conexiones TCP/IP en el puerto 5432?

Resolución

Para corregir este error, compruebe que el nodo de trabajo acepta conexiones y que Azure DNS se resuelve correctamente.

Cancelación de la transacción desde que estaba implicada en un interbloqueo distribuido

Los interbloqueos pueden producirse no solo en una base de datos de nodo único, sino también en una base de datos distribuida. Las consultas que se ejecutan en varios nodos pueden provocar interbloqueos. Citus reconoce interbloqueos distribuidos y los desactiva anulando una de las consultas implicadas.

Puede ver este comportamiento mediante la distribución de filas entre nodos de trabajo y, a continuación, la ejecución de dos transacciones simultáneas con actualizaciones en conflicto:

CREATE TABLE lockme (id int, x int);
SELECT create_distributed_table('lockme', 'id');

-- id=1 goes to one worker, and id=2 another
INSERT INTO lockme VALUES (1,1), (2,2);

--------------- TX 1 ----------------  --------------- TX 2 ----------------
BEGIN;
                                       BEGIN;
UPDATE lockme SET x = 3 WHERE id = 1;
                                       UPDATE lockme SET x = 4 WHERE id = 2;
UPDATE lockme SET x = 3 WHERE id = 2;
                                       UPDATE lockme SET x = 4 WHERE id = 1;

ERROR: cancelación de la transacción desde que estaba implicada en un interbloqueo distribuido

Resolución

Detectar interbloqueos y detenerlos forma parte del control normal de transacciones distribuidas. Permite a una aplicación reintentar consultas o realizar otro curso de acción.

No se pudo conectar al servidor: no se puede asignar la dirección solicitada

WARNING: connection error: localhost:9703
DETAIL: could not connect to server: Cannot assign requested address

Este error se produce cuando no hay más sockets disponibles por los que el coordinador puede responder a las solicitudes de trabajo.

Resolución

Configure el sistema operativo para reutilizar sockets TCP. Ejecute esta resolución en el shell en el nodo de coordinación:

sysctl -w net.ipv4.tcp_tw_reuse=1

Esta resolución permite reutilizar sockets en TIME_WAIT estado para las nuevas conexiones cuando es seguro desde un punto de vista del protocolo. El valor predeterminado es 0 (deshabilitado).

Error de SSL: error en la comprobación del certificado

A partir de Citus 8.1, los nodos deben comunicarse entre sí mediante SSL de forma predeterminada. Si SSL no está habilitado en un servidor postgreSQL cuando Citus se instala por primera vez, el proceso de instalación lo habilita. Esta habilitación incluye la creación y autofirmado de un certificado SSL.

Sin embargo, si existe un archivo de entidad de certificación raíz (normalmente en ~/.postgresql/root.crt), el certificado se comprueba incorrectamente con esa ENTIDAD de certificación en el momento de la conexión. La documentación de PostgreSQL sobre la compatibilidad con SSL advierte:

Para la compatibilidad con versiones anteriores de PostgreSQL, si existe un archivo de ca raíz, el comportamiento de sslmode=require será el mismo que el de verify-ca, lo que significa que el certificado de servidor se valida con la CA. No se recomienda confiar en este comportamiento y las aplicaciones que necesitan validación de certificados siempre deben usar verify-ca o verify-full.

Resolución

Las posibles soluciones son firmar el certificado, desactivar SSL o quitar el certificado raíz. Además, un nodo podría tener problemas para conectarse a sí mismo sin la ayuda de local_hostname.

No se pudo conectar a ninguna ubicación activa

Cuando todas las ranuras de conexión de trabajo disponibles están en uso, se producirá un error en las conexiones adicionales.

WARNING: connection error: hostname:5432
ERROR: could not connect to any active placements

Resolución

Este error se produce con más frecuencia al copiar datos en Citus en paralelo. El comando COPY abre una conexión por partición. La ejecución de copias simultáneas de M en un destino con N particiones da como resultado conexiones M*N. Para resolver el error, reduzca el número de particiones de las tablas distribuidas de destino o ejecute menos \copy comandos en paralelo.

Las ranuras de conexión restantes están reservadas para las conexiones de superusuario que no son de replicación

Este error se produce cuando PostgreSQL se queda sin conexiones disponibles para atender solicitudes de cliente simultáneas.

Resolución

El max_connections GUC ajusta el límite, con un valor predeterminado típico de 100 conexiones. Cada conexión consume recursos, por lo que se ajusta con sensibilidad. Al aumentar max_connections, también debe aumentar los límites de memoria .

PgBouncer también puede ayudar mediante la puesta en cola de solicitudes de conexión que superan el límite de conexión. (Nuestro cloud_topic tiene una instancia de PgBouncer integrada).

PgBouncer no se puede conectar al servidor

En un clúster de Citus autohospedado, este error indica que el nodo de coordinación no responde a PgBouncer.

Resolución

Para asegurarse de que el servidor se está ejecutando y aceptando conexiones, intente conectarse directamente al servidor con psql.

La relación foo no se distribuye

Este error ya no se produce en la versión actual de Citus. Se produjo al intentar combinar tablas locales y distribuidas en la misma consulta.

Resolución

Actualice a Citus 10.0 o posterior.

Tipo de cláusula no admitida

Este error ya no se produce en la versión actual de Citus. Solía ocurrir al ejecutar una combinación con una condición de desigualdad:

SELECT *
 FROM identified_event ie
 JOIN field_calculator_watermark w ON ie.org_id = w.org_id
WHERE w.org_id = 42
  AND ie.version > w.version
LIMIT 10;

ERROR: tipo de cláusula no compatible

Resolución

Actualice a Citus 7.2 o posterior.

No se pueden abrir nuevas conexiones después del primer comando de modificación dentro de una transacción

Este error ya no se produce en la versión actual de Citus, excepto en determinados escenarios inusuales de reparación de particiones. Solía ocurrir al actualizar las filas de una transacción y, a continuación, ejecutar otro comando, que abriría nuevas conexiones de coordinación a trabajo.

BEGIN;
-- run modification command that uses one connection
DELETE FROM http_request
 WHERE site_id = 8
   AND ingest_time < now() - '1 week'::interval;

-- now run a query that opens connections to more workers
SELECT count(*) FROM http_request;

ERROR: cannot open new connections after the first modification command within a transaction

Resolución

Actualice a Citus 7.2 o posterior.

No se puede crear una restricción de unicidad

Como sistema distribuido, Citus solo puede garantizar la unicidad si un índice único o una restricción de clave principal incluye la columna de distribución de una tabla. Las particiones se dividen para que cada partición contenga valores de columna de partición que no superponen. El índice de cada nodo de trabajo puede aplicar localmente su parte de la restricción.

Si se intenta crear un índice único en una columna sin distribución, se genera un error:

ERROR: creating unique indexes on non-partition columns is currently unsupported

La aplicación de la unicidad en una columna sin distribución requeriría que Citus compruebe cada partición en cada INSERT para validar, lo que derrota el objetivo de escalabilidad.

Resolución

Hay dos maneras de aplicar la unicidad en una columna sin distribución:

  • Cree un índice único compuesto o una clave principal que incluya la columna deseada (C), pero también incluya la columna de distribución (D). Esta resolución no es tan sólida como una condición tan sólida como unicidad en C solo, pero garantiza que los valores de C sean únicos para cada valor de D. Por ejemplo, si se distribuye por company_id en un sistema multiinquilino, este enfoque haría que C sea único dentro de cada empresa.
  • Use una tabla de referencia en lugar de una tabla distribuida hash. Esta resolución solo es adecuada para tablas pequeñas, ya que el contenido de la tabla de referencia se duplica en todos los nodos.

La función create_distributed_table no existe

SELECT create_distributed_table('foo', 'id');
/*
ERROR:  function create_distributed_table(unknown, unknown) does not exist
LINE 1: SELECT create_distributed_table('foo', 'id');
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
*/

Resolución

Cuando los conceptos básicos user_defined_functions no estén disponibles, compruebe si la extensión Citus está instalada correctamente. En ejecución \dx en listas de psql se incluyen extensiones instaladas.

Una manera de terminar sin extensiones es crear una nueva base de datos en un servidor PostgreSQL, lo que requiere que se vuelvan a instalar las extensiones. Vea create_db para aprender a hacerlo correctamente.

No se puede llamar a las funciones STABLE usadas en las consultas UPDATE con referencias de columna

Cada función de PostgreSQL se marca con una volatilidad, que indica si la función puede actualizar la base de datos y si el valor devuelto de la función puede variar con el tiempo según las mismas entradas. STABLE Se garantiza que una función devuelva los mismos resultados dados los mismos argumentos para todas las filas dentro de una sola instrucción, mientras que se garantiza que una IMMUTABLE función devuelva los mismos resultados dados los mismos argumentos para siempre.

Las funciones no inmutables pueden ser inconvenientes en los sistemas distribuidos, ya que pueden introducir cambios sutiles cuando se ejecutan en momentos ligeramente diferentes entre particiones. Las diferencias en la configuración de la base de datos entre nodos también pueden interactuar de forma perjudicial con funciones no inmutables.

Una de las formas más comunes en que se produce este problema es mediante el timestamp tipo de PostgreSQL, que a diferencia timestamptz de no mantiene un registro de la zona horaria. La interpretación de una columna de marca de tiempo hace referencia a la zona horaria de la base de datos, que se puede cambiar entre consultas, por lo que las funciones que funcionan en marcas de tiempo no son inmutables.

Citus no permite consultas distribuidas que filtran los resultados mediante funciones estables en columnas. Por ejemplo:

-- foo_timestamp is timestamp, not timestamptz
UPDATE foo SET ... WHERE foo_timestamp < now();

ERROR: STABLE functions used in UPDATE queries cannot be called with column references

En este caso, el operador < de comparación entre marca de tiempo y marca de tiempo no es inmutable.

Resolución

Evite las funciones estables en las columnas de una instrucción UPDATE distribuida. En concreto, siempre que trabaje con horas use timestamptz en lugar de timestamp. Tener una zona horaria en la marca de tiempo hace que los cálculos se inmutables.

Contenido relacionado

  • Last updated on