(c) Yandex.Pictures
Todos os personagens são fictícios, as marcas registradas pertencem aos seus proprietários, quaisquer coincidências são aleatórias e, em geral, este é o meu "julgamento subjetivo do valor, por favor, não quebre a porta ...".
Temos uma experiência considerável na tradução de sistemas de informação com lógica no banco de dados de um DBMS para outro. No contexto do decreto governamental nº 1236, de 16/11/2016, geralmente é uma transferência da Oracle para o Postgresql. Como organizar o processo da maneira mais eficiente e indolor possível - podemos falar separadamente, hoje falaremos sobre os recursos do uso de um cluster e quais problemas você pode encontrar ao criar sistemas distribuídos altamente carregados com lógica complexa em procedimentos e funções.
Spoiler - sim cap, RAC e pg multimaster são soluções muito diferentes.
Suponha que você já tenha transferido toda a lógica de pl \ sql para pg \ sql. E seus testes de regressão estão bem, agora você está pensando em escalar, porque Os testes de carga não são muito agradáveis para você, especialmente no hardware originalmente previsto no projeto, sob esse DBMS muito diferente. Suponha que você tenha encontrado uma solução do fornecedor doméstico "Postgres Professional" com uma opção chamada "multimaster", disponível apenas na versão "máxima" do "Postgres Pro Enterprise" e de acordo com a descrição - ela é muito semelhante ao que você precisa e, no primeiro estudo de superfície, ela virá na minha cabeça o pensamento: “Oh! Em vez de RAC, então! Sim, e com o pipeline técnico na pátria! ”
Mas não se apresse para se alegrar, e mais adiante descreveremos por que você precisa conhecer essas nuances, porque eles são difíceis de visualizar, mesmo depois de lerem bem a documentação do produto. Avalie se você estará pronto para atualizar frequentemente a versão do DBMS diretamente no site industrial, como alguns defeitos não são compatíveis com a operação industrial e são difíceis de detectar nos testes.
Comece lendo atentamente a seção "multimaster" - "restrição" no site do fabricante.
A primeira coisa que você pode encontrar são os recursos da operação de transações, os chamados Modo "bifásico" e, às vezes, exceto reescrevendo toda a lógica do seu procedimento, isso não pode ser corrigido. Aqui está um exemplo simples:
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;
Ocorre um erro:
: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.
Em seguida, você pode combater o bloqueio morto por um longo tempo nas versões 10.5, 10.6 e a única salvação conhecida que mata toda a essência do cluster é remover as tabelas de "problemas" do cluster, ou seja, faça make_table_local, mas pelo menos isso permitirá que você trabalhe e não "apostará" tudo por causa das expectativas pendentes de confirmar transações. Bem, ou coloque uma atualização para a versão 11.2, que deve ajudar, ou talvez não, não se esqueça de verificar.
Em algumas versões, você pode obter um bloqueio ainda mais misterioso:
username= mtm backend_type = background worker
E nessa situação, apenas a atualização da versão do DBMS para 11.2 e posterior ajudará ou poderá não ajudar.
Algumas operações com índices podem levar a erros, onde é claramente indicado que o problema está na Replicação Bidirecional, nos logs do MTM, você verá diretamente o BDR. Realmente 2ndQuadrant? Ah, não ... nós compramos um multimaster, é apenas uma coincidência, é o nome da tecnologia.
[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
Se você usa tabelas temporárias, apesar das garantias: “A extensão multimaster replica os dados de maneira totalmente automática. "Você pode escrever transações simultaneamente e trabalhar com tabelas temporárias em qualquer nó do cluster."
Na verdade, você verá que a replicação não funcionará para todas as tabelas usadas no procedimento, se o código contiver a criação de uma tabela temporária e, mesmo usando multimaster.remote_functions não ajudar, será necessário atualizar ou reescrever sua lógica no procedimento. Se você precisar usar duas extensões multimaster e pg_pathman ao mesmo tempo como parte do Postgres Pro Enterprise v 10.5, verifique isso com este exemplo simples:
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);
Os seguintes erros começam a aparecer nos logs nos nós do 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
Você pode descobrir quais são esses erros no suporte técnico, não foi à toa que você o comprou.
O que fazer Certo! Atualize para o Postgres Pro Enterprise para v 11.2
Você precisa saber separadamente que, sendo um objeto de um banco de dados replicado, ele não possui um valor transversal em todo o cluster, cada sequência é local para cada nó e, se você tiver campos com restrições exclusivas e usar a sequência, poderá incrementar apenas o número do nó em cluster, porque quantos nós no cluster são muito mais rápidos que a sequência aumentará e o int terminará mais rápido do que o esperado. Para simplificar o trabalho com sequência no produto, você encontrará até a função alter_sequences, que fará os incrementos necessários para cada sequência em todos os nós, mas esteja preparado para que a função não funcione em todas as versões. Obviamente, você pode escrevê-lo, usando o código do github como base ou corrigindo-se diretamente no DBMS. Ao mesmo tempo, os campos com o tipo serial \ bigserial funcionarão mais corretamente, mas, para usá-los, provavelmente você precisará reescrever o código de seus procedimentos e funções. Talvez alguém ache a função monotonic_sequences útil.
Antes da versão 11.2 do Postgres Pro Enterprise, a replicação só funcionaria se houvesse chaves primárias exclusivas, lembre-se disso ao projetar.
Também gostaria de mencionar os recursos do npgsql em uma solução de cluster, esses problemas não ocorrem em um único nó, mas estão presentes no multimaster.
Em algumas versões, você pode encontrar um erro:
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.
O que pode ser feito? Só não use algumas versões. Você precisa conhecê-los, porque o erro não aparece em uma versão e, mesmo após sua primeira correção, você pode encontrá-lo mais tarde. Você também precisa estar preparado para isso e é melhor identificar todos os defeitos do DBMS corrigidos pelo fabricante e cobri-los com testes de regressão separados. Confie, por assim dizer, mas verifique.
Se o aplicativo usar o npgsql e alternar entre nós, pensando que são todos iguais, você poderá receber um erro:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...
Tal erro ocorrerá devido ao fato de a ligação
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)
tipos compostos na inicialização do aplicativo para todas as conexões. Como resultado, obtemos o identificador de um dos nós e, quando solicitado em outro nó, ele não corresponde, como resultado do qual um erro é retornado, ou seja, trabalhar de forma transparente com tipos compostos em um cluster para alguns aplicativos será impossível sem reescritas adicionais no lado do aplicativo (se você conseguir fazer isso).
Como todos sabemos, uma avaliação geral do estado do cluster é muito importante para diagnósticos e medidas operacionais durante o trabalho. No produto, você pode encontrar algumas funções que devem facilitar sua vida, mas às vezes elas podem não produzir o que você e o próprio fabricante a partir delas. esperar.
Por exemplo:
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")
Mas por que o número 2 está em todo lugar no campo LiveNodes, embora, de acordo com a descrição do trabalho do multimaster, ele deva corresponder ao número AllNodes = 3? Resposta: você precisa atualizar a versão do DBMS.
E esteja preparado para coletar logs em todos os nós, como geralmente você verá "o erro está no log de outro nó". O TechSupport aceitará todos os defeitos identificados e informará que a próxima versão está pronta, que precisará ser instalada algumas vezes com o serviço interrompido, outras por um longo tempo (dependendo do volume do seu DBMS). Não vale a pena esperar que os problemas de operação perturbem muito o fornecedor, e a atualização devido a defeitos identificados seja realizada com a participação dos representantes do fornecedor, ou melhor, nem é necessário envolver os representantes do fornecedor, pois, no final, você pode obter um cluster desmontado sem backup no produto.
Na verdade, na licença de um produto comercial, o fabricante adverte honestamente: "Este software é fornecido" no estado em que se encontra "e a empresa de responsabilidade limitada do Postgres Professional não é obrigada a fornecer suporte, suporte, atualizações, extensões ou alterações."
Se você ainda não adivinhou que tipo de produto estamos falando, toda essa experiência foi adquirida como resultado da operação anual da base do Postgres Pro Enterprise. Você pode fazer uma conclusão, com tanta umidade que os cogumelos crescem.
Mas seria metade do problema, se fosse realizado em tempo hábil e eliminado imediatamente os problemas que surgissem.
Mas isso simplesmente não está acontecendo. Aparentemente, os recursos do fabricante não são suficientes para corrigir rapidamente os erros identificados.