“É paradoxal, mas verdadeiro, dizer que quanto mais sabemos, mais ignorantes nos tornamos no sentido absoluto, pois é somente através da iluminação que nos tornamos conscientes de nossas limitações. Precisamente um dos resultados mais gratificantes da evolução intelectual é a contínua abertura de novas e maiores perspectivas.” Nikola Tesla
PostgreSQL é um projeto incrível e evolui a uma velocidade incrível. Vamos nos concentrar na evolução dos recursos de tolerância a falhas no PostgreSQL em todas as suas versões com uma série de postagens no blog.
PostgreSQL em poucas palavras
O PostgreSQL é tolerante a falhas por natureza. Primeiro, é um sistema avançado de gerenciamento de banco de dados de código aberto e comemorará seu 20º aniversário este ano. Por isso, é uma tecnologia comprovada e tem uma comunidade ativa, graças à qual tem um rápido progresso de desenvolvimento.
PostgreSQL é compatível com SQL (SQL:2011) e totalmente compatível com ACID (atomicidade, consistência, isolamento, durabilidade).
O PostgreSQL permite replicação física e lógica e possui soluções de replicação física e lógica integradas. Falaremos sobre métodos de replicação (nos próximos posts do blog) no PostgreSQL sobre tolerância a falhas.
O PostgreSQL permite transações síncronas e assíncronas, PITR (recuperação pontual) e MVCC (controle de simultaneidade multiversão). Todos esses conceitos estão relacionados à tolerância a falhas em algum nível e tentarei explicar seus efeitos enquanto explico os termos necessários e suas aplicações no PostgreSQL.
O PostgreSQL é robusto!
Todas as ações no banco de dados são executadas em transações , protegido por um registro de transações que executará a recuperação automática de falhas em caso de falha de software.
Os bancos de dados podem ser criados opcionalmente com somas de verificação de bloco de dados para ajudar a diagnosticar falhas de hardware. Existem vários mecanismos de backup, com PITR completo e detalhado, em caso de necessidade de recuperação detalhada. Uma variedade de ferramentas de diagnóstico estão disponíveis.
A replicação de banco de dados é suportada nativamente. Replicação Síncrona pode fornecer mais de "5 Noves" (99,999 por cento) disponibilidade e proteção de dados, se configurados e gerenciados adequadamente.
Considerando os fatos acima, podemos facilmente afirmar que o PostgreSQL é robusto!
Tolerância a falhas do PostgreSQL:WAL
O registro de escrita antecipada é o principal sistema de tolerância a falhas do PostgreSQL.
O WAL consiste em uma série de arquivos binários gravados no subdiretório pg_xlog do diretório de dados do PostgreSQL. Cada alteração feita no banco de dados é registrada primeiro no WAL, daí o nome “write-ahead” log, como sinônimo de “log de transações”. Quando uma transação é confirmada, o comportamento padrão — e seguro — é forçar os registros WAL para o disco.
Caso o PostgreSQL falhe, o WAL será repetido, o que retorna o banco de dados ao ponto da última transação confirmada e, assim, garante a durabilidade de quaisquer alterações no banco de dados.
Transação? Comprometer-se?
As próprias alterações do banco de dados não são gravadas no disco na confirmação da transação. Essas alterações são gravadas no disco algum tempo depois pelo gravador em segundo plano ou pelo checkpointer em um servidor bem ajustado. (Verifique a descrição do WAL acima. )
As transações são um conceito fundamental de todos os sistemas de banco de dados. O ponto essencial de uma transação é que ela agrupa várias etapas em uma única operação de tudo ou nada.
Os estados intermediários entre as etapas não são visíveis para outras transações simultâneas e, se ocorrer alguma falha que impeça a conclusão da transação, nenhuma das etapas afetará o banco de dados. O PostgreSQL não é compatível com leituras sujas (transação lê dados escritos por uma transação não confirmada concorrente ).
Ponto de verificação
A recuperação de falhas reproduz o WAL, mas a partir de que ponto ele começa a se recuperar?
A recuperação começa a partir de pontos no WAL conhecidos como pontos de verificação . A duração da recuperação de falhas depende do número de alterações no log de transações desde o último ponto de verificação. Um ponto de verificação é um ponto de partida seguro conhecido para recuperação, pois garante que todas as alterações anteriores no banco de dados já foram gravadas no disco.
Um ponto de verificação pode ser imediato ou agendado . Pontos de verificação imediatos são acionados por alguma ação de um superusuário, como o
CHECKPOINT comando ou outro; os checkpoints agendados são decididos automaticamente pelo PostgreSQL. Conclusão
Nesta postagem do blog, listamos recursos importantes do PostgreSQL relacionados à tolerância a falhas no PostgreSQL. Mencionamos registro de gravação antecipada, transação, confirmação, níveis de isolamento, pontos de verificação e recuperação de falhas. Continuaremos com a replicação do PostgreSQL na próxima postagem do blog.
Referências:
Documentação do PostgreSQL
Livro de receitas de administração do PostgreSQL 9 – segunda edição
