“Pro, pero no un clúster” o cómo reemplazamos DBMS importados

(ts) Yandex.Imágenes

Todos los personajes son ficticios, las marcas pertenecen a sus dueños, las similitudes son aleatorias y en general, este es mi “juicio de valor subjetivo, por favor no rompas la puerta…”.

Tenemos una experiencia considerable en la transferencia de sistemas de información con lógica a una base de datos de un DBMS a otro. En el contexto del decreto gubernamental nº 1236 del 16.11.2016 de noviembre de XNUMX, esto suele ser una transferencia de Oracle a Postgresql. Podemos decirle por separado cómo organizar el proceso de la manera más eficiente y sencilla posible, hoy hablaremos sobre las características del uso de un clúster y qué problemas se pueden encontrar al construir sistemas distribuidos altamente cargados con lógica compleja en procedimientos y funciones.

Spoiler: sí, cap, RAC y pg multimaster son soluciones muy diferentes.

Digamos que ya transfirió toda la lógica de plsql a pgsql. Y tus pruebas de regresión están bastante bien, ahora por supuesto que estás pensando en escalar, porque... Las pruebas de carga no te dejan muy contento, especialmente en el hardware que se incluyó originalmente en el proyecto, para ese DBMS tan diferente. Supongamos que encontró una solución del proveedor nacional "Postgres Professional" con una opción llamada "multimaster", que está disponible sólo en la versión "máxima" de "Postgres Pro Enterprise" y, según la descripción, es muy similar a lo que necesitas, y con el primer estudio superficial vendrá el pensamiento que me viene a la cabeza: “¡Oh! ¡Eso es todo en lugar de RAC! ¡E incluso con un oleoducto técnico en nuestra patria!”

Pero no se apresure a alegrarse, y más adelante le explicaremos por qué necesita conocer estos matices, porque... son difíciles de predecir, incluso después de leer detenidamente la documentación del producto. Evalúe si está listo para actualizar con frecuencia las versiones de DBMS directamente en el sitio de producción, porque Algunos defectos no son compatibles con el uso industrial y son difíciles de detectar durante las pruebas.
Comience leyendo atentamente la sección "multimaster" - "limitaciones" en el sitio web del fabricante.

Lo primero que puede encontrar son las peculiaridades de cómo funcionan las transacciones, en las llamadas. modo "bifásico" y, a veces, no hay forma de solucionarlo excepto reescribiendo toda la lógica del procedimiento. He aquí un ejemplo sencillo:

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

Se produce un error:

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

Entonces puedes luchar durante mucho tiempo con el punto muerto en las versiones 10.5, 10.6, y la única solución conocida que acaba con toda la esencia del clúster es eliminar las tablas "problemáticas" del clúster, es decir. haga make_table_local, pero esto al menos permitirá que funcione y no pondrá todo en espera debido a esperas bloqueadas para las confirmaciones de transacciones. Bueno, o instala una actualización a la versión 11.2, lo que debería ayudar, pero tal vez no, no olvides comprobarlo.

En algunas versiones puedes conseguir un candado aún más misterioso:

username= mtm и backend_type = background worker

Y en esta situación, solo actualizar la versión DBMS a 11.2 y superior le ayudará, o tal vez no le ayude.

Algunas operaciones con índices pueden generar errores, lo que indica claramente que el problema está en la replicación bidireccional; verá BDR directamente en los registros de MTM. ¿Es realmente el segundo cuadrante? No... compramos un multimaster, es solo una coincidencia, es el nombre de la tecnología.

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 

Si utiliza tablas temporales, a pesar de las garantías: “La extensión multimaster realiza la replicación de datos de forma completamente automática. Puede realizar simultáneamente transacciones de escritura y trabajar con tablas temporales en cualquier nodo del clúster”.

Entonces, de hecho, obtendrá que la replicación no funciona en todas las tablas utilizadas en el procedimiento, si el código contiene la creación de una tabla temporal, e incluso usar multimaster.remote_functions no ayudará, tendrá que actualizar o reescribir su lógica en el procedimiento. Si necesita utilizar dos extensiones multimaster y pg_pathman simultáneamente dentro de Postgres Pro Enterprise v 10.5, compruébelo con este sencillo ejemplo:

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

Los siguientes errores comienzan a aparecer en los registros de los nodos DBMS:

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

Puedes averiguar cuáles son estos errores en soporte técnico, no en vano lo compraste.

¿Qué hacer? ¡Bien! Actualice a "Postgres Pro Enterprise" v 11.2

Por separado, necesitas saber que la secuencia, al ser un objeto de una base de datos replicada, no tiene un valor de extremo a extremo en todo el cluster, cada secuencia es local para cada nodo y si tienes campos con restricciones únicas y utilizas secuencia, entonces solo puede hacer un incremento equivalente al número de nodo en el clúster, porque Tantos nodos como sea posible en el clúster, secuencia e int crecerán más rápido de lo esperado. Para simplificar el trabajo con secuencias en el producto, incluso encontrará la función alter_sequences, que realizará los incrementos necesarios para cada secuencia en todos los nodos, pero esté preparado porque la función no funcionará en todas las versiones. Por supuesto, puede escribirlo usted mismo, utilizando el código de github como base o corrigiéndolo usted mismo directamente en el DBMS. En este caso, los campos con el tipo serialbigserial funcionarán más correctamente, pero para usarlos, lo más probable es que necesites reescribir el código de tus procedimientos y funciones. Quizás alguien encuentre útil la función monotonic_sequences.

Antes de la versión 11.2 de Postgres Pro Enterprise, la replicación solo funcionará si hay claves primarias únicas; tenga esto en cuenta al desarrollar.

Por separado, me gustaría mencionar las peculiaridades de cómo funciona npgsql en una solución de clúster; estos problemas no surgen en un solo nodo, pero están bastante presentes en un multimaestro.
En algunas versiones puede encontrar un error:

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

¿Qué se puede hacer? Simplemente no debes usar algunas versiones. Necesitas conocerlos, porque... El error aparece en más de una versión e incluso después de su primera solución, es posible que lo encuentres más adelante. También debe estar preparado para esto y es mejor cubrir todos los defectos identificados del DBMS que el fabricante corrige con pruebas de regresión separadas. Por así decirlo, confía, pero verifica.

Si la aplicación usa npgsql y cambia entre nodos pensando que todos son iguales, es posible que obtenga un error:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

Este error ocurrirá porque el enlace está en progreso.

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) 

tipos compuestos al inicio de la aplicación para todas las conexiones. Como resultado, obtenemos un identificador de un nodo y, cuando lo solicitamos en otro nodo, no coincide, como resultado de lo cual se devuelve un error, es decir. No será posible trabajar de forma transparente con tipos compuestos en un clúster para algunas aplicaciones sin reescrituras adicionales del lado de la aplicación (si logra hacerlo).

Como todos sabemos, una evaluación general del estado del cluster es muy importante para el diagnóstico y las medidas operativas durante la operación, en el producto puede encontrar algunas funciones que deberían facilitarle la vida, pero a veces pueden brindarle algo completamente diferente de lo que usted e incluso el propio fabricante esperan de ellos lo que esperan.

Por ejemplo:

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

Pero, ¿por qué el campo LiveNodes contiene el número 2 en todas partes, aunque según la descripción del funcionamiento del multimaster debería corresponder al número AllNodes=3? Respuesta: necesita actualizar la versión del DBMS.

Y prepárate para recopilar registros de todos los nodos, porque... normalmente verá "el error está en el registro de otro nodo". El soporte técnico aceptará todos los defectos que identifique y le informará que la próxima versión está lista, que a veces deberá instalarse con el servicio detenido, a veces durante mucho tiempo (dependiendo del tamaño de su DBMS). No se debe esperar que los problemas operativos molesten mucho al proveedor, y la actualización debido a defectos identificados se llevará a cabo con la participación de los representantes del proveedor, o mejor dicho, ni siquiera es necesario involucrar a los representantes del proveedor, ya que en el Al final, puede terminar con un clúster desensamblado en producción sin respaldo.

De hecho, en la licencia de un producto comercial, el fabricante advierte honestamente: "Este software se proporciona "tal cual" y Postgres Professional Limited Liability Company no está obligado a proporcionar mantenimiento, soporte, actualizaciones, extensiones o cambios".

Si aún no ha adivinado de qué producto estamos hablando, toda esta experiencia se obtuvo como resultado del funcionamiento durante un año de la base de datos Postgres Pro Enterprise. Puedes sacar tu propia conclusión: hay tanta humedad que crecen hongos.

Pero esto no sería tan malo si se hiciera de manera oportuna y se eliminaran rápidamente los problemas que surgieran.

Pero esto es precisamente lo que no sucede. Aparentemente el fabricante no tiene recursos suficientes para eliminar rápidamente los errores identificados.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Tiene experiencia en cambiar de un DBMS extranjero/propietario a uno libre/nacional?

• 21,3%Sí, positivo10

• 10,6%Sí, negativo5

• 21,3%No, el DBMS no fue cambiado10

• 4,3%Se cambió el DBMS, pero nada cambió2

• 42,6%Ver resultados20

47 usuarios votaron. 12 usuarios se abstuvieron.

Fuente: habr.com