A migração de dados com PostgresSQL é conveniente, mas pode levar a dados corrompidos se você não cuidar da revisão e das atualizações do agrupamento. Aqui estão alguns pontos a considerar:
Observe se a versão glibc corresponde
O uso de uma versão glibc incompatível pode apresentar os seguintes riscos:
- Dados ausentes ao consultar
- Ordenação inconsistente entre as versões
- Nenhuma violação de restrição exclusiva detectada
Tudo isso pode causar problemas de corrupção de dados. Por exemplo, se houver uma restrição exclusiva em endereços de e-mail e versões diferentes classificarem os resultados de maneira diferente, quando duas contas de usuário forem consultadas ao mesmo tempo. Você pode obter resultados vazios ao consultar. Se a corrupção de dados for um único registro, pode ser simples corrigir a corrupção de dados, mas quanto maior o tamanho dos dados, mais difícil será a limpeza.
As diferenças entre as versões da glibc podem causar problemas quando:
- Migre bancos de dados (ou seja, wal-e, wal-g, pgbackrest) de um host para um novo host usando replicação física.
- Restaurando um backup binário (usando pg_basebackup) em um sistema com uma configuração de sistema operacional diferente.
- O sistema operacional Linux é atualizado para uma nova versão, mantendo o diretório de dados do PostgreSQL. Nesse caso, a versão glibc pode ter mudado, mas os dados subjacentes não.
Nem todos os tipos de migração ou replicação são afetados por essa inconsistência. As situações em que os dados são transferidos de maneira lógica (não binária) são muito seguras, incluindo:
- Use pg_dump para o processo de backup e restauração, pois o processo usa apenas dados lógicos
- Replicação lógica, usando apenas cópias de dados e não cópias físicas
Como funciona a classificação
Aqui está um exemplo, em versões glibc acima de 2.28, execute esta consulta e veja como os dados são classificados.
test=# SELECT * FROM (values ('a'), ('$a'), ('a$'), ('b'), ('$b'), ('b$'), ('A'), ('B')) AS l(x) ORDER BY x ;
x
----
a
$a
a$
A
b
$b
b$
B
(8 rows)glibc
Libc é a principal biblioteca C usada pelos sistemas Linux. Muitos programas Linux, incluindo Postgres, são implementados usando glibc. Ele é usado para fornecer muitas operações básicas de software e é usado no Postgres para classificar texto ou comparar dados ao criar um índice.
A atualização glibc 2.28 lançada em 2018 traz informações de localização e agrupamento em conformidade com a 4ª edição de 2016 do padrão ISO 14651. Devido a atualizações, os índices criados com uma versão anterior do agrupamento podem ser corrompidos quando lidos com o agrupamento mais recente. Se houver uma incompatibilidade, o índice deverá ser reconstruído para evitar problemas.
Método de consulta de agrupamento
O agrupamento de dados que o banco de dados está usando pode ser encontrado por meio do campo datcollate de pg_database.
test=# SELECT datname, datcollate FROM pg_database;
datname | datcollate
-----------+-------------
test | en_US.UTF-8
security | en_US.UTF-8
template1 | en_US.UTF-8
template0 | en_US.UTF-8Verifique a versão do glibc
ldd --version //versão da consulta do comando ldd
ldd (GNU libc) 2.17
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.Método de reparo
- Correção durante a migração
Como esse problema ocorre em dados binários movidos entre versões de glibc em sistemas operacionais, ele geralmente ocorre durante migrações. A migração via cópia lógica ou backup lógico (ou seja, pg_dump) elimina esse problema, pois todos os índices afetados serão recriados neste ponto. Portanto, alterar o método de recuperação para a recuperação lógica do banco de dados é uma maneira eficaz.
Para grandes bancos de dados com mais de 100 GB, a migração de backup lógico pode demorar muito. Nesses casos, a reconstrução dos índices afetados após a migração do WAL geralmente é o método preferido, o que minimiza o tempo de inatividade e o esforço.
- no banco de dados em tempo real
Se você acha que pode haver um problema com o agrupamento migrado, o plug-in amcheck pode ajudar a identificar inconsistências de dados.
Como observação: o plug-in amcheck é um processo intensivo de recursos para executar, tanto em termos de E/S quanto de tempo. Se o banco de dados for grande ou se você não quiser afetar o funcionamento do banco de dados, considere executar o banco de dados em uma cópia física, para que o fluxo de trabalho da produção não seja interrompido, pois pode ser detectado na cópia do banco de dados.
- índice de reconstrução
Se forem encontrados problemas nas etapas acima, você precisará executar REINDEX ou REINDEX CONCURRENTLY. (Observação: se estiver usando Postgres 14, versão 14.4 ou superior é recomendado para reconstruir corretamente o índice online para evitar mais riscos de corrupção).