Embora não haja uma fórmula mágica para o ajuste do MySQL, existem algumas áreas que podem ser focadas no início e que podem melhorar drasticamente o desempenho da instalação do MySQL. Embora muitas informações tenham sido publicadas sobre esse tópico ao longo dos anos, eu queria analisar algumas das configurações mais críticas que qualquer um pode implementar sem a necessidade de suposições.
Cada nova conexão recebida precisa passar por uma etapa de autenticação antes de ser permitido o acesso aos dados do banco de dados de destino. Essa autenticação é baseada em diversas configurações, permissões de usuário e em uma tabela de regras contida no arquivo pg_hba.conf.
Além dos catálogos do sistema, o PostgreSQL fornece várias visualizações integradas. Algumas visualizações do sistema fornecem acesso conveniente a algumas consultas comumente usadas nos catálogos do sistema. Outras visualizações fornecem acesso ao estado do servidor interno.Primeiramente precisamos entender o que são os catalogos de sistema.
O WAL (Write Ahead Log) é um log de transação, necessário para garantir a atomicidade e durabilidade das transações mesmo após falhas. Até a verão 9.6 o diretório que armazena os logs de transação ficam por padrão em pg_xlog dentro do pg_data, a partir da versão 10 este foi renomeado para pg_wal, inicialmente no pg_data, mas podendo ter sua localização modificada no arquivo postgresql.conf, muitas das vezes essa alteração ocorre para um tuning do banco de dados, movendo os logs de transação para discos de Continue lendo→
Quando comandos DML são executados, o MVCC faz com que versões novas das tuplas(Linhas) sejam criadas na tabela. Com o tempo, as transações atuais são finalizadas e algumas das versões de tuplas se tornam permanentemente inacessíveis para todas as transações atuais e futuras, chamadas de tuplas mortas. Ainda assim, essas versões ocupam espaço na tabela e esse espaço precisa ser recuperado. A relação entre espaço ocupado por tuplas mortas e espaço total é conhecido como inchaço (bloat, em inglês).
Neste tutorial, você irá aprender como fazer backup e restore dos bancos de dados PostgreSQL usando a ferramenta pg_dump, pg_dumpall, psql e pg_restore. Fazer backup de bancos de dados é uma das tarefas mais críticas na administração de banco de dados. Antes de fazer backup dos bancos de dados, você deve considerar os seguintes tipos de backup: Bancos de dados completos ou parciais Dados e estruturas, ou apenas estruturas Recuperação pontual Restaurar desempenho O PostgreSQL vem com pg_dump e pg_dumpall que são ferramentas que ajudam Continue lendo→
O programa pg_upgrade depende dos serviços, tanto da versão de origem quanto da versão de destino, não estejam no ar. Contudo, depende dos diretórios de dados estarem inicializados. Quando executado, o pg_upgrade inicia as instâncias das duas versões e faz a transferência (cópia ou hard link) dos objetos que não sofreram alterações estruturais, assim como cria novos objetos no destino e copia os dados daqueles que sofreram alterações estruturais. Portanto, ele precisa conhecer as localizações dos diretórios de dados e dos diretórios de binários. Para usar o modo de hard link, Continue lendo→
Neste artigo, vamos mergulhar nos detalhes básicos de configuração do recurso de Streaming Replication no PostgreSQL. A replicação de streaming é o bloco de construção fundamental para alcançar alta disponibilidade em seu Servidor PostgreSQL e é produzida executando uma configuração master-slave. Terminologia Master-Slave Servidor Master(Mestre) / Primário O servidor que pode receber gravações. Também chamado de servidor de leitura / gravação. Slave(slave) / Standby Server Um servidor onde os dados são mantidos em sincronia com o Master continuamente. Também chamado de servidor de backup ou Continue lendo→
O banco de dados é o coração da aplicação. Antes de nos aprofundarmos em alguns insights sobre por que é essencial monitorar o Postgres, primeiro discutiremos um pouco sobre monitoramento. Monitorar é coletar pontos de dados históricos que você usa para gerar alertas (para quaisquer anomalias), para otimizar seu banco de dados e, por último, ser proativo no caso de algo dar errado (por exemplo, um banco de dados com falha). A abordagem “Veremos quando isso acontecer” pode funcionar com seus projetos pessoais, mas pode Continue lendo→
Pessoal recentemente precisei fazer um restore de um banco corrompido no PostgreSQL 12, já havia sido configurado previamente o arquivamento dos logs de transação e uma copia do pg_data para que quando necessário fosse feito o Point-in-time Recovery (PITR) em que conseguimos voltar no tempo no banco de dados. Ate ai tudo bem, facil de fazer. Mas eu não achava o recovery.conf que seria o arquivo onde determinamos o target time ou seja em qual data e hora iremos voltar no banco de dados. Então Continue lendo→