(c) Google Imagens
Todos os personagens são fictícios, as marcas pertencem aos seus proprietários, quaisquer coincidências são aleatórias e, na verdade, esta é a minha ‘opinião subjetiva, por favor, não quebre a porta…’.
Temos uma boa experiência na tradução de sistemas de informação com lógica em banco de dados de um SGBD para outro. No contexto da resolução do governo nº 1236 de 16.11.2016, frequentemente isso envolve a migração de Oracle para Postgresql. Como organizar o processo da forma mais eficiente e indolor — podemos falar separadamente sobre isso, hoje falaremos sobre as particularidades do uso de clusters e quais problemas podem surgir ao construir sistemas distribuídos de alta carga com lógica complexa em procedimentos e funções.
Spoiler — sim, RAC e pg multimaster são soluções bem diferentes.
Digamos que você já transferiu toda a lógica de plsql para pgsql. E seus testes de regressão estão bem, agora você certamente está pensando em escalabilidade, já que os testes de carga não estão lhe agradando, especialmente naquele hardware que foi planejado originalmente para aquele outro SGBD. Digamos que você encontrou uma solução de um fornecedor nacional ‘Postgres Professional’ com uma opção chamada ‘multimaster’, que está disponível apenas na versão ‘max’ do ‘Postgres Pro Enterprise’ e pela descrição — parece ajustar-se ao que você precisa, e em uma primeira análise superficial, vem à mente: ‘Oh! Em vez de RAC é perfeito! E ainda com suporte técnico em casa!’
Mas não se apresse em ficar animado, e a seguir descreveremos por que esses detalhes devem ser conhecidos, pois são difíceis de prever, mesmo lendo bem a documentação do produto. Avalie se você estará preparado para atualizar frequentemente as versões do SGBD diretamente no ambiente de produção, pois alguns defeitos não são compatíveis com a operação industrial e são difíceis de identificar durante os testes.
Comece com uma leitura atenta da seção ‘multimaster’ — ‘limitações’ no site do fabricante.
A primeira coisa que você pode encontrar são as particularidades do funcionamento das transações no chamado modo ‘duas fases’, e às vezes, a única forma de resolver isso é reescrevendo toda a lógica do seu procedimento. Aqui está um exemplo simples:
criar tabela test1 (id inteiro, id1 inteiro);
insira valores em test1 (1, 1),(1, 2);
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
atualizar test1
definir id1 =
caso id1
quando 1
então 2
senão id1 - sinal(2 - 1)
fim
onde id1 entre 1 e 2;Ocorre um erro:
ERRO: [MTM] Transação MTM-1-2435-10-605783555137701 (10654) está abortada no nó 3. Verifique seu log para detalhes do erro.A partir daí, você pode lutar contra dead locks nas versões 10.5, 10.6 e a única solução conhecida que destrói toda a essência do cluster é remover as tabelas "problemáticas" do cluster, ou seja, fazer make_table_local, mas isso pelo menos permitirá que você trabalhe, e não deixará tudo travado por causa de esperas pendentes na confirmação das transações. Ou você pode atualizar para a versão 11.2, que deve ajudar, ou talvez não, não esqueça de verificar.
Em algumas versões, você poderá obter um bloqueio ainda mais enigmático:
username= mtm e backend_type = worker em segundo planoE nessa situação, somente a atualização da versão do SGBD para 11.2 ou superior pode ajudá-lo, ou talvez não.
Algumas operações com índices podem levar a erros, onde está claramente indicado que o problema está na Replicação Bi-Direcional, nos logs MTM você verá diretamente BDR. Será que é 2ndQuadrant? Não… nós compramos multimaster, é apenas uma coincidência, é o nome da tecnologia.
[MTM] bdr não suporta rechecagens de índice
[MTM] 12124: REMOTO início aborta transação 4083
[MTM] 12124: enviar notificação ABORT para transação (5467) local xid=4083 ao coordenador 3
[MTM] Receber mensagem lógica ABORT_PREPARED para transação MTM-3-25030-83-605694076627780 do nó 3
[MTM] Abortou a transação preparada MTM-3-25030-83-605694076627780 status InProgress do nó 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 Se você está usando tabelas temporárias, apesar das afirmações: "A extensão multimaster realiza a replicação de dados de maneira totalmente automática. Você pode executar transações de gravação simultaneamente e trabalhar com tabelas temporárias em qualquer nó do cluster."
Então, na prática, você verá que a replicação não funciona em todas as tabelas usadas no procedimento, se no código existir a criação de uma tabela temporária, e mesmo o uso de multimaster.remote_functions não ajudará, será necessário atualizar ou reescrever sua lógica no procedimento. Se você precisa usar simultaneamente duas extensões multimaster e pg_pathman dentro do "Postgres Pro Enterprise" v 10.5, verifique se em um exemplo tão simples:
CRIE A TABELA measurement (
city_id int não nulo,
logdate data não nula,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);
CRIE A TABELA measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insira na measurement valores (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insira na measurement valores (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insira na measurement valores (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insira na measurement valores (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);Nos logs nos nós do SGBD começam a aparecer os seguintes erros:
…
PATHMAN_CONFIG não contém a relação 23245
> find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: tentando "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEPURAÇÃO: find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) nome: sem nome; blockState: PREPARAR; estado: EM PROGRESSO, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) nome: sem nome; blockState: PÁS DEFAULT; estado: EM PROGRESSO, xid\/subid\/cid: 0\/1\/0
> mudado para a linha do tempo 1 válida até 0\/0
…
Transação MTM-1-13604-7-612438856339841 (6919) está abortada no nó 2. Verifique seu log para detalhes do erro.
...
[MTM] 28295: REMOTE iniciar abortar transação 7017
…
[MTM] 28295: enviar notificação ABORT para a transação (6919) xid local=7017 para o coordenador 1
O que são esses erros, você poderá descobrir no suporte técnico, afinal, você o comprou.
E agora, o que fazer? Certo! Atualizar para "Postgres Pro Enterprise" para a versão 11.2
É importante saber que a sequência, sendo um objeto de banco de dados replicável, não possui um valor contínuo em todo o cluster; cada sequência é local para cada nó e se você tem campos com restrições únicas e utiliza sequência, você pode apenas fazer um incremento equivalente ao número do nó no cluster, já que quantos mais nós houver no cluster, mais rápido sua sequência aumentará, e um int acabará mais rápido do que você esperava. Para simplificar o trabalho com a sequência no produto, você encontrará até uma função alter_sequences, que fará os incrementos necessários em cada sequência em todos os nós, mas esteja preparado para que a função não funcione em todas as versões. Claro que pode-se escrever uma própria, baseando-se no código do github ou modificando diretamente no SGBD. Além disso, campos com tipos serialbigserial funcionarão de forma mais correta, mas para utilizá-los você provavelmente precisará reescrever o código de seus procedimentos e funções. A função monotonic_sequences pode ser útil para alguns.
Até a versão 11.2 do "Postgres Pro Enterprise", a replicação funcionará apenas na presença de chaves primárias únicas, considere isso ao desenvolver.
Gostaria de mencionar especialmente as características do funcionamento do npgsql em soluções de cluster; esses problemas não surgem em um único nó, mas estão presentes no multimestre.
Em algumas versões, você pode encontrar o erro:
Detalhes da Exceção: Npgsql.PostgresException: 25001: comando SET TRANSACTION ISOLATION LEVEL
Descrição: Uma exceção não tratada ocorreu durante a execução da solicitação web atual. Por favor, revise a pilha de chamada para mais informações sobre o erro e onde ele se originou no código. O que pode ser feito? Basta não usar algumas versões. É necessário conhecê-las, pois o erro não aparece em uma única versão e, mesmo após a primeira correção, você pode encontrá-lo novamente mais tarde. Você também deve estar preparado para isso e é melhor encobrir todos os defeitos identificados do SGBD, corrigidos pelo fabricante, com testes de regressão separados. Como se costuma dizer, confie, mas verifique.
Se o aplicativo utiliza npgsql e alterna entre nós achando que todos são iguais, pode surgir o seguinte erro:
EXCEÇÃO:Npgsql.PostgresException (0x80004005): XX000: falha na procura em cache para tipo ...Esse erro ocorrerá devido ao fato de que a vinculação está sendo executada
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) dos tipos compostos ao iniciar o aplicativo para todas as conexões. Como resultado, obtemos um identificador de um único nó e, ao fazer uma consulta em outro nó, ele não coincide, resultando em um erro. Portanto, trabalhar de forma transparente com tipos compostos em um cluster será impossível para alguns aplicativos sem reescritas adicionais no lado do aplicativo (se você conseguir fazer isso).
Como todos sabemos, a avaliação geral do estado do cluster é muito importante para diagnóstico e ações rápidas durante a operação; no produto você encontrará algumas funções que devem facilitar sua vida, mas às vezes elas podem fornecer resultados totalmente diferentes do que você e até mesmo o próprio fabricante esperavam.
Por exemplo:
select mtm.collect_cluster_info();
Em cada nó, retorna o mesmo resultado:
(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 no campo LiveNodes está sempre o número 2, embora pela descrição do funcionamento do multimestre deva corresponder ao número AllNodes=3? Resposta: é necessário atualizar a versão do SGBD.
E esteja pronto para coletar logs de todos os nós, pois geralmente você verá "o erro está no log de outro nó". O suporte técnico aceitará todos os defeitos que você identificar e informará sobre a disponibilidade de uma nova versão, que às vezes precisará ser instalada com a interrupção do serviço e, em outras ocasiões, por um período prolongado (dependendo do tamanho do seu banco de dados). Não devemos esperar que problemas de operação preocupem muito o fornecedor, e a atualização devido a defeitos identificados será feita sem a participação de representantes do fornecedor; na verdade, nem é necessário envolver representantes do fornecedor, pois no final você pode acabar com um cluster em produção desmontado sem backup.
De fato, na licença do produto comercial, o fabricante avisa honestamente: "Este software é fornecido no princípio de 'como está' e a sociedade de responsabilidade limitada 'Postgres Profissional' não é obrigada a fornecer manutenção, suporte, atualizações, extensões ou modificações."
Se você ainda não adivinhou de qual produto estamos falando, toda essa experiência foi adquirida após um ano de uso do banco de dados Postgres Pro Enterprise. Você pode concluir por si mesmo, está tão cru que até cogumelos crescem.
Mas isso ainda seria só metade dos problemas, se os problemas que surgissem fossem resolvidos de forma oportuna e ágil.
Mas isso, na verdade, não acontece. Parece que o fabricante não tem recursos suficientes para corrigir rapidamente os bugs identificados.
Apenas usuários registrados podem participar da pesquisa. , por favor.
Você tem experiência em migrar de um banco de dados estrangeiro/proprietário para um banco de dados livre/nacional?
21,3%Sim, positiva10
10,6%Sim, negativa5
21,3%Não, não mudamos de banco de dados10
4,3%Mudamos de banco de dados, mas nada mudou2
42,6%Ver resultados20
Votaram 47 usuários. 12 usuários se abstiveram.
Fonte: habr.com
