Machine Translated by Google

Machine Translated by Google

Baji Shaik

Configuração do PostgreSQL
Práticas recomendadas para desempenho e segurança
Machine Translated by Google

Baji Shaik
Hyderabad, Andhra Pradesh, Índia

Qualquer código-fonte ou outro material suplementar mencionado pelo autor neste livro
está disponível para leitores no GitHub por meio da página do produto do livro,
. Para maisvisite
localizada em www. apresse. com/978-1-4842-5662-6 informações, detalhes
http://www.
apresse. com/ código-fonte .

ISBN 978-1-4842-5662-6 e-ISBN 978-1-4842-5663-3

https://doi.org/10.1007/978-1-4842-5663-3

© Baji Shaik 2020

Impressão padrão

Nomes de marcas registradas, logotipos e imagens podem aparecer neste livro. Em

vez de usar um símbolo de marca registrada com cada ocorrência de um nome, logotipo
ou imagem de marca registrada, usamos os nomes, logotipos e imagens apenas de
forma editorial e para benefício do proprietário da marca registrada, sem intenção de
infringir a marca registrada. O uso nesta publicação de nomes comerciais, marcas
registradas, marcas de serviço e termos semelhantes, mesmo que não sejam identificados
como tal, não deve ser entendido como uma expressão de opinião sobre se eles estão
ou não sujeitos a direitos de propriedade.

Embora se acredite que os conselhos e informações neste livro sejam verdadeiros e

precisos na data de publicação, nem os autores, nem os editores, nem a editora
podem aceitar qualquer responsabilidade legal por quaisquer erros ou omissões que
possam ser cometidos. A editora não oferece nenhuma garantia, expressa ou implícita,
com relação ao material aqui contido.

Distribuído para o mercado livreiro mundial pela Springer Science+Business Media

New York, 1 New York Plaza, New York, NY 10004. Telefone 1-800- SPRINGER, fax
(201) 348-4505, e-mail orders-ny@springer- sbm.com ou visite www.springeronline.com.
Apress Media, LLC é uma LLC da Califórnia e
Machine Translated by Google

o único membro (proprietário) é Springer Science + Business Media Finance Inc

(SSBM Finance Inc). A SSBM Finance Inc é uma corporação de Delaware.
Machine Translated by Google

Índice
Capítulo 1: Melhores maneiras de instalar o PostgreSQL
Informações necessárias para a instalação

Tipos de instalações
Instalação da fonte

Instalação binária
Instalação RPM

Instaladores de um clique para Linux, Windows e Mac

Plano para a instalação

Recomendações gerais para disco/armazenamento do PostgreSQL

Escolha o local e a propriedade certos

Um cluster e banco de dados por servidor

Layouts do sistema de arquivos

Ajustando os parâmetros do SO

Antes da instalação

Depois da instalação

Solução de problemas de instalação

Resumo

Capítulo 2: Configurar seu banco de dados para melhor desempenho

Etapas iniciais após a instalação

Para desenvolvedores PostgreSQL

Para administradores

Arquivos de configuração e recomendações

postgresql. conf pg_hba. conf pg_ident. conf

Machine Translated by Google

Recomendações de parâmetros

Recomendações do SO

Por que permitir overcommits?

Estratégia Overcommit 0

Estratégia Overcommit 1

Estratégia Overcommit 2

Páginas enormes

Resumo

Capítulo 3: Gerenciamento de usuários e proteção de bancos de dados

Informações que você precisa saber

Mecanismos de Segurança

Autenticação no HBA

ACLs

RLS (Segurança em Nível de Linha)

SSL

Acionador de evento

Auditoria

Funções de monitoramento

Criptografia e PCI

Replicação

PL confiável vs. não confiável

Diretrizes de alta segurança e criptografia

Resumo

Capítulo 4: Práticas recomendadas de backup e restauração

Objetivo de fazer backup de um banco de dados

Reúna informações para configurar uma estratégia de backup

Machine Translated by Google

Tipos de backup

Backups lógicos

Backups físicos
Restaure seu banco de dados

Recuperação pontual

Projete uma estratégia de backup

Backups diários

Backups semanais

Backups Mensais

Backup anual

Monitoramento de backups

Resumo

Capítulo 5: Habilitar o registro de seu banco de dados e monitoramento

Instâncias do PostgreSQL

Por que / Quando / Como Registrar

Parâmetros a serem definidos para registro

Bancos de dados de monitoramento

Níveis de Monitoramento

Monitoramento de nível de SO

Monitoramento de nível de banco de dados

Ferramentas de monitoramento/relatório

Resumo

Capítulo 6: Executar Manutenção

O que é MVCC

MVCC no PostgreSQL

Por que/Como—Atividades de Manutenção

Machine Translated by Google

Inchaço de tabela e índice

AUTOVACUUM/VACUUM

Fragmentação do Índice
Outra manutenção de banco de dados

Resumo

Capítulo 7: Procedimentos de alta disponibilidade e implementação de um pooler

Por que alta disponibilidade?

Reúna informações para configurar HA

RPO e RTO

RPO (objetivo do ponto de recuperação)

RTO (Objetivo de Tempo de Recuperação)

Soluções de alta disponibilidade no núcleo PostgreSQL

Warm Standby/Remessa de Logs

Replicação de Streaming em Hot

Standby Replicação em Cascata

Warm/Hot Standby vs.Replicação

de Streaming Solução simples de alta disponibilidade

Melhor solução de alta disponibilidade

Ferramentas de failover automático disponíveis

Atraso de replicação

Problemas comuns de replicação

Por que o pool de conexões

pgBouncer pgpool-II

Resumo
Machine Translated by Google

Capítulo 8: Erros básicos e consultas úteis

Erros básicos do PostgreSQL

Erros de conexão

Erros de configuração

Erros de consulta
Outros erros

Consultas úteis do PostgreSQL

Consultas básicas

Consultas de monitoramento

Consultas de privilégios de objeto

Consultas em nível de objeto

Resumo
Índice
Machine Translated by Google

Sobre o autor Baji Shaik é

administrador e desenvolvedor
de banco de dados.
Ele foi apresentado aos bancos de dados em
2011 e, ao longo dos anos, trabalhou com Oracle,
PostgreSQL, Postgres Advance Server, RedShift
e Greenplum. Ele tem uma ampla gama de
conhecimentos e experiência em bancos de
dados SQL/NoSQL, como Cassandra e
DynamoDB. Ele é especialista em migração de
banco de dados e desenvolveu muitas soluções
de banco de dados bem-sucedidas, abordando
requisitos de negócios desafiadores para mover
bancos de dados locais para a Nuvem AWS
usando vários serviços da AWS.
Baji organizou vários encontros do
PostgreSQL e mantém seu próprio blog
técnico, onde gosta de compartilhar seu
conhecimento com a comunidade. Ele é coautor do Begining PostgreSQL on the
Cloud , lançado em março de 2018.
Machine Translated by Google

Sobre o revisor técnico Jobin Augustine é

especialista em PostgreSQL e defensor do
código aberto e tem mais de 18 anos de
experiência de trabalho como consultor,
arquiteto, administrador, escritor e instrutor em
PostgreSQL, Oracle e outras tecnologias de
banco de dados. Ele sempre foi um participante
ativo nas comunidades de código aberto, e sua
principal área de foco é desempenho e
otimização de banco de dados. Ele é um rosto
regular em muitas das conferências do
PostgreSQL. Ele contribui para vários projetos
de código aberto, é um blogueiro ativo e adora
codificar em C++ e Python. Jobin é Mestre em
Aplicações Informáticas e ingressou na Percona
em 2018 como Engenheiro de Suporte Sênior.
Antes de ingressar na Percona, ele trabalhou na
OpenSCG por 2 anos como arquiteto e fez parte da equipe principal do
BigSQL, uma oferta completa de distribuição do PostgreSQL. Antes de seu
trabalho no OpenScg, Jobin trabalhou na Dell como Consultor Sênior de Banco
de Dados por 10 anos e 5 anos com TCS/CMC.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_1

1. Melhores maneiras de instalar o PostgreSQL

Baji Shaik1 (1)

Hyderabad, Andhra Pradesh, Índia

Este capítulo aborda as melhores maneiras de instalar o PostgreSQL. Ele responde as seguintes perguntas:

1.
Quais informações você precisa para instalar o PostgreSQL em um servidor?
2.
Quais pré-requisitos você deve seguir?
3.
Quais são as melhores maneiras de instalar o PostgreSQL?
4.
Quais são as etapas pós-instalação que facilitam sua vida?
5.
Como você soluciona problemas de instalação?
6.
Como você ajusta os parâmetros do sistema operacional (SO) para evitar problemas no futuro?

O PostgreSQL é um dos bancos de dados de código aberto mais avançados do mundo. Se alguém quiser migrar de um banco de
dados corporativo para um banco de dados de código aberto para economizar algum dinheiro ou para melhorar a segurança usando código-
fonte totalmente auditável ou desenvolvimento personalizado, o PostgreSQL é um dos melhores bancos de dados a serem considerados.
Possui um rico conjunto de recursos e é famoso por constantes lançamentos importantes. Sua enorme comunidade garante a estabilidade do
banco de dados corrigindo continuamente bugs e adicionando novos recursos de desenvolvimento, incluindo uma alta porcentagem de
conformidade ANSI SQL com a qual compete com outros grandes bancos de dados corporativos no mercado.
Antes de poder usar o PostgreSQL, você precisa instalá-lo. Como é de código aberto, existem várias maneiras de instalá-lo.
Depende do ambiente em que você vai instalar e da distribuição do PostgreSQL que você instala. Nem todos os ambientes são amigáveis
para seguir o mesmo procedimento de instalação. Portanto, é muito importante obter o máximo de informações possível antes de instalá-lo.

Às vezes, os clientes podem não conseguir fornecer todos os detalhes necessários para a instalação. Portanto, como administrador,
você precisa solicitar explicitamente as informações necessárias. É sempre recomendável conversar com seu cliente sobre isso. Para garantir
uma conversa eficaz sobre instalação, é importante saber de quais informações você precisa e por que precisa delas.

Informações necessárias para a instalação Nesta seção,

abordaremos as respostas para a pergunta: Que informações precisamos ter para instalar o PostgreSQL em um servidor?

Aqui estão algumas perguntas através das quais você obterá os detalhes para instalar o PostgreSQL.

Observação Cada pergunta tem um propósito específico adicionado a ela, o que ajuda na conversa com o cliente e para prosseguir.

Q1. Qual é o sistema operacional? Qual é a arquitetura do SO (32/64 bits)?

Objetivo: Esta é uma pergunta básica que você deve fazer. Os procedimentos de instalação variam de um SO para
outro. Portanto, é importante saber qual sistema operacional você vai instalar. Ele ajuda você a planejar o
Machine Translated by Google

instalação, sobre a qual falaremos em seções posteriores do capítulo.

Q2.
Quais são as especificações da máquina (RAM, CPU)?
Objetivo: O PostgreSQL usa alguma memória compartilhada (com base em sua configuração) enquanto está em
funcionamento. Portanto, com base na memória do servidor, você deve planejar definir a memória compartilhada do sistema operacional.
Ele pode ser definido por meio de alguns parâmetros do kernel, que serão abordados mais adiante neste capítulo.
Q3.
Qual é o tamanho atual e o crescimento esperado do aplicativo?
Objetivo: Quanto armazenamento deve ser alocado ao PostgreSQL depende do tamanho atual dos dados e
crescimento esperado de dados. Em geral, as empresas planejam o armazenamento com base no crescimento futuro.
Recomenda-se planejar tendo em mente os próximos 3 a 5 anos de crescimento.
Q4.
Qual é o tipo de armazenamento?
Objetivo: Armazenamentos diferentes têm comportamento diferente com o PostgreSQL. Assim, recomenda-se
saber que tipo de armazenamento, como discos magnéticos, SSD (Solid State Drive), NVMe (Non-Volatile Memory express),
SAN (Storage Area Network), LVM (Logical Volume Management) ou armazenamento em nuvem como EBS (Elastic Block Store) — que
o cliente deseja usar.
Q5.
Qual sistema de arquivos está sendo usado pelo servidor?
Objetivo: Um dos principais fatores que afetam o desempenho do PostgreSQL é o tipo de sistema de arquivos. Você deve
saber qual sistema de arquivos está atualmente no servidor e quais recomendações você pode dar para obter o melhor desempenho.
Como varia de aplicativo para aplicativo e de ambiente para ambiente (basicamente, depende dos tipos de carga de trabalho), você
deve realmente avaliar seu desempenho para os sistemas de arquivos disponíveis e decidir qual é o mais adequado para seu aplicativo.
No entanto, existem algumas recomendações gerais de tipos de sistema de arquivos para o PostgreSQL, sobre as quais falaremos na
seção “Recomendações gerais para disco/armazenamento do PostgreSQL”.

Q6.
Quantos pontos de montagem?
Objetivo: Esta pergunta ajuda você a saber sobre os pontos de montagem atuais no servidor. O PostgreSQL foi projetado para
gravar em vários arquivos quando algo é selecionado/inserido/atualizado/excluído no banco de dados.
Portanto, a E/S de disco se torna um gargalo na maioria das vezes. Se você puder planejar adicionar pontos de montagem conforme
necessário, isso distribuirá a E/S pelos pontos de montagem para que os gargalos de E/S possam ser evitados, o que reduziria muito o
consumo de E/S no servidor. Discutimos quais arquivos são gravados e como planejar vários pontos de montagem em uma seção
posterior do capítulo.
Q7.
A Internet pública é acessível a partir do servidor?
Finalidade: Dependendo da instalação escolhida, é necessário saber se o servidor pode acessar
a Internet pública ou não. Isso pode afetar a maneira como você instala o software PostgreSQL e faz manutenções futuras,
incluindo atualizações. Se o servidor não puder se conectar à Internet pública, você precisará baixar os pacotes de software
necessários em um servidor que tenha acesso à Internet e copiar esses pacotes de software para um servidor de produção por meio
de uma rede privada ou de qualquer maneira possível para o cliente.

Para planejar o procedimento de instalação correto, você precisa saber as respostas para as perguntas anteriores.

Tipos de instalações
Vamos falar sobre os tipos de instalações antes de planejarmos a instalação. Você pode instalar o PostgreSQL de quatro maneiras.

Instalação de origem
Instalação binária
Instalação de RPM
Instalador de um clique

Como o PostgreSQL é de código aberto, o código-fonte está disponível no site do PostgreSQL (postgresql.org).
Vamos cobrir cada método de instalação em detalhes a seguir.
Machine Translated by Google

Instalação do código-
fonte A instalação do código-fonte nada mais é do que compilar o código-fonte do PostgreSQL. Você não precisa ser um
especialista em codificação para compilar o código-fonte. No entanto, você precisa entender cada etapa da instalação para
poder solucionar problemas de instalação.
A seguir estão as etapas de alto nível que você pode executar para instalar a partir da fonte.

Observação O PostgreSQL Versão 11.4 é usado no exemplo a seguir. Etapas semelhantes também funcionam para outras
versões.

1.
Você pode baixar a fonte do site oficial do PostgreSQL (postgresql.org).
Para baixar do navegador:

https://ftp.postgresql.org/pub/source/v11.4/postgresql-11.4.tar.bz2

No Linux:

wget https://ftp.postgresql.org/pub/source/v11.4/postgresql 11.4.tar.bz2

No Mac:

curl -O https://ftp.postgresql.org/pub/source/v11.4/postgresql 11.4.tar.bz2

2.
Descompacte o arquivo baixado da seguinte forma:

tar -xf postgresql-11.4.tar.bz2 Todos os arquivos

fonte serão descompactados em um diretório postgresql-11.4

3. Entre no diretório criado na etapa 2 e execute o comando configure da seguinte forma:

O diretório de instalação padrão para os binários finais do PostgreSQL é /usr/local/pgsql. Se você deseja
instalá-lo em um local diferente, uma opção de prefixo pode ser usada para o comando configure da seguinte maneira.

cd postgresql-11.4 ./
configure

./configure --prefix=/location/to/install/

O comando configure basicamente procura em sua máquina as bibliotecas de dependência necessárias para
o PostgreSQL. Ele informa se sua máquina está faltando algum. Você pode instalar as bibliotecas ausentes primeiro e, em
seguida, executar novamente o comando configure. Então, basicamente, você prepara sua máquina para compilar o código
fonte do PostgreSQL neste estágio. Se você não conseguir capturar informações de configuração enquanto estiver em
execução ou o terminal for fechado após a falha do comando configure, ele criará um config.log no mesmo local de onde
você está executando o comando configure. Usando este log, você verá a saída do comando configure.
Se seu aplicativo for projetado para usar linguagens como Perl, Python, Tcl, etc. no lado do banco de
dados, você precisará optar por locais de pacotes de idiomas correspondentes usando os seguintes parâmetros:

--with-perl --with-
python --with-tcl

Da mesma forma, se você quiser usar o OpenSSL, forneça as bibliotecas do OpenSSL usando o seguinte parâmetro:

--with-openssl
Machine Translated by Google

Existem várias opções disponíveis com base no requisito. Você pode obter ajuda para configurar usando
o seguinte comando:

./configure --help

4.
Assim que a configuração estiver concluída, você pode executar make e make install para concluir a instalação.

make -j 8 && make install

A opção -j especifica trabalhos paralelos. Defina esse valor com base em seus núcleos de CPU, que podem ser utilizados
para o trabalho de compilação.
Basicamente, o make prepara compila todas as bibliotecas e binários para o PostgreSQL e o make install copia todas
as bibliotecas e binários necessários para o local de instalação (pode ser o local padrão ou o local especificado através da
opção “--prefix”).
5.
Verifique se todos os binários e bibliotecas estão instalados e no local que você especificou.
6.
Após a instalação, crie um diretório de dados onde os dados podem ser armazenados. Recomenda-se criar um usuário do
sistema operacional “postgres” para possuir esse diretório de dados e os Serviços Postgres.
Cada instância do PostgreSQL é chamada de “cluster”. Significa apenas que uma instância pode ter vários bancos
de dados. Por favor, não se confunda com um cluster de vários nós de servidor. Cada diretório de dados contém todos os
dados e arquivos de configuração de uma instância. Assim, cada instância pode ser referida de duas maneiras:

Localização do diretório de dados

Número da porta

Um único servidor pode ter muitas instalações e você pode criar vários clusters usando o initdb.
Aqui estão os comandos que precisam ser executados para criar um usuário, criar um diretório de dados e inicializá-lo
diretório de dados (supondo que você o tenha instalado em locais padrão):

adduser postgres mkdir /usr/

local/pgsql/data chown postgres /usr/local/pgsql/
data su – postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/
data

Nota “/usr/local/pgsql/data” é o diretório de dados. initdb é o binário para inicializar um novo diretório de dados.

Para iniciar o PostgreSQL, devemos especificar o diretório de dados associado. Use a ferramenta pg_ctl e especifique o
diretório de dados para iniciar a instância da seguinte forma:

/usr/local/pgsql/bin/pg_ctl -D/usr/local/pgsql/data start

Detalhes de requisitos básicos, procedimento de instalação, etapas de pós-instalação e plataformas suportadas são
aqui: www.postgresql.org/docs/current/static/installation.html.
A compilação completa do código-fonte e da instalação pode ser roteirizada como um script de shell simples.
Vamos ver um script de shell de amostra que faz a compilação e configuração do código-fonte para você. Este arquivo de script pode ser
executado com três parâmetros para especificar o tipo de SO, a versão do PostgreSQL e o número da porta
Por exemplo, se quisermos construir o PostgreSQL 11.4 no Linux e configurar a instância na porta padrão 5432,
usamos a seguinte linha de comando:

sh <scriptfile> Linux 11.4 5432

Machine Translated by Google

Aqui está o conteúdo do arquivo de script:

#!/bash/sh
export OS=$1
export VERSION=$2
export PORT=$3 export
INSTALL_DIR=$HOME/pg_software

if ! -d "$ INSTALL_DIR"]
[ then
echo "$INSTALL_DIR diretório não existe. Criando agora" mkdir $INSTALL_DIR
echo "$INSTALL_DIR diretório criado" else echo "$INSTALL_DIR existe"

ser

cd $HOME/pg_software

## Baixando o código-fonte de acordo com o sistema operacional

if [ "$1" == "Linux" ] || ["$1" == "linux"]; então echo "Baixando PostgreSQL

$VERSION.." wget

https://ftp.postgresql.org/pub/source/v$VERSION/postgresql-$VERSION.tar.bz2 >/dev/null if [ "$?" -gt "0"];

então

echo "Não foi possível baixar o arquivo, verifique se o wget está instalado ou não" exit else echo
"Baixado PostgreSQL $VERSION..."

ser
elif [ "$1" == "Mac" ] || ["$1" == "mac"]; então echo "Baixando
PostgreSQL $VERSION.." curl -O

https://ftp.postgresql.org/pub/source/v$VERSION/postgresql-$VERSION.tar.bz2 > $HOME/pg_software/

comile_$VERSION.log 2>&1 if [ "$?" -gt "0"]; então

echo "Não foi possível baixar o arquivo, verifique se o curl está instalado ou
não"
exit
else echo
"Baixado PostgreSQL $VERSION..."
ser

senão
echo "atualmente funciona com linux e mac OS" exit

ser

## Compilando o código fonte

echo "espere! deixe compilar..." cd

$INSTALL_DIR/tar -xf postgresql-
$VERSION.tar.bz2
Machine Translated by Google

cd postgresql-$VERSION ./
configure --prefix=$HOME/pg_software/$VERSION && make world -j 8 && make install-world > $HOME/
compile.log if [ "$?" -gt "0"]; then echo "Não foi possível compilar o código-fonte, por favor veja compile.log
para

mais informações" sair

senão
echo "Ok, compilei para você !!.."
ser

## Configurando o evn
"
echo "configurando o env... isso facilita sua vida..

touch $HOME/pg_software/$VERSION/source_$VERSION.env echo

"export PATH=$HOME/pg_software/$VERSION/bin:$PATH" >> $HOME/
pg_software/$VERSION/source.env echo "export PGPORT= 5432" >> $HOME/
pg_software/$VERSION/source.env echo "exportar PGDATA=$HOME/pg_software/$VERSION/
data" >> $HOME/pg_software/$VERSION/source.env echo "exportar PGDATABASE=postgres"
>> $HOME/pg_software/$VERSION/source.env echo "export PGUSER=postgres" >> $HOME/
pg_software/$VERSION/source.env

echo "source $HOME/pg_software/$VERSION/source.env" >> $HOME/.bash_profile . $HOME/.bash_profile

echo "Ok, feito com a configuração do ambiente .. agora você pode ser preguiçoso .. !"
## Criar diretório DATA

echo "Ah, é hora dos dados.. criando diretório de dados...!"

initdb -D $PGDATA -U postgres >/dev/null 2>&1

echo "Feito amigo !! .. deixe-me habilitar o log e permitir conexões de outros hosts ....."

## Habilite o registro.. e permita outros hosts.

echo "port=$PORT" >> $PGDATA/postgresql.conf echo

"logging_collector=on" >> $PGDATA/postgresql.conf echo "listen_addresses='*'"
>> $PGDATA/postgresql.conf

## Iniciar banco de
dados echo "você está tomando café !!!.. Ok, np, deixe-me começar para você..!" pg_ctl -D
$PGDATA start >/dev/null sleep 5 echo "hmm.. parece que começou.. mas deixe-me verificar uma
vez.." ## check DB está ativo

psql -p $PGPORT -U $PGUSER -d $PGDATABASE -c "selecione 1;" > /dev/null

if [ "$?" -gt "0"]; then echo

"Desculpe !!, não foi iniciado .. ainda não sou esperto o suficiente para corrigir .. :-(.. culpar o
autor !!.." else

echo "hurra.. funciona.. divirta-se!"

ser
Machine Translated by Google

Instalação Binária Esta

instalação nada mais é do que baixar binários já compilados (da instalação fonte) de diferentes repositórios mantidos
por comunidades e fornecedores de suporte ao PostgreSQL.
A instalação binária espera que o servidor satisfaça todas as dependências. No entanto, a maior parte do pacote
os gerentes são inteligentes o suficiente para detectar as dependências necessárias e instalá-las, se necessário.
Alguns dos repositórios binários notáveis são:

www.postgresql.org/ftp/binary/ https://
yum.postgresql.org/ www.postgresql.org/download/
linux/ubuntu/

Instalação RPM
O PostgreSQL mantém um repositório onde você pode ver todas as versões do
PostgreSQL: https://yum.postgresql.org/rpmchart.php.
RHEL, CentOS, Oracle Enterprise Linux e Scientific Linux são atualmente suportados pelo repositório PostgreSQL yum.
Apenas a versão atual do Fedora é suportada devido a um ciclo de suporte mais curto, portanto, o Fedora não é recomendado para
nenhuma implantação de servidor crítica para os negócios.
Você precisa adicionar e atualizar o repositório PostgreSQL mantido pelo PostgreSQL Global Development
Group (PGDG) para instalar uma versão específica dos RPMs do PostgreSQL. Você pode selecionar uma versão do PostgreSQL
e do sistema operacional em www.postgresql.org/download/linux/redhat/ para atualizar seu repositório, conforme mostrado na
captura de tela a seguir.

Figura 1-1 instalação de rpm

Vamos adicionar e atualizar o repositório e instalar RPMs.

Nota PostgreSQL 11 e RHEL 8 são usados para mostrar demonstração.

1.
Para adicionar e atualizar o repositório pgdg para obter o PostgreSQL 11, execute o seguinte comando:

dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL 8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2.
Para instalar apenas pacotes de cliente:

dnf instalar postgresql11

3. Para instalar os pacotes do servidor:

dnf instalar postgresql11-server

Machine Translated by Google

4.

Para inicializar o banco de dados e habilitar o início automático:

/usr/pgsql-11/bin/postgresql-11-setup initdb systemctl habilita postgresql-11

systemctl start postgresql-11

5.
Para instalar RPMs de linguagem como Perl, Python, Tcl, etc., use o seguinte comando:

dnf install postgresql11-plperl* dnf install postgresql11-

plpython* dnf install postgresql11-pltcl*

6.
Pós-instalação
A inicialização automática ou a inicialização automática do diretório de dados não está habilitada para distribuições da família Red Hat
devido a algumas políticas. Portanto, você precisa executar as etapas a seguir manualmente para concluir a instalação do
banco de dados.

Para RHEL / CentOS / SL / OL 6 service postgresql

initdb chkconfig postgresql on Para RHEL / CentOS /
SL / OL 7, 8 ou Fedora 29 e posteriores
distribuições derivadas: postgresql-setup initdb systemctl enable postgresql.service systemctl start
postgresql.service

Instaladores de um clique para Linux, Windows e Mac A maneira mais

fácil de instalar o PostgreSQL é por meio de instaladores. Os instaladores de um clique fornecem um assistente gráfico para
instalação. Esses instaladores têm opções para escolher seus locais de instalação e diretório de dados, porta, usuário, senhas, etc.

Baixe os instaladores aqui (de acordo com o seu sistema operacional):

www.enterprisedb.com/downloads/postgres-postgresql-downloads.
Clique duas vezes no instalador e siga o assistente da GUI, onde você pode seguir as etapas simples para fornecer
informações básicas do local de instalação, diretório de dados e porta.

Plano para a instalação Discutimos os

tipos de instalação do PostgreSQL e como instalá-lo em diferentes tipos de sistemas operacionais na seção anterior. No
entanto, como você planeja a instalação?
Para planejar a instalação, você precisa analisar as respostas às perguntas na seção “Informações Necessárias para
seção Instalação”. Então, anote:

Q1. Qual é o sistema operacional? Qual é a arquitetura do SO (32/64 bits)?

Se for Linux:
Você pode optar por qualquer tipo de instalação que foi discutida na seção “Tipos de instalações”.
No entanto, a instalação do RPM é recomendada porque é fácil atualizar o repositório e executar alguns comandos para
instalar e configurar o banco de dados. Para instalações de origem e binárias, você precisa cuidar das dependências
manualmente, o que será uma tarefa enorme se você tiver um servidor com instalação mínima por motivos de segurança.
Para uma instalação do instalador você precisa de uma GUI, que não será permitida em alguns servidores.
Se for Mac ou Windows:
Machine Translated by Google

Você pode ir para a instalação do instalador usando uma GUI. No entanto, recomenda-se evitar a instalação em
Mac em ambientes de produção.
Q2.
Quais são as especificações da máquina (CPU, RAM)?
Com base na quantidade de RAM no servidor, você pode definir os parâmetros de nível do kernel antes/depois da instalação.
Abordaremos mais sobre quais parâmetros precisam ser alterados e quais são os valores na seção “Ajustando os parâmetros do sistema
operacional”.
Q3.
Qual é o tamanho atual e o crescimento esperado do aplicativo?
Com base no tamanho atual e no crescimento esperado, o armazenamento precisa ser provisionado antes da instalação e
configurar o servidor. Depois de preparar os sistemas de arquivos com o armazenamento necessário, você pode iniciar a instalação.
É difícil aumentar o armazenamento sem obter um tempo de inatividade do banco de dados. Portanto, configurar o armazenamento no
momento da instalação economizará muito tempo no futuro.
Q4.
Qual sistema de arquivos está sendo usado pelo servidor?
O PostgreSQL é melhor para trabalhar com o sistema de arquivos ext4. Portanto, certifique-se de ter o sistema de arquivos ext4
no servidor antes da instalação. Às vezes, isso economizará muito tempo para descobrir os problemas de desempenho com o banco de
dados.

Nota Você precisa comparar os resultados e ver qual sistema de arquivos é o mais adequado para suas cargas de trabalho.

Q5.
Quantos pontos de montagem?
Recomenda-se criar vários pontos de montagem para o PostgreSQL para evitar gargalos de E/S no futuro.
Discutiremos mais sobre o que pode ser distribuído entre os pontos de montagem na seção “Recomendações
gerais para disco/armazenamento do PostgreSQL”.
Q6.
A Internet pública é acessível a partir do servidor?
Se você tiver acesso público à Internet no servidor, seu trabalho será fácil. Você pode baixar
source/binaries/rpms diretamente no servidor e instale-os.
Se você não tiver acesso público à Internet no servidor, baixe source/binaries/rpms em uma bastion/jump machine que
tenha acesso público e copie-o para um servidor de produção por meio de uma rede privada.

Depois de anotar todos os detalhes, prepare a documentação e siga o procedimento para instalar o PostgreSQL.

Recomendações gerais para disco/armazenamento do PostgreSQL

A instalação do PostgreSQL é um esforço combinado de administradores de banco de dados, sistema e armazenamento. Os
administradores de banco de dados (DBAs) devem trabalhar em estreita colaboração com os administradores de sistema e armazenamento. O
PostgreSQL depende muito do sistema operacional host para gerenciamento de armazenamento. Ele não possui os recursos do tipo ASM do
Oracle para gerenciamento de armazenamento.
Aqui estão algumas recomendações para padronizar e simplificar as instalações do banco de dados PostgreSQL.

Escolha o local e a propriedade corretos A maioria das pessoas

escolhe o local padrão para instalar os binários do PostgreSQL. No entanto, você pode instalá-los em um local específico, se desejar, para que
não sejam misturados com o material do sistema operacional. Conforme discutido na seção “Tipos de instalações”, você pode escolher qualquer
local personalizado para instalação. É uma boa prática ter um diretório base como “/opt/PostgreSQL” e diferenciar as versões usando os dois
primeiros dígitos do número da versão, como “/opt/PostgreSQL/11/.” Ele ajuda você a acompanhar a versão dos binários durante uma atualização
do banco de dados no futuro.

Recomenda-se ter um usuário de SO separado para instalação do PostgreSQL, “postgres”, por exemplo, e
torná-lo o proprietário da instalação do PostgreSQL.
Machine Translated by Google

Um cluster e banco de dados por servidor No PostgreSQL,

existem objetos que são específicos do cluster e específicos do banco de dados. Os seguintes objetos físicos e lógicos são aplicáveis em todo o
cluster em uma instância do PostgreSQL.

Arquivos de configuração
Arquivos WAL (online e arquivados)
Espaços de tabela
Contas de usuário e funções
Arquivo de log do servidor

Um estilo mais antigo de separação de objetos de banco de dados era por meio do uso de vários bancos de dados. Um método alternativo e
mais gerenciável para separar objetos de banco de dados em um único servidor de banco de dados é por meio do uso de esquemas. No entanto,
muitos esquemas com um grande número de tabelas podem ter um efeito adverso na
autovácuo.

Para separar clusters PostgreSQL em um servidor, diferentes áreas de dados e números de porta IP precisam ser usados.
No entanto, os recursos de virtualização de sistemas operacionais como as zonas do Solaris e jails do FreeBSD ou hipervisores como Xen e KVM
tornam desnecessária a criação de vários clusters em um único host. A recomendação é ter apenas um cluster PostgreSQL por host virtualizado.

Layouts de sistema de arquivos

Falamos sobre pontos de montagem na seção “Informações necessárias para instalação”. O PostgreSQL grava em vários arquivos, dependendo
da transação que você executa. A seguir estão os arquivos que são atualizados:

Arquivos de dados

Arquivos WAL

Arquivos de registro

Arquivos temporários

Espaços de tabela

Para distribuir o IO ao atualizar esses arquivos, é recomendável ter esses diferentes tipos de arquivos em
diferentes pontos de montagem. Vejamos como fazê-lo.

Separação do cluster de dados Ao

criar um cluster de dados, você pode escolher um ponto de montagem no qual deseja que seus dados residam. Ao inicializar o cluster, use a
opção -D para mencionar o local do diretório de dados ou use a variável PGDATA para especificar o local. Por exemplo:

initdb -D /filesystem/for/data

Separação de arquivos WAL

Você pode ter um ponto de montagem separado para arquivos WAL, pois esses arquivos serão atualizados em cada transação que modifica o banco
de dados. Não há parâmetro de configuração que faça essa separação diretamente. Cada cluster de dados tem um diretório chamado “pg_xlog” (<=
versão 9.6) ou “pg_wal” (>= versão 10). Você pode criar um diretório no ponto de montagem que deseja designar para arquivos WAL e criar um link
simbólico do diretório pg_xlog ou pg_wal para o novo diretório criado.

Nota Esta alteração requer uma reinicialização do PostgreSQL. Depois que um link simbólico é criado e o PostgreSQL é reiniciado, você pode ver
novos arquivos WAL gerados em um novo local. Você pode considerar copiar WALs de um local antigo para o novo local antes de reiniciar o
PostgreSQL.

Separação de arquivos de log

Os arquivos de log são essenciais para iniciar a solução de problemas de banco de dados. A quantidade de registro é baseada nas
configurações de registro no arquivo de configuração. Se você deseja registrar tudo para sistemas de banco de dados críticos, pode haver uma
enorme geração de logs. Portanto, separar os arquivos de log em outro ponto de montagem que não os dados economiza um pouco de pressão de E/S. Você pode fazer
Machine Translated by Google

que usando o parâmetro “log_directory”. Essa alteração requer apenas um recarregamento do cluster. Você pode usar
as seguintes etapas:

postgres=# show log_directory ; log_directory

---------------
log
(1 linha)

postgres=# altere system set log_directory TO '/path/to/log/filesystem';

ALTER SYSTEM
postgres=# selecione pg_reload_conf();
pg_reload_conf
----------------
t
(1 linha)

postgres=# show log_directory ; log_directory

-------------------------
/path/to/log/filesystem (1 linha)

postgres=#

Separação de arquivos
temporários O PostgreSQL usa arquivos temporários para a operação de classificação em uma consulta se a memória de trabalho
alocada não for suficiente. Por padrão, ele cria arquivos temporários no diretório “pgsql_tmp” em $PGDATA/base. No entanto, você pode
criar um tablespace e usá-lo para operações de arquivos temporários. Você pode usar as seguintes etapas.

postgres=# show temp_tablespaces ;

temp_tablespaces
------------------

(1 linha)

postgres=# cria tablespace for_temp_files local '/tmp';

CREATE TABLESPACE
postgres=# postgres=#
altere system set temp_tablespaces para '/tmp';
ALTER SYSTEM
postgres=#
postgres=# selecione pg_reload_conf();
pg_reload_conf
----------------
t
(1 linha)

postgres=# show temp_tablespaces ;

temp_tablespaces
------------------
"/tmp" (1
linha)

postgres=#
Machine Translated by Google

O diretório de
dados de tablespaces não é o único local para armazenar os dados postgres; no entanto, você pode escolher um ponto de
montagem diferente para armazenar os dados. Para isso, você precisa criar um tablespace e atribuí-lo ao objeto que deseja
mover do local de dados padrão para um novo local. Ou você pode atribuir o tablespace ao nível de usuário ou banco de dados
para que todos os objetos criados pelo usuário ou todos os objetos criados dentro do banco de dados sejam armazenados no ponto
de montagem para o qual um tablespace foi criado. Você pode criar um tablespace e atribuir objetos usando as seguintes etapas:

postgres=# cria a localização do tablespace new_tblsc

'/Users/shbaji/pg_software/newtblsc';
CREATE TABLESPACE
postgres=# postgres=#
alter table orders_1 set tablespace new_tblsc;
ALTER TABLE
postgres=#
postgres=# selecione relname, reltablespace de pg_class onde relname="orders_1";
relname | reltablespace

----------+---------------
pedidos_1 | 33888
(1 linha)

postgres=# selecione oid, spcname de pg_tablespace onde

spcname="new_tblsc"; oid | spcname

-------+-----------
33888 | new_tblsc (1
linha)

postgres=#

Ajustando os parâmetros do SO
O ajuste dos parâmetros do SO é dividido em:
Antes da instalação
Depois da instalação

Antes da instalação A
primeira coisa que você precisa procurar antes de começar a instalar o PostgreSQL são os parâmetros de memória
compartilhada. Como o PostgreSQL usa memória compartilhada, você pode precisar alterar parâmetros do kernel como
SHMMAX, SHMMIN, SHMALL, etc. Para novas versões do PostgreSQL 9.3, talvez não seja necessário fazer isso, pois ele usa
alocação de memória POSIX.

Se você não mudar, a instalação do PostgreSQL pode esgotar os limites de recursos rapidamente.
Você pode alterar os parâmetros de acordo com as configurações de parâmetros do PostgreSQL. O uso de memória compartilhada do
PostgreSQL é o seguinte:

Nome Descrição Valores necessários para executar uma instância do PostgreSQL

SHMMAX Tamanho máximo do compartilhado Pelo menos 1kB, mas o padrão geralmente é muito maior
segmento de memória (bytes)

SHMMIN Tamanho mínimo compartilhado 1

segmento de memória (bytes)

SHMALL Quantidade total de memória compartilhada Igual a SHMMAX se bytes ou ceil(SHMMAX/PAGE_SIZE) se páginas, mais espaço para outros aplicativos
disponível (bytes ou páginas)
Machine Translated by Google

Nome Descrição Valores necessários para executar uma instância do PostgreSQL

SHMSEG Número máximo de compartilhados Apenas um segmento é necessário, mas o padrão é muito maior.
segmentos de memória por processo

SHMMNI Número máximo de compartilhados Como SHMSEG mais espaço para outras aplicações
segmentos de memória em todo o sistema

SEMMNI Número máximo de Pelo menos ceil((max_connections + autovacuum_max_workers + max_wal_senders +

identificadores de semáforo (ou seja, conjuntos) max_worker_processes + 5) / 16) mais espaço para outros aplicativos

SEMMNS Número máximo de semáforos Ceil((max_connections + autovacuum_max_workers + max_wal_senders + max_worker_processes + 5) / 16) * 17 mais
em todo o sistema espaço para outras aplicações

SEMMSL Número máximo de semáforos Pelo menos 17

por conjunto

SEMMAP Número de entradas no mapa de semáforos Ver texto

SEMVMX Valor máximo do semáforo Pelo menos 1000 (O padrão geralmente é 32767; não altere a menos que seja necessário.)

De acordo com o uso do PostgreSQL conforme mostrado na tabela anterior, você pode alterar os parâmetros do kernel usando a tabela a
seguir (é aplicável <= PostgreSQL 9.2):

Se você estiver alterando esses parâmetros, lembre-se de que precisará recarregar as configurações usando “sysctl -p”.
Você pode até alterá-los em tempo de execução.

Após a instalação Aqui

estão os parâmetros que você pode ajustar em um servidor onde o PostgreSQL está rodando.

overcommit_memory
overcommit_ratio
vm.dirty_ratio
vm.dirty_background_ratio THP
(Transparent Huge Pages)
HP (Páginas Enormes)

Antes de definir qualquer um desses parâmetros, você deve entender exatamente quais são esses parâmetros e o que
benefício você obteria ao defini-los. Como vem mais em “configuração”, abordaremos esses parâmetros no Capítulo 2.

Solução de problemas de instalação

Aqui estão algumas coisas que você deve observar para instalações, pois elas ajudam na solução de problemas:

Na instalação do código-fonte, a maioria dos problemas ocorre durante a compilação. Os problemas mais comuns são bibliotecas ausentes
como readline ou zlib. Você pode instalar manualmente essas bibliotecas e tentar recompilar.
Configure cria um log de compilação onde você pode ver problemas relacionados a bibliotecas e ferramentas ausentes.
Na instalação do RPM, você deve primeiro atualizar o repositório e depois tentar a instalação; caso contrário, talvez você não consiga
encontrar a versão que está tentando instalar.
Em uma instalação baseada no instalador da GUI, os arquivos de log serão criados em um local /tmp. Estes são instaladores bitrock,
portanto, você pode ver arquivos de log com bitrock_xx.log, por exemplo.
Machine Translated by Google

Resumo Neste
capítulo, falamos sobre os tipos de procedimentos de instalação do PostgreSQL e como trabalhar com eles. Também
abordamos quais informações você precisa do cliente para planejar a instalação e algumas recomendações gerais que você
deve seguir para configurar o melhor ambiente. Também abordamos as etapas de pré/pós instalação e alguns procedimentos
de solução de problemas. No próximo capítulo, falaremos sobre como configurar o postgres, pois as configurações padrão
vêm com ampla compatibilidade. Abordaremos quais áreas podem ser definidas para melhorar o desempenho do PostgreSQL.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_2

2. Configure seu banco de dados para melhor desempenho

Baji Shaik1
(1) Hyderabad, Andhra Pradesh, Índia

No capítulo anterior, falamos sobre as informações que precisam ser coletadas para a instalação do
PostgreSQL e como planejar a instalação com base nessas informações. Além disso, abordamos os tipos
de instalações do PostgreSQL, ajustes pré/pós-instalação, procedimentos de solução de problemas e
algumas recomendações gerais a serem consideradas durante a instalação para evitar problemas de
desempenho no futuro. Neste capítulo, abordaremos algumas etapas iniciais de pós-instalação para
iniciantes, todos os arquivos de configuração importantes e seus usos e suas configurações padrão,
recomendações para ajustar os arquivos de configuração e ajustes de parâmetros do SO para melhorar o desempenho.

Etapas iniciais após a instalação Vamos começar

com algumas etapas iniciais logo após a instalação. Essas etapas são diferenciadas entre desenvolvedores
e administradores do PostgreSQL.

Para desenvolvedores do PostgreSQL

Uma vez que o PostgreSQL é instalado pelos administradores, os desenvolvedores precisam de uma
ferramenta cliente para conectar o PostgreSQL e fazer seu trabalho de desenvolvimento. A ferramenta cliente
mais popular para o PostgreSQL é o pgAdmin. Esta ferramenta é da comunidade PostgreSQL. Você pode baixar
esta ferramenta em http://pgadmin.org.

Nota Existem muitas ferramentas cliente que você pode usar para o PostgreSQL. Todas as ferramentas
disponíveis estão em Clientes PostgreSQL (https://wiki.postgresql.org/wiki/PostgreSQL_Clients).

Depois de baixar e instalar o pgAdmin, a janela se parece com a Figura 2-1.

Machine Translated by Google

Figura 2-1 página inicial do pgAdmin

Agora você precisa adicionar seu banco de dados para se conectar. Se você clicar com o botão direito do mouse nos
servidores, poderá ver a opção Create Server, conforme mostrado na Figura 2-2.

Figura 2-2 Criar servidor

Insira um nome para o servidor que você deseja adicionar e detalhes e credenciais do banco de dados de acordo com a
instalação e configuração fornecidas pelo administrador na seção de conexão, conforme visto na Figura 2-3.
Machine Translated by Google

Figura 2-3 Fornecer detalhes do banco de dados

Depois de se conectar com os detalhes do banco de dados, você poderá ver os bancos de dados/objetos
incluindo algumas informações de monitoramento, como visto na Figura 2-4.

Figura 2-4 Status do banco de dados

Isso é um pouco básico e direcionado para iniciantes em PostgreSQL.

Machine Translated by Google

Para administradores
Após a instalação, os administradores podem configurar variáveis de ambiente para conectar o
banco de dados facilmente. Todas as variáveis de ambiente relacionadas ao PostgreSQL estão
descritas na documentação do PostgreSQL (www.postgresql.org/docs/11/libpq-envars.html).
Aqui estão algumas variáveis, por exemplo:

PGPORT=5432
PGUSER=postgres
PGPASSWORD=postgres
PGDATABASE=postgres
PGDATA=/Users/username/pg_software/9.6.9/data

Você pode exportá-los para o seu bash_profile, incluindo o local binário do PostgreSQL.
Os administradores usam o cliente psql para conectar o banco de dados. O cliente Psql pode ler um arquivo
chamado “.psqlrc” automaticamente. Assim, os administradores podem configurar algumas consultas de monitoramento
nesse arquivo para ver as informações assim que se conectarem. Este arquivo deve ser colocado no diretório home do
usuário do PostgreSQL. Aqui está um exemplo de saída que você vê se configurar o arquivo “.psqlrc”.

$ cat .psqlrc
\set QUIET ON
'
\set PROMPT1 '%[%033[1;32;40m%]%M:%>; %n@%/%[%033[0m%]% # \set
PAGER OFF \set HISTSIZE 2000 \set ECHO_HIDDEN ON \set
COMP_KEYWORD_CASE superior

\timing
\encoding unicode

\pset null 'NULL' \pset

border 2

\set QUIET OFF

\echo '\nData e hora do servidor host atual: '`date` '\n'

\echo 'Consultas administrativas:\n' \echo

'\t\t\t:configurações\t-- Configurações do servidor' \echo
'\t\t\t:conninfo\t-- Conexões do servidor' \echo '\t \t\t:activity\t--
Atividade do servidor' \echo '\t\t\t:locks\t\t-- Lock info' \echo
'\t\t\t:waits\t\t-- Aguardando consultas' \echo '\t\t\t:uptime\t\t--
Server uptime' \echo '\t\t\t:menu\t\t-- Help Menu' \echo '\t\t \t\
\h\t\t-- Ajuda com comandos SQL'
Machine Translated by Google

\echo '\t\t\t\\?\t\t-- Ajuda com comandos do psql\n'

\echo 'Consultas de desenvolvimento:\n'

\echo '\t\t\t:sp\t\t-- Caminho de pesquisa atual' \echo
'\t\t\t:clear\t\t-- Limpar tela' \echo '\t\t\t:ll\t\t-- Lista\n'

-- Consultas de administração

\set menu '\\i ~/.psqlrc'

\set settings 'selecione nome, configuração, unidade, contexto de

pg_settings;'

\set locks 'SELECT bl.pid AS Blocked_pid, a.usename AS Blocked_user,

kl.pid AS Blocking_pid, ka.usename AS Blocking_user, a.query AS
Blocked_statement FROM pg_catalog.pg_locks bl JOIN
pg_catalog.pg_stat_activity a ON bl.pid = a .pid JOIN pg_catalog.pg_locks kl JOIN
pg_catalog.pg_stat_activity ka ON kl.pid = ka.pid ON bl.transactionid =
kl.transactionid AND bl.pid != kl.pid WHERE NOT bl.granted;'

\set conninfo 'selecione nome de uso, contagem(*) do grupo pg_stat_activity por

nome de uso;'

\set activity 'select datname, pid, usename, application_name,

client_addr, client_hostname, client_port, query, state from pg_stat_activity;'

\set espera 'SELECT nome de dados, nome de uso, wait_event_type,

wait_event, pg_blocking_pids(pid) AS blocking_by, query FROM pg_stat_activity
WHERE wait_event IS NOT NULL;'

\set uptime 'select now() - pg_postmaster_start_time() AS uptime;'

-- Consultas de desenvolvimento:

\set sp 'MOSTRAR caminho_pesquisa;'

\set clear '\\! Claro;' \set ll '\\! ls -lrt;'

Você pode ver as informações mostradas na Figura 2-5 quando se conecta ao psql com o
arquivo “.psqlrc” anterior.
Machine Translated by Google

Figura 2-5 informações do psqlrc

Arquivos de configuração e recomendações Vamos falar

brevemente sobre os arquivos de configuração do PostgreSQL. Existem três
arquivos de configuração de cluster que devemos conhecer ao trabalhar com o PostgreSQL.
Esses são os postgresql. conf, pg_ hba. conf, e pg_ident. conf arquivos.

postgresql.conf
Este é o principal arquivo de configuração do PostgreSQL. Todas as configurações relacionadas
ao comportamento do PostgreSQL com relação à auditoria, autenticação, log, desempenho, etc. são
definidas por meio deste arquivo de configuração. A localização padrão deste arquivo está na
localização $PGDATA (diretório de dados); porém, pode ser customizado através do parâmetro
“config_file”. Para saber a localização do seu arquivo de configuração, basta digitar “show config_file;”
no terminal psql.

[local]:5411; postgres@postgres # mostra arquivo_config;

+------------------------------------------------- -----------+
| arquivo_config |
+------------------------------------------------- -----------+
| /Users/shbaji/pg_software/10.2/bin/../data/postgresql.conf |
+------------------------------------------------- -----------+
(1 linha)

Tempo: 1,721ms
Machine Translated by Google

Nota Uma configuração de parâmetro em postgres.conf pode ser substituída pela próxima configuração.
Portanto, se você tiver uma configuração duplicada de um parâmetro no arquivo, o inferior sempre estará
em vigor.

Dependendo do parâmetro, você precisaria recarregar ou reiniciar o banco de dados de acordo.

Você encontrará qual parâmetro precisa ser recarregado e qual precisa ser reiniciado usando a seguinte
consulta:

SELECT nome, contexto FROM pg_settings WHERE nome = '<parameter_value>';

Se o valor de context for “postmaster” ele precisa reiniciar o banco de dados. Para todos os outros valores,
é apenas um recarregamento.

pg_hba.conf
A autenticação do cliente será controlada por este arquivo. Você pode controlar de qual servidor
deseja conexões com o banco de dados e de que maneira. A localização padrão deste arquivo
é o diretório $PGDATA; no entanto, isso pode ser alterado usando o parâmetro “hba_file” no
arquivo postgresql.conf.

[local]:5411; postgres@postgres # show hba_file ;

+------------------------------------------------- -------+
| hba_file |
+------------------------------------------------- -------+
| /Users/shbaji/pg_software/10.2/bin/../data/pg_hba.conf |
+------------------------------------------------- -------+
(1 linha)

Tempo: 3,434ms

Observação Este arquivo é lido de cima para baixo para a primeira correspondência da regra. Se
você tiver linhas semelhantes com métodos de autenticação diferentes ou intervalos de IP diferentes, a
primeira será escolhida.

A alteração deste arquivo requer um recarregamento do banco de dados.

Os registros neste arquivo podem ter um destes sete formatos:

usuário do banco de dados local auth-method [auth-options] endereço do usuário do

banco de dados host auth-method
dados [auth-options]
hostssl método endereço endereço
auth [auth-options] do usuáriododousuário
banco do
de banco de dados
hostnossl método auth [auth-options] usuário do banco de dados host Método de autenticação de
máscara de IP de endereço IP [auth-options]
Machine Translated by Google

hostssl banco de dados usuário endereço IP máscara IP método de autenticação [auth-options]

hostnossl database user endereço IP máscara IP método de autenticação [auth-options]

Informações detalhadas sobre este arquivo estão disponíveis na documentação do PostgreSQL:

www.postgresql.org/docs/current/auth-pg-hba-conf.html.

pg_ident.conf
O PostgreSQL fornece autenticação baseada em ident. Funciona obtendo a informação do cliente
nome de usuário do sistema operacional e usá-lo como o nome de usuário do banco de dados permitido com um opcional
mapeamento de nome de usuário. Quando usamos um sistema de autenticação externo, o nome de usuário do sistema
pode não ser o mesmo nome de usuário do banco de dados. Para permitir a autenticação externa, devemos
mapear o nome de usuário do sistema com o nome de usuário do banco de dados e também podemos definir um nome de mapa para
ocultar o nome de usuário do sistema e os detalhes relacionados ao nome de usuário do banco de dados. A localização padrão de
este arquivo no diretório $PGDATA e pode ser alterado usando o “ident_file”
parâmetro no arquivo postgresql.conf.
Se você abrir seu arquivo pg_ident.conf, você encontrará a seguinte linha na parte inferior do
Arquivo:

# MAPNAME SYSTEM-USERNAME PG-NOME DE USUÁRIO

Você pode adicionar valor para mapear o nome de usuário do sistema e o nome de usuário do banco de dados:

# MAPNAME SYSTEM-USERNAME PG-NOME DE USUÁRIO

Usuário 123 Usuário Linux PGUser

Depois de mapear o usuário do sistema e o usuário do banco de dados no arquivo pg_ident.conf, você pode usar
o nome do mapa no arquivo pg_hba.conf para permitir autenticação externa.
Vá para o diretório de dados do PostgreSQL e abra um arquivo pg_hba.conf. Você pode adicionar o
nome do mapa do usuário do sistema e do usuário do banco de dados na coluna MÉTODO. Por exemplo :

# TYPE DATABASE host all USUÁRIO ENDEREÇO MÉTODO

map=User123 todos 127.0.0.0/16 identificação

Recomendações de parâmetros
O PostgreSQL vem com uma configuração básica ajustada para ampla compatibilidade em vez de
atuação. Embora as configurações padrão do PostgreSQL que acompanham a instalação
são viáveis, é sempre recomendável ajustar alguns parâmetros básicos de acordo com sua
ambiente e comportamento do aplicativo.
Antes de alterar qualquer configuração no arquivo postgresql.conf, você deve conhecer os tipos de
configurações e quando elas entram em vigor.

Os tipos de configurações
Machine Translated by Google

Existem vários tipos diferentes de definições de configuração, divididas com base nas entradas possíveis que podem receber:

Boolean: true, false, on, off Inteiro:

números inteiros (2112)
Flutuante: valores decimais (21,12)
Memória / Disco: Inteiros (2112) ou “unidades de computador” (512 MB, 2112 GB). Evite números inteiros — você precisa
conhecer a unidade subjacente para descobrir o que eles significam.
Tempo: Unidades de tempo, também conhecidas como d, m, s (por exemplo, 30 s). Às vezes, a unidade é deixada de fora; não faça isso.

Strings: texto entre aspas simples ('pg_log')

ENUMs: Strings, mas de uma lista específica ('WARNING', 'ERROR')
Listas: Uma lista de strings separadas por vírgulas (“$user”,public,tsearch2)

Quando entram em vigor As

configurações do PostgreSQL têm diferentes níveis de flexibilidade para quando podem ser alteradas, geralmente
relacionadas a restrições internas de código. A lista completa de níveis é:

Postmaster: Requer reinicialização do servidor

SIGHUP: Requer um HUP do servidor, seja por kill -HUP (geralmente -1), pg_ctl reload ou SELECT pg_reload_conf();

Usuário: Pode ser definido em sessões individuais; entra em vigor apenas nessa sessão
Interno: Definido em tempo de compilação e não pode ser alterado; principalmente para referência
Backend: configurações que devem ser definidas antes do início da sessão
Superusuário: pode ser definido em tempo de execução para o servidor por superusuários

Ferramentas de ajuste

Ao invés de você analisar seu banco de dados manualmente, existem algumas ferramentas disponíveis no mercado que
fazem isso por você:

postgresqltuner (https://github.com/jfcoz/postgresqltuner) pgBadger (https://github.com/darold/pgbadger)

PGTune (https://pgtune.leopard.in.ua/#/)

Ferramenta de configuração do PostgreSQL (www.pgconfig.org/#/tuning)

Você pode analisar seu banco de dados usando as ferramentas listadas e elas podem fornecer alguns conselhos de
ajuste.

Parâmetros de revisão Não

vamos cobrir todos os parâmetros aqui; no entanto, há alguns parâmetros que você deve considerar ao configurar um ambiente
pela primeira vez. Vamos dividir os parâmetros em seções como:

Conexões relacionadas

Relacionado à memória
Planejador/Custo relacionado
Relacionado a WAL
Machine Translated by Google

Relacionado ao vácuo automático

Registro relacionado
Replicação relacionada

Vamos examinar cada seção e ver quais parâmetros podem ser alterados.

Relacionados a
Conexões Toda a documentação para parâmetros relacionados a conexão ou autenticação
está aqui: www.postgresql.org/docs/current/runtime-config connection.html.

listen_addresses
Por padrão, o PostgreSQL escuta apenas na interface de loopback para que ele responda às
conexões do host local. Se você deseja que seu servidor seja acessível de outros sistemas via rede TCP/
IP padrão, você precisa alterar listen_addresses de seu padrão. A abordagem usual é configurá-lo para
escutar em todas as interfaces de rede no servidor por uma configuração como esta:

'*'
listen_addresses =

E então controle quem pode e quem não pode se conectar através do arquivo pg_hba.conf.

max_connections
A configuração max_connections refere-se ao número máximo de conexões de cliente permitidas.
Antes de definir esse parâmetro, você deve perguntar ao seu cliente quantas conexões
simultâneas seu aplicativo solicita no ponto de pico.
Se o sistema que está sendo revisado usar um pool de conexões, provavelmente haverá um limite
predefinido para o número de conexões necessárias ao banco de dados. Portanto, max_connections não
deve ser muito maior que esse limite, mas você ainda precisará levar em consideração todas as conexões
de superusuário (definidas por superuser_reserved_connections) e quaisquer conexões não agrupadas
(como aquelas provenientes de sistemas de relatórios ou tarefas agendadas).
Você deve ter cuidado antes de aumentar este parâmetro, pois aumentar também precisa de
alguma configuração de memória, e isso é explicado na seção “Antes da instalação” do Capítulo 1.
Geralmente, o PostgreSQL em um bom hardware pode suportar algumas centenas de conexões. Se
você quiser ter milhares em vez disso, considere usar um software de pool de conexões para reduzir a
seção de sobrecarga de conexão do Capítulo 7.
, que discutiremos no "Implementação do Pooler"

Relacionados à
Memória Você pode ver todos os parâmetros
relacionados à memória em: www.postgresql.org/docs/current/runtime-config-resource.html.
Vamos discutir alguns parâmetros para recomendações aqui.

shared_buffers
No Linux, há uma regra geral que é usada para determinar um valor decente para shared_buffers.
É recomendado que seja configurado para um tamanho de 15% a 25% da RAM total.
No entanto, há um ponto em que a quantidade de memória compartilhada usada para armazenar páginas em buffer
Machine Translated by Google

deixa de produzir benefícios visíveis. Nas versões do PostgreSQL anteriores a 8.4, o valor máximo deve
ser de 2,5 GB, caso contrário, o máximo deve ser dependente e deve ser decidido após o benchmark.
Observe que ao usar o PostgreSQL 9.2 ou anterior, os parâmetros do kernel podem exigir ajustes para
acomodar quaisquer alterações neste parâmetro em versões posteriores.

No Windows, o conselho geral é limitar os shared_buffers a 512 MB. Isso é baseado em

benchmarks que a comunidade PostgreSQL realizou nele no passado. Aumentar além desse
tamanho não foi confirmado como útil.

Effective_cache_size
O parâmetro Effective_cache_size deve ser definido para uma estimativa de quanta memória está
disponível para cache de disco pelo sistema operacional (cache de página) e dentro do próprio banco
de dados, depois de considerar o que é usado pelo próprio SO e outros aplicativos. Esta é uma diretriz
para o planejador de SQL dizendo quanta memória ele deve esperar estar disponível nos caches de buffer
do sistema operacional e do PostgreSQL, mas não uma alocação. Esse valor é usado apenas pelo
planejador de consultas do PostgreSQL para descobrir se os planos que ele está considerando devem
caber na RAM ou não. Se estiver definido muito baixo, os índices não poderão ser usados para executar
consultas da maneira esperada. A configuração para shared_buffers não é considerada aqui - apenas o
valor Effective_cache_size é, portanto, deve incluir memória dedicada ao banco de dados também.
Esse parâmetro pode ser definido com segurança para um valor grande sem nenhum risco de ficar sem
memória, pois é usado apenas para planejamento de consultas. Na maioria dos casos, isso deve ser 75% da RAM.

work_mem
Este parâmetro é útil quando as instruções SQL usam muitas classificações complexas. Isso permite
que o PostgreSQL faça operações na memória, reduzindo o tempo de execução.
Aumentar work_mem pode levar a muito menos troca de disco e, portanto, consultas muito mais
rápidas. No entanto, pode causar problemas se definido muito alto e deve ser restringido levando em
consideração max_connections. O cálculo a seguir é o que normalmente é recomendado para determinar
um valor work_mem decente:

RAM total *
0,25 / max_connections

Se houver grandes consultas de relatórios executadas no banco de dados que exijam mais memória de
trabalho do que uma conexão típica, work_mem pode ser definido para essas consultas específicas. Se, por
exemplo, houver um usuário de relatório que executa apenas relatórios esporádicos, mas grandes, uma configuração
work_mem específica pode ser aplicada a esse usuário/função específico.
Por exemplo:

ALTER ROLE reportando SET work_mem = '64MB';

Maintenance_work_mem
Especifica a quantidade máxima de memória a ser usada pelas operações de manutenção, como VACUUM,
CREATE INDEX e ALTER TABLE ADD FOREIGN KEY. É importante que Maintenance_work_mem receba
memória suficiente para que os processos VACUUM possam concluir seu trabalho mais rapidamente
trabalhando em lotes maiores. Normalmente recomendamos 1/20 de RAM (ou RAM total ÿ 0,05). Observe
que isso deve ser equilibrado com o
Machine Translated by Google

número de autovacuum_max_workers, conforme cada trabalhador de autovacuum aloca

Maintenance_work_mem tamanho da memória. Caso contrário, se em um sistema de 64 GB você tivesse:

Maintenance_work_mem = 3GB
autovacuum_max_workers = 20

Isso provavelmente esgotaria a memória disponível (3 GB ÿ 20 = 60 GB), supondo que o

o cluster de banco de dados era grande o suficiente para que os processos de autovacuum fizessem uso de toda a memória.
Então, isso deve ser equilibrado:

Maintenance_work_mem = 400 MB
autovacuum_max_workers = 20

Resultando em 8 GB (400 MB ÿ 20) sendo usados , o que seria muito mais razoável
em um sistema de 64 GB. Para fatorar isso em seu cálculo, você pode usar algo como
a seguir:
RAM total ÿ 0,15 / autovacuum_max_workers
Vale a pena notar que outros processos ainda podem solicitar Maintenance_work_mem para construir
índices e na configuração de chaves estrangeiras, portanto, é necessário haver algum espaço adicional.

Planejador/ Custo Relacionado

Todos os parâmetros relacionados ao planejador de consultas estão aqui:

www.postgresql.org/docs/current/runtime-config-query.html.
Você pode definir alguns parâmetros como dicas para o planejador de consultas para que ele mude de plano
adequadamente. Portanto, todos os parâmetros que começam com “enable_” referem-se a dicas.

[local]:5411; postgres@postgres # seleciona o nome, configurando de

pg_settings onde nome como 'enable_%';
+------------------+---------+
| nome | configuração |
+------------------+---------+
| enable_bitmapscan | em | |
enable_gathermerge | em | |
enable_hashagg | em | enable_hashjoin
| em |
| enable_indexonlyscan | em | |
enable_indexscan | em | habilitar_material |
| em | enable_mergejoin | em | |
enable_nestloop | em | enable_seqscan
| em |
| enable_sort | em | enable_tidscan sobre
| |
|
|
|
|
+------------------+---------+
(12 linhas)
Machine Translated by Google

seq_page_cost
Isso representa o custo estimado de uma busca de disco como parte da varredura sequencial. O otimizador
escolhe um plano dependendo dos parâmetros relacionados ao custo. Portanto, este é um dos parâmetros que
você deve considerar para o ajuste. Você deve ter cuidado ao modificar o valor deste parâmetro, pois o
planejador escolhe planos diferentes às vezes dependendo do valor.
É recomendável ajustar esse parâmetro se você estiver usando SSD para armazenamento.

random_page_cost
Essa configuração sugere ao otimizador quanto tempo levará para seus discos buscarem uma página de disco
aleatória, como um múltiplo de quanto tempo demora uma leitura sequencial (com um custo de 1,0). Se você tiver
discos particularmente rápidos, como comumente encontrados em matrizes RAID de discos SCSI, pode ser
apropriado reduzir random_page_cost, o que incentivará o otimizador de consulta a usar varreduras de índice de
acesso aleatório. Alguns acham que o 4.0 é sempre muito grande no hardware atual; não é incomum que os
administradores padronizem sempre a configuração entre 2.0 e 3.0. Em alguns casos, esse comportamento é um
resquício das versões anteriores do PostgreSQL, onde ter random_page_cost muito alto era mais provável de
estragar a otimização do plano do que agora (e a configuração igual ou inferior a 2.0 era regularmente necessária).
Como essas estimativas de custo são apenas isso — estimativas — não custa tentar valores mais baixos.

Mas não é aqui que você deve começar a procurar problemas de plano. Observe que
random_page_cost está bem abaixo nesta lista (na verdade, no final). Se você está recebendo planos ruins,
essa não deve ser a primeira coisa que você deve observar, embora a redução desse valor possa ser eficaz.
Em vez disso, você deve começar certificando-se de que o autovacuum está funcionando corretamente, que
você está coletando estatísticas suficientes e que dimensionou corretamente os parâmetros de memória para o
seu servidor – todas as coisas que acabaram de ser revisadas. Depois de ter feito todas essas coisas muito mais
importantes, se você ainda está recebendo planos ruins, então você deve ver se reduzir random_page_cost
ainda é útil.

cpu_tuple_cost
Este é o custo de processamento de cada linha. O padrão é 0,01, mas os benefícios de desempenho
anteriores foram vistos configurando-o como 0,03, o que pode resultar em melhores planos de consulta. Isso é
particularmente relevante para sistemas em que o(s) banco(s) de dados cabe(m) na memória e a utilização da
CPU é alta

A documentação
relacionada ao WAL para todos os parâmetros relacionados ao WAL está
disponível aqui: www.postgresql.org/docs/current/runtime-config-wal.html.

wal_buffers A
partir da versão 9.1 do PostgreSQL, o padrão para isso é definido como -1, que o define automaticamente como
1/32 dos shared_buffers limitados a 16 MB. Isso provavelmente é bom, mas houve benefícios de desempenho
observados ao configurar isso para 32 MB, embora não superior. É recomendado que não seja inferior a 16 MB,
pois é uma quantidade trivial de memória compartilhada para reservar em relação a shared_buffers.

wal_level
Machine Translated by Google

Como sempre recomendamos que o cliente use a recuperação pontual, sugerimos que wal_level seja definido como
pelo menos “archive”. Isso precisará ser definido como “hot_standby” ou “replica” para usar a replicação de streaming.

bgwriter_delay O
padrão para esta configuração é 200ms. Isso deve ser definido como não inferior a 10 ms, mas em sistemas com
um alto volume de gravações, é uma boa ideia diminuir isso do valor padrão para pelo menos 100 ms.

bgwriter_lru_maxpages Essa
configuração é definida para um valor muito conservador de 100 por padrão, o que significa que apenas 100 buffers
são gravados em cada rodada. Isso tende a ser definido como 1000 para garantir que o processo de gravação em
segundo plano possa gravar uma quantidade considerável de buffers em cada rodada .

bgwriter_lru_multiplier Isso é
definido como um padrão de 2, mas em sistemas com uma carga de gravação pesada, pode ser benéfico aumentar
para 3 ou 4.

synchronous_commit Isso
é ativado por padrão, mas se um cliente estiver disposto a arriscar as alterações mais recentes para melhorar a
taxa de transferência de gravação, isso poderá ser desativado. Esta é uma alternativa mais segura para desabilitar o fsync.
Na verdade, isso pode ser definido no nível do banco de dados, para que possa ser desabilitado em bancos de dados
em que o risco de perder alguns dados em uma falha não é grande coisa, mas o desempenho é. Ele também pode ser
desabilitado para funções específicas (como aquelas que executam atividades de carregamento em massa) ou em
sessões individuais se essa função dedicada não existir.

fsync
Isso quase sempre deve estar habilitado, porque se o sistema travar sem que ocorram fsyncs, o cluster
provavelmente será corrompido. Alguns clientes alegarão que o cache com bateria de seu sistema de armazenamento
resolverá quaisquer problemas de liberação de alterações no disco. Embora muitos dispositivos de armazenamento
afirmem isso, não pode ser toda a verdade. Se o cliente estiver determinado a manter essa configuração desativada,
pode valer a pena sugerir que, em vez disso, defina synchronous_commit como “off”, pois isso trará um benefício de
desempenho sem o risco de corrupção, mas trará o risco de perder alguns dos mais dados recentes
.

Effective_io_concurrency Se o
sistema de armazenamento principal do cluster de banco de dados tiver vários eixos, defina
Effective_io_concurrency para corresponder ao número de eixos, mas não inclua nenhuma unidade de paridade.
Isso pode melhorar as varreduras de índice de bitmap lendo antecipadamente quando vários índices são usados.

Por exemplo, se eles estiverem usando quatro discos em RAID 10 (distribuído e espelhado),
Effective_io_concurrency deve ser 4. Para SSDs e armazenamentos com suporte de memória, esse valor pode ser
de centenas.

checkpoint_segments
Machine Translated by Google

Este parâmetro existe na versão < PostgreSQL 9.5. O padrão de 3 é sempre muito baixo.
Normalmente, isso deve ser definido entre 16 e 64 ou 256; quanto mais ocupadas forem as gravações no sistema, maior
deve ser esse número. Se definido muito alto, pode afetar o impacto dos pontos de verificação e aumentar os tempos de
recuperação em um valor excessivo.

checkpoint_timeout
Quanto mais checkpoint_segments houver, mais tempo será necessário para completar um checkpoint, então isso
deve estar em algum lugar no intervalo de 5 min a 15 min. Observe que aumentar esse tempo limite aumentaria o tempo
de recuperação.

checkpoint_completion_target Esse
padrão de 0,5 significa que os pontos de verificação terão como objetivo concluir na metade do tempo definido por
checkpoint_timeout. Para reduzir o impacto de E/S dos pontos de verificação, isso deve espalhar o ponto de verificação
para mais próximo do tempo limite, portanto, um valor de 0,8 ou 0,9 é normalmente recomendado.

checkpoint_warning Isso
precisa ser alterado para considerar o tempo esperado para a conclusão de um ponto de verificação.

Relacionados ao

Autovacuum Todos os parâmetros relacionados ao

autovacuum estão aqui: www.postgresql.org/docs/current/runtime-config autovacuum.html.

vácuo automático

Isso quase sempre deve ser definido como "ligado", caso contrário, não ocorrerá autovacuuming no banco de dados
e certamente será necessário aplicar vácuos manuais de rotina.

autovacuum_max_workers O padrão
de 3 tende a ser muito baixo para qualquer coisa, exceto para pequenos sistemas de banco de dados. Isso
provavelmente deve ser definido para algo dentro do intervalo de 6 a 12, inclinando-se mais para o último se houver muitas
tabelas com atualizações ou exclusões frequentes.

autovacuum_naptime O
padrão de 1 min pode ser suficiente para alguns sistemas, mas em sistemas mais ocupados com muitas gravações,
pode ser benéfico aumentá-lo para impedir que o autovacuum acorde com muita frequência.
Além disso, em sistemas com muitos bancos de dados, isso deve ser aumentado porque essa configuração
determina o tempo de ativação por banco de dados. Um processo de trabalho de autovacuum começará com a
mesma frequência que autovacuum_naptime / número de bancos de dados.
Por exemplo, se autovacuum_naptime = 1 min (60 segundos) e houvesse 60 bancos de dados, um
processo de trabalho de autovacuum seria iniciado a cada segundo (60 segundos / 60 bancos de dados = 1 segundo).

No entanto, ajustar essa configuração muito alta pode resultar em mais trabalho necessário a ser feito em cada rodada
de aspiração.

autovacuum_vacuum_threshold / autovacuum_analyze_threshold
Machine Translated by Google

Ambos determinam o número mínimo de linhas em uma tabela que precisam ser alteradas para que a
tabela seja agendada para um autovacuum e uma autoanálise, respectivamente. O padrão para ambos é
50, que é muito baixo para a maioria das tabelas.

autovacuum_vacuum_scale_factor / autovacuum_analyze_scale_factor Ambos

determinam a porcentagem de uma tabela que precisa ser alterada para que a tabela seja agendada
para um autovacuum e uma autoanálise, respectivamente. O padrão para o autovacuum_vacuum_scale_factor
é 0,2 (significando 20%) e autovacuum_analyze_scale_factor é 0,1 (significando 10%). Ambos os
números são bons para tabelas de tamanho modesto (até cerca de 500 MB), mas para tabelas maiores
eles são muito altos. Se, por exemplo, houvesse uma tabela com 120 GB de tamanho, 24 GB (20% de 120
GB) de tuplas mortas teriam que existir antes que elas pudessem começar a ser limpas, o que seria muito
trabalho de aspiração depois de entrar em ação No entanto, se as tabelas grandes estiverem em minoria
no banco de dados, é melhor definir esses parâmetros no nível da tabela e não no arquivo de configuração.

autovacuum_vacuum_cost_delay O
padrão é 20 ms, o que é muito conservador e pode impedir que o VACUUM acompanhe as alterações. Isso
quase sempre deve ser reduzido e, em muitos casos, até 2 ms. Ele pode precisar ser testado com várias
configurações para ver o que é necessário para acompanhar.

Relacionado ao
registro Todos os parâmetros relacionados ao
registro estão aqui: www.postgresql.org/docs/current/runtime-config-logging.html.
Abordaremos muito sobre o registro no Capítulo 5.

Relacionados à
replicação Todos os parâmetros relacionados à
replicação estão aqui: www.postgresql.org/docs/current/runtime-config
replication.html.

max_wal_senders
Deve ser sempre maior que o número de réplicas. Se os dados forem replicados para vários sites, vários
max_wal_senders entrarão em ação. Portanto, é importante garantir que esse parâmetro seja definido com
um número ideal.

max_replication_slots
Em geral, todas as alterações de dados que ocorrem nas tabelas são gravadas em arquivos WAL em
pg_xlog / pg_wal, que são conhecidos como registros WAL. O processo do remetente wal pegaria esses
registros WAL (pertencentes às tabelas que estão sendo replicadas) e enviaria para as réplicas, e o
processo wal_receiver no site da réplica aplicaria essas alterações no nó do assinante.

Os arquivos WAL são removidos do local pg_xlog/pg_wal sempre que ocorre um ponto de verificação.
Se os arquivos WAL forem removidos antes mesmo que as alterações sejam aplicadas ao nó do assinante,
a replicação será interrompida e ficará para trás. Caso o nó do assinante fique para trás, um slot de
replicação garantiria que todos os arquivos WAL necessários para o assinante entrarem em sincronia com
Machine Translated by Google

o provedor são mantidos. Recomenda-se configurar um slot de replicação para cada nó do assinante.

max_worker_processes É
importante ter um número ideal de processadores de trabalho configurados. Isso depende do número máximo de
processos que um servidor pode ter. Isso só é possível em ambientes com várias CPUs. Max_worker_processes garantirá
que vários processos sejam gerados para realizar o trabalho de maneira mais rápida, utilizando vários núcleos de CPU.
Ao replicar dados usando a replicação lógica, esse parâmetro pode ajudar a gerar vários processos de trabalho para
replicar os dados mais rapidamente. Existe um parâmetro específico chamado max_logical_worker_processes que
garantirá que vários processos sejam usados para copiar os dados.

max_logical_worker_processes Esse
parâmetro especifica o número máximo de processos de trabalho lógicos necessários para executar a replicação
e sincronização de dados de tabela. Este valor é obtido de max_worker_processes, que deve ser maior que este
valor de parâmetro. Esse parâmetro é muito benéfico ao replicar dados para vários sites em ambientes com várias
CPUs. O padrão é 4. O valor máximo depende de quantos processos de trabalho o sistema suporta.

max_sync_workers_per_subscription Este
parâmetro especifica o número máximo de processos de sincronização necessários por assinatura. O processo de
sincronização ocorre durante a sincronização inicial de dados e esse parâmetro pode ser usado para garantir que isso
aconteça mais rapidamente. Atualmente, apenas um processo de sincronização pode ser configurado por tabela, o
que significa que várias tabelas podem ser sincronizadas inicialmente em paralelo. O valor padrão é 2. Esse valor é
selecionado do valor max_logical_worker_processes
.

Recomendações do SO
Conforme mencionado na seção “Após a instalação” no Capítulo 1, aqui estão os parâmetros que você pode ajustar
no sistema operacional Linux onde o PostgreSQL está sendo executado:

overcommit_memory
overcommit_ratio
vm.dirty_ratio
vm.dirty_background_ratio THP
(Transparent Huge Pages)
HP (Páginas Enormes)

Antes de irmos para o ajuste, vejamos algumas definições:

Memória Virtual : A soma de toda a RAM e SWAP em um determinado sistema. Ao falar sobre memória no contexto
desta seção, estamos nos referindo à memória virtual.
Overcommit : Alocando mais memória do que disponível Memória Virtual Allocate : No
contexto de gerenciamento de memória, uma alocação de memória pode ser considerada uma “promessa”
de que a memória está disponível. A memória realmente física é
Machine Translated by Google

não atribuído até que seja realmente necessário. Essa atribuição é feita em um nível de página. Quando uma
nova página (normalmente 8 KB) é necessária, o sistema aciona uma falha de página.

Por que permitir overcommits?

A implementação da memória virtual do Linux usa várias táticas para otimizar a quantidade de memória usada
(uma dessas estratégias é chamada de “Copy on Write” e é usada ao bifurcar processos filhos). O resultado disso
é que muitas vezes menos memória é realmente usada do que é relatado pelo sistema de arquivos /proc (e pela
extensão ps).
Nesse caso, pequenos overcommits são aceitáveis, pois normalmente há memória suficiente
disponível para atender a isso. No entanto, essa abordagem pode resultar na alocação de memória quando, na
verdade, não há espaço suficiente disponível.
Para lidar com esse caso, o Linux suporta várias estratégias de overcommit diferentes especificadas por um
valor inteiro para a configuração vm.overcommit.

Estratégia Overcommit 0 Esta é

a estratégia padrão que o Linux usa. Nesse caso, toda a memória virtual está disponível para o sistema
para alocações e todas as alocações são concedidas, a menos que pareçam exigir uma superalocação
significativa.
Se, quando ocorrer uma falha de página, não houver memória suficiente disponível (ou seja, temos um
overcommit), o sistema acionará um “Out of Memory Killer” (OOM Killer). O OOM Killer selecionará um processo
atualmente em execução no sistema e encerrará esse processo. Ele usa um conjunto de heurísticas para
selecionar o processo a ser finalizado. Observe que geralmente não é possível prever quando esse processo será
necessário, nem quais processos serão selecionados para encerramento.

Estratégia Overcommit 1 Essa

estratégia é normalmente reservada para sistemas que executam processos que alocarão arrays muito grandes
que são pouco preenchidos. Nesse modo, qualquer alocação será bem-sucedida. No caso de um overcommit ser
detectado, o processo que detecta o overcommit gerará um erro de memória e falhará catastroficamente (sem
limpeza; o processo simplesmente para).
Observe que, como a memória não é atribuída até que seja necessária, um processo que falha não é
necessariamente aquele que alocou mais memória. Devido à natureza do uso de memória, não é possível prever
qual processo falhará devido a superalocações de memória.

Estratégia Overcommit 2 Com

este modo, o Linux executa uma contabilidade de memória estrita e só concederá uma alocação se a memória
necessária estiver realmente disponível. Como essa verificação é feita no momento da alocação, o programa que
solicita a memória pode lidar com a falha normalmente (no caso do GPDB gerar um erro de “Sem Memória”) e
limpar a sessão que encontrou o erro.

Essa estratégia também alocará uma parte da RAM física estritamente para uso do kernel.
A quantidade restrita é configurada pela configuração vm.overcommit_ratio. Isso significa que a quantidade de
memória virtual (sobre a memória confirmável) disponível para programas é, na verdade:

SWAP + (RAM ÿ (sobrecommit_ratio/100))

Machine Translated by Google

A memória reservada é usada para coisas como buffers de E/S e chamadas de sistema.
Vejamos alguns números:

Cenário 1:
4 GB de RAM, 4 GB de troca, overcommit_memory = 2, overcommit_ratio = 50
Limite de alocação de memória = 4 GB de espaço de troca + 4 GB de RAM ÿ (50% de taxa de overcommit /
100)
Limite de alocação de memória = 6 GB
Cenário 2:
4 GB RAM, 8 GB Swap, overcommit_memory = 2, overcommit_ratio = 50
Limite de alocação de memória = 8 GB de espaço de troca + 4 GB de RAM ÿ (50% de taxa de superalocação /
100)
Limite de alocação de memória = 10 GB
Cenário 3:
4 GB RAM, 2 GB Swap, overcommit_memory = 2, overcommit_ratio = 50
Limite de alocação de memória = 2 GB de espaço de troca + 4 GB de RAM ÿ (50% de taxa de overcommit /
100)
Limite de alocação de memória = 4 GB

Observe que esta é a quantidade total de memória que o Linux alocará. Isso inclui todos os daemons
em execução e outros aplicativos. Não assuma que seu aplicativo será capaz de alocar o limite total. O Linux
também fornecerá o limite de alocação de memória no campo CommitLimit em /proc/meminfo.

vm.dirty_ratio Isso
determina o número de páginas, como uma porcentagem da memória total do sistema, após o qual o daemon
de write-back em segundo plano do pdflush começará a gravar dados sujos. O padrão é 20.
É recomendado que isso seja reduzido para 2 para tornar as descargas mais frequentes, mas resultar em
menos picos de E/S.

vm.dirty_background_ratio Isso
determina o número de páginas, como uma porcentagem da memória disponível (incluindo cache), que
o daemon de write-back em segundo plano do pdflush começará a gravar dados sujos.
O padrão é 10. É recomendado que seja reduzido para 1 para tornar as descargas mais frequentes, mas
resultar em menos IO.

THP
É sempre recomendado desabilitar o THP em um sistema Linux para melhor desempenho do PostgreSQL.
Para desativá-lo: Kernels do Red Hat Enterprise Linux:

# cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

Outros núcleos:

# cat /sys/kernel/mm/transparent_hugepage/enabled
Machine Translated by Google

A seguir está um exemplo de saída que mostra que o THP está sendo usado quando o sinalizador [sempre] está ativado:

[sempre] nunca

Hugepages A
memória virtual é mapeada para a memória física usando uma combinação de mecanismos de software e hardware.
Esse recurso de memória virtual permite que o SO espalhe o espaço endereçável em diferentes áreas da RAM física.

Mas, esse conceito de VM requer tradução de endereço virtual para endereço físico.
As informações para essa transformação são armazenadas em “tabelas de páginas”. Para acelerar a
pesquisa/traduções nessas tabelas, essa tabela é armazenada em um cache chamado Translation Lookaside Buffer
(TLB)
A quantidade de memória que pode ser traduzida por esse cache TLB é chamada de “alcance TLB”.
Se houver uma falha na TLB, há uma penalidade maior associada.
De acordo com a arquitetura x86, o tamanho da página é de 4K bytes. Isso significa que quando um processo usa 1 GB de
memória, são 262.144 entradas para procurar! O efeito disso se multiplica à medida que o tamanho da memória aumenta.

A ideia do enormepage é aumentar esses 4K bytes para 2MB normalmente. Aquilo vai
reduzir drasticamente o número de referências de página.
O ganho de desempenho óbvio é de menos traduções que exigem menos ciclos. Um menos
O benefício óbvio é que as informações de tradução de endereços são normalmente armazenadas no cache L2.
Normalmente, as cargas de trabalho de banco de dados obtêm um ganho de desempenho instantâneo de 7%.

O maior benefício das páginas enormes é o desempenho mais estável dos sistemas de banco de dados.

Resumo Neste

capítulo, falamos sobre alguns passos iniciais após a instalação para desenvolvedores e administradores, e também
falamos sobre todos os arquivos de configuração do PostgreSQL e recomendações de como usá-los. Cobrimos alguns
parâmetros básicos que devem ser considerados ao configurar seu ambiente inicialmente. Essas recomendações também
incluem parâmetros de banco de dados e parâmetros de sistema operacional. No próximo capítulo, falaremos sobre
gerenciamento de usuários e segurança de bancos de dados.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_3

3. Gerenciamento de usuários e proteção de bancos de dados

Baji Shaik1
(1) Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre como configurar um banco de dados PostgreSQL para um melhor desempenho, o que inclui o ajuste
de vários parâmetros relacionados ao banco de dados com base em seu comportamento e também sobre parâmetros relacionados ao
sistema operacional que ajudam a melhorar o desempenho. Neste capítulo, falaremos sobre gerenciamento de usuários no PostgreSQL
e segurança de bancos de dados gerenciando privilégios de usuários. Também abordaremos diferentes tipos de privilégios em nível de
objeto e como podemos planejar melhor a utilização desses privilégios de nível granular para proteger os bancos de dados e diferentes
tipos de técnicas de criptografia que você pode usar para proteger seus dados.
Antes de falarmos sobre como gerenciar usuários e implementar segurança, vamos falar sobre quais informações precisamos
saber para a configuração. Se você está trabalhando para uma nova implementação de um ambiente PostgreSQL ou migrando de
qualquer banco de dados corporativo, você precisa saber informações básicas para começar. Vamos passar por algumas perguntas,
através das quais você terá um ponto de partida.

Informações que você precisa saber Ao discutir a implementação

de segurança, aqui estão algumas perguntas básicas que você pode fazer ao seu cliente.
Cada uma das perguntas a seguir tem um propósito específico, que ajuda você a criar um plano ao implementar a segurança no lado
do PostgreSQL.
Q1.
Qual é o seu gerenciamento de usuários atual?
Objetivo: Esta é a informação básica que você precisa saber. Diferentes clientes têm diferentes gerenciamentos de
usuários, como: Um usuário por um aplicativo Vários usuários por um aplicativo Um usuário por vários aplicativos

Na maioria das vezes, são vários usuários por aplicativo com base na função do usuário. Se for usado um único usuário, é
difícil manter a segurança. Portanto, é recomendável usar vários usuários e funções e atribuir privilégios às funções com base no
requisito.
Q2.
Como os usuários estão sendo criados?
Objetivo: Você deve saber como os usuários estão sendo criados no ambiente atual ou como eles desejam que os
usuários sejam criados. Alguns clientes usam ferramentas para criar usuários dinamicamente com base no requisito e removê-
los quando terminarem o trabalho do usuário. Se for esse o caso, talvez seja necessário desenvolver um script que possa fazer
isso.
Q3.
Você está usando usuários diferentes para escrever e ler o banco de dados?
Objetivo: Se o cliente estiver usando usuários diferentes para leitura e escrita, talvez seja necessário criar
usuários de acordo com os requisitos. Basicamente, para escrever, pode ser um usuário normal com as permissões
necessárias em objetos que podem ser modificados. No entanto, para leitura, você precisará de uma função somente leitura, que
pode ler apenas os objetos necessários, mas não modificar em nenhum caso. Às vezes, você também precisa de uma função
somente leitura para monitoramento. O PostgreSQL 10 veio com poucas funções de monitoramento por padrão, que abordaremos
neste capítulo na seção “Mecanismos de segurança”.
Q4. Você tem alguma política de senha configurada?
Finalidade: Bancos de dados corporativos como Oracle e MS SQL Server possuem políticas de senha para usuários, como:

PASSWORD_LIFE_TIME
Machine Translated by Google

PASSWORD_REUSE_TIME
PASSWORD_REUSE_MAX

PASSWORD_VERIFY_FUNCTION
PASSWORD_LOCK_TIME
PASSWORD_GRACE_TIME
INACTIVE_ACCOUNT_TIME

No entanto, o PostgreSQL possui apenas PASSWORD_LIFE_TIME (basicamente, data de expiração da senha) por padrão.
Nenhuma outra funcionalidade está disponível por padrão. No entanto, você pode usar um módulo de verificação de senha.
Mais informações estão disponíveis em
www.postgresql.org/docs/current/passwordcheck.html.
Q5.
Você tem segurança em nível de linha implementada?
Objetivo: Verificar se o cliente está usando atualmente alguma segurança em nível de linha. Se sim, o PostgreSQL também tem um
Recurso RLS (Row Level Security) disponível. Se você obtiver essas informações do cliente, poderá preparar políticas no
PostgreSQL de acordo com o requisito. Abordaremos mais sobre RLS na seção “Mecanismos de segurança”.

Q6.
Você está usando conectividade SSL? Em caso afirmativo, como os certificados estão sendo gerenciados?
Objetivo: Caso o cliente esteja utilizando conexões SSL (maneira segura de conectar banco de dados), você precisa
habilitar este recurso no PostgreSQL ativando o parâmetro ssl no arquivo de configuração. No entanto, você precisa saber como eles
estão gerenciando os certificados. Eles são autogerenciados ou certificados pela CA? Isso permitirá o requisito de manter os certificados
no lado do PostgreSQL.
Q7.
Você tem alguma configuração de auditoria?
Objetivo: A auditoria é um dos principais recursos que todo banco de dados moderno possui e todo cliente tenta
implementar. A auditoria pode ser um requisito de conformidade em muitos sistemas. Se o sistema tiver que ser equipado
com recursos de auditoria, a auditoria em nível de banco de dados também pode ser definida no PostgreSQL. Abordaremos mais sobre
esse recurso na seção "Mecanismos de segurança".
Q8.
Qual é a sua implementação atual de segurança?
Objetivo: Você precisa conhecer sua implementação atual de segurança para procurar alternativas em
PostgreSQL, pois tem sua própria maneira de proteger as coisas. Se eles estiverem usando alguma ferramenta externa para proteger
os dados, talvez seja necessário procurar essas funcionalidades nas ferramentas disponíveis do PostgreSQL.
Q9.
Quais são suas expectativas com o PostgreSQL em relação à segurança?
Objetivo: Isso é muito importante. Eles não podem esperar que tudo funcione da mesma maneira que seus
banco de dados corporativo de origem (se estiverem migrando de um banco de dados corporativo). Cada banco de dados tem seus
próprios mecanismos de segurança. Eles podem ser comparáveis; no entanto, eles podem não corresponder às vezes. Portanto, você
precisa avaliar cuidadosamente sua implementação de segurança atual e definir as expectativas de acordo quando eles estiverem
usando o PostgreSQL.
Q10.
Você usa criptografia de dados em repouso ou em movimento? Se sim, como é implementado?
Objetivo: A criptografia é outro aspecto fundamental da segurança. Pode estar em repouso ou em movimento. Você precisa saber
como ele é implementado e criar as ferramentas que podem fornecer a mesma funcionalidade no PostgreSQL. Abordaremos mais
sobre criptografia na seção “Mecanismos de segurança”.

Mecanismos de segurança Quando

um cliente está migrando de um banco de dados corporativo (como Oracle ou servidor MS SQL), ele pode querer saber o nível básico de
segurança que o PostgreSQL oferece. Você pode distinguir a segurança como mecanismos diferentes, como segue:

Métodos de autenticação no HBA

ACLs
RLS—Segurança em Nível de Linha
Conexões SSL/TLS
Machine Translated by Google

Acionadores de eventos

Auditoria
Funções de monitoramento

Criptografia e PCI
Replicação
PL confiável versus não confiável

A intenção deste capítulo é que, depois de lê-lo, você saiba quais recursos o PostgreSQL possui em termos de
gestão e segurança. Então, se a qualquer momento você encontrar algo, de repente você pode se lembrar que
O PostgreSQL tem RLS ou há algo chamado gatilhos de eventos que você pode usar para fins de segurança.
Antes de mais nada: o site do PostgreSQL tem uma página de segurança que contém informações sobre todos os
informações de vulnerabilidade comuns e quais versões secundárias do PostgreSQL e versões principais são vulneráveis
e quais não são: www.postgresql.org/support/security/.
É altamente recomendável marcar esta página como favorita e consultá-la pelo menos algumas vezes por semana por todos que
lida com o PostgreSQL em seu ambiente de produção. Correções de segurança têm precedência sobre bugs regulares. Segurança
os problemas são identificados e corrigidos pela comunidade PostgreSQL ainda mais rapidamente. É muito útil.

Autenticação no HBA
O PostgreSQL basicamente autentica conexões para si mesmo usando um arquivo HBA (arquivo de autenticação baseada em host). Se
você instala o PostgreSQL e abre um arquivo pg_hba.conf, este arquivo se parece com o seguinte por padrão:

# TIPO BASE DE DADOS DO UTILIZADOR MORADA MÉTODO

# "local" é apenas para conexões de soquete de domínio Unix

local todos todos Confiar em

# Conexões locais IPv4:

hospedar todos tudo 127.0.0.1/32 Confiar em

# Conexões locais IPv6:

hospedar todos tudo ::1/128 Confiar em

# Permitir conexões de replicação do localhost, por um usuário com o

# privilégio de replicação.
replicação local toda a replicação do host toda a Confiar em
replicação do host tudo 127.0.0.1/32 ::1/128 Confiar em
Confiar em

Isso não é o que deveria ser visto quando o PostgreSQL está rodando em produção.
Existem muitos tipos de autenticação que o PostgreSQL suporta em seu HBA. Diferentes tipos de autenticação
métodos são:

SENHA
MD5
SCRAM
CONFIAR EM

REJEITAR
PAR
IDENTIFICAÇÃO

LDAP
HOSTSSL

SENHA
Este é o sistema de autenticação baseado em senha mais simples que o PostgreSQL possui. É uma senha de texto simples. Não é
criptografado e, portanto, não é ideal.

MD5
Machine Translated by Google

Isso é o que ainda é, de muitas maneiras, o formato de autenticação de senha padrão e o algoritmo salgado para hash. Ele tem
algumas falhas pelas quais as pessoas criticam o PostgreSQL, como: “Por que o PostgreSQL tem md5? Não está quebrado?”
No entanto, a forma como o PostgreSQL usa o md5 é melhor do que a forma como o md5 básico funcionaria. Na verdade,
temos um sal aleatório toda vez via autenticação que o torna um pouco mais seguro do que o md5 puro.

SCRAM A
partir do PostgreSQL 10, temos o SCRAM (Salted Challenge Response Authentication Mechanism ).
SCRAM é melhor que md5, pois supera as falhas que o md5 tem. É mais seguro; aqui está um exemplo de configuração de
criptografia de senha SCRAM no PostgreSQL 10:

postgres=# set password_encryption ='scram-sha-256';

SET
postgres=# CRIAR FUNÇÃO finanças COM SENHA 'mostcommonpassword';
CREATE ROLE
postgres=# selecione substr(rolpassword,1,14) de pg_authid onde rolname ='finance'; substr

----------------
SCRAM-SHA-256$ (1
linha) postgres=#

E então, qual é a diferença quando se trata de como o SCRAM é melhor que o md5 aqui? No pg_authid
tabela, se você tiver senhas criptografadas no formato md5, ele mostrará o hash md5 como o seguinte:

postgres=# crie vendas de função com a senha 'md5password';

CREATE ROLE
postgres=# selecione rolpassword de pg_authid onde rolname ='vendas';
rolpassword
--------------------------
md5059f18f30cad64836a01f936c9ba7dd4
(1 linha)

Ele não vai esconder essa informação, então você pode realmente ver o hash da senha, o que não é o ideal. É muito
melhor que o MySQL, que em seu formato padrão armazenará a senha em texto simples, a menos que você envolva a senha
com uma função de senha explicitamente. O PostgreSQL não precisa que você o envolva em nenhuma função; se você der
uma senha, ele a armazenará automaticamente como um valor com hash. No entanto, com md5 a substring é um hash md5 puro,
enquanto você pode ver como o SCRAM funciona no exemplo anterior. Portanto, o SCRAM basicamente fornece os detalhes do
cálculo do valor da senha. Ele não fornece o hash, portanto, é mais seguro. Se você está pensando em atualizar para o
PostgreSQL 10 e possivelmente migrar para o SCRAM do md5 por um tempo limitado pelo menos para o PostgreSQL 10 e 11, o
PostgreSQL está permitindo o fallback para o md5. Então, basicamente, se você tiver sua criptografia de senha configurada para
SCRAM e algum cliente estiver tentando se conectar usando autenticação md5, o PostgreSQL permitirá que isso aconteça -
apenas para facilitar a transição para as pessoas, mas não em versões posteriores.
Uma entrada de exemplo em um arquivo pg_hba.conf é a seguinte:

# Todos os usuários (de 192.168.12.10) requerem autenticação SCRAM para conectar o banco de dados postgres.

# TYPE DATABASE host USUÁRIO ENDEREÇO MÉTODO

postgres todos 192.168.12.10/32 scram-sha-256

CONFIAR
Basicamente, “não confie” na autenticação TRUST . CONFIANÇA é basicamente nenhuma senha. Por exemplo, “estou
apenas confiando que você, meu melhor amigo, pode fazer o que quiser na minha sala” e isso leva a problemas. Uma
das piores maneiras que isso pode acontecer é se você viu no arquivo padrão a primeira linha tinha autenticação TRUST,
Machine Translated by Google

então alguém que não olha para a documentação pode apenas pensar “CONFIANÇA é simples e ainda é
autenticação, então vou usar confiança para todos os meus outros acessos também.” Para eliminar essa possibilidade existe
uma maneira no PostgreSQL: ao inicializar o diretório de dados, você pode dizer ao PostgreSQL para não colocar essa linha no
arquivo HBA padrão. Então, basta removê-lo da própria causa raiz. Essa opção é -A no initdb:

8c85902e3a2c:data $ initdb --help|grep auth

-A, --auth=MÉTODO método de autenticação padrão para conexões locais
--auth-host=MÉTODO método de autenticação padrão para TCP/IP local
conexões
--auth-local=MÉTODO método de autenticação padrão para soquete local
conexões
8c85902e3a2c:dados $

É a maneira de dizer ao initdb para usar md5 como o nível mínimo de autenticação para que não haja confiança se você
.
gerar um arquivo usando esta opção em um banco de dados

REJEITAR
Muitas vezes você tem um subconjunto de IPs que deseja permitir o acesso para uma função específica em um banco de dados específico;
no entanto, pode haver um ou dois IPs nesse subconjunto aos quais você não deseja permitir acesso. Então, ou você ou
um dos seus DBAs é preguiçoso e eles apenas pensam “ninguém vai acessar desses poucos IPs e eu só vou
permitir todos eles” ou seu DBA é bom, onde eles vão além e não colocam o IP como uma sub-rede, mas eles
coloque em IPS /32 individual mesmo se houver uma centena. No entanto, observe que há uma opção de rejeição. O que você pode fazer
é permitir o acesso a uma sub-rede e definir essa rejeição de IP específica, o que significa não olhar para nenhuma linha após essa linha. Isso é
realmente importante que você rejeite qualquer superusuário que se conecte de um host que não seja o host local apenas por segurança
propósitos. Normalmente, se for um DBA, eles podem fazer SSH no servidor de banco de dados e efetuar login como superusuário.
Uma entrada de exemplo no arquivo pg_hba.conf é a seguinte:

#Todos os usuários do servidor 192.168.54.1 são rejeitados.

# TYPE DATABASE host all USUÁRIO ENDEREÇO MÉTODO

todos 192.168.54.1/32 rejeitar

PEER e IDENT
Em ambos os métodos de autenticação, o PostgreSQL obtém o nome de usuário do sistema operacional do qual o cliente está se conectando e o corresponde
com o nome de usuário do banco de dados solicitado. A diferença entre esses métodos de autenticação é que o PEER está disponível para
conexões locais enquanto IDENT é para conexões TCP/IP.
Para autenticação de pares, a entrada pg_hba.conf se parece com o seguinte:

# "local" é apenas para conexões de soquete de domínio Unix

local tudo tudo par

Para autenticação de identificação, a entrada pg_hba.conf se parece com o seguinte:

hospedeiro todos todos 192.168.10.22/24 ident map=my_ident_map

Um arquivo $PGDATA/ident.conf se parece com o seguinte:

# MAPNAME SYSTEM-USERNAME PG-NOME DE USUÁRIO

my_ident_map my_os_user ident_db_user

LDAP
Este método de autenticação é usado quando sua conexão está sendo autenticada de um servidor LDAP .

Observação Qualquer alteração feita em um arquivo HBA precisa de uma recarga do servidor PostgreSQL para ter efeito.

Um exemplo de entrada de pg_hba.conf se parece com o seguinte:

Machine Translated by Google

host tudo dbuser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com

ldapprefix="cn=" ldapsuffix=", dc=exemplo, dc=com"

HOSTSSL
Este método de autenticação é usado quando você usa conexões SSL. Antes de usar esta autenticação, você deve
ativar os parâmetros SSL no arquivo de configuração postgresql.conf.
Uma entrada de exemplo se parece com o seguinte:

hostssl todos tudo 0.0.0.0/0 md5

ACLs

ACL significa Lista de Controle de Acesso. Então, basicamente esta lista mostra uma lista de privilégios que um usuário tem em um objeto.
Esses privilégios são atribuídos usando o comando GRANT e revogados usando o comando REVOKE.

Privilégios disponíveis
Antes de falarmos mais, você precisa conhecer as abreviações de privilégios da ACL, conforme mostrado a seguir:

r — SELECT ("ler") w —
UPDATE ("escrever") a —
INSERT ("anexar") d — DELETE

D — TRUNCAR x —
REFERÊNCIAS t —
DISPARAR
X - EXECUTAR
U - USO
C — CRIAR c
— CONECTAR
T — TEMPORARY
arwdDxt — TODOS OS PRIVILÉGIOS (para tabelas, varia para outros objetos) — concede opção para
*
privilégio anterior /yyyy — função que concedeu este privilégio

Essas abreviações de ACL são bem explicadas na documentação do PostgreSQL em

www.postgresql.org/docs/current/ddl-priv.html#PRIVILEGE-ABBREVS-TABLE.
Cada tipo de objeto tem diferentes tipos de privilégios que podem ser concedidos a eles. Esta tabela explica sobre isso:
www.postgresql.org/docs/current/ddl-priv.html#PRIVILEGES-SUMMARY-TABLE.
Portanto, com base no requisito, conceda cuidadosamente os privilégios GRANT/REVOKE nos objetos. Dessa forma, você pode garantir
um banco de dados contra ser acessado por usuários indesejados. Ao compará-lo com outros bancos de dados
relacionais e corporativos, você notará que, além de todos os comuns (como SELECT, INSERT, DELETE, etc.), existe
algo chamado USAGE. Isso tem um significado diferente no PostgreSQL. Esse privilégio permite que o usuário/função use
um esquema específico para acessar objetos dentro dele para fins de leitura/gravação. Observe que, embora você tenha
certos privilégios em um objeto, a menos que tenha uso no esquema no qual o objeto existe, você não poderá acessá-lo.
Você pode usar \z para ver os privilégios de acesso de um objeto. Aqui está um exemplo:

postgres=# \z títulos
Privilégios de acesso
Esquema | Nome | Tipo | Privilégios de acesso | Privilégios de coluna | Políticas
--------+--------+-------+--------+---- ---------------+----------
público | títulos | mesa | (1 linha) | |

postgres=# grant select,insert em títulos para vendas; GRANT Tempo: 27,145 ms

postgres=# \z títulos
Machine Translated by Google

Privilégios de acesso
Esquema | Nome | Tipo | Privilégios de acesso | Privilégios de coluna |
Políticas
--------+--------+-------+------------------------ ---+-------------------+--
--------
público | títulos | mesa | postgres=arwdDxt/postgres+| | |
| | | vendas=ar/postgres |
(1 linha)

DDLs transacionais
Ao contrário de outros mecanismos de banco de dados (como Oracle, MySQL, etc.), o PostgreSQL possui DDLs de transação. Significa que você pode
executar DDLs dentro de uma transação e confirmar/reverter se necessário. Alguns bancos de dados relacionais permitem que você execute o
DDLs dentro de uma transação, mas se você fizer um rollback, eles não serão realmente revertidos. No entanto, a reversão de um DDL
em uma transação realmente reverte no PostgreSQL. Por exemplo:

postgres=# inicio;
COMEÇAR

postgres=# concede seleção de títulos para vendas;

CONCEDER

postgres=# \z títulos
Privilégios de acesso
Esquema | Nome | Tipo | Privilégios de acesso | Privilégios de coluna |
Políticas
--------+--------+-------+------------------------ ---+-------------------+--
--------
público | títulos | mesa | postgres=arwdDxt/postgres+| | |
| | | vendas=r/postgres |
(1 linha)

postgres=# reversão;
RECUPERAR
postgres=# \z títulos
Privilégios de acesso
Esquema | Nome | Tipo | Privilégios de acesso | Privilégios de coluna |
Políticas
--------+--------+-------+------------------------ ---+-------------------+--
--------
público | títulos | mesa | postgres=arwdDxt/postgres | (1 linha) |

Alterar privilégios padrão

Se você tiver um novo esquema e souber que todas as tabelas nesse esquema devem ter um número definido de permissões por
default, então você pode dar privilégios padrão usando alguma sintaxe semelhante a esta:

ALTER DEFAULT PRIVILEGES IN SCHEMA <schema_name> GRANT <privilege> ON TABLES

PARA <função>;

O que acontece mesmo se seu esquema estiver vazio? Ele saberá que esses são os privilégios padrão para ele, então o próximo
o passo é realmente criar uma tabela dentro desse esquema; se você verificar os privilégios usando \dp, verá o que quer que seja
permissões que você queria que ele tivesse. Uma coisa a notar é que você pode definir isso em qualquer esquema, mesmo com
objetos existentes nele Depois de executar alterar privilégios padrão e criar outro objeto dentro desse esquema, ele
vai ler esses privilégios e atribuí-los automaticamente. No entanto, ele não vai atribuir seu padrão
privilégios para os objetos que já existem dentro do esquema. Você terá que fazer isso manualmente. Você pode preparar
comandos ou gerar um script SQL.

Funções e grupos
Machine Translated by Google

A próxima coisa sobre ACL são os papéis. Normalmente, funções e funções de grupo são a norma, mas o PostgreSQL
não fornece nenhum tipo especial de definição dentro de si para uma função de grupo. Qualquer função pode ter
outras funções como seus membros. Você não precisa ter nenhuma declaração especial para essa função. O que
você deve fazer é por convenção e boa política; você pode ter funções de grupo como vendas e ter todos os privilégios
que qualquer pessoa que ingresse na equipe de vendas exigiria em um conjunto de bancos de dados ou de esquemas.
Qualquer nova pessoa que se juntar à equipe de vendas terá apenas sua própria função individual e acabamos de
torná-la membro da função de vendas, sem privilégios extras ou especiais para esse vendedor em particular. Então, o
que acontece dessa forma é que você tem menos trabalho a fazer quando essa pessoa sai ou mesmo quando uma
nova pessoa se junta. está quebrado porque esse usuário não existe mais e eles criaram a tabela.

ACLs em nível de coluna

Este é outro recurso muito interessante do PostgreSQL. Você pode ter ACLs de nível de coluna, conforme mostrado a seguir:

postgres=# GRANT update(emp_no) ON títulos PARA vendas;

GRANT
postgres=# \z títulos
Privilégios de acesso
Esquema | Nome | Tipo | Privilégios de acesso | Privilégios de coluna |
Políticas
--------+--------+-------+------------------------ ---+--------------------+-
---------
público | títulos | mesa | postgres=arwdDxt/postgres | emp_no: +|
| | | | vendas=c/postgres |
(1 linha)

postgres=#

Você pode conceder privilégios de nível de coluna aos usuários. O exemplo anterior atualiza uma coluna específica
chamada emp_no para sales role e você pode ver que ela tem esse privilégio.

Evite Esquemas Públicos

É recomendado que você tenha seus próprios esquemas mesmo que conceder o uso seja uma dor às vezes,
especialmente se você é novo no PostgreSQL, porque o esquema público por padrão permite acesso a todos. Portanto,
não importa quão importante seja uma função que você crie, se ela estiver no esquema público, qualquer usuário do seu
banco de dados poderá executá-la. Se você tiver um pequeno aplicativo, poderá pensar “Por que precisamos de um esquema
separado? Podemos saber exatamente quais papéis estarão lá e sabemos exatamente quais permissões eles terão.” No
entanto, ser restritivo não significa que o PostgreSQL será restritivo. Por padrão, há uma função pública atribuída a uma função/
usuário recém-criado. Você não pode realmente revogar os privilégios de nenhum usuário atribuído por meio do esquema público
.

Funções somente
leitura Uma função somente leitura é uma das partes mais complicadas do PostgreSQL. Conforme explicado na seção anterior, uma
função pública será atribuída a um usuário/função recém-criado. Portanto, por padrão, o usuário/função obtém privilégios para criar
objetos no esquema público. No entanto, se você se refere a uma função somente leitura, ela deve ler os objetos do banco de dados
e não deve ter privilégios para criar os objetos. Mas você não pode realmente revogar essa permissão de um usuário/função
diretamente. No entanto, você pode revogar esses privilégios de uma função pública, que herda todos os usuários criados e os novos
usuários que serão criados.

#isto irá revogar os privilégios de criação de todos os usuários

REVOKE CREATE ON SCHEMA public FROM public; #você
precisa conceder privilégios explicitamente se quiser um usuário com permissões de gravação

GRANT CREATE ON SCHEMA público para escrever;

#criar somente leitura
CREATE ROLE user_readonly COM SENHA 'minha senha';
GRANT SELECT EM TODAS AS TABELAS NO SCHEMA public TO user_readonly;
Machine Translated by Google

Observe que se você revogar privilégios da função pública, observe que você terá que concedê-los explicitamente a novos
.
usuários para os quais deseja conceder acesso de leitura/gravação ao esquema público

RLS (Segurança em Nível de Linha)

RLS tem tudo a ver com restringir o acesso a algumas linhas de uma tabela. Ele é introduzido no PostgreSQL 9.5. Você pode
dizer que é acesso parcial da tabela. Às vezes você pode ter uma tabela enorme (como contas no exemplo a seguir) na qual
você tem dados sobre gerentes e funcionários. Você pode ter todos os tipos de informações confidenciais, como salários, e pode
não querer que um gerente veja os detalhes dos funcionários que não estão subordinados a ele. Portanto, nesses casos, você
pode dividir a tabela em mil partes, dependendo do tamanho da sua empresa, ou pode usar a segurança em nível de linha.
Algumas finalidades críticas mais importantes surgem se você acessar bancos de dados governamentais e tiver mais problemas
de privacidade, portanto, para essa finalidade, você pode habilitar a segurança em nível de linha. Aqui está um exemplo:

postgres=# ALTER TABLE contas ENABLE ROW LEVEL SECURITY;

ALTERAR A TABELA
postgres=# CRIAR POLÍTICA account_managers EM contas PARA gerentes postgres-# USING (manager
= current_user); CRIAR POLÍTICA postgres=> \c - postgres psql (11.2, servidor 10.2)

Agora você está conectado ao banco de dados "postgres" como usuário "postgres". postgres=# selecione
count(1) das contas ;
contar
-------
2
(1 linha)

postgres=# \c - gerenciadores psql

(11.2, servidor 10.2)
Agora você está conectado ao banco de dados "postgres" como usuário "managers". postgres=>
selecione * das contas; gerente | empregado | contato_email | salário

----------+----------+---------------+--------
gerentes | empregado | [email protected] | 100000 (1 linha) postgres=>
selecione count(1) from accounts ; contar

-------

1 (1 linha)

Então, basicamente no exemplo anterior, está criando uma política que afirma que se seu usuário atual estiver listado como um
gerente em um subconjunto das linhas na tabela de contas, esse usuário pode ver apenas essas linhas específicas.
Esta é uma política muito simples, mas é assim que funciona. Mesmo que este usuário atual "selecione * das contas", ele
só poderá ver as linhas das quais é gerente. Existem exceções e você pode conceder exceções. Então, digamos, o usuário
abc é o gerente de nível superior da organização, mas você não quer que ele seja o proprietário da tabela. Ele tem uma
conta regular, não superusuário no PostgreSQL, mas precisa ver a tabela inteira; você pode fornecer a ele o privilégio de
ignorar RLS, conforme mostrado a seguir:

ALTER PAPEL abc BYPASSRLS;

O proprietário da tabela está automaticamente isento da restrição de RLS. Se você possui a mesa, mesmo que você
tiver o nível de linha ativado, você poderá ver todas as linhas. Se você quiser que isso aconteça, você precisa usar uma
palavra-chave force ao definir a habilitação no nível da linha.
Machine Translated by Google

contas ALTER TABLE FORCE ROW LEVEL SECURITY;

Observação A política padrão quando você habilita o nível de linha é negada, portanto, a menos que você crie uma
política, ninguém pode selecionar nada dessa tabela. Portanto, se você planeja habilitá-lo, certifique-se de fazer essas
duas coisas (habilitar e criar política) em uma única transação.

No PostgreSQL 9.5 e 9.6, se você tiver três políticas na tabela e estiver tentando consultar algo, o usuário não precisará
satisfazer todas as três políticas. Se o usuário puder passar por qualquer uma dessas políticas, isso é suficiente para obter
acesso. Essa era a única opção que você tinha quando tinha várias políticas — apenas a lógica OR. No entanto, a partir do
PostgreSQL 10, você também tem AND ou restritivo, em que, se um usuário não puder passar por todas essas políticas, ele
não poderá ler nada da tabela .

SSL
Como você sabe, o SSL é uma das formas seguras de conectar um banco de dados. Se você deseja fazer conexões SSL,
deve ativar o SSL, o que exigirá uma reinicialização. Se você estiver instalando ou compilando seu próprio PostgreSQL,
certifique-se de compilá-lo com SSL aberto como o seguinte:

./configure --with-openssl

Por padrão, o SSL permitirá autenticação e criptografia. Você pode optar por não criptografar. Algumas pessoas
parece que é muita sobrecarga, mas você tem a opção. Mas só porque você tem a opção não significa que você deve usá-
la, porque a maior parte da carga de trabalho em SSL vai para autenticação e criptografia, o que não leva muito tempo ou
consumo de recursos. Então, se você já decidiu usar SSL, por que não apenas criptografá-lo também.
Aqui estão os certificados necessários e os parâmetros para definir os locais dos certificados:

ssl = on # (alteração requer reinicialização) #ssl_ciphers =

'ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH' # permitido cifras SSL #ssl_prefer_server_ciphers = on # (alteração requer
reinicialização) #ssl_ecdh_curve = 'prime256v1' # (mudança requer reinicialização) ssl_cert_file = '/etc/ssl/postgres/
starry.io.crt' # (mudança requer reinicialização) ssl_key_file = '/etc/ssl/postgres/starry.io.key' # (mudança requer reinicialização)
ssl_ca_file = #ssl_crl_file =

"
# (mudança requer reinicialização)
"
# (mudança requer reinicialização)

Certifique-se de que as permissões do certificado sejam 600, caso contrário o PostgreSQL se recusará a iniciar .

Até o Postgres 9.6, sempre que você precisava alterar seu certificado, era necessário reiniciar. No entanto, você apenas
precisa de uma recarga do PostgreSQL 10.

Túneis
Se você tem suporte a SSL e deseja todas as conexões de SSL, mas tem um cliente desatualizado que não suporta SSL,
sempre há encapsulamento SSH e você ainda pode ter SSL ativado

ssh -L 63333:localhost:5432 [email protected] psql -h localhost -p

63333 postgres

Acionador de
evento A maneira como os acionadores de evento diferem dos acionadores normais é que eles não são disparados em
DDLs. Eles disparam em eventos maiores como você tem um novo DBA e é o primeiro dia de trabalho deles e eles descartam
a tabela de usuários. Os gatilhos de eventos vão impedir isso. Não é algo que vai ser usado todos os dias, mas é a única
coisa que vai salvar você e seu site. No dia em que alguém cometer um grande erro, um gatilho de evento irá salvá-lo. Então,
basicamente as vantagens dos gatilhos de eventos são: Auditoria Modificação indesejada de dados
Machine Translated by Google

Perda acidental de dados

Vamos ver um exemplo:

postgres=# CRIAR FUNÇÃO to_avoid_object_drops()

postgres-# RETURNS event_trigger
postgres-# IDIOMA plpgsql AS $$
postgres$# DECLARE
registro de objeto postgres$#;
postgres$# BEGIN
*
postgres$# FOR objeto IN SELECT postgres$# LOOP DE pg_event_trigger_dropped_objects()

postgres$# RAISE EXCEPTION '% objeto descartado: % %.% %',

postgres$# tg_day,
postgres$# object.object_type,
postgres$# object.schema_name,
postgres$# object.object_name,
postgres$# objeto.objeto_identidade;
postgres$# FIM DO LOOP;
postgres$# END
postgres$# $$;
CRIAR FUNÇÃO

postgres=# CRIAR GATILHO DE EVENTO to_avoid_object_drops

postgres-# ON sql_drop
postgres-# EXECUTAR PROCEDIMENTO to_avoid_object_drops();
CRIAR ACIONADOR DE EVENTO

postgres=# DROP TABLE

juntar1;
Objeto descartado TABLE: table public.join1 public.join1
AVISO: DROP TABLE objeto descartado: index public.unq_index_join public.unq_ind
AVISO: DROP TABLE objeto descartado: digite public.join1 public.join1
AVISO: DROP TABLE objeto descartado: digite public._join1 public.join1[]
AVISO: DROP TABLE objeto descartado: tabela de brinde pg_toast.pg_toast_16554 pg_toa
AVISO: DROP TABLE objeto descartado: index pg_toast.pg_toast_16554_index pg_toa
AVISO: DROP TABLE objeto descartado: digite pg_toast.pg_toast_16554 pg_toast.pg_t
ERRO: DROP TABLE objeto descartado: tabela public.join1 public.join1
CONTEXTO: função PL/pgSQL para_avoid_object_drops() linha 7 em RAISE

Estes são os quatro eventos que, a partir de agora, os gatilhos de evento suportam:

ddl_command_start
ddl_command_end
sql_drop
table_rewrite na página 10

Em nosso exemplo anterior, era um evento drop SQL. ddl_command_start e ddl_command_end são
equivalente a gatilhos normais antes e depois de um comando DDL. Quanto às reescritas de tabelas, algumas atividades como alterar
um tipo de dados de colunas ou definir um valor padrão para uma coluna não é a melhor coisa a fazer quando é o horário de pico de carregamento para
seu site. Você pode evitar que isso aconteça criando um gatilho de evento que verifica uma reescrita de tabela
operação e você pode proibir esse tipo de operação quando for um momento ruim. Então, você pode dizer que você só pode fazer
essas operações das 12h às 9h

Auditoria
O PostgreSQL não tem uma diferença de extensão de , para que você possa criar um gatilho DML normal e apenas obter o
auditoria principal dos novos valores e os valores antigos e os armazena em outra tabela. Aqui está um exemplo simples:
Machine Translated by Google

CREATE FUNCTION test_audit_trig() RETURNS gatilho

IDIOMA plpgsql
COMO $$
DECLARAR
v_dmltype texto;
COMEÇAR

SE TG_OP = 'INSERIR' ENTÃO

v_dmltype = 'I';
ELSE
v_dmltype = 'U';
FIM SE;

INSERT INTO auditing.test (col1, col2,....dmltype, change_timestamp)

VALORES (NEW.col1, NEW.col2,....v_dmltype, current_timestamp)
RETORNO NULO;

Anexar gatilho a uma tabela:

CREATE TRIGGER test_audit_trig ANTES DE INSERT OU UPDATE OU DELETE ON table_name

PARA CADA LINHA EXECUTAR PROCEDIMENTO test_audit_trig();

pgaudit é o mais próximo que o PostgreSQL tem quando se trata de uma extensão de auditoria. No entanto, tenha em
. auditado.
mente que não é uma extensão central do PostgreSQL. A extensão pgaudit é útil se todo o seu banco de dados precisar ser

Funções de
.
monitoramento PostgreSQL 10 em diante, quando se trata de monitoramento existem novas funções de monitoramento Antes do
PostgreSQL 10, se você quisesse conectar uma ferramenta de monitoramento com sua instância, o usuário que essa ferramenta usava para
falar com o PostgreSQL tinha que ser um superusuário porque existem coisas em suas informações de metadados de catálogo que um não
superusuário não pode consultar. Então, se você quisesse certos tipos de informação, teria que ter um superusuário. No entanto, do PostgreSQL
10 em diante, há novas funções de monitoramento disponíveis:

pg_monitor
pg_read_all_settings
pg_read_all_stats
pg_stat_scan_tables

Criptografia e PCI
pgcrypto é usado para obter criptografia em nível de banco de dados no PostgreSQL. É uma extensão do núcleo do PostgreSQL
e não uma ferramenta de terceiros. Ainda é uma extensão, mas é suportada pela comunidade PostgreSQL, por isso é confiável.
Agora, o que deve ser criptografado quando falamos de criptografia? Vamos falar sobre:

Impacto no desempenho
Backups
Volumes
Nível da instância

Impacto no desempenho
Você pode ter diferentes tipos de algoritmos AES (como AES-128, AES-192 ou AES-256) no pgcrypto. Haverá um
impacto óbvio no desempenho. Então, basicamente você está dizendo ao pgcrypto para criptografar cada valor atômico em
sua tabela ou conjunto de tabelas. Você pode optar por criptografar a tabela inteira ou criptografar apenas as colunas
importantes que deseja proteger. Quando se trata de PCI e dados de cartão de crédito (por exemplo), você tem uma das
colunas na sua tabela de cartão de crédito e que é o número do cartão de crédito, por exemplo; essa é a única que você
realmente precisa proteger, dependendo de quais outras colunas você possui. No entanto, você certamente não precisa
criptografar a tabela inteira porque você tem informações lá que por si só não serão úteis para uma parte ruim. Aqui está um
exemplo de como usar as funções do pgcrypto:
Machine Translated by Google

postgres=# CREATE TABLE crypt_table(uname varchar, pwd_crypt texto, pwd_md5 texto);

CREATE TABLE
postgres=# cria extensão pgcrypto ;
CREATE EXTENSION
postgres=# INSERT INTO crypt_table VALUES ('Robert',
crypt('testpassword',gen_salt('md5')),md5('testpassword'));
INSERT 0 1
postgres=# INSERT INTO crypt_table VALUES ('Tom',
crypt('testpassword',gen_salt('md5')),md5('testpassword'));
INSERT 0 1
postgres=# select * from crypt_table ; uname | pwd_crypt
| pwd_md5
--------+------------------------------------+---- --------------------------
----
Roberto | $1$Y3iUMA6h$OUTGwuH7hoFJnOO48taNV1 |
e16b2ab8d12314bf4efbd6203906ea6c
Tom | $1$IfATTihP$A78rkOIIEvkZ2LjcRT6hd1 |
e16b2ab8d12314bf4efbd6203906ea6c (2 linhas) postgres=#
selecione uname de crypt_table onde uname="Tom" e
pwd_crypt=crypt('testpassword',pwd_crypt);

uname
-------
Tom
(1 linha)

Backups
Os backups devem ser criptografados. Um requisito importante sobre o PCI é que você não deseja ter as chaves de
criptografia com seu backup porque, se o backup for roubado, a chave o acompanhará. Lá se vão todos os dados, então é
preferível usar pg_dump porque assim você pode fazer um backup lógico. Seu sistema de arquivos não terá backup e,
portanto, suas chaves.

Volumes

Há também uma opção com certos sistemas de arquivos para criptografar. Você pode ter um volume de volta criptografado no ZFS (por
exemplo) e pode fazer todos os tipos de coisas seguras, como exigir um início de chave dividida. Portanto, você não pode nem restaurar
ou aumentar o volume, a menos que duas pessoas insiram suas próprias senhas específicas.

Nível de instância
E a criptografia em nível de instância em uma instância em execução? Há uma demanda crescente por criptografia
de dados em repouso — TDE (Transparent Data Encryption). No entanto, ainda não há nada no PostgreSQL. Há
um patch de prova de conceito sendo discutido aqui: www.postgresql.org/message id/flat/
CA%2BCSw_tb3bk5i7if6inZFc3yyf%2B9HEVNTy51QFBoeUk7UE_V%3Dw%40mail.gma il.com. Existem vários
esforços como este na comunidade, mas eles ainda não foram concluídos.

Replicação
Por que a replicação seria discutida como parte da segurança? Às vezes, principalmente quando se trata de um ambiente PCI e
você precisa cuidar de um banco de dados de cartão de crédito, é recomendável não ter um hot standby. Porque, se você tiver
uma réplica somente leitura, qualquer pessoa poderá selecionar e ler qualquer coisa em sua réplica sem ficar preso. Se você tem
uma réplica PCI, você tem que estar extremamente seguro de que fora dela ninguém pode acessá-la, porque nem mesmo o DBA
deveria conseguir.
Se você tiver um arquivo de recuperação - o que deve fazer se tiver uma réplica - tente não ter a senha de texto simples na
string de conexão do arquivo de recuperação. A maneira mais simples de evitar isso é ter um arquivo .pgpass. É um arquivo
secreto no diretório home do PostgreSQL e é um arquivo de ponto com permissão muito restrita 600. Ele permitirá que você se
conecte sem ter que escrever sua senha explicitamente ou tê-la em texto simples em seu conf de recuperação.
Machine Translated by Google

PL Trusted vs. Untrusted Os

procedimentos não confiáveis são basicamente aqueles que podem acessar e manipular coisas fora do banco de dados, e confiáveis
são aqueles que só têm permissão para manipular e fazer coisas dentro do software de gerenciamento de banco de dados.
Se você quiser que um usuário sem privilégios tenha um privilégio escalonado com o propósito de executar uma função específica,
você pode usar uma palavra-chave “definidora de segurança” na função que está criando. Basicamente, o que o definidor de segurança faz é
que, quando um usuário tenta executar uma função, ele concede privilégios elevados ao usuário para poder executar essa função como
proprietário da função. Portanto, é bastante útil se você deseja apenas que um usuário execute uma função específica, mas não deseja que ele
tenha esse privilégio o tempo todo.

Diretrizes de alta segurança e criptografia Nunca abra a porta 5432 para a

Internet pública.
Não conceda permissões a nenhum usuário para SSH no servidor de banco de dados. Em vez disso, use um host bastion e abra a porta para
esse host.
Se você planeja um Bastion Host, restrinja o acesso com VPN.
Se você estiver em serviços gerenciados baseados em nuvem, certifique-se de ter os grupos de segurança corretos (abertos aos hosts
necessários).
Certifique-se de sempre atualizar seu banco de dados com os patches de segurança mais recentes. As informações de patches
de segurança estão aqui: www.postgresql.org/support/security/.
Nunca, nunca use o método de autenticação “trust” em pg_hba.conf.
Sempre crie “funções” com as concessões necessárias e atribua as funções certas aos usuários certos.
Ao criptografar os dados, considere criptografar apenas as colunas necessárias, mas não todas as tabelas ou todo o banco de dados.
Não registre informações confidenciais em texto simples.
Certifique-se de criptografar os backups.
Restrinja o acesso de usuários às linhas obrigatórias usando RLS.
Tente fazer a criptografia no lado do aplicativo, não no banco de dados.

Resumo Neste
capítulo, falamos sobre privilégios de nível de objeto no PostgreSQL e como usá-los para proteger seu banco de dados. Criar funções e separá-
las com base no uso do aplicativo oferece melhor segurança sobre seus dados. Dependendo da sensibilidade dos dados, você pode criptografar
seus dados usando extensões do PostgreSQL disponíveis, como pgcrypto. Também falamos sobre algumas diretrizes que você pode considerar
antes de implementar a segurança do banco de dados. No próximo capítulo, falaremos sobre as opções de backup/restauração disponíveis e como
construir uma estratégia de backup do seu banco de dados, dependendo das informações disponibilizadas pelo cliente.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_4

4. Melhores práticas de backup e restauração

Baji Shaik1
(1) Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre gerenciamento de usuários no PostgreSQL usando

funções, atribuindo privilégios apropriados e dados seguros, criptografando usando o módulo
pgcrypto. Ele ajuda a melhorar a segurança controlando o acesso a objetos e dados. Neste
capítulo, falaremos sobre estratégias e procedimentos de backup/restauração. Construir
essas estratégias precisa de muita informação. Este capítulo orienta você pelos estágios em
que as informações serão coletadas para configurar o backup/restauração de um banco de
dados, com base na criticidade dos dados.
Este capítulo também fala sobre quando/o que fazer/como fazer backup/restaurar.

Propósito de fazer backup de um banco de dados É

realmente surpreendente a frequência com que hoje em dia, como consultor indo para
diferentes clientes, você se depara com este cenário: eles não têm backups e você ouve
coisas como "Bem, você sabe, temos replicação . Na verdade, não precisamos fazer backups
porque nossa replicação cuidará disso.” Não é bem assim que funciona. Quando você
descarta a tabela errada, ela é replicada instantaneamente para a réplica e nunca há chance
de parar isso antes que seja tarde demais. Antigamente, os backups eram necessários para
recuperação de desastres (o que significava trazer todo o banco de dados em caso de
falhas). No entanto, existem muitos procedimentos para salvar bancos de dados de
recuperações de desastres hoje em dia (os quais discutiremos no Capítulo 7).

Você já deve ter ouvido falar de clientes dizendo que estão executando na nuvem
então eles não precisam de backups. Você possivelmente precisa de backups mais do
que nunca se fizer isso agora; você pode ter outra pessoa para fazer os backups para
você como parte de seu contrato de serviço, mas é necessário que haja backups. Um pouco
Machine Translated by Google

os clientes podem dizer que executam suas coisas no Docker, portanto, não precisam fazer
backups separados. É altamente recomendável fazer os backups em qualquer um dos casos.

O objetivo principal do backup é a recuperação pontual (PITR), o que significa restaurar

o banco de dados para um ponto no tempo. O PITR é necessário quando ocorrem
alterações acidentais no banco de dados e essas alterações precisam ser corrigidas ou
restauradas no banco de dados para continuar os negócios.

Reúna informações para configurar uma estratégia de backup Há muitas perguntas que
precisam ser respondidas para planejar o backup. Depois de reunir todas as informações,
você pode planejar uma estratégia de backup. Vejamos algumas questões:

Q1.
Qual é a criticidade dos dados?
Objetivo: Você precisa saber qual é a importância dos dados antes de configurar
uma estratégia de backup. Dependendo da criticidade, você planeja com
que frequência fará backup, qual deve ser a retenção e com que rapidez poderá
recuperar os dados, se necessário.
Q2.
Quão sensíveis são os dados?
Objetivo: Se os dados forem muito confidenciais, você deve planejar
a criptografia dos backups. Como a criptografia pode ser uma sobrecarga, você deve
saber se os backups precisam ser criptografados ou não.
Q3.
Quanto tempo de inatividade você pode pagar caso o PITR seja necessário?
Objetivo: Você deve saber quanto tempo de inatividade pode pagar nos piores
cenários. Dependendo dessas informações, você saberia com que frequência precisa
fazer backup de seu banco de dados. Você sempre escolhe o pior cenário para calcular
o tempo de inatividade acessível.
Q4.
Qual o tamanho do banco de dados?
Objetivo: Dependendo do tamanho do banco de dados, você planejaria o backup
servidores e retenções, e também decidir que tipo de backup você pode escolher
para seu banco de dados.
Q5. Você seria capaz de pagar armazenamento em nuvem ou um servidor físico/virtual para
backups?
Finalidade: É sempre recomendável armazenar seus backups em um
Machine Translated by Google

Objetivo: É sempre recomendável armazenar seus backups em uma máquina

diferente da máquina do banco de dados. Portanto, você deve fazer essa pergunta ao
cliente antes de implementar uma estratégia de backup.
Q6.

Qual será a retenção de backups?

Objetivo: Para planejar o armazenamento dos backups, você precisa conhecer o
retenção. O cliente deve saber quantos backups precisaria em caso de falhas.

Q7.
Quanta janela de manutenção pode ser fornecida para fazer backups?
Finalidade: Dependendo da janela de manutenção dos backups,
você pode planejar a frequência de backup e o tipo de backup.
Q8.
Que tipo de backup você deseja?
Objetivo: Alguns clientes podem ser específicos sobre o tipo de backup que
desejam. No entanto, se o cliente solicitar, você precisará recomendar que tipo de
backups eles podem fazer, com base nas informações coletadas.

Tipos de Backup Quando

se fala em backups de banco de dados, e os backups no PostgreSQL?
Existem duas abordagens fundamentalmente diferentes para fazer backup de
bancos de dados PostgreSQL:

Backups lógicos
Backups físicos

Backups lógicos Os
backups lógicos também são conhecidos como dumps SQL. PostgreSQL tem
“pg_dump” através do qual você pode fazer um backup lógico. Aqui estão algumas opções
usando pg_dump:
Como “pg_dump” é um dos métodos mais conhecidos para fazer backup do
PostgreSQL e fácil de usar, as pessoas podem decidir usá-lo para sua solução de backup. Ele
permite que você faça algumas coisas legais, como usar um formato personalizado - você pode
fazer compactação em paralelo, fazer apenas dados ou apenas esquema e escolher exatamente
as coisas que deseja. Então, pg_dump é incrível de várias maneiras, mas tem algumas
limitações:
Machine Translated by Google

Muito lento para restaurar

Muita sobrecarga
Não PITR

No entanto, hoje em dia, o pg_dump realmente não é uma solução de backup. Ele
tem muitos casos de uso, mas o backup não é um deles, a menos que seu banco de dados
seja muito pequeno (menos de alguns GB). Mesmo que seu banco de dados seja muito
pequeno, provavelmente não é a solução certa devido às limitações explicadas anteriormente.

Usar o pg_dump é muito simples, mas geralmente leva muito tempo para fazer o
cópia de segurança. Isso geralmente é bom, mas o verdadeiro problema é que leva
muito tempo para restaurar porque o pg_dump recriará suas tabelas e, em seguida,
reconstruirá todos os seus índices. Portanto, se você estiver usando um backup baseado em
pg-dump por algum motivo, certifique-se de testá-lo ao longo do tempo para ver quanto tempo
de restauração será. Há muita sobrecarga e, mesmo em bancos de dados pequenos, o
problema é que você não pode fazer PITR.
Para mais detalhes sobre pg_dump e pg_dumpall, acesse: www.postgresql.org/
docs/current/app-pgdump.html e www.postgresql.org/docs/current/app-pg dumpall.html.

Como fazer backups lógicos

Vejamos alguns exemplos aqui:

Para fazer o dump de um cluster inteiro:

pg_dumpall -p porta > $backup_location/

dumpall.sql

Onde -p é a porta do cluster.

Para fazer o dump de um banco de dados (use pg_dump para isso)
Formato simples:

pg_dump -p port -U user_name db_name > $backup_location/

dump_postgres_db.sql

Formato compactado:
Machine Translated by Google

pg_dump -p port -U user_name dbname -Fc -f $backup_location/dump.dmp

Onde -p – porta
-U - usuário

-Fc – Formato compactado (você pode usar tar usando -Ft) -f

– dumpfile.

Para fazer o dump de uma tabela/sequência:

pg_dump -p porta -U user_name -t table_name db_name > $backup_location/

dump_test_table.sql

Onde -t - tablename/sequencename

Backups físicos Se
você está planejando fazer backups, deve pensar em fazer backups físicos. Esses
backups são chamados de backups básicos:
Restauração rápida

Somente cluster completo

Específico da plataforma

As maiores vantagens do backup físico são que ele é rápido para restaurar e você
pode fazer PITR. Você só pode fazer backup de tudo. Você não pode fazer backup de um
banco de dados individual ou de uma tabela ou esquema individual. É específico da plataforma.
Você pode fazer um dump ou backup em um sistema de 64 bits e restaurá-lo em um de 32
bits. Mas você não pode alternar de 32 bits para 64 bits.

Como fazer um backup básico

Vamos começar com um script de exemplo que muitas pessoas usam para fazer um
backup básico:

#!/bin/bash set -e
psql -U postgres -q
"SELECT pg_start_backup('foo')" # 'foo' é um
rótulo que
Machine Translated by Google

identifica este backup. tar cfz /backup/$

(date +%Y%m%d).tar.gz /var/lib/pgsql/data psql -U postgres -q
"SELECT pg_stop_backup()"

Este é um procedimento tradicional que é usado para fazer o backup. Então,

inicia o backup usando a função pg_start_backup o diretório de dados , ele copia
para um local de backup e, em seguida, interrompe o backup usando a função
pg_stop_backup . No entanto, o erroo mais
comando
comum
tar éfalha
a verificação
em algumdemomento:
erros. Quando

Ele será abortado, deixando seu sistema no modo de backup e você não poderá
fazer outro backup.
Você realmente não quer que seu sistema falhe agora, porque deixou coisas (arquivo
backup_label) no diretório de dados que tornarão seu sistema incapaz de iniciar se
ele travar.

Há tantas maneiras de fazer isso errado; esta costumava ser a única maneira,
mas existem muitos scripts por aí que as pessoas usam que fazem isso.
Para superar isso, o PostgreSQL disponibiliza a ferramenta pg_basebackup, que
basicamente faz esses backups básicos da mesma forma que o procedimento
tradicional, mas ao invés de você executar comandos, ele roda apenas como um
cliente PostgreSQL.
Se você precisar de um backup simples do PostgreSQL sem fazer nenhuma
configuração e não quiser adicionar muita complexidade, use a ferramenta pg_basebackup.
Além disso, se você estiver fazendo pg_dump para suas soluções de backup, você deve
realmente olhar apenas para mudar para pg_basebackup. Aqui está um script simples:

#!/bin/bash
set -e
pg_basebackup -D /backup/$(data +%Y%m%d) -Ft -X busca

-X inclui os WALs necessários no backup. "buscar" indica que os WALs são

coletados no final do backup.

Você só precisa fornecer um diretório para copiar os arquivos de backup e indicar

qual formato você deseja.
Machine Translated by Google

No entanto, para fazer isso funcionar, você precisa ter a replicação habilitada no
arquivo hba. Você deve ter uma linha como esta:

peer postgres de replicação local

E os seguintes parâmetros no arquivo postgresql.conf:

wal_level = hot_standby max_wal_senders

= 10

Se você estiver no PostgreSQL 10 ou anterior, precisará definir os parâmetros

anteriores. Caso contrário, mais recente que 10, o valor padrão de wal_level é replica e
max_wal_senders é 10. “max_wal_senders” é o mesmo que max connections, apenas para
conexões de replicação.

Formatos de Backup
O pg_basebackup pode gravar seus backups em dois formatos diferentes:

avião

Cópia segura do diretório de dados

Não é bom com vários espaços de tabela

alcatrão

Destino ainda é um diretório

Cada tablespace recebe um arquivo

Ele pode usar o formato simples, caso em que basicamente seu backup será uma cópia
que se parece exatamente com seu diretório de dados com todos os subdiretórios e todos os
arquivos. No entanto, isso é feito de maneira segura, portanto, na verdade, será um diretório de
dados consistente no final, junto com o log de transações.
Simples funciona bem se você tiver um tablespace. Se você tiver vários tablespaces,
por padrão, ele terá que gravar todos os tablespaces no mesmo local em que já estão, o que
obviamente só funciona se você estiver fazendo isso pela rede. Em versões recentes, você pode
remapear seus tablespaces para locais diferentes, mas rapidamente se torna muito complicado
usar o formato simples se você tiver vários tablespaces. O outro formato para pg_basebackup é
tar, neste caso o destino ainda é um diretório e você colocará arquivos tar nesse diretório. Seu
tablespace raiz estará em um arquivo chamado base.tar ou, se você estiver fazendo compressão,
será base.tar.gz e então
Machine Translated by Google

haverá um arquivo tar para cada tablespace. Portanto, de muitas maneiras, é

mais fácil lidar com cenários em que você tem mais de um tablespace.
Sempre use -x ou -X (usar -x é equivalente a -X fetch) para incluir arquivos WAL
no backup. Você pode usar o seguinte comando:

$ pg_basebackup -x -D /path/to/backupdir

O pg_basebackup também pode suportar backups compactados. Ele usa padrão

compressão gzip. Você pode usar a opção “-Z” para isso. Uma coisa a lembrar
é que se você usar -Z, a compactação é feita pelo pg_basebackup e não pelo
PostgreSQL. Portanto, se você executar o pg-basebackup na rede para o PostgreSQL,
os dados serão enviados descompactados do PostgreSQL para o pg_basebackup e
depois compactados e gravados no disco

Nota A compactação é suportada apenas para o formato tar e a

compactação é vinculada à CPU.

O que precisa ser feito backup?

Para realmente usar um backup básico, o que você precisa?
Você precisa de todos os logs de transações (WALs) gerados em seu sistema
desde o início do backup até o final do backup. O PostgreSQL basicamente pega
uma cópia inconsistente do seu diretório de dados e então usa o log de transações
para torná-lo consistente. Portanto, se você não tiver o log de transações, não é um
backup consistente, o que significa que você não possui um backup válido.

pg_receivexlog/ pg_receivewal
Uma maneira recomendada de configurar o backup WAL é usar a
ferramenta interna do PostgreSQL chamada pg_receivexlog (que é pg_receivewal
do PostgreSQL 10). É muito mais fácil de configurar do que o seu archive_command.
Você pode executá-lo em seu servidor de arquivamento, mas não arquive na
mesma máquina em que seu banco de dados está. Se você perder a máquina principal,
perderá os backups e os primários.
Se você executar o pg_receivexlog, ele se conectará ao PostgreSQL
pelo protocolo de replicação. É basicamente um standby de replicação do PostgreSQL
sem o PostgreSQL e regenera o arquivo de log com base nos dados de replicação em
seu servidor de arquivamento. Dá-lhe uma recuperação mais granular. Com um
Machine Translated by Google

comando archive, os dados são enviados em blocos de 16 megabytes; mas com

pg_receivexlog, eles são enviados em pedaços, pois ele usa o protocolo de streaming
para transmitir os WALs. Portanto, não é necessário esperar que o segmento WAL
seja concluído. É seguro contra reinicializações do servidor. Se o seu servidor for
reinicializado no meio da execução do comando arquivado - como o comando cp está
sendo executado, mas não foi concluído e, em seguida, o servidor foi reinicializado -,
pode ocorrer perda ou corrupção de dados. O pg_receivexlog pode cuidar disso, pois
pode seguir as opções da linha do tempo no mestre.
Sempre use pg_receivexlog junto com um slot de replicação para
que nenhum xlog seja removido antes do backup. O slot de replicação
garante que nenhum WAL seja removido do primário até que seja recebido
por todos os standbys. Mais informações estão disponíveis em:
www.postgresql.org/docs/current/warm standby.html#STREAMING-
REPLICATION-SLOTS.

pg_receivewal -D /log/archive -h master -S backup

-S é para slot de replicação.

Retenção de backup
A próxima pergunta que as pessoas acabam fazendo após a configuração do backup é “E
quanto à retenção de backup? Por quanto tempo vou manter meus backups?” A melhor
maneira de obter respostas para essas perguntas é entrar em contato com o cliente. Se
eles quiserem uma retenção de 10 anos, tudo bem, mas precisa de muito espaço, e se
eles quiserem restaurar, levará muito tempo. Se os clientes puderem criar uma estratégia
sobre até onde eles precisam voltar para qualquer situação, você poderá configurar a
retenção com base nela. Depois que isso for decidido, aqui está um script de exemplo para
remover seus backups com base na retenção:

#!/bin/bash find /
var/backups/basebackup -type f -mtime +30 - print0 | xargs -0 -r /bin/rm
find /var/backups/wal -type f -mtime +7 -print0 | xargs -0 -r /bin/rm

Portanto, neste exemplo, estamos excluindo todos os nossos backups básicos com
mais de 30 dias. Às vezes, talvez isso não seja a melhor coisa. Você pode querer manter
alguns backups mais antigos do que isso em seu servidor de teste ou copiá-los em fita.
Machine Translated by Google

E então estamos dizendo para excluir todo o log de transações no arquivo com mais de 7 dias.
Então, isso significa voltar uma semana, você pode restaurar usando PITR para uma transação
individual ou nível de microssegundo. Além disso, você pode restaurar com a granularidade de
1 dia até 30 dias; depois de chegar a esse ponto, você não pode mais restaurar.

Outras ferramentas de
backup Existem algumas ferramentas um pouco mais avançadas do que o
pg_basebackup pode fazer. São eles: pgBackRest Barman

Barman

A ferramenta Barman é desenvolvida pela empresa 2ndQuadrant e escrita em Python. As

características desta ferramenta são:

Agendamento de backup
Arquivamento de registros

Gerenciamento de retenção
Multiservidor
Restaurar atalhos

É licenciado gplv3. Você pode baixar aqui: https://github.com/

2ndquadrant-it/barman.
A documentação está disponível aqui:
http://docs.pgbarman.org/release/2.9/.
Ele usa principalmente SSH e rsync para transferir backups básicos e
registros de transações. É bem simples de configurar. Você pode passar pela
documentação para configurá-lo. No entanto, você precisa criar uma estratégia de backup antes
de configurá-la.

pgBackRest
pgBackRest é outra ferramenta de código aberto para configurar backups. Ele é construído pela
empresa CrunchyData e escrito em Perl. Os recursos desta ferramenta são: Agendamento de

backup Arquivamento de logs Gerenciamento de retenção Multiservidor

Machine Translated by Google

Restaurar atalhos
Validação obsessiva

Essa é uma lista bastante semelhante de recursos quando comparada com Barman.
Essas ferramentas resolvem o mesmo problema, portanto, a lista de recursos é semelhante. No
entanto, uma vez que você entra nos detalhes, as implementações são diferentes.
A documentação está disponível aqui: https://pgbackrest.org/.
É licenciado pelo MIT. Ele usa SSH, mas não usa rsync. Ele usa seu próprio protocolo
encapsulado em SSH. O protocolo é o ativador dos recursos que o pgBackRest possui e o
Barman não. Em particular, ele oferece suporte a sessões de backup paralelas para que você
possa expandir e fazer seus backups serem executados mais rapidamente. Para a maioria das
pessoas, backups de thread único não são realmente um problema. Mas se o seu banco de dados
for grande, poder fazer backups multithread pode economizar significativamente o tempo de
backup e também obviamente o tempo de restauração quando você estiver recuperando as
coisas, o que é mais importante.
Ele também suporta backups diferenciais e incrementais completos, e faz isso por
segmento. No PostgreSQL, temos todas as nossas tabelas divididas em segmentos de um
gigabyte, e backrest basicamente funciona como “se nada naquele gigabyte foi modificado,
então não preciso fazer backup novamente. Se mesmo um único byte foi modificado, copiarei
todo o segmento.” Porque se você realmente quiser olhar para cada bloco, levará muito tempo
para descobrir se algo mudou. Fazer isso em um gigabyte significa que se grandes partes do seu
banco de dados forem somente leitura, seus backups serão muito mais rápidos porque podemos
simplesmente pular isso e obtê-lo dos backups completos ou diferenciais anteriores.

Não suporta backups simultâneos

Restaure seu banco de dados Até

agora, falamos sobre os tipos de backup. Vejamos a restauração de backups de banco de

dados (lógicos e físicos).

Backups lógicos
Existem duas maneiras de restaurar um banco de dados PostgreSQL:

psql para restauração de um arquivo de script SQL simples criado com pg_dump
pg_restore para restauração de um arquivo .tar, diretório ou formato personalizado
criado com pg_dump
Machine Translated by Google

Restaurando um arquivo de
despejo simples É muito simples restaurar um arquivo de despejo simples gerado pelo
pg_dump. Você pode simplesmente usar o utilitário “psql” para isso. Segue um exemplo:

psql -d db -U usuário -p porta -h host -f dump_file.sql

Restaurando arquivos de despejo de formato

personalizado/ tar Você pode usar pg_restore para restaurar arquivos de despejo de
formato personalizado/tar. Segue um exemplo:

# restaurando um arquivo de formato personalizado

$ pg_restore -U db_user -d db_name_new -v -1 db_name.dmp

# restaura uma única tabela do dump $ pg_restore -U db_user

-d db_name_new -- table=mytable -v -1 db_name.dmp

# restaura uma única função do dump $ pg_restore -U db_user -d

db_name_new -- function=myfunc -v -1 db_name.dmp

onde db_user é o usuário do banco de dados, db_name é o banco de dados de destino

name e db_name.dmp é o nome do arquivo de backup.
Se você usa pg_restore, você tem várias opções disponíveis, por exemplo:

-c para descartar objetos de banco de dados antes de recriá-los

-C para criar um banco de dados antes de restaurá-lo -e sair se um erro for
encontrado
-F formato para especificar o formato do arquivo

Use “pg_restore -?” para obter a lista completa de opções disponíveis.

Restaurar backups físicos Se

for um backup offline que foi feito quando o banco de dados estava inativo, a
restauração é bastante simples. Você pode simplesmente copiar o diretório de backup para
Machine Translated by Google

o local onde você deseja que seu novo banco de dados de restauração seja executado e
descompacte e inicie a instância usando pg_ctl.

$ pg_ctl stop postgresql $ sudo rm -rf /

path/to/data/directory/* $ tar -xvC /path/to/data/directory -f /path/
to/dumpdir/base.tar.gz $ pg_ctl start postgresql

Recuperação pontual Para fazer

um PITR , você precisa
backup de um
completo e WALs gerados até o ponto de recuperação
desejado. Você só precisa copiar todos os seus arquivos para algum local e criar um
arquivo recovery.conf em um local de diretório de dados restaurado.

restore_command = 'cp /tmp/demo/archive/%f "%p"' recovery_target_time =

'2019-08-31 15:00:00'

O comando restore_especifica como buscar um arquivo WAL requerido pelo

PostgreSQL. É o inverso de archive_command. O recovery_target_time especifica
o tempo até precisarmos das alterações.
Todas as configurações de recuperação disponíveis estão aqui:

www.postgresql.org/docs/11/recovery-target settings.html.

Assim que o arquivo recovery.conf estiver pronto com o conteúdo anterior, você
pode iniciar o servidor usando pg_ctl.

pg_ctl -D /restored/data/directory start

Se for necessário aplicar arquivos compactados sobre o backup para recuperação,

você verá mensagens como as seguintes no arquivo de log:

LOG: arquivo de log restaurado "000000010000000300000022" do arquivo

LOG: arquivo de log restaurado "000000010000000300000023" do arquivo

LOG: arquivo de log restaurado "000000010000000300000024" do arquivo

Machine Translated by Google

Quando a recuperação estiver concluída, você poderá ver as seguintes mensagens:

LOG: estado de recuperação consistente alcançado em

0 / 40156B0
LOG: o sistema de banco de dados está pronto para aceitar conexões somente leitura

Agora você pode usar o banco de dados recuperado.

Projete uma estratégia de backup Agora é hora

de configurar uma estratégia de backup com base nas informações da seção anterior “Reunir
informações para configurar uma estratégia de backup”. Você pode projetar backups como:

Backups diários
Backups semanais
Backups mensais
Backups anuais

Você pode encontrar alguns scripts de backup para agendar backups automatizados aqui:
https://wiki.postgresql.org/wiki/Automated_Backup_ on_Linux.

Backups Diários
Com base nas informações coletadas, pode haver alguns bancos de dados que precisam de
backup todos os dias. Normalmente, os bancos de dados com o seguinte comportamento podem
precisar de um backup diário:

Bancos de dados que contêm informações de login dos usuários (de um site)
Bancos de dados críticos com tamanho pequeno

Backups semanais
Bancos de dados de tamanho médio se enquadram nesta categoria. Este é um tipo
muito comum de backup que um administrador prefere.

Backups Mensais Se você

tiver uma retenção de backup de alguns meses, é recomendável ter também uma política de
backup mensal. Desta forma, você pode evitar a restauração de
Machine Translated by Google

backup semanal, o que reduzirá o tempo de restauração.

Backup anual Muito

poucos bancos de dados precisam de uma política de backup anual. Se você tiver uma
retenção de backup de vários anos, isso é recomendado. Esses tipos de bancos de
dados podem conter dados históricos e são usados principalmente para fins de
arquivamento.

Monitorando Backups Não é suficiente

apenas adicionar cron jobs para backup; você precisa monitorá-los também!

Certifique-se de monitorar:

Se seus trabalhos de backup estão sendo concluídos com êxito

O tempo necessário para cada backup e fique de olho em como isso aumenta

Além disso, você também deve ter outro cron job que pegue um backup recente,
tente restaurá-lo em um banco de dados vazio e, em seguida, exclua o banco de dados. Isso
garante que seus backups sejam acessíveis e utilizáveis. Certifique-se de tentar restaurar nas
versões corretas do seu servidor PostgreSQL.
Você também deve monitorar essa tarefa cron de restauração, bem como o tempo
necessário para a restauração. O tempo de restauração tem um impacto direto em quanto
tempo levará até que você volte a ficar online após uma falha no banco de dados.

Resumo Neste
capítulo, falamos sobre quais informações você precisa para configurar uma estratégia de
backup e como configurar uma política de backup depois de obter as informações necessárias.
Também abordamos os tipos de backups (físicos e lógicos), como fazer um backup e como
restaurar os backups. O monitoramento do backup também é importante, conforme discutido.
No próximo capítulo, falaremos sobre a importância de registrar as atividades do banco de
dados e as melhores práticas para habilitar o registro. Também falaremos sobre o monitoramento
dos bancos de dados usando consultas de banco de dados e ferramentas externas.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_5

5. Habilite o registro de seu banco de dados e

o monitoramento de instâncias do PostgreSQL

Baji Shaik1
(1) Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre os estágios em que as informações podem ser coletadas para
configurar o backup/restauração de um banco de dados. Também falamos sobre os tipos de backup
e como restaurá-los quando necessário. Explicamos como você pode configurar uma estratégia de
backup para seus dados. Neste capítulo, falaremos sobre a importância de registrar seu banco de
dados e quais parâmetros devem ser considerados como parte do registro.
Também falaremos sobre quando registrar e como usar as informações registradas. Veremos quão
importante é o monitoramento de um banco de dados e quais fatores devem ser considerados ao
monitorá-lo. Também abordaremos algumas ferramentas de monitoramento disponíveis no mercado.

Por que/quando/como registrar Vamos

começar com o motivo pelo qual o registro é tão importante. Você pode estar se perguntando por
que você ainda quer logs. Pode haver muitos motivos para habilitar o registro:

Talvez você queira saber quando seu banco de dados foi reiniciado. Alguém fez isso e você
não estava ciente disso.
Descartou um objeto ou atualizou/excluiu alguns dados
Detectando consultas ineficientes

É sempre divertido e desafiador saber dessas coisas quando elas acontecem e

uma ótima maneira de descobrir isso é no seu log de atividades do PostgreSQL.
Logging tem vantagens e desvantagens. A vantagem é que você obtém muitas
informações, o que o ajuda a depurar os problemas. A desvantagem é que o registro pode realmente
deixar seu sistema mais lento, então isso é algo para se estar ciente e a se considerar.

Parâmetros a serem definidos para registro

Machine Translated by Google

Existem muitos parâmetros diferentes no arquivo de configuração do PostgreSQL (postgresql.conf), e

a seguir estão alguns parâmetros importantes que precisam ser considerados para definir o log:

log_min_duration_statement
log_line_prefix log_checkpoints
log_connections log_disconnections
log_lock_waits log_temp_files
log_autovacuum_min_duration

Nota O parâmetro logging_collector deve ser habilitado para registrar qualquer coisa
nos arquivos de log do banco de dados.

log_min_duration_statement Esse
parâmetro faz com que cada instrução executada por pelo menos o número especificado de milissegundos
seja registrada. No entanto, definir esse parâmetro para um valor mais baixo faz com que mais instruções sejam
registradas, potencialmente resultando em arquivos de log muito grandes e aumentando a quantidade de
atividade de gravação no servidor. A principal vantagem de configurar esse parâmetro é identificar consultas
lentas que exigiriam otimização e geralmente é definido em um valor acima do qual as consultas seriam
consideradas inaceitavelmente lentas.

Este parâmetro é o que realmente permite que você obtenha as informações que você precisa em
o arquivo de log para algo como pgBadger (é uma ferramenta de análise de log que fornece relatórios e
gráficos detalhados) ou até mesmo algumas das outras ferramentas. Essas ferramentas permitem que você
analise essas consultas e as agrupe, fornecendo as informações estatísticas que você está procurando. Defini-lo
como zero significa que você registrará todas as instruções enviadas ao PostgreSQL. Se você quiser definir um
pouco menos agressivo do que isso, você pode definir o número acima de 0; o número está em milissegundos
por padrão. Você pode ver a duração e a instrução na mesma linha de log da seguinte maneira:

LOG: duração: 2008,448 ms declaração: selecione pg_sleep(2);

Você verá a linha de log anterior nos arquivos de log no diretório $PGDATA/pg_log (no PostgreSQL 9.6 ou
anterior) ou $PGDATA/log (no PostgreSQL 10 ou posterior).
Isso é realmente importante para ferramentas de análise de log. Se você estiver usando a instrução de log e
duração do log, você acaba com aqueles em duas linhas diferentes, o que se torna muito mais difícil de
analisar.
Machine Translated by Google

Observação Se você definir esse parâmetro como 0, ele gerará um log de arquivos de log se você tiver
um banco de dados ocupado (onde muitas consultas são enviadas ao banco de dados). Verifique se
você tem espaço em disco suficiente para arquivos de log e uma retenção para limpar arquivos de log
desnecessários.

log_line_prefix Ao
ler os logs, é essencial saber exatamente quando ocorreu uma consulta, ação ou erro, em qual
banco de dados ocorreu, qual usuário a chamou e quais instruções a precederam na mesma
transação. Por esse motivo, log_line_prefix deve ser configurado corretamente para que essas
informações estejam disponíveis.
O valor recomendado para este parâmetro é '%t [%p]: [%l-1]
query=%u,user=%u,db=%d,app=%a,client=%h '.

%a Nome do aplicativo

%u Nome de usuário

%d nome do banco de dados

%r Nome do host remoto ou endereço IP e porta remota

%h Nome de host remoto ou endereço IP

%p ID do processo

%t Carimbo de hora sem milissegundos

%m carimbo de hora com milissegundos

Tag de comando %i: tipo de comando atual da sessão

%e código de erro SQLSTATE

%c ID da sessão

%l Número da linha de log para cada sessão ou processo, começando em 1

%s Carimbo de hora de início do processo

%v ID da transação virtual (backendID/localXID)

%x ID de transação (0 se nenhum for atribuído)

%q Não produz saída, mas diz aos processos que não são de sessão para parar neste ponto da string; ignorado pela sessão
processos

%% Literal %

Ele é essencialmente extraído exatamente do que o pgBadger está procurando por

padrão, o que eu acho ser um prefixo de linha de log muito bom. Você pode personalizá-lo se
quiser, e o pg badger na verdade permite duas opções para configurá-lo para qualquer configuração
para que ele saiba que tipo de prefixo de linha de log você possui.

03/12/2019 10:13:41 IST[46369]:[7-1]

Machine Translated by Google

query=postgres,user=postgres,db=postgres,app=psql,client= [local] LOG: duração: 2000,434 ms

instrução: selecione pg_sleep(2);

Na linha anterior, temos o timestamp (2019-12-03 10:13:41 IST); isto é

realmente importante para poder fazer uma análise ao longo do tempo de quando uma consulta foi executada.
Sessão de ID de processo e número de linha ([46369]: [7-1]) são bastante simples. O usuário logado
(user=postgres) é na verdade o usuário que logou no banco de dados; se você alterar o usuário
usando algo como set role, isso não será atualizado. Ele ainda será o usuário que estava logado
como. Então, isso é algo para estar ciente quando você estiver usando isso. O banco de dados que
foi conectado é db=postgres e app=psql é o nome do aplicativo, se definido. Portanto, muitas pessoas
podem não estar cientes de que temos essa capacidade de ter o nome do aplicativo. Se você estiver
usando o terminal psql, ele será definido como “psql” ou se for pgAdmin, ele será definido como
“pgAdmin”. Mas se você estiver escrevendo seu próprio código personalizado, você pode definir isso
essencialmente para o que quiser para cada conexão de banco de dados; que pode ser realmente
útil para dividir seu arquivo de log com base em quais aplicativos estão se conectando. Você pode
usar o parâmetro “application_name” para essa finalidade.

log_checkpoints Um
ponto de verificação é um processo de banco de dados que ocorre para sincronizar os blocos de
banco de dados no cache de buffer para arquivos de dados no disco. Durante um checkpoint, as
páginas sujas de shared_buffers serão gravadas no disco pelo gravador em segundo plano ou, a
partir do PostgreSQL 9.2, o processo do checkpointer.
Os pontos de verificação são muito perturbadores para o desempenho do banco de dados e podem causar
conexões param por até alguns segundos enquanto elas ocorrem. A partir do
PostgreSQL 8.3, você pode obter o log detalhado do processo de checkpoint ativando
log_checkpoints:

2019-12-03 10:16:32 IST [46135]: [6-1] query=,user=,db=,app=,client=

LOG: checkpoint completo: escreveu 64 buffers (0,4%); 0 arquivo(s) WAL adicionados, 0 removidos,
0 reciclados; gravação=0,002 s, sincronização=0,002 s, total=0,008 s; arquivos de sincronização=16,
mais longos=0,000 s, média=0,000 s; distância=711 kB, estimativa=711 kB

log_checkpoints vai nos contar todas as informações sobre quando um checkpoint

começou, por que começou, quanto tempo durou e um monte de outras informações estatísticas
realmente úteis que ferramentas como o pgBadger podem coletar e fornecer informações a você.
Você pode entrar em um lugar onde as pessoas estão reclamando que as consultas lentas estão
acontecendo – como a cada dois minutos ou a cada poucos minutos. Aquilo é
Machine Translated by Google

provavelmente porque a cada poucos minutos um ponto de verificação é iniciado e gravamos

todos os dados no disco. Enquanto estamos gravando todos os dados, todo o sistema acaba
ficando lento ou as consultas ficam mais lentas, então isso é algo a se procurar. Às vezes, você
pode correlacionar isso entre quando os pontos de verificação estão acontecendo e quando as
consultas estão acontecendo, o que é uma informação realmente útil

log_connections e log_disconnections Esta é uma

informação de registro de conexão direta, apenas registrando as conexões e desconexões. É
bastante simples: muito importante e muito útil, mas não muito complicado.

Ativando esses parâmetros, você acaba com três entradas de log:

03/12/2019 10:17:47 IST [46595]: [1-1] query=

[unknown],user=[unknown],db=[unknown],app= [unknown],client=[local] LOG :
conexão recebida: host= [local]

03/12/2019 10:17:47 IST [46595]: [2-1]

query=postgres,user=postgres,db=postgres,app= [desconhecido],client=[local]
LOG: conexão autorizada: user= banco de dados postgres = postgres

03/12/2019 10:18:33 IST [46595]: [3-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] LOG: desconexão: hora da
sessão: 0: 00:45.725 user=postgres database=postgres host=[local]

Você obtém uma entrada de conexão recebida e, em seguida, obtém a autenticação real
informações quando a conexão foi autorizada e, em seguida, você obtém uma
desconexão. Portanto, isso pode ajudá-lo a analisar por quanto tempo as conexões foram feitas
com o banco de dados; em particular, se você tiver muitas conexões de curta duração, isso
geralmente é uma coisa ruim. Na verdade, você deseja usar um pool de conexões. Mais sobre o
pool de conexões é abordado no Capítulo 7.

log_lock_waits O
registro de log_lock_waits é outro realmente importante que as pessoas nem sempre percebem.
Sua consulta fica lenta porque pode estar aguardando um bloqueio em uma tabela ou linha.
Isso acontece o tempo todo e as pessoas não sabem disso. Se você ativar log_lock_waits, após
um segundo o PostgreSQL faz algo chamado verificação de deadlock. Ele executará essa rotina
de verificação de deadlock, que verifica se há algum deadlock entre as consultas existentes que
estão em execução. Ele registrará linhas como as seguintes:
Machine Translated by Google

2019-12-03 10:21:46 IST [46729]: [4-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] LOG:
processo 46729 ainda aguardando o ShareLock ativado transação 573 após
1000,186 ms

2019-12-03 10:21:46 IST [46729]: [5-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] DETAIL:
Process holding the lock: 46705. Fila de espera: 46729.

2019-12-03 10:21:46 IST [46729]: [6-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] CONTEXT:
ao atualizar tupla (0,1 ) em relação "lock_test"

2019-12-03 10:21:46 IST [46729]: [7-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local]
STATEMENT: update lock_test set id=4;

A primeira linha está dizendo que o processo 46729 ainda está esperando por esse sharelock
na transação 573. Depois de esperar por uma segunda ocorrência de tempo limite de deadlock,
executamos o verificador de deadlock e descobrimos que estamos aguardando um bloqueio.
Também sabemos o que está segurando esse cadeado. Então, o processo 46705 está segurando
o bloqueio que precisamos. Também temos as informações sobre que tipo de bloqueio estamos
esperando. Esta é uma informação muito útil para fazer análises de deadlock e lock; se você não ,
tiver isso ativado, é definitivamente recomendável habilitá-lo.

log_temp_files Este
parâmetro é para registrar as informações sobre arquivos temporários. Sempre que você cria arquivos
temporários, isso significa que o banco de dados precisa fazer alguma quantidade de E/S de disco.

2019-12-03 10:27:35 IST [46729]: [26-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] LOG:
duração: 9,927 ms instrução: selecione * do pedido temp_test por id;

2019-12-03 10:27:40 IST [46729]: [27-1]

query=postgres,user=postgres,db=postgres,app=psql,client= [local] LOG:
arquivo temporário: path "base/ pgsql_tmp/pgsql_tmp46729.1", tamanho
147456
Machine Translated by Google

No caso anterior, você pode ver que a consulta executada é “select ÿ from temp_test
ordem por id;”. Então, o que aconteceu é que estamos fazendo uma ordenação e está usando um arquivo
temporário para fazer essa ordenação. Isso tende a ser caro porque significa que você está indo para o
disco para fazer uma classificação. Você pode detectar isso e perceber isso registrando esses arquivos
temporários que o PostgreSQL cria. Você apenas define os arquivos temporários de log iguais a 0 e, então,
toda vez que o PostgreSQL cria um arquivo temporário quando está tentando executar uma consulta para
qualquer coisa, ele registrará informações sobre qual era a consulta. Isso pode ser realmente útil para
descobrir o motivo por trás das consultas lentas que geram muitos arquivos temporários.

log_autovacuum_min_duration Outra
coisa que as pessoas costumam reclamar é “o autovacuum está rodando e está aspirando as
coisas e está matando meu sistema e eu quero pará-lo”. Nunca faça isso, para começar. Isso se
torna um problema real porque você acaba com muito inchaço. Abordaremos mais sobre inchaço/
vácuo no Capítulo 6.
Se você definir log_autovacuum_min_duration como zero, poderá ver uma linha como a seguinte
quando o autovacuum ocorrer em uma tabela:

2019-12-03 10:30:28 IST [47078]: [1-1] query=,user=,db=,app=,client=

LOG: vácuo automático da tabela "postgres.public.autovac_test": verificações de índice : 0
páginas: 45 removidas, 0 restantes, 0 ignoradas devido a

pinos, 0 ignorados congelados

tuplas: 10.000 removidas, 0 restantes, 0 mortas, mas ainda não removíveis, xmin
mais antigo: 577 uso de buffer: 161 acertos, 0 erros, 4 sujos taxa média de leitura: 0,000 MB/s,
taxa média de gravação: 6,793

MB/s
uso do sistema: CPU: usuário: 0,00 s, sistema: 0,00 s, decorrido: 0,00 s

Você pode ver tudo o que o VACUUM está fazendo em todas as mesas todas as vezes,
e você obtém todas essas informações maravilhosas, como quantas tuplas mortas foram
encontradas, quantas foram capazes de marcar como completamente removidas e quantas
estão mortas, mas não removíveis.

Monitoramento de bancos de dados O

registro em log é uma coisa fundamental para o monitoramento. Muitas ferramentas de monitoramento
dependem das informações de registro para monitoramento. O monitoramento ajuda você a identificar
problemas de forma proativa e resolvê-los antes que eles realmente aconteçam.
Machine Translated by Google

Mais do que como monitorar, aprenderemos o que monitorar neste capítulo. o

a intenção é que existam muitas ferramentas disponíveis no mercado com documentação detalhada de

como utilizá-las; no entanto, é importante saber o que monitorar primeiro. Então, vamos discutir:

Níveis de monitoramento
Monitoramento do nível do SO
Monitoramento de nível de banco de dados

Ferramentas de monitoramento/relatório disponíveis

Níveis de Monitoramento
Você não pode simplesmente monitorar tudo o tempo todo, então existem vários níveis de monitoramento:

Todo minuto
A cada 5 minutos
Toda hora
A cada 6 horas
Diariamente uma vez

Semanalmente uma vez

Portanto, alguns valores de alguns recursos que você pode monitorar diariamente uma vez ou semanalmente
também são bons. Mas algumas coisas, como número de sessões de banco de dados ou carga por sessão, você
gostaria de monitorar a cada minuto ou 5 minutos. Isso ajudará sua depuração em caso de problemas de banco de
dados. Se você deseja depurar qual sessão ontem às 5 horas estava consumindo mais CPU e RAM e o que estava
sendo executado, esses dados históricos específicos devem estar presentes. Sem os dados históricos, você não pode
entender ou depurar quais sessões ou consultas são afetadas pela sessão e quantas sessões são afetadas. Portanto,
esses parâmetros devem ser capturados a cada minuto ou 5 minutos.

No entanto, se você capturar cada minuto, terá mais dados em seu sistema de monitoramento. Isso
afetará a quantidade de dados necessários no sistema de monitoramento para capturá-los e armazená-los. Portanto,
geralmente dependendo do espaço de armazenamento em sua ferramenta de monitoramento, decida se é 1 ou 5
minutos e avance a partir daí.

Monitoramento no nível do

sistema operacional Você deve ter monitoramento no nível do sistema operacional, pois às vezes o motivo por trás da
lentidão de um banco de dados é o hardware do sistema operacional ou a utilização de recursos. Então, o que deve ser
monitorado no nível do sistema operacional? E como deve ser monitorado?

CPU

Memória (RAM/SWAP)
IO
Machine Translated by Google

Rede

Sistema de arquivo

Você pode monitorar todas as métricas relacionadas a hardware por meio do comando “sar”, conforme
explicado na subseção “sar” da seção “Ferramentas de Monitoramento/Relatórios” mais adiante neste capítulo.

CPU

Ao monitorar a utilização da CPU, você deve observar o tempo ocioso, o uso da CPU do usuário, o quanto
o sistema está usando, o uso total da CPU e quantas alternâncias de contexto da CPU. Se houver mais
alternâncias de contexto, é provável que você não tenha núcleos suficientes para lidar com seus processos.

Memória
Fique de olho na RAM e no uso de swap. Se a troca estiver sendo usada, monitore quantos swap-ins ou
swap-outs estão acontecendo e page-ins ou page-outs estão acontecendo. Isso ajuda a saber se a memória é
suficiente ou se você precisa adicionar memória adicional.

IO

Você deve monitorar suas operações de entrada/saída por segundo (IOPS). Ele informa quanta leitura/
gravação está acontecendo com seu disco rígido, o que ajuda a saber se seu aplicativo é mais intensivo em
leitura/gravação. Se houver mais leituras, seu sistema está lento porque a quantidade de dados solicitados é
alta. Você precisa monitorar o IO para saber essas informações.

Você saberia então que o sistema que possui é suficiente para suportar o IOPS necessário ou precisa
de atualização.

Rede

Monitore a rede para ver quantos dados estão entrando e saindo. Se o usuário estiver solicitando
grandes volumes de dados entrando e saindo do sistema, sua rede pode travar.
Você precisa monitorar quanta entrada e saída de rede está acontecendo para que você possa alocar a
largura de banda da rede de acordo.

Sistema de
arquivos Monitore o uso do espaço do sistema de arquivos para evitar problemas de inatividade do banco de
dados quando ele estiver cheio. Isso é monitoramento proativo. Você pode definir um alarme em 70% ou 80%
cheio e quando o alarme disparar, você pode adicionar mais armazenamento ou remover coisas desnecessárias
do sistema de arquivos.

Monitoramento de nível de banco de dados

Machine Translated by Google

Então, vamos falar sobre o que deve ser monitorado no nível do banco de dados. Vamos diferenciar com base na frequência
de monitoramento.

Monitoramento frequente
As seguintes informações do banco de dados precisam de monitoramento frequente a cada minuto ou 5 minutos:

Sessão ativa
Sessão inativa

Consulta de longa duração (tempo de execução da consulta de sessão)

Fechaduras

Sessões de espera
Consultas SQL sendo executadas
CPU e memória ocupada por cada sessão
Número de conexões

Atraso primário/em espera

Quaisquer erros nos registros

Base diária ou semanal

Outras informações relacionadas ao banco de dados que podem ser monitoradas diariamente ou semanalmente são:

Tamanho do banco de dados

Tamanho do espaço de tabela

Tamanho do objeto (tabela/índice)

Último vácuo/autovácuo
Última análise/análise automática
Inchaço na tabela/índices
Número de pontos de verificação
Número de arquivos wal gerados

É muito importante monitorar a frequência com que seu banco de dados/espaço de tabela/objetos está crescendo.
Isso ajuda no planejamento de capacidade, como quantos dados aumentarão nos próximos anos. Se você tem esses dados,
você pode planejar para isso. Se você estiver monitorando por meio de uma ferramenta, selecione uma ferramenta que tenha
o recurso de monitorá-la.
Monitore com que frequência o VACUUM está sendo executado e quando foi a última execução de
vácuo/análise. Com base nisso, você pode certificar-se de que as configurações atuais do autovacuum são suficientes ou
você pode reconfigurar o autovacuum ou analisar as configurações. Ajuda na melhoria do desempenho.

Monitorar o inchaço ajuda a remover o inchaço na tabela/índice e melhorar o desempenho. Outra vantagem
é que você pode remover espaço se perceber que o tamanho do objeto é enorme devido ao inchaço.
Machine Translated by Google

Pontos de verificação frequentes afetam o desempenho. Se os pontos de verificação estiverem

ocorrendo em uma taxa alta, o problema seria carregar muitos dados ou muitas atualizações/exclusões.
Portanto, essas informações ajudam a investigar os problemas.
Se a carga de dados for grande, ela gerará muitos wals, o que significa muito IO e espaço. Assim,
você pode ajustar os parâmetros para reduzir a geração.

Ferramentas de monitoramento/relatório
Existem vários métodos de monitoramento de um sistema de produção que podem ser usados para
identificar problemas com a carga e a taxa de transferência do sistema. Existem muitas ferramentas de
código aberto ou corporativas disponíveis no mercado para monitoramento. As informações das
ferramentas estão disponíveis aqui: https://wiki.postgresql.org/wiki/Monitoring.
Aqui estão algumas ferramentas que você pode considerar usar. Não vamos cobrir todas as
ferramentas, mas algumas:

pgBadger
pgCluu
sar
pg_buffercache
Nagios
Zabbix
datadog

pgBadger
pgBadger é uma ferramenta de análise de log especificamente para PostgreSQL. Ele produz um relatório
detalhado da atividade no servidor de banco de dados (ou pelo menos a atividade que entra nos arquivos
de log), incluindo arquivos temporários, consultas lentas, operações VACUUM, conexões e muitos outros
conjuntos de informações. É sempre aconselhável usar a versão mais recente, pois ela conterá correções e
os recursos de análise mais recentes.
Ele pode ser baixado aqui: https://pgbadger.darold.net/.
Muitas vezes, é necessário habilitar vários parâmetros de log com antecedência para que os
relatórios contenham informações úteis. Estes são tipicamente:

logging_collector = em log_line_prefix =
'%t [%p]: [%l-1] user=%u,db=%d ' log_min_duration_statement = 2s log_checkpoints = em
log_connections = em log_disconnections = em log_lock_waits = em log_temp_files = 0
log_autovacuum_min_duration = 0
Machine Translated by Google

Não use os valores anteriores cegamente, mas ajuste cada configuração para ser apropriado
ao sistema do cliente. Definir certos parâmetros muito baixos (como
log_min_duration_statement) pode afetar negativamente o desempenho do banco de dados em um
sistema ativo devido a um volume muito alto de log.

pgCluu O
pgCluu monitora um cluster inteiro para métricas de desempenho, como utilização de CPU,
memória, swap, carga do sistema, número de processos, bloco de E/S, alterações no tamanho de
bancos de dados individuais, conexões de banco de dados, arquivos temporários e muitas outras
medidas. Ele pode ser baixado aqui: https://github.com/darold/pgcluu.

Ele vem em duas partes: o processo de coleta (pgcluu_collectd) e o relatório

ferramenta geradora (pgcluu).
O uso típico seria:

mkdir /tmp/stat_db/ pgcluu_collectd

-D -i 60 /tmp/stat_db/ -h localhost -d postgres

Isso começaria a coletar dados a cada 60 segundos. A coleta pararia com:

pgcluu_collectd -k

Você então geraria o relatório:

mkdir /tmp/report_db/ pgcluu -o /tmp/

report_db/ /tmp/stat_db/

Esse diretório conterá um relatório HTML que pode ser aberto no

navegador. Todos os arquivos nesse diretório serão necessários.

sar
sar (que significa Relatório de Atividade do Sistema) monitora a atividade da CPU, memória,
paginação, carga do dispositivo e atividade da rede. Ele está prontamente disponível (e
geralmente já em execução) na maioria das instalações Linux modernas por meio do pacote
sysstat; isso o torna muito útil para situações em que o cliente não tem o monitoramento
configurado ou não permite que você o acesse.
Descubra se o sar já está habilitado e em execução verificando os dados coletados em /var/
log/sa (CentOS) ou /var/log/sysstat (Ubuntu). Os arquivos saXX são dados binários; sarXX são
textos convertidos.
Verifique o ciclo de pesquisa observando o crontab apropriado em /etc/cron.d/sysstat.
O padrão é 10 minutos; determinar se isso é frequente o suficiente para seus propósitos.
Machine Translated by Google

Verifique se a coleta de estatísticas de disco está habilitada no arquivo de

configuração: /etc/sysconfig/sysstat (CentOS) ou /etc/default/sysstat (Ubuntu). Você deve encontrar
um parâmetro OPTIONS definido como “-S DISK”.
Se o sar já estiver em execução, você pode usar apenas as estatísticas já coletadas. Apenas
os arquivos de dados binários conterão a pesquisa mais recente; a conversão para texto acontece
apenas uma vez por dia, portanto, se você quiser estatísticas imediatas, precisará executar a conversão por
conta própria.
Se o sar não estiver em execução, você poderá coletar os dados manualmente:

sar [opções de estatísticas] -o [output_file] [intervalo de pesquisa em segundos] [número de

pesquisas]

Um exemplo é:

sar -A -o my_cool_stats 60 30

-A = coletar todas as
estatísticas -o = armazenar estatísticas neste arquivo (em
formato binário) 60 = coletar a cada 60 segundos 30 =
coletar 30 vezes

Observe que a opção -A gera cerca de 18 MB de dados por pesquisa; planeje o espaço
de acordo.
Você pode então usar o seguinte comando para gerar um relatório:

sar -A -f my_cool_stats > my_cool_stats.txt

Observe que a conversão de binário para texto deve ser executada em uma máquina com a
mesma arquitetura do coletor. Normalmente você fará a conversão na mesma máquina que fez a
coleta.
Aqui estão opções úteis, se você não quiser coletar todas as estatísticas com -A.

-b para estatísticas de E/S – pode ser útil no ajuste de checkpoint_completion_target e checkpoint_segments.

-
atividade por dispositivo de bloco; Pretty-imprima os nomes dos blocos (deve usar -S DISK ou -A ao coletar) você dp
REALMENTE quero muito imprimi-los

-n Estatísticas de rede “DEV,EDEV”, incluindo erros

-r memória

-S trocar

-u uso da CPU (ou -P “ALL” para uso da CPU por processo) – alta % de tempo do sistema pode indicar um problema com
Compactação transparente de página grande
-
mudança de contexto
dentro

- páginas trocadas - um pico aqui pode indicar ajuste de shared_buffers e work_mem/max_connections

Machine Translated by Google

W pode ser necessário

Como isso se parece:

sar -bdprSuwW -n "DEV,EDEV" -f my_cool_stats > my_cool_stats.txt

Os dados de texto podem ser analisados em uma planilha ou outras ferramentas gráficas.
Você também pode gerar um relatório gráfico diretamente dos dados binários usando as
ferramentas .isag, ksar Mais informações sobre a coleta e conversão de dados podem ser encontradas
no sar
páginas man.

pg_buffercache A
extensão pg_buffercache é útil para monitorar quais relações estão ocupando espaço na memória
compartilhada. Será necessário obter permissão do cliente antes de instalar qualquer extensão
como esta e, em muitos casos, pode não ser possível fazê-lo. Se você instalá-lo, ele só precisa
ser instalado em um banco de dados, que pode ser um que não seja usado para nenhum dado
de produção.
Armazenar os resultados da consulta que usa a visualização pg_buffercache fornecida por esta
extensão em um arquivo de texto pode revelar problemas de remoção de página de buffer. É aqui que
uma única consulta pode enviar todas as páginas usadas com frequência no cache, o que significa que
elas precisam ser carregadas novamente, resultando em períodos em que as consultas são executadas
mais lentamente. Se você fizer isso, certifique-se de produzir o carimbo de data/hora para ver se há alguma
correlação entre esses resultados e os do pgBadger.
Este é um exemplo, onde a consulta usada para coletar os dados do cache do buffer é colocada
em um arquivo em /tmp/pg_buffercache.sql. A consulta que usaremos é a seguinte:

SELECT now(), d.datname, c.relname, count(ÿ) AS buffers FROM pg_buffercache b INNER JOIN
pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)

INNER JOIN pg_database d

ON b.reldatabase = d.oid GROUP BY
d.datname, c.relname ORDER BY 4 DESC LIMIT 10;

Em seguida, chamamos o arquivo usando psql, solicitamos saída separada por vírgulas e anexamos o
resultados para um arquivo. Em sistemas de sistemas Unix/Linux, poderíamos então executar:

enquanto [verdadeiro]; do psql -AtX -F ',' -f /tmp/pg_buffercache.sql

postgres >>
Machine Translated by Google

/tmp/pg_buffercache.log;sleep 5;concluído

Isso produziria uma saída para buffers a cada 5 segundos .

Resumo Neste
capítulo, abordamos por que o registro é importante e como registrar e quais
informações registrar. Também falamos sobre o que considerar ao ativar os parâmetros
de registro e como usar as informações registradas. Cobrimos os procedimentos de
monitoramento, incluindo o que monitorar e com que frequência o monitoramento é
necessário. No próximo capítulo, falaremos sobre o que é bloat no banco de dados e
como ele pode ser removido. E abordaremos em detalhes quais são as melhores práticas
para executar atividades de manutenção como VACUUM e reindexar.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_6

6. Executar Manutenção

Baji Shaik1
(1) Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre a importância do registro e como/quando/o que registrar. Analisamos diferentes
parâmetros de registro e seus casos de uso. E abordamos o que deve ser monitorado no nível do sistema operacional
e do banco de dados e detalhes sobre algumas ferramentas de monitoramento. Neste capítulo, começaremos com o
conceito MVCC no PostgreSQL e continuaremos com as atividades de manutenção no PostgreSQL e como agendá-las
com base nas informações disponíveis. Também veremos como o autovacuum e o VACUUM funcionam no PostgreSQL
e como melhorar o desempenho do banco de dados. Também abordaremos outra importante atividade de manutenção
que é o REINDEX.

O que é o MVCC O

controle de simultaneidade multiversão (MVCC) é atualmente o esquema de gerenciamento de transações mais popular nos
modernos sistemas de gerenciamento de banco de dados (DBMSs). Embora o MVCC tenha sido projetado no final da década
de 1970, ele é usado em quase todos os principais SGBDs relacionais lançados na última década. A manutenção de várias
versões de dados aumenta potencialmente o paralelismo sem sacrificar a serialização ao processar transações.

MVCC no PostgreSQL Para

entender como o MVCC funciona ao processar transações em configurações de hardware modernas, precisamos entender quatro
decisões principais de design: protocolo de controle de simultaneidade, armazenamento de versão, coleta de lixo e gerenciamento de
índice. O protocolo de controle de simultaneidade fala sobre como as sessões simultâneas em um banco de dados podem ser
gerenciadas. É aqui que você vê diferentes níveis de transação. O armazenamento de versão está armazenando diferentes versões
de dados. O PostgreSQL armazena versões antigas e novas de dados em caso de atualização/exclusão. A coleta de lixo é um processo
para remover versões antigas de dados. O gerenciamento de índice é uma maneira de armazenar os dados de índice.
Aqui está um exemplo para entender o MVCC em termos práticos. Cada instrução que modifica o banco de dados
gera um ID de transação, que é representado por uma pseudocoluna xid dentro de cada tabela. E há algumas outras
pseudocolunas, xmin e xmax, que representam IDs de transação dependendo do status da linha.

Considere uma tabela “teste” com uma coluna. Agora veja o que acontece se uma linha for inserida:

postgres=# CREATE TABLE test(ID int);

CREATE TABLE
postgres=# INSERT INTO test VALUES(1);
INSERT 0 1
postgres=# SELECT xmin, xmax, id FROM test; xmin | xmax | Eu iria

---+------+----
1739 | (1 0|1
linha)

Assim, xmin representa o xid (ID da transação) através do qual a linha foi inserida e xmax é sempre 0 para
linhas visíveis. xmax > 0 representa uma linha expirada, que não é visível.
Machine Translated by Google

Existem alguns casos em que xmax > 0, mas ainda assim a linha é visível. É possível se você atualizar/excluir
algo em uma transação e é revertida.

Se a linha for excluída A linha

é excluída e uma versão dessa linha ainda aparece para manter o MVCC. Nesse cenário, para a linha excluída, xmin é o xid da
instrução INSERT por meio da qual a linha foi inserida e xmax se torna o xid da instrução DELETE por meio da qual a linha foi excluída.

Se a linha for atualizada no

PostgreSQL, UPDATE é considerado como DELETE + INSERT. A linha antiga é excluída e a nova linha é inserida. Ambas as linhas são
mantidas para cumprir o MVCC. Nesse cenário, para a linha antiga, xmin é o xid por meio do qual a linha foi inserida e xmax é o xid por meio
do qual a linha foi atualizada. Para a nova linha, xmin é o xid através do qual a linha foi atualizada e xmax é 0, pois a linha é visível.

A Figura 6-1 ilustra o comportamento do MVCC.

Figura 6-1 Comportamento do MVCC

Por que/como—atividades de manutenção A primeira pergunta

que vem à mente quando ouvimos falar de manutenção é “por que precisaríamos de manutenção?” Conforme explicado na seção “MVCC
no PostgreSQL”, o PostgreSQL usa diferentes versões de linha como parte do comportamento do MVCC. Assim, quando você DELETE ou
ATUALIZA uma tabela, ela cria duas versões de dados, em que uma é visível e a outra invisível. Essas linhas invisíveis, que chamamos de
“tuplas mortas” (também chamamos de inchaço de tabela/índice), precisam ser limpas. É aqui que precisamos de manutenção.

A próxima parte da pergunta é “como podemos fazer a manutenção?” VACUUM é um processo para limpar tuplas mortas.

Inchaço de tabela e índice

O inchaço de tabela e índice é causado por linhas excluídas ou atualizadas que não são VACUUMed. Isso significa que essas linhas
ocuparão espaço e não poderão ser reutilizadas até que sejam limpas. Esse estado pode fazer com que as tabelas aumentem de tamanho,
mesmo se apenas UPDATEs forem emitidos no banco de dados.
As causas disso são bloqueios mantidos por transações de longa duração (embora isso tenha sido atenuado um pouco
desde o PostgreSQL 8.4), ou a configuração de autovacuum para o banco de dados e/ou tabelas específicas não é agressiva o suficiente.
Machine Translated by Google

Uma consulta para obter o maior número de tabelas e índices está disponível no wiki do PostgreSQL: https://
wiki.postgresql.org/wiki/Show_database_bloat.
Se houver tabelas ou índices com mais de 10% de inchaço e onde o número de bytes desperdiçados for significativo (por exemplo,
200 MB), eles devem ser incluídos no relatório. Se houver um grande número para relatar, coloque-os em um arquivo de texto separado e faça
referência a esse arquivo no relatório, que deve ser fornecido ao cliente junto com o relatório final.

AUTOVACUUM/VACUUM Vamos falar um

pouco sobre AUTOVACUUM.

O que o autovacuum faz?

Como funciona o vácuo automático?

O que mais importante pode o daemon de autovacuum fazer

parâmetros de autovacuum Estratégias de VACUUM sobrecarga
de IO de autovacuum

O que o Autovacuum faz?

Bancos de dados modernos (clássicos) devem lidar com dois problemas fundamentais: Operações

simultâneas : Para isso podem usar transações.

Falhas : Para isso, eles podem se recuperar até a última transação bem-sucedida usando o WAL.

Para conviver com o primeiro problema, operações simultâneas, os bancos de dados geralmente implementam algum tipo de
algoritmo de escalonamento de simultaneidade e transações. O segundo problema são as falhas; se algo der errado, geralmente temos um algoritmo
WAL para PostgreSQL.
Tecnicamente, isso significa que há uma combinação de algoritmos de bloqueio e MVCC que fornece transações
Apoio, suporte. As informações de desfazer e refazer são armazenadas em algum lugar para possibilitar a recuperação. O PostgreSQL mantém o
redo como muitos outros bancos de dados no WAL, mas o desfazer é mantido um pouco não tradicional. Ele é mantido em arquivos de dados em si.
Por exemplo, o Oracle tem algumas informações de desfazer e segmentos especiais que são chamados de segmentos de desfazer, e o db2
armazena algumas informações de desfazer nas versões modernas do Linux.

Devido a esse tipo de mecanismo de desfazer, o PostgreSQL precisa lidar com o processo de coleta de lixo chamado VACUUM. Tuplas que não
são visíveis para nenhuma transação em execução devem ser removidas. Caso contrário, a fragmentação aumenta e você fica inchado.

VACUUM remove todas as páginas que não são visíveis para nenhuma transação em execução. Você precisa executar o VACUUM com muita
frequência para evitar inchaço. Caso contrário, você precisará de VACUUM FULL. Ele reconstrói a mesa, o que pode ser doloroso. Autovacuum
automatiza o processo de VACUUM.

Como funciona o Autovacuum?

Existem dois tipos diferentes de sistemas de autovacuum: o autovacuum launcher e o auotvacuum worker.
Vejamos como funciona o fluxo:

O lançador auotvacuum é um processo de execução contínua, iniciado pelo postmaster.

O lançador agenda os trabalhadores de autovacuum para iniciar quando necessário.
O processo do trabalhador auotvacuum é o processo real que faz a aspiração. Eles se conectam a um banco de dados determinado pelo iniciador
e, uma vez conectados, eles leem as tabelas do catálogo para selecionar uma tabela como candidata à limpeza.

Existe uma área de memória compartilhada de autovacuum, onde o launcher armazena informações sobre as tabelas em um banco de dados
que precisa de um VACUUM.

Quando o lançador de autovacuum deseja que um novo trabalhador inicie, ele define um sinalizador na memória compartilhada e envia um sinal ao
postmaster.
Em seguida, o postmaster inicia um trabalhador. Esse novo processo de trabalho se conecta à memória compartilhada e lê as informações na área
de memória compartilhada de autovacuum armazenada pelo processo iniciador e faz seu trabalho.

O que mais importante pode fazer o Autovacuum Daemon?

Além de aspirar, o autovacuum também:
Machine Translated by Google

Coleta estatísticas para o otimizador (autoanálise)

Executa o autovacuum de wraparound de transação

Parâmetros de Autovacuum
Basicamente, duas coisas que podem deixar os DBAs não tão felizes são ver um banco de dados com comutação automática de VACUUM
desligado ou autovacuum com configurações padrão. Existem muitas ideias sobre como melhorar o desempenho do
banco de dados, mas desligar o autovacuum definitivamente não é um deles. Nem sempre é recomendado sair
configurações de autovacuum em valores padrão.
Se o seu processo de autovacuum for executado por horas e interferir em alguma linguagem de definição de dados (DDL)
instruções como ALTER/TRUNCATE, simplesmente terminá-lo não é uma opção. só vai adiar o
VACUUM e o trabalho será acumulado. Especialmente para processamento de transações online (OLTP), autovacuum
deve ser configurado de forma suficientemente agressiva para que possa trabalhar com pequenas porções de dados rapidamente.
Se você vir as configurações do autovacuum, elas se parecem com isso:

postgres=# selecione nome, configuração, contexto de pg_settings onde categoria

~ 'Autovácuo';
nome | configuração | contexto
--------------------------+-----------+ ------------
autovacuum | em | suspirar
autovacuum_analyze_scale_factor | 0,1 | suspirar
autovacuum_analyze_threshold | 50 | suspirar
autovacuum_freeze_max_age | 200000000 | chefe dos correios
autovacuum_max_workers | 3 | chefe dos correios
autovacuum_multixact_freeze_max_age | 400000000 | chefe dos correios
autovacuum_naptime | 60 | , suspirar
autovacuum_vacuum_cost_delay 20 | , suspirar
autovacuum_vacuum_cost_limit -1 | , suspirar
autovacuum_vacuum_scale_factor 0,2 | 50 , suspirar
autovacuum_vacuum_threshold (11 linhas) , suspirar

vácuo automático

Isso quase sempre deve estar ativado, caso contrário, não ocorrerá autovacuuming no banco de dados e haverá
certamente precisa ser aplicado vácuos manuais de rotina.

autovacuum_max_workers
O padrão de 3 tende a ser muito baixo para qualquer coisa, exceto para pequenos sistemas de banco de dados. Isso provavelmente deve ser definido como
algo dentro do intervalo de 6 a 12, inclinando-se mais para o último se houver muitas tabelas com atualizações frequentes
ou elimina.

autovacuum_naptime
É o atraso mínimo entre as execuções de autovacuum. O padrão de 1 min pode ser suficiente para alguns sistemas, mas
nos mais ocupados com muitas gravações, pode ser benéfico aumentar isso para impedir que o autovacuum acorde com muita frequência.
Isso também deve ser aumentado em sistemas com muitos bancos de dados, pois essa configuração determina o tempo de ativação
por banco de dados. Um processo de trabalho de autovacuum começará com a mesma frequência que autovacuum_naptime / number of
bancos de dados.

Por exemplo, se autovacuum_naptime = 1 min (60 segundos) e houver 60 bancos de dados, um autovacuum
processo de trabalho seria iniciado a cada segundo (60 segundos / 60 bancos de dados = 1 segundo). No entanto, afinar este
configuração muito alta pode resultar em mais trabalho necessário a ser feito em cada ciclo de aspiração.

autovacuum_vacuum_threshold / autovacuum_analyze_threshold
Ambos determinam o número mínimo de linhas em uma tabela que precisam ser alteradas para que a tabela
a ser programado para um autovacuum e uma autoanálise, respectivamente. O padrão para ambos é 50, o que é muito
baixo para a maioria das mesas.
Machine Translated by Google

autovacuum_vacuum_scale_factor / autovacuum_analyze_scale_factor Ambos

determinam a porcentagem de uma tabela que precisa ser alterada para que a tabela seja agendada para um autovacuum e uma
autoanálise, respectivamente. O padrão para o autovacuum_vacuum_scale_factor é 0,2 (significando 20%) e o
autovacuum_analyze_scale_factor é 0,1 (significando 10%). Ambos os números são bons para tabelas de tamanho modesto (até
cerca de 500 MB), mas para tabelas maiores eles são muito altos. Se, por exemplo, houvesse uma tabela com 120 GB de
tamanho, 24 GB (20% de 120 GB) de tuplas mortas teriam que existir antes que elas pudessem começar a ser limpas, o que seria
muito trabalho de aspiração depois de entrar em ação No entanto, se as tabelas grandes estiverem em minoria no banco de
dados, é melhor definir esses parâmetros no nível da tabela e não no arquivo de configuração.

autovacuum_vacuum_cost_delay O
padrão é 20ms, o que é muito conservador e pode impedir que o VACUUM acompanhe as alterações.
Isso deve quase sempre ser diminuído, em muitos casos até 2 ms. Pode precisar ser testado com várias configurações para ver
o que é necessário para acompanhar.

Estratégias de VACUUM
É importante garantir que as tabelas sejam regularmente VACUUMed. A métrica inicial mais útil é garantir que todas as
tabelas tenham sido VACUUMed pelo menos uma vez a cada 7 dias (uma semana).
Embora esse número possa precisar ser ajustado para cima ou para baixo, é o melhor ponto de partida.

SELECT schemaname,
relname, now()
- last_autovacuum AS "noautovac", now() - last_vacuum AS
"novac", n_tup_upd, n_tup_del,
pg_size_pretty(pg_total_relation_size(schemaname||'.'||relname)),
autovacuum_count, last_autovacuum, vacuo_count , last_vacuum
FROM pg_stat_user_tables WHERE (now() - last_autovacuum > '7 days'::interval OR now() - last_vacuum >'7
days'::interval )

OR (last_autovacuum IS NULL AND last_vacuum IS NULL )

ORDEM POR novac DESC;

Esta lista fornecerá uma visão de todas as tabelas e suas necessidades de VACUUM. Se a lista retornar sem linhas, significa
que todas as tabelas foram VACUUMed nos últimos 7 dias. A lista de alvos gerada (se houver) deve ser priorizada pelo número
de atualizações e exclusões.

Aspiração manual
Uma maneira de lidar com essa lista de tabelas é executar manualmente o comando “VACUUM VERBOSE <table>” em
cada uma dessas tabelas. Isso executará um VACUUM sem aceleração da tabela e fornecerá estatísticas de saída.

Throttle VACUUM
Embora VACUUM não execute nenhuma operação de bloqueio/bloqueio, ele realiza uma varredura profunda de uma tabela; isso
pode causar um estresse adicional aos subsistemas de E/S (e armazenamento em cache). Se o impacto de VACUUM começar
a afetar o desempenho, você pode cancelar um VACUUM em execução por ctrl+c ou:

SELECT pid,
estado,
consulta
DE pg_stat_activity
WHERE consulta como '%VACUU%
Machine Translated by Google

E estado = 'ativo';

Pegue o PID que você encontrar e execute:

selecione pg_terminate_backend(pid);

A partir daqui, você pode acelerar o VACUUM definindo o parâmetro “vacuum_cost_delay” apenas na sua sessão:

postgres=# set vacuo_cost_delay=10; SET

postgres=# VACUUM VERBOSE pgbench_branches ;
INFO: aspirando "public.pgbench_branches"

INFO: índice "pgbench_branches_pkey" agora contém 10 versões de linha em 2 páginas DETALHE:

0 versões de linha de índice foram removidas. 0 páginas de índice foram excluídas, 0 são atualmente
reutilizáveis.
CPU 0,00s/0,00u seg decorridos 0,00 seg.
INFO: "pgbench_branches": encontrado 0 versões de linhas removíveis, 10 não removíveis em 1 de
DETAIL: 0 versões de linhas inativas ainda não podem ser removidas.
Havia 0 ponteiros de item não utilizados. 0
páginas estão totalmente vazias.
CPU 0,00s/0,00u seg decorridos 0,00 seg.
VACUUM
postgres=#

Você pode incrementar o atraso de custo em incrementos de 10 para aumentar a quantidade de aceleração que
deseja aplicar. É possível (mas não recomendado) alterar essa configuração globalmente. Definir isso como o anterior
afetará apenas sua sessão e será redefinido quando você fechar a conexão .

Cronograma

Para agendar este trabalho, o psql pode ser usado para executar um trabalho. Crie um arquivo SQL (por exemplo - vácuo.sql)

--set vacuo_cost_delay= VACUUM

VERBOSE ANALYZE tabela1; VACUUM
VERBOSE ANALYZE tabela2; VACUUM
VERBOSE ANALYZE tabela3; etc...

Então, ele pode ser executado usando psql de qualquer host:

psql -h <server_ip> -f vacuo.sql -U <user> -d <db> >> /log/vacuum.log Isso pode ser feito de forma
mais dinâmica. Crie um arquivo sql usando o seguinte comando (por exemplo, gen_vacuum_list.sql):

SELECT 'VACUUM VERBOSE ANALYZE '|| nome do esquema || '.' || relname ||';'
DE pg_stat_user_tables
WHERE (agora() - last_autovacuum > '7 dias'::interval
OR now() - last_vacuum >'7 days'::interval )
OR (last_autovacuum IS NULL AND last_vacuum IS NULL );

Despeje a saída em um arquivo e execute o resultado no banco de dados:

psql -h <server_ip> -f gen_vacuum_list.sql -U <user> -d <db> >> /tmp/vacuum_tables.sql

psql -h <server_ip> -f /tmp/vacuum_tables.sql -U <user> -d <db> >> /log/vacuum.log

Machine Translated by Google

E/ S de vácuo automático

Autovacuum tem seu próprio mecanismo para reduzir a sobrecarga de E/S.

Autovacuum atrasa autovacuum_naptime segundos e verifica se as tabelas precisam de um VACUUM. Ele é executado
VACUUM em uma tabela até que autovacuum_vacuum_cost_limit seja alcançado e, em seguida,
dorme: autovacuum_vacuum_cost_delay milissegundos.
Isso pode não ser um bom algoritmo, principalmente porque foi projetado para todo o hardware. Por exemplo, ele
não diferencia o IO lógico e físico. Portanto, pode ser IO do disco ou IO da memória compartilhada; comportamento de
autovacuum é o mesmo para esses mecanismos. Assim, os resultados podem ser confusos. Os SSDs modernos são
bastante rápidos. Assim, tais tipos de regulação externa de IO não são tão necessários para eles.
Se você tiver discos lentos, você pode realmente enganar um pouco aumentando a quantidade de autovacuum_workers.
Como o autovacuum tem três trabalhadores por padrão, eles começam a trabalhar com várias tabelas. Quando eles
estão limpando essas tabelas, na verdade o autovacuum_vacuum_scale_factor entra e provavelmente a próxima tabela
deve ser limpa para 1% de seus dados alterados. Mas devido à falta de trabalhadores do autovacuum, não pode ser
aspirado nesse ponto. Quando os trabalhadores de autovacuum estiverem disponíveis, os dados dessa tabela poderão
mudar para 50% ou 80%. Isso aumentará o trabalho do autovacuum, que então fica mais lento. Na verdade, depende de
quantas CPUs você tem para trabalhadores de autovacuum.
Outra idéia é manter autovacuum_vacuum_cost_delay mais baixo, talvez em 10. Menor que 10 efetivamente não
ajuda muito, mas seus trabalhadores de autovacuum trabalharão o mais intensamente possível. O PostgreSQL não
regulará sua atividade de IO de forma alguma; nesse caso, você pode tentar regular a atividade externamente usando ionice
e renice em trabalhadores de autovacuo regularmente.
No crontab:

* * * * * /usr/bin/pgrep -f 'postgres: autovacuum' | xargs --no-run-if vazio -I $ renice -n 20 -p $ >/dev/null 2>/dev/null * * *

* * /usr/bin/pgrep -f 'postgres: autovacuum' | xargs --no-run-if vazio -I $ ionice -c 3 -t -p $

Em postgresql.conf:

autovacuum_max_workers = 20
autovacuum_vacuum_cost_delay = 10

Tenha em mente que o ionice não pode funcionar se você tiver um agendador não CFQ (Fila Completamente Justa) em
Linux .

Fragmentação de Índices Os

índices podem ficar fragmentados ao longo do tempo à medida que são atualizados. Isso afeta o desempenho, e esses índices devem ser
REINDEXADOS para otimizar seu uso. Uma maneira de identificar a fragmentação do índice é usar a extensão pgstattuple. Se o cliente lhe
conceder permissão para instalá-lo, você pode usar a função pgstatindex que fornece da seguinte forma:

postgres=# cria tabela index_test (id int);

CREATE TABLE
postgres=# inserir nos valores index_test (generate_series(1,10000000));
INSERT 0 10000000
postgres=# cria índice fragmented_index em index_test (id);
CREATE INDEX
postgres=#
postgres=# cria extensão pgstattuple ;
CREATE EXTENSION
postgres=# insira nos valores index_test (generate_series(1,10000000));
INSERT 0 10000000
postgres=# atualização index_test set id = 1 onde id < 5000000;
ATUALIZAÇÃO 4999999
Machine Translated by Google

*
postgres=# SELECT FROM pgstatindex('fragmented_index');
-[ REGISTRO 1 ]------+----------
versão | 2
tree_level | 2
index_size | 366919680
root_block_no | 412
páginas_internas | 177
folhas_páginas | 44612
páginas_vazias | 0
páginas_excluídas | 0
avg_leaf_density | 82,79
folha_fragmentação | 35,65

Isso mostra que o índice chamado "fragmented_index" é 35,65% fragmentado (como mostrado para
folha_fragmentação). Em índices pequenos, isso pode não ser um problema, mas em índices maiores pode visivelmente
degradar o desempenho e ocupar espaço desnecessário. Um REINDEX desfragmentaria o índice e, portanto,
também reduzir seu tamanho:

postgres=# índice de reindexação fragmented_index ;

REINDEX
Tempo: 7.960,823 ms (00:07.961)
*
postgres=# SELECT - FROM pgstatindex('fragmented_index');
[ RECORD 1 ]------+----------
versão | 2
tree_level | 2
index_size | 224641024
root_block_no | 290
páginas_internas | 98
folhas_páginas | 27323
páginas_vazias | 0
páginas_excluídas | 0
avg_leaf_density | 90,09
folha_fragmentação | 0

Como você pode ver, neste exemplo o leaf_fragmentation mostra que agora não há fragmentação no
index e index_size passou de 366919680 bytes para 224641024bytes, reduzindo seu tamanho quase pela metade.
Se estiver usando o PostgreSQL 9.3 ou superior, você pode usar a seguinte consulta para obter os detalhes de cada índice em
uma vez:

SELECT a.indexrelname, b.*

DE pg_stat_user_indexes a,
LATERAL pgstatindex(indexrelname) b
ORDER BY folha_fragmentação DESC;

Para versões anteriores, use:

SELECT (xa).indexrelname, (xb).*

FROM (SELECT a, pgstatindex(a.indexrelname) AS b
DE pg_stat_user_indexes a) x
ORDER BY folha_fragmentação DESC;

No entanto, no sistema de produção é difícil realizar operações dispendiosas como o REINDEX, pois este adquire
vários bloqueios nos objetos. Não é aconselhável reconstruir índices durante os horários de pico, e é necessário planejamento
para tais operações. Planeje essas operações caras sempre que houver um tempo de inatividade para o aplicativo e
Machine Translated by Google

banco de dados em nível organizacional. REINDEX adquire vários bloqueios nos objetos e executa a eliminação e recriação do
índice. Os índices do PostgreSQL 8.2 em diante também podem ser criados simultaneamente, se necessário.
REINDEX reconstrói um índice usando os dados armazenados na tabela do índice, substituindo a cópia antiga do índice.
Existem duas razões principais para usar o REINDEX:

Um índice foi corrompido e não contém mais dados válidos. REINDEX fornece um método de recuperação.
O índice contém muitas páginas de índice quase vazias que não estão sendo recuperadas. REINDEX fornece uma maneira de
reduzir o consumo de espaço do índice escrevendo uma nova versão do índice sem as páginas mortas.

Observação Se você suspeitar de corrupção de um índice em uma tabela de usuário, você pode simplesmente reconstruir esse índice ou todos
índices na tabela, usando REINDEX INDEX ou REINDEX TABLE.

Também é recomendado executar ANALYZE após alterações de DDL ou operações REINDEX. PostgreSQL
9.0 fornece uma ferramenta de linha de comando “reindexdb” que executa a mesma função. Para obter mais informações sobre
reindexação, consulte: www.postgresql.org/docs/current/static/sql-reindex.html .

Outra manutenção de banco de dados

Como parte da manutenção, recomenda-se eliminar:
Índices não usados
Índices duplicados

Índices não usados

Os índices que não são usados adicionam sobrecarga de manutenção às tabelas às quais pertencem e ocupam espaço. Como tal,
devemos recomendar que tais índices sejam descartados.
Uma consulta para identificar esses índices é a seguinte:

SELECT relname AS tabela, indexrelname AS index,

pg_size_pretty(pg_relation_size(indexrelid)) AS size
DE pg_stat_user_indexes
ONDE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

Se houver um grande número de resultados (por exemplo, mais de 15 linhas), eles devem ser fornecidos em um arquivo
de texto separado do relatório. Os resultados são ordenados por tamanho para que os índices que ocupam mais espaço sejam listados
primeiro.
Os benefícios de remover índices redundantes são que eles liberarão espaço e melhorarão o desempenho de
atualizações, exclusões e inserções em tabelas, pois os índices não precisarão mais ser atualizados com essas alterações.

A decisão de remover um determinado índice pode ser mitigada por vários fatores possíveis:

O padrão de tráfego atualmente em uso não faz com que os índices sejam usados, mas as mudanças antecipadas fariam com
que eles fossem usados.
O planejador não está usando corretamente todos os índices esperados. Existem casos incomuns em que o planejador de
execução de consulta deveria estar usando um índice para execução de SQL DML, mas não o faz. Nesses casos, o índice não
deve ser removido, e o SQL em questão examinado e possivelmente reestruturado para usar adequadamente o índice.

Índices duplicados
Índices duplicados resultam em desperdício de espaço e aumentam a sobrecarga nas atualizações de tabela. A consulta a seguir
retornará índices duplicados, mas os índices ainda podem diferir de maneiras sutis, como usar um método de acesso de agrupamento
ou índice diferente (btree, hash, gin, gist), portanto, eles devem ser comparados manualmente:

SELECT indrelid::regclass AS table, indkey AS column_numbers, array_agg(indexrelid::regclass) AS indexes,

Machine Translated by Google

pg_catalog.pg_get_expr(indpred, indrelid, true) AS expressão FROM pg_index

GROUP BY indrelid, indkey, pg_catalog.pg_get_expr(indpred, indrelid, true)

HAVING contagem(*) > 1;

Isso retornará uma linha para cada conjunto de duplicatas aparentes e uma matriz de índices duplicados será
exibido na coluna "índices" .

Resumo Neste
capítulo, falamos sobre o MVCC no PostgreSQL e como ele causa inchaço no banco de dados e como pode ser removido.
Explicamos detalhadamente o trabalho do autovacuum e seus usos. E abordamos detalhadamente as melhores práticas
para executar atividades de manutenção como VACUUM e reindexar. No próximo capítulo, falaremos sobre a importância
da Alta Disponibilidade e procedimentos para implementá-la no PostgreSQL. Abordaremos algumas ferramentas de
código aberto e corporativas para implementar a Alta Disponibilidade. Também abordaremos a importância de um pooler,
e os poolers disponíveis no mercado e sua implementação.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_7

7. Procedimentos de Alta Disponibilidade

e Implementação de um Pooler

Baji Shaik1 (1)

Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre algumas coisas básicas sobre MVCC no PostgreSQL, e o que é
bloat no banco de dados e como ele pode ser removido.
Explicamos como o autovacuum ajuda a remover o inchaço e melhorar o desempenho. Também
abordamos detalhadamente as melhores práticas para executar atividades de manutenção como
VACUUM e reindexação. Neste capítulo, falaremos sobre a importância da Alta Disponibilidade (HA), e
quais informações precisamos para construir uma solução de HA e os procedimentos para implementá-
la no PostgreSQL. Abordaremos algumas ferramentas de código aberto e corporativas para implementar
HA. Também abordaremos a importância de um pooler, e poolers disponíveis no mercado e sua
implementação.

Por que alta disponibilidade?

Esta é uma pergunta básica que todo DBA deve responder. HA é proteger seu banco de dados contra
falhas e ajuda em recuperações de desastres. O que exatamente significa a “proteção”? Não é um tipo
de reparo dos dados com falha, mas sim disponibilizar os dados para os negócios de qualquer forma ou
a qualquer custo. Se seu banco de dados estiver indisponível por algum motivo, você terá que se
certificar de que tem algo para continuar seu aplicativo rodando com os mesmos dados. Os motivos das
falhas do banco de dados podem ser:

Devido a um desastre

Falha no banco de dados e não inicializa

O banco de dados está indisponível devido à carga pesada
Machine Translated by Google

O banco de dados está corrompido devido a um disco ou hardware defeituoso

Reunir informações para configurar o HA Antes de configurar

o HA, precisamos saber quais informações são necessárias. Se você tiver as informações
corretas, com base nisso, poderá sugerir uma solução de HA.
Então, aqui estão algumas perguntas que você pode fazer ao seu cliente, para construir a
solução. Cada pergunta tem um propósito que ajuda na arquitetura: Q1.

Quais são as suas expectativas para esta solução de HA?

Objetivo: Esta é uma pergunta básica para a qual você precisa de respostas. Você
deve perguntar sobre as expectativas do cliente sobre as soluções de HA
do PostgreSQL. Os clientes vêm de diferentes origens de banco de dados e esperam
que tipos semelhantes de soluções sejam possíveis no PostgreSQL. Pode não ser
possível às vezes. O PostgreSQL tem suas próprias implementações de HA e pode
não corresponder com os procedimentos de outros bancos de dados o tempo todo.
Portanto, se os clientes tiverem o mesmo tipo de expectativas que seus bancos de
dados anteriores (caso estejam migrando de alguns bancos de dados corporativos),
você deve explicar as possibilidades e definir as expectativas.

Q2.
Quais são as especificações do seu servidor principal?
Objetivo: É muito importante saber sobre o cliente
especificações do servidor primário para que você também possa sugerir um
tipo semelhante de hardware para servidores em espera. A razão por trás de ter
um hardware semelhante é que, se você fizer um failover, também esperará o mesmo
comportamento e desempenho em um servidor em espera recém-promovido. Portanto,
se você tiver o mesmo hardware no primário e no modo de espera, não verá muita
diferença no desempenho após o failover.

Q3.
Quantos servidores em espera você deseja?
Finalidade: O número de servidores em espera depende do cliente
escolha. Se eles tiverem um banco de dados crítico e também precisarem de HA
em seus data centers, você precisará projetar uma solução de acordo com isso.
Estaremos discutindo uma solução relacionada a ele neste capítulo.

Q4. Quão críticos são seus dados?

Machine Translated by Google

Objetivo: Assim como a pergunta anterior, se eles tiverem um banco de

dados crítico, você deve sugerir mais servidores standby do que um e

mais data centers do que um. Claro, você terá que cuidar das latências para diferentes
data centers.
Q5.
Quais são seus RPO e RTO?
Objetivo: Esta é uma parte muito crítica no nível de negócios. Devemos conhecer
o RTO e o RPO em detalhes primeiro e depois perguntar ao cliente suas expectativas.
Com base nos valores, você pode projetar sua solução ou convencer o cliente se for
algo que não pode ser alcançado. RTO (objetivo de tempo de recuperação) e RPO
(objetivo de ponto de recuperação) são explicados na próxima seção.

Q6.
É um único data center ou mais de um?
Finalidade: O cliente pode não conseguir compartilhar os detalhes de seus data
centers até que solicitemos especificamente. Portanto, esta pergunta nos ajuda a
conhecer seus data centers e implementar replicações entre centros, se necessário.

Q7.
Se você tiver mais de um data center, qual a distância entre eles?
Objetivo: Se o cliente quiser uma solução em data centers diferentes, você
precisa saber a que distância eles estão localizados para analisar antecipadamente o
atraso de replicação. Você pode explicar ao cliente sobre atrasos entre data centers,

Q8.
Você está procurando especificamente por alguma solução de replicação?
Objetivo: O cliente já fez algumas pesquisas e apresentou algumas soluções
que incluem ferramentas de código aberto ou corporativas para implementação. Você
precisará examinar a arquitetura e as ferramentas e informar ao cliente se há problemas
ou limitações conhecidos usando sua arquitetura e ferramentas. Se necessário, você
pode redesenhar a solução.

Q9. Você abre servidores em espera para conexões de leitura?

Finalidade: PostgreSQL suporta servidores standby para propósitos de
leitura. Portanto, se o cliente não estiver ciente disso, convém sugerir consultas de leitura
para servidores em espera para reduzir a carga no primário.
No entanto, se os dados primários forem criptografados nas conexões durante a
leitura, você deve informar o cliente e usar o mesmo
Machine Translated by Google

nós ead g, você s ou d et te custo e ow ad usar o processo sa e para puxar os

dados.
Q10.
Você quer soluções de failover automático?
Objetivo: O failover automático é algo que o PostgreSQL não possui
embutido. Você pode querer criar alguns scripts para fazer isso, ou existem
muitas ferramentas disponíveis no mercado que você pode usar como parte de
sua solução. Falaremos sobre as ferramentas nas próximas seções deste capítulo.

Q11.
Qual é o atraso máximo que você espera entre o primário e o standby?

Finalidade: Alguns clientes usam servidores em espera para fins

de leitura. A maneira como eles os usam pode ser modificar dados no primário
e recuperá-los imediatamente do standby. Se houver algum atraso entre o primário
e o de espera, você verá dados diferentes do esperado. Portanto, se você obtiver
os detalhes de como eles estão consultando, poderá sugerir horários para consultar
se houver algum atraso esperado.

RPO e RTO Esses são

itens de negócios típicos que precisam ser atendidos ao configurar soluções de alta
disponibilidade.

RPO (objetivo do ponto de recuperação)

Isso representa o ponto em que você pode perder dados a qualquer momento.
Envolve o tamanho dos dados, ou seja, no momento da recuperação em situações
de desastre, quanta perda de dados você pode arcar.
Às vezes, o standby pode estar atrás (atrasado) do primário. Nesse caso, se
você precisa de um failover, ele pode perder alguns dados que não são replicados
para o modo de espera. Portanto, teste sua solução com uma carga de produção e
.
analise quanto atraso você vê em qualquer ponto. Isso se tornará seu RPO

RTO (Objetivo de Tempo de Recuperação)

É tudo sobre 9s. Ele representa quanto tempo o aplicativo pode ficar inativo. Portanto,
este é o tempo de recuperação para fazer o standby agir como primário em um failover.
Machine Translated by Google

Aqui está uma tabela típica que representa o tempo de inatividade do aplicativo com base em
disponibilidade.

Disponibilidade Tempo de inatividade por

Ano Mês Semana

90% (Um Nove) 36,5 dias 73 horas 16,8 horas

99% (dois noves) 87,7 horas 7,3 horas 1,68 horas

99,9% (Três Noves) 8,77 horas 43,8 minutos 10,1 minutos

99,99% (Quatro Noves) 52,56 minutos 4,38 minutos 1,01 minutos

99,999% (cinco noves) 5,26 minutos 26,3 segundos 6,05 segundos

99,9999% (Seis Noves) 31,5 segundos 2,63 segundos 0,605 segundos

Soluções de alta disponibilidade no núcleo PostgreSQL

O PostgreSQL oferece várias opções de HA que fornecem um mecanismo de failover
para bancos de dados altamente ativos e críticos no momento do desastre. É importante
que as conexões do aplicativo sejam roteadas para o site de espera para dados contínuos
acessibilidade.

Espera quente/transporte de log

Hot Standby
Replicação de streaming
Replicação em cascata

Espera Quente/Remessa de Log

O arquivamento contínuo pode ser usado para criar uma configuração de cluster de alta disponibilidade
com um ou mais servidores em espera prontos para assumir as operações se o
servidor primário falha. Esse recurso é amplamente conhecido como espera quente
ou envio de logs. Isso é suportado pelo PostgreSQL no nível do arquivo.
O servidor primário e de reserva trabalham juntos para fornecer esse recurso
com servidores fracamente acoplados. O servidor primário opera em contínuo
modo de arquivamento, enquanto cada servidor em espera opera em recuperação contínua
modo, lendo os arquivos de log do primário. Sem alterações no banco de dados
tabelas são necessárias para habilitar esse recurso, por isso oferece baixa administração
sobrecarga em comparação com algumas outras abordagens de replicação. este
A configuração também tem um impacto mínimo no desempenho do servidor primário.
Machine Translated by Google

Como a origem espera até que o arquivo de log esteja cheio antes de enviar o arquivo de log,
há algum atraso entre a origem e o destino; quanto mais lento o volume de atualização,
maior o atraso entre o primário e o standby.
O servidor em espera não está disponível para acesso em uma configuração de
espera a quente, pois está continuamente em recuperação. O desempenho da recuperação é
suficientemente bom para que o modo de espera normalmente esteja a apenas alguns momentos
da disponibilidade total depois de ativado. Como resultado, nos referimos a esse recurso como uma
configuração de espera quente que oferece HA. A restauração de um servidor a partir de um
backup de base arquivado e rollforward levará muito mais tempo, de modo que essa técnica
realmente oferece apenas uma solução para recuperação de desastres, não HA.

Hot Standby Este

recurso (disponível no PostgreSQL 9.0) permite aos usuários criar uma instância de banco de
dados “hot standby” para consultas somente leitura (SELECTs). As consultas são executadas
normalmente enquanto o banco de dados standby reproduz continuamente o fluxo de modificações
binárias provenientes do banco de dados primário.
Para mais informações, consulte:
www.postgresql.org/docs/current/static/hot standby.html.

Replicação de streaming A
Replicação de streaming (também disponível no PostgreSQL 9.0) melhora o mecanismo de
arquivamento para torná-lo o mais atualizado possível e não depender do envio de arquivos de log.
Os servidores em espera agora podem se conectar ao primário e receber dados WAL sob demanda
à medida que são gerados, em vez de aguardar a conclusão de um segmento WAL inteiro.

A replicação de streaming é assíncrona por padrão (não espera a confirmação de que

as alterações foram aplicadas a um servidor em espera), mas a partir do PostgreSQL 9.1
também pode ser configurada para ser síncrona. O atraso na replicação de streaming é muito
curto, ao contrário de outros sistemas de replicação, e as alterações replicadas podem ser tão
pequenas quanto uma única transação, dependendo da velocidade da rede, atividade do banco
de dados e configurações de espera ativa. Além disso, a carga no primário para cada standby é
mínima, permitindo que um único primário dê suporte a dezenas de standbys.

Uma configuração de replicação síncrona também oferece suporte a transações

assíncronas, de modo que nem todas as alterações precisam aguardar a confirmação do
Machine Translated by Google

servidor em espera. Isso significa que uma combinação de síncrono e assíncrono pode ser
usada no mesmo sistema e pode ser selecionada com base na importância dos dados em
uma tabela específica.
Para habilitar a replicação de streaming , a configuração wal_level deve ser definida
como “archive” ou “hot standby”.
Consulte a documentação para obter mais detalhes:
www.postgresql.org/docs/current/warm standby.html#STREAMING-
REPLICATION.

Replicação em cascata O
PostgreSQL 9.2 fornece a capacidade de transmitir alterações de um standby para outros
standbys. Isso pode ser útil se você tiver muitos standbys configurados e não desejar
sobrecarregar a replicação no primário. Consulte a documentação para obter mais
detalhes: www.postgresql.org/docs/current/warm standby.html#CASCADING-REPLICATION.

Warm/Hot Standby vs. Replicação de Streaming Muitas pessoas

se confundem com Warm/Hot Standby e replicação de streaming e as consideram a mesma
coisa. No entanto, existem algumas diferenças.

Espera Quente/ Quente

Ambos são criados com uma cópia de backup do primário.
Ambos funcionam com base na aplicação WAL.
Ambos são um WAL atrás do primário, portanto, na pior das hipóteses, você perderá 16
MB de dados (ou seja, um WAL que está sendo gravado no primário).

A única diferença é que o hot standby pode ser aberto para fins de leitura, mas o
warm standby não.

Replicação de streaming É

bem diferente do modo de espera quente/quente.

Funciona com processos emissor/receptor WAL.
Os registros XLOG para cada operação de modificação de dados seriam enviados
para espera.
Machine Translated by Google

Ele está atualizado com o primário, portanto, na pior das hipóteses, você perderá
a transação atual que está sendo executada no primário.

Solução de HA simples
Vejamos uma solução de HA simples que pode ser implementada com um servidor
primário e um de reserva.

Como você vê, esta solução tem um primário e um de espera, que são configurados por
meio de replicação de streaming.

O cliente se conecta ao primário para operação de leitura/gravação e pode se

conectar ao modo de espera para operação de leitura O mecanismo de failover
aqui é manual. Você pode criar um arquivo acionador no servidor em espera ou
promover a espera usando o comando “pg_ctl promote”.

Assim que um novo primário estiver disponível, você precisará atualizar o aplicativo
com novos detalhes primários.
Machine Translated by Google

Parece uma boa solução, mas não é a melhor. tem alguns manuais
etapas, o que aumentaria seu tempo de inatividade em caso de falhas.

Melhor solução de alta disponibilidade

Vejamos outra solução.

Então aqui:

O cliente se conecta ao pgBouncer ou HAProxy

PgBouncer ou HAProxy está configurado para se conectar ao servidor disponível
Dois data centers com um servidor primário e três servidores em espera
Um primário e um standby em um data center e outros dois standbys em outro data
center
A replicação entre o primário e o standby no mesmo data center é síncrona, pois
não haverá muito atraso devido ao mesmo data center
Machine Translated by Google

A replicação entre o primário e um dos standbys em outro datacenter é assíncrona,

pois haverá atraso O quarto servidor standby é uma réplica em cascata para o
terceiro standby em outro datacenter. Dessa forma, você pode reduzir a carga no
primário.
Se APENAS o servidor primário no primeiro data center não estiver disponível, o
standby no mesmo data center assumirá a posição principal Se todo o data center
estiver inativo, o terceiro standby assumirá a posição principal solução.

Se o primário não estiver disponível e o failover for feito, o pgBouncer ou o

HAProxy cuidarão do envio de conexões para o novo servidor.
Pode ser necessário configurar o VIP, se necessário.

Ferramentas de failover automático

disponíveis Existem muitas ferramentas de failover automático disponíveis no
mercado que você pode integrar ao PostgreSQL. Aqui estão algumas ferramentas:

repmgr (https://repmgr.org/)
Clientes (https://github.com/zalando/patroni)
PAF (Failover Automático PostgreSQL;
https://pgstef.github.io/2018/02/07/introduction_to_postgresql_automatic_failover.html )
pg_ auto_ failover (www.citusdata.com/blog/2019/05/30/introducing pg-auto-failover/)
pgpool-II (www.pgpool.net/docs/latest/en/html/intro whatis.html)

Não vamos cobrir todas as ferramentas; no entanto, mostraremos como o failover

automático pode ser feito por meio do repmgr. Observe que estas são apenas etapas de nível
superior para configuração.

auto-failover através da instalação

do repmgr Você pode seguir esta
documentação para instalar o repmgr: https://repmgr.org/
docs/4.2/installation.html.
Servidores:
Machine Translated by Google

Servidor primário – 192.168.0.1 Servidor em espera

– 192.168.0.2

Certifique-se de que as chaves sejam trocadas entre todos esses servidores.

Configuração Em servidores primários e em espera, configure um usuário rep_mgr e um

banco de dados rep_mgr no PostgreSQL.

psql -c 'CRIAR REPLICAÇÃO DE USUÁRIO rep_gmr'; psql -c 'CRIAR

BANCO DE DADOS rep_mgr PROPRIETÁRIO rep_mgr';

Certifique-se de criar SUPERUSER.

Configuração
Configure o arquivo de configuração repmgr em ambos os servidores, pois eles
precisam estar cientes um do outro. A localização do arquivo de configuração é /etc/repmgr.conf.
No servidor principal:

cluster=cls node=1
node_name=node1
conninfo= 'host=192.168.0.1
user=repmgr dbname=repmgr' pg_bindir='/usr/pgsql-9.5/bin'
loglevel=DEBUG reconnect_attempts=1 reconnect_interval=1 logfile='/
var /lib/pgsql/repmgr.log' use_replication_slots=6 service_start_command
= 'sudo /bin/systemctl start postgresql-9.5' service_stop_command =
'sudo /bin/systemctl stop postgresql-9.5' service_restart_command =
'sudo /bin/systemctl restart postgresql 9.5'
Machine Translated by Google

service_reload_command = '/usr/pgsql-9.5/bin/pg_ctl -D /var/lib/pgsql/

9.5/data reload' service_promote_command = '/usr/pgsql 9.5/bin/
pg_ctl -D /var/lib/pgsql/9.5/ data promote' priority=100
failover='automatic' promote_command='/var/lib/pgsql/
standby_promote.sh' follow_command='/usr/pgsql-9.5/bin/repmgr
standby follow -f /etc/repmgr/9.5/repmgr .conf -W'

No servidor em espera:

cluster=cls
node=2
node_name=node2
conninfo= 'host=192.168.0.2 user=repmgr
dbname=repmgr' pg_bindir='/usr/pgsql-9.5/bin'
loglevel=DEBUG logfile='/var/lib/pgsql/repmgr .log'
use_replication_slots=6 service_start_command =
'sudo /bin/systemctl start postgresql-9.5'
service_stop_command = 'sudo /bin/systemctl stop
postgresql-9.5' service_restart_command = 'sudo /bin/systemctl
restart postgresql 9.5' service_reload_command = '/usr/ pgsql 9.5/
bin/pg_ctl -D /var/lib/pgsql/9.5/data reload' service_promote_command
= '/usr/pgsql 9.5/bin/pg_ctl -D /var/lib/pgsql/9.5/data promote'
Machine Translated by Google

priority=100
failover='automatic'
master_response_timeout=10
reconnect_attempts=1 reconnect_interval=1
promote_command='repmgr standby
promote -f /etc/repmgr.conf --log-to-file' follow_command='/usr/pgsql-9.5/
bin /repmgr espera siga -f /etc/repmgr/9.5/repmgr.conf -W'

Você precisaria configurar as entradas pg_hba.conf do servidor primário para

deixe o servidor primário aceitar conexões de replicação do standby
servidor.

host rep_mgr rep_mgr 192.168.0.2/32 replicação de host confiável

rep_mgr 192.168.0.2/32 host de confiança rep_mgr rep_mgr 192.168.0.1/32
trust

Por favor, reinicie o PostgreSQL e o daemon repmgrd.

sudo /bin/systemctl start postgresql-9.5 sudo /etc/init.d/repmgrd

restart

Registro do Nó A
configuração dos servidores primário e de espera foi concluída e agora
precisamos verificar qual servidor está desempenhando qual função.
No servidor principal:

sudo -u postgres repmgr registro primário

No servidor primário, você deverá ver:

$ psql -U rep_mgr -c 'select node_id, node_name, type, conninfo from

repmgr.nodes' -d rep -mgr

node_id | node_name | tipo | informação

Machine Translated by Google

---------+----------------+---------+-------------
-----
1 | servidor primário | primário |
host=192.168.0.1

Você precisa registrar o servidor em espera agora. Para isso você precisará
faça um backup, e é aí que o servidor de backup aparece.
Vamos clonar o banco de dados do servidor primário no servidor em espera.
No servidor em espera:

sudo /etc/init.d/postgresql stop sudo -u postgres

repmgr -h '192.168.0.1' -U repmgr -d repmgr -D /var/lib/pgsql/9.5/data -f /
etc/repmgr/9.5/repmgr .conf clone em espera

sudo /bin/systemctl start postgresql-9.5

repmgr -f /etc/repmgr/9.5/repmgr.conf registro de espera --verbose

Em ambos os servidores (primário e em espera), você vê:

$ psql -U rep_mgr -c 'selecione node_id,

upstream_node_id, node_name, digite repmgr.nodes'
-d rep_mgr

node_id | upstream_node_id | node_name

| tipo |
--------+------------------+-----------------+----
-----+
1| | servidor primário |
primário | 2
| 1 | servidor de espera |
espera |

Failover automático de teste

Machine Translated by Google

Como a opção de failover em ambos os arquivos de configuração regmgr (primário e

standby) é automática, se você tentar parar o primário, ele promoverá o standby
automaticamente.

Replication Lag No
PostgreSQL 9.2 e superior, isso pode ser encontrado executando:

SELECT application_name,
pg_xlog_location_diff(sent_location, flush_location) AS lag

DE pg_stat_replication
ORDER BY replay_delta ASC, application_name;

No PostgreSQL 9.0 e 9.1, o seguinte pode ser usado para calcular o atraso
de replicação:

FAÇA $$
DECLARE resultado int;
COMEÇAR

EXECUTE 'SELECT x"' ||

replace(sent_location,'/',") || "'::int - x"' || replace(flush_location,'/',") || "'::int'
FROM pg_stat_replication INTO resultado;

RAISE NOTICE 'Atraso de replicação: % bytes', resultado;

FIM $$;

Se houver um grande atraso, pode ser que a interface de rede que está
sendo usada esteja enfrentando outro tráfego de rede. Isso pode ser causado por
outros aplicativos em execução no mesmo sistema que usam largura de banda de
rede ou que vários standbys estejam conectados ao primário. Se o último for
verdadeiro, devemos recomendar a replicação em cascata, onde apenas um
standby se conecta ao primário e todos os outros standbys se conectam ao primeiro standby.
Isso, no entanto, está disponível apenas no PostgreSQL 9.2 e superior.

Problemas comuns de replicação

FATAL,58P01,"segmento WAL solicitado
Machine Translated by Google

0000000100000B110000000D já foi removido

Isso pode ser causado pela remoção do segmento WAL do primário que é
exigido pelo standby. Esta remoção é um processo de limpeza no PostgreSQL.
A solução é garantir um planejamento adequado para o armazenamento de arquivos.
Certifique-se de que os arquivos estão sendo copiados para o local de espera ou use um slot
de replicação.

FATAL: não foi possível conectar ao servidor primário: não foi possível conectar
ao servidor: Arquivo ou diretório inexistente

Isso pode ser causado devido à perda de conexão entre o primário e o

standby. A solução é configurar um script ou ferramentas de monitoramento para
verificar o status da conexão entre primário e standby.

FATAL: o sistema de banco de dados está iniciando

Se o banco de dados estiver em recuperação, o usuário deverá aguardar a conclusão da

recuperação. Se hot_standby não estiver habilitado, você poderá ver este erro Fatal no modo de
espera caso esteja usando para consultas somente leitura.

FATAL: terminando a conexão devido a conflito com a recuperação

Você pode ver se há consultas de longa duração no modo de espera. Se

os clientes estiverem recebendo o erro FATAL anterior e as consultas estiverem
falhando, o DBA precisará verificar e definir os parâmetros a seguir.

hot_standby_feedback
vacuo_diffr_cleanup_age
max_standby_archive_delay
max_standby_stream_delay

Por que o pool de conexões O pool de

conexões é usado para armazenar em cache as conexões do banco de dados e
reutilizá-las para conexões futuras. Assim, ele remove a sobrecarga na inicialização e
Machine Translated by Google

fechamento de conexões no cluster de banco de dados, o que pode ser um

grande benefício de desempenho, principalmente em ambientes com transações frequentes
e de curta duração. Ele também pode fornecer uma fila para conexões em excesso de
max_connections para que as conexões de entrada não sejam rejeitadas, mas sim atrasadas
enquanto aguardam a próxima conexão disponível do pool.

Existem dois poolers de conexão geralmente recomendados para uso com

PostgreSQL, embora existam muitos outros que funcionarão.

pgBouncer (www.pgbouncer.org/) pgpool

(www.pgpool.net/docs/latest/en/html/intro whatis.html)

pgBouncer
Este é um pool de conexões muito leve que é simples de configurar e configurar. Se as
conexões com uma única instância precisarem ser agrupadas de maneira simples, essa é a
melhor opção. Ele foi originalmente desenvolvido pela Skype e era responsável por toda a
infraestrutura do Skype (antes da aquisição da Microsoft). Essencialmente, o pgBouncer atua
como um proxy de banco de dados transparente que permite a reutilização de alto
desempenho dos recursos do banco de dados.
Do ponto de vista de gerenciamento, o pgBouncer também permite uma
ponto de controle para conectividade de banco de dados. Essencialmente, um
número n de servidores pgBouncer pode ser criado que pode ser um funil para um
número muito grande de hosts de aplicativos. Como os servidores pgBouncer podem
ser executados como entidades independentes sem necessidade de coordenação, não
há problema em dimensionar essa camada muito ampla. Se a camada do pgBouncer for
dimensionada, é recomendável que a configuração do pgBouncer (apenas um único arquivo
pgbouncer.ini) seja controlada pelo chef ou similar para garantir a consistência.
As instruções para configurar o pgBouncer estão
aqui: www.pgbouncer.org/install.html.
Você pode configurar usando este documento:
www.pgbouncer.org/config.html.
Observe que, se o SSL for adicionado à infraestrutura, o pgBouncer não será capaz de
quebrando a conexão SSL nativamente. Você pode usar o Stunnel (que é um proxy
projetado para adicionar a funcionalidade de criptografia TLS a clientes e servidores
existentes sem nenhuma alteração nos programas), mas isso às vezes cria
Machine Translated by Google

problemas (www.pgbouncer.org/faq.html#how-to-use-ssl connections-with-pgbouncer).

Problemas

Existem alguns problemas que são comumente encontrados com aplicativos

Java e pgBouncer.

Parâmetro de inicialização não suportado

Este é um problema causado pelo fato de que o driver JDBC está sempre
emitindo

defina extra_float_digits=...

Para combater esse problema, o pgBouncer permite que você ignore esse
parâmetro na inicialização e evite gerar o erro. Você pode definir a opção de
configuração ignore_startup_parameters em pgbouncer.ini para contornar isso.

pgpool-II
Fornece recursos que o pgBouncer não oferece, ou seja, balanceamento de carga
para permitir que consultas somente leitura sejam distribuídas entre todos os standbys
e todas as consultas de gravação continuem no primário. No entanto, o pgpool-II tem
várias ressalvas e é mais complicado de configurar e configurar do que o pgBouncer.
Mais sobre o pgpool está aqui:
www.pgpool.net/docs/latest/en/html/intro whatis.html.

Resumo Neste
capítulo, falamos sobre a importância da Alta Disponibilidade e quais informações
precisamos para construir uma solução de Alta Disponibilidade e os procedimentos
para implementá-la no PostgreSQL em um nível básico. Passamos por algumas
soluções de HA. Mencionamos algumas ferramentas de código aberto e corporativas
para implementar a Alta Disponibilidade. Também falamos sobre alguns problemas
comuns que vemos no ponto de vista da replicação. Nós temos
Machine Translated by Google

abordou a importância de um pooler, e poolers disponíveis no mercado

e sua implementação.
Machine Translated by Google

© Baji Shaik 2020

B. Shaik, Configuração do PostgreSQL
https://doi.org/10.1007/978-1-4842-5663-3_8

8. Erros básicos e consultas úteis

Baji Shaik1 (1)
Hyderabad, Andhra Pradesh, Índia

No último capítulo, falamos sobre por que precisamos de Alta Disponibilidade e quais são os diferentes tipos de procedimentos disponíveis para
implementar a Alta Disponibilidade usando algumas ferramentas open source e corporativas disponíveis no mercado. Também falamos sobre a
importância de um pool de conexões, poolers disponíveis no mercado e como implementar um pooler com instâncias do PostgreSQL. Este capítulo é
basicamente direcionado aos usuários que começaram a trabalhar com o PostgreSQL. Neste capítulo, falaremos sobre erros básicos que enfrentamos
quando começamos a trabalhar com o PostgreSQL e algumas consultas úteis que são úteis no dia-a-dia de um administrador de banco de dados.

Erros básicos do PostgreSQL Quando você começa

a trabalhar com o PostgreSQL, você pode ver muitos erros ao instalar, conectar e consultar os bancos de dados. Alguns erros podem ser muito
simples de resolver; no entanto, você só precisa saber as razões pelas quais esses
ocorrem erros.

Vamos categorizar os erros com base em quando eles ocorrem:

Erros de conexão

Erros de configuração
Erros de consulta
Outros erros

Erros de conexão Esta

seção fala sobre os erros que vemos ao conectar ao banco de dados. Vamos ver Erros e Causa/Resolução para cada erro em detalhes.

Erro

psql -p 5432 -U postgres -d postgres psql: não foi possível conectar

ao servidor: Arquivo ou diretório inexistente O servidor está executando localmente e aceitando conexões no soquete
de domínio Unix "/tmp/.s.PGSQL.5432"?

Causa/ Resolução Este

erro é causado pela indisponibilidade do arquivo de soquete no local onde o psql está procurando. Isso pode ocorrer por motivos como: 1.

O PostgreSQL não está em execução.

2. Você está usando uma porta diferente para se conectar.

A primeira coisa que você precisa verificar é o status do servidor (usando os comandos abaixo); se o servidor não estiver em execução,
inicie-o e tente se conectar. Você pode usar o utilitário pg_ctl para verificar o status e inicializar da seguinte forma:

$ pg_ctl -D $PGDATA status pg_ctl: nenhum

servidor em execução
Machine Translated by Google

$ pg_ctl -D $PGDATA início

aguardando a inicialização do servidor....2019-09-05 22:47:51.551 IST [87688]
LOG: escutando no endereço IPv6 "::1", porta 5432 2019-09-05 22:47:51.552 IST
[87688] LOG: escutando no endereço IPv4 "127.0.0.1", porta 5432 2019-09-05 22:47 :51.555 IST [87688] LOG:
escutando no soquete Unix "/tmp/.s.PGSQL.5432"

2019-09-05 22:47:51.576 IST [87689] LOG: o sistema de banco de dados foi desligado em 2019-09-05 22:46:37 IST

2019-09-05 22:47:51.621 IST [87688] LOG: o sistema de banco de dados está pronto para aceitar as conexões feitas

servidor iniciado

$ pg_ctl -D $PGDATA status

pg_ctl: o servidor está em execução (PID: 87688)
/Users//pg_software/11.5/bin/postgres "-D"
"/Users//pg_software/11.5/data"

Uma opção alternativa para verificar se o PostgreSQL está em execução é verificar o status do processo da seguinte
forma:

$ ps -ef|grep postgres
1363659639 87690 87688 0 22:47 ?? checkpointer 1363659639 0:00.00 postgres:
87691 87688 0 22:47 ?? escritor de plano de fundo 1363659639
87692 87688 0 22:47 ?? escritor de parede 0:00.01 postgres:

0:00.05 postgres:

1363659639 87693 87688 0 22:47 ?? lançador de vácuo 0:00.05 postgres:

automático
1363659639 87694 87688 0 22:47 ?? colecionador 0:00.04 postgres: estatísticas

1363659639 87695 87688 0 22:47 ?? iniciador de replicação 0:00.05 postgres: lógico

1363659639 87688 0:00.03 /Users//pg_software/11.5/bin/
postgres -D /Users//pg_software/11.5/data 1363659639
1 0 22:47 ttys002 87705 27416 0 22:48 ttys002

0:00.01 grep postgres

$

Se você descobriu que o cluster está em execução e ainda não consegue se conectar, verifique o número da porta
no arquivo postgresql.conf e tente conectar usando a porta correta.

$ grep -i porta $ PGDATA/postgresql.conf # (mudança requer

reinicialização) porta = 5432

Erro

psql -p 5435 -U postgres -h 192.168.225.185 postgres psql: não foi possível conectar ao
servidor: Conexão recusada O servidor está rodando no host "192.168.225.185" e aceitando
Machine Translated by Google

Conexões TCP/IP na porta 5432?

Causa/ Resolução
Este erro significa que não há serviço escutando na porta especificada: 5432. Isso pode ser porque o PostgreSQL
(postmaster) não está escutando uma conexão de entrada na porta da interface de rede. O padrão para a maioria das
distribuições do PostgreSQL é escutar apenas na interface de loopback. 1.

Você precisaria ver seu parâmetro “listen_addresses” no arquivo postgresql.conf; verifique se você definiu isso para
permitir as interfaces de rede disponíveis. Uma configuração parainterfaces.
* fará com que o PostgreSQL escute em todas as

$ psql -p 5432 -U postgres -d postgres psql (11.5)

Digite "ajuda" para obter ajuda.

postgres=# show listen_addresses ; listen_addresses

------------------
localhost (1
linha)

postgres=#

2.
Se você descobriu que configurou para permitir, terá que verificar a configuração do firewall. A porta pode estar
bloqueada pelo firewall desse servidor por motivos de segurança.

Erro

psql -p 5435 -U postgres -h 192.168.225.185 postgres psql: FATAL: nenhuma entrada

pg_hba.conf para o host "192.168.225.130", usuário "postgres", banco de dados "postgres", SSL desativado

Causa/ Resolução
Como diz o erro, não há entrada no arquivo pg_hba.conf (que está localizado no local do diretório de dados) para a política
HBA (Host Based Authentication) para o servidor. Você pode adicionar uma entrada para esse host como o seguinte:

Abra o pg_hba.conf localizado no diretório de dados do servidor PostgreSQL.

$ vi $ PGDATA / pg_hba.conf
Adicione uma linha como esta:

hospedeiro tudo tudo 192.168.225.130/32 Confiar em

Observação A confiança é um tipo de autenticação. Você obterá mais

informações aqui: www.postgresql.org/docs/current/auth-pg-hba-conf.html.

Esta política permite uma conexão de cliente PostgreSQL de 192.168.225.130.

Recarregue a configuração.

$ pg_ctl -D $PGDATA recarregar servidor

sinalizado

Agora tente conectar.

$ psql -p 5435 -U postgres -h 192.168.225.185 postgres psql (11.5)

Machine Translated by Google

Digite "ajuda" para obter ajuda.

postgres=#

Como você pode ver, a nova política de HBA permite a conexão da máquina cliente.

Erros de configuração
Erro

$ psql -p 5432 -U postgres -d postgres psql.bin: FATAL:

desculpe, muitos clientes já
Causa/ Resolução

Esse erro nos informa que o número total de conexões de clientes atingiu o max_connections; verifique o
parâmetro e as conexões com o cluster de uma sessão já conectada:

postgres=# show max_connections ;

max_connections
-----------------
2
(1 linha)

postgres=# selecione count(*) de pg_stat_activity; contar

-------

2 (1 linha)

Para se livrar disso, você provavelmente precisará aumentar o parâmetro ou desconectar algumas sessões
“inativas” do lado do aplicativo. Encerrar conexões inativas do back-end pode ser perigoso, pois o lado do aplicativo pode
receber um erro. Mas você pode selecionar conexões ociosas ad hoc para terminação. Você obterá sessões ociosas
usando a seguinte consulta:

postgres=# selecione pid,query,state de pg_stat_activity onde estado como 'idle'; pid | consulta | Estado

-------+-------+-------
11855 | | parado
(1 linha)

postgres=# selecione pg_terminate_backend(pid) de pg_stat_activity onde state="idle" e pid <>

pg_backend_pid(); pg_terminate_backend

-----------------------
t
(1 linha)

postgres=# selecione pid,query,state de pg_stat_activity onde estado como 'idle'; pid | consulta | Estado

-----+-------+-------
(0 linhas)

Observação A alteração de qualquer um dos parâmetros anteriores requer uma reinicialização do cluster.

Erro
Machine Translated by Google

psql -p 5432 -U test postgres

psql.bin: FATAL: os slots de conexão restantes são reservados para conexões de superusuário sem replicação

Causa/ Resolução
Como diz o erro, as conexões restantes são reservadas para superusuários. Portanto, você precisaria aumentar
o parâmetro max_connections ou diminuir o parâmetro superuser_reserved_connections para se conectar como *normal*
do utilizador.

Observação A alteração de qualquer parâmetro max_connections ou superuser_reserved_connections requer uma reinicialização

do cluster.

Erro
ERRO: cancelando declaração devido ao tempo limite da declaração

Causa/ Resolução Use

statement_timeout para limpar consultas que demoram muito. Muitas vezes, você sabe que não tem nenhum uso para consultas
executando mais de x segundos. Talvez seu front-end da Web simplesmente se recuse a esperar mais de 10 segundos para que
uma consulta seja concluída e retorne alguma resposta padrão aos usuários se demorar mais, abandonando a consulta.
Nesse caso, é uma boa ideia definir statement_timeout = 15 sec no postgresql.conf ou como uma configuração por usuário ou por banco de
dados, para que as consultas executadas por muito tempo não consumam recursos preciosos e façam com que as consultas de outros falhem
como Nós vamos.
As consultas encerradas pelo tempo limite da instrução aparecem no log da seguinte maneira:

hannu=# set statement_timeout = '3 s';

SET
hannu=# selecione pg_sleep (10);
ERRO: cancelando declaração devido ao tempo limite da declaração

Erros de consulta
Erro

postgres=# selecione * do teste;

ERRO: relação "teste" não existe
LINHA 1: selecione * do teste;
^

Causa/ Resolução
1.
Como primeiro passo, certifique-se de que esta tabela realmente existe.
2.
Se a tabela existir, verifique se o nome da tabela fornecido está correto ou não. Você pode ter criado a tabela com
caracteres mistos (superior/inferior). Você pode obter o nome exato usando esta consulta:

postgres=# selecione quote_literal(relname) de pg_class onde upper(relname)='TEST'; citação_literal

---------------
'TesT' (1
linha)
postgres=# selecione * de "TesT";
t
---

(0 linhas)

Verifique se você tem a tabela em um esquema diferente para poder especificar o nome do esquema explicitamente antes do
Machine Translated by Google

Verifique se você tem a tabela em um esquema diferente para poder especificar o nome do esquema explicitamente antes do
3. nome da tabela OU defina o nome do esquema no parâmetro search_path:

postgres=# \d '*'."TesT"

Tabela "teste.TesT"
Coluna | Tipo | Modificadores
--------+---------+-----------
t | inteiro |

Então, você tem a tabela no esquema “teste”, então use a seguinte consulta ou defina search_path como mostrado:

postgres=# selecione * de "teste".."TesT";

t
---
(0 linhas)

postgres=# defina search_path para "teste";

SET
postgres=# selecione * de "TesT";
t
---
(0 linhas)

Erro

testdb=# solte o usuário bob;

ERRO: o papel "bob" não pode ser descartado porque alguns objetos dependem dele
DETALHE: dono da tabela bobstable dono da
sequência bobstable_id_seq

Causa/ Resolução Não

deve haver nenhum objeto pertencente ao usuário quando estivermos tentando eliminar um usuário. Para descartar esses
usuários, existem dois métodos: 1.

Reatribua todos os objetos pertencentes ao usuário para algum outro usuário e, em seguida, elimine o usuário.
Isso é muito útil se o funcionário que saiu da empresa escreveu algum procedimento/objetos que estão
sendo usados em um aplicativo/processo.

REASSIGN PROPRIEDADE DE old_role para new_role;

DROP USER função_antiga;

Nota O comando reatribuir precisa ser executado para todos os bancos de dados em uma instância do PG.

2.
Primeiro, elimine todos os objetos pertencentes ao usuário e, em seguida, elimine o usuário.

Isso é útil se o administrador não quiser manter os objetos dos usuários e quiser descartar todos os objetos pertencentes
ao usuário.
Um comando que pode ser usado é o seguinte:

DROP DE PROPRIEDADE nome [, ...] [ CASCADE | RESTRITO ]; DROP

nome de usuário do usuário;

Observação O nome DROP OWNED BY precisa ser executado em todos os bancos de dados.
Machine Translated by Google

Outros erros
Erro

"LOG: fora dos descritores de arquivo: Muitos arquivos abertos no sistema; libere e tente novamente"

Causa/ Resolução Se
você vir esta mensagem de erro em um arquivo de log, considere reduzir a configuração max_files_per_process do Postgres.

Erro

postgres=> copie o teste de '/tmp/test.txt'; ERRO: deve ser

superusuário para COPIAR de ou para um arquivo DICA: Qualquer pessoa
pode COPIAR para stdout ou de stdin. O comando \copy do psql também funciona para qualquer pessoa.

Causa/ Resolução

Como diz o erro, um usuário normal não pode copiar de um arquivo para uma tabela. Você pode usar “\COPY” em vez disso.

postgres=> selecione usuário_atual; usuário

atual
--------------
teste
(1 linha)

postgres=> \copiar teste de '/tmp/test.txt';

postgres=> selecione * do teste;

t
---
1

2 3 4 5 (5 linhas)

OU
Para permitir que um usuário “teste” copie diretamente de um arquivo, o superusuário pode escrever uma função wrapper especial para o usuário
“teste”, como segue:

criar ou substituir a função copy_for_testuser(texto do nome da tabela, texto do caminho do arquivo)

retorna o definidor de segurança void

Como

$$
declare
start
execute 'copy ' || nome da tabela || ' from "' || caminho do arquivo || "";
fim; $
$ idioma plpgsql;

postgres=# \c postgres test Agora você

está conectado ao banco de dados "postgres" como usuário "test". postgres=>
Machine Translated by Google

postgres=> selecione copy_for_testuser('test','/tmp/test.txt'); copy_for_testuser

-------------------

(1 linha)

postgres=> selecione * do teste;

t
---
1

2 3 4 5 (5 linhas)

Erro
ERRO: tablespace "old_tablespace" não está vazio

Causa/ Resolução
Como diz o erro, o diretório do tablespace deve estar vazio se você estiver criando um novo tablespace. Tente
criar um novo diretório ou remova o conteúdo do diretório atual se não for útil.

Erro

postgres=# INSERT INTO cust_view postgres-

# VALUES (5, 'nome', 'sobrenome', 133); ERRO: não é possível inserir em
uma visualização DICA: Você precisa de uma regra incondicional ON
INSERT DO INSTEAD.

Causa/ Resolução
Você pode inserir diretamente em uma visualização. Então, vamos tentar o que a HINT diz no erro.

CRIAR REGRA cust_view_insert AS ON

insert TO cust_view DO INSTEAD INSERT
INTO cust VALUES (new.customerid,
new.firstname, new.lastname, new.age);

E agora tente novamente nosso INSERT da seguinte forma:

postgres=# INSERT INTO cust_view

postgres-# VALORES (5, 'nome', 'sobrenome', 133);

INSERIR 0 1

Erro

postgres=> defina log_min_duration_statement para 0;

ERRO: permissão negada para definir o parâmetro "log_min_duration_statement"

Causa/ Resolução
Vários dos parâmetros que controlam o log são reservados para serem usados apenas por superusuários.
Se você quiser permitir que alguns de seus desenvolvedores definam o logon e se puder escrever uma função para eles fazerem exatamente
isso:

criar ou substituir a função debugging_info_on()

Machine Translated by Google

retorna o definidor
de segurança void
Como

$$ start set
client_min_messages para 'DEBUG1'; defina
log_min_messages para 'DEBUG1'; defina
log_error_verbosity para 'VERBOSE'; defina
log_min_duration_statement como 0; fim; $$ idioma
plpgsql;

revogue tudo na função debugging_info_on() de public;

conceder execução na função debugging_info_on() para bob;

Erro

postgres=# CRIAR OU SUBSTITUIR VIEW test_view

AS SELECT id como title2 FROM test;
ERRO: não é possível alterar o nome da coluna de visualização "title1" para "title2"

Causa/ Resolução
Se você deseja alterar a definição de saída de uma função ou exibição, o uso de CREATE OR REPLACE não é
suficiente. Nesse caso, você deve usar DROP e recriar, da seguinte forma:

postgres=# CRIAR OU SUBSTITUIR VIEW test_view AS postgres-#

SELECT id como title1 FROM test;
CRIAR VISUALIZAÇÃO

postgres=# CRIAR OU SUBSTITUIR VIEW test_view AS postgres-#

SELECT id como title2 FROM test;
ERRO: não é possível alterar o nome da coluna de visualização "title1" para "title2"

postgres=# DROP VIEW test_view;

RETIRAR VISUALIZAÇÃO

postgres=# CRIAR OU SUBSTITUIR VIEW test_view AS postgres-#

SELECT id como title2 FROM test;
CRIAR VISUALIZAÇÃO

Erro

FATAL: não foi possível criar segmento de memória compartilhada: argumento inválido
DETALHE: falha na chamada do sistema foi shmget(key=5440001, size=4011376640, 03600

Causa/ Resolução
Quando o PostgreSQL é iniciado, ele gera um erro como o anterior; sua configuração de memória compartilhada é menor
do que o que o PostgreSQL está tentando criar (4011376640 bytes neste exemplo). Ou seu kernel não está configurado para
suportar memória compartilhada no estilo System-V. Como solução temporária, você pode tentar iniciar o servidor com um número
de buffers menor que o normal (shared_buffers). No entanto, você deve reconfigurar sua configuração de memória compartilhada
no nível do kernel. Outra razão pela qual esse erro pode ocorrer é quando você tem vários servidores PostgreSQL em execução na
mesma máquina. Nesse caso, a memória compartilhada de todos os servidores não deve exceder o limite do kernel.

Nota A alteração de shared_buffers requer uma reinicialização da instância do PostgreSQL.

Erro
Machine Translated by Google

Em pg_log, "pgstat wait timeout"

Causa/ Resolução Este

aviso pode ocorrer em vários casos.

Caso 1 { Enorme IO }

Quando o processo de autovacuum do PostgreSQL não consegue obter o IO necessário para gravar as estatísticas
em “stats_temp_directory”, podemos receber esse tipo de mensagem de AVISO. Conforme discutido, os checkpoints frequentes são
uma boa indicação de alta IO. Pontos de verificação frequentes criarão mais E/S e, para analisar os pontos de verificação, é
recomendável habilitar log_checkpoints.
Como registrar as informações dos pontos de verificação:

1.
Edite o arquivo postgresql.conf como log_checkpoints = on
2.
Selecione Pg_Reload_Conf();

Caso 2 {stats_temp_location inválido}

Quando o “stats_temp_directory” do PostgreSQL está em um caminho inválido, nesse caso também podemos esperar esse
tipo de mensagem de AVISO. Se você quiser alterar esse local para algum outro lugar, precisará seguir a abordagem abaixo.

1.
Edite o arquivo postgresql.conf como stats_temp_location='<PATH>'
2.
Selecione pg_reload_conf();

Caso 3 {IP de host local inválido}

Pode haver uma chance de termos um IP Localhost inválido. Por favor, verifique as entradas localhost nos “hosts”
arquivar e corrigir se algo estiver errado.
Assim que fizermos qualquer alteração neste arquivo, precisamos reiniciar o cluster do PostgreSQL para que tenha efeito no auto
processos de trabalho a vácuo.

Consultas Úteis do PostgreSQL Esta seção contém

algumas consultas básicas que são úteis diariamente. Essas consultas são categorizadas da seguinte forma: Consultas básicas
Consultas de monitoramento Consultas de privilégios de objeto Consultas em nível de objeto

Consultas básicas
Vejamos algumas consultas básicas.

Para verificar a versão

selecione a versão();

Para verificar o tamanho do banco de dados

SELECT pg_size_pretty(pg_database_size('mydatabasename')) As fulldbsize;

Para obter todas as tabelas do catálogo

Machine Translated by Google

\dt pg_catalog.*

Consultas de
monitoramento As consultas nesta seção o ajudarão quando você estiver monitorando seu banco de dados diariamente.

As 10 principais tabelas de escrita

selecione schemaname como "Schema Name", relname como "Table Name",

n_tup_ins+n_tup_upd+n_tup_del como "no.of writes" de pg_stat_all_tables onde
schemaname não está em ('snapshots','pg_catalog') ordem por n_tup_ins+n_tup_upd+n_tup_del
desc limite 10;

As 10 principais tabelas de leitura

SELECT schemaname como "Schema Name", relname como "Table

Name", seq_tup_read+idx_tup_fetch como "no. of reads" FROM
pg_stat_all_tables WHERE (seq_tup_read + idx_tup_fetch) > 0 e schemaname NOT
IN ('snapshots','pg_catalog') ORDER BY seq_tup_read+idx_tup_fetch desc limite 10;

Maiores tabelas no banco de dados

SELECT QUOTE_IDENT(TABLE_SCHEMA)||'.'||QUOTE_IDENT(table_name) as
table_name,pg_relation_size(QUOTE_IDENT(TABLE_SCHEMA)||'.'||QUOTE_IDENT(table_
pg_total_relation_size(QUOTE_IDENT(TABLE_SCHEMA)||'.'||QUOTE_IDENT( table_name)
pg_size_pretty(pg_relation_size(QUOTE_IDENT(TABLE_SCHEMA)||'.'||QUOTE_IDENT(ta
pretty_relation_size,pg_size_pretty(pg_total_relation_size(QUOTE_IDENT(TABLE_S as
pretty_total_relation_size FROM information_schema.tables WHERE QUOTE_IDENT ORDER BY size;

Tamanho do banco de dados

SELECT datname, pg_database_size(datname),

pg_size_pretty(pg_database_size(datname))
DE pg_database
ORDEM POR 2 DESC;

Tamanho da tabela

SELECT schemaname, relname, pg_total_relation_size(schemaname || '.' ||

relname ) , pg_size_pretty(pg_total_relation_size(schemaname || '.' || relname ))

FROM pg_stat_user_tables
ORDER BY 3 DESC;

Tamanho do índice

SELECT schemaname, relname, indexrelname,

pg_total_relation_size(schemaname || '.' || indexrelname ) ,
pg_size_pretty(pg_total_relation_size(schemaname || '.' || indexrelname ))

FROM pg_stat_user_indexes
ORDER BY 1,2,3,4 DESC;

Utilização do índice
Machine Translated by Google

SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_fetch, idx_tup_read

DE pg_stat_user_indexes
ORDEM POR 4 DESC,1,2,3;

Tabelas que estão sendo mais atualizadas e em busca de VACUUM

selecione relname, /* pg_size_pretty( pg_relation_size( relid ) ) como table_size,

pg_size_pretty( pg_total_relation_size( relid ) ) como

table_total_size, */
n_tup_upd, n_tup_hot_upd, n_live_tup, n_dead_tup, last_vacuum::date,
last_autovacuum::date, last_analyze::date, last_autoanalyze::date de pg_stat_all_tables
onde relid em (selecione oid de pg_class

onde relnamespace não está (selecione oid de

pg_namespace
onde nspname em ('information_schema',
'pg_catalog','pg_toast', 'edbhc' ) ) ) ordem por
n_tup_upd desc, schemaname, relname;

SELECT schemaname,
relname,
now() - last_autovacuum AS "noautovac", now() -
last_vacuum AS "novac", n_tup_upd, n_tup_del,
autovacuum_count, last_autovacuum, vacuo_count,
last_vacuum

DE pg_stat_user_tables
WHERE (agora() - last_autovacuum > '7 dias'::interval
AND now() - last_vacuum >'7 days'::interval)
OR (last_autovacuum IS NULL AND last_vacuum IS NULL ) AND n_dead_tup
>0
ORDEM POR novac DESC;

SELECT relname, n_live_tup, n_dead_tup,

trunc(100*n_dead_tup/(n_live_tup+1))::float "ratio%",
to_char(last_autovacuum, 'YYYY-MM-DD HH24:MI:SS') como autovacuum_date,
to_char(last_autoanalyze , 'AAAA-MM-DD HH24:MI:SS') como autoanalyze_date
FROM pg_stat_all_tables onde schemaname não está em
('pg_toast','pg_catalog','information_schema')
ORDER BY last_autovacuum ;

Índice inchado para executar a reindexação (operação de bloqueio)\pgrepack (reconstrução online)

SELECT current_database(), nspname AS schemaname, tblname, idxname, bs* (relpages)::bigint

AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size, 100 * (relpages-
est_pages)::float
est_pages_ff)/ relpages AS extra_ratio,
AS bloat_size, fillfactor, bs*(relpages-
100 * (relpages-est_pages_ff)::float /relpages AS
bloat_ratio, is_na
Machine Translated by Google

-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,

maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages -- (DEBUG INFO)

FROM
( SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata
pagehdr)/(4+nulldatahdrwidth)::float)), 0 -- Tamanho do ItemIdData + tamanho médio calculado de uma tupla
(nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*)
(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff, bs,
nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- ,
stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst, index_tuple_hdr_bm,
maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples -- (DEBUG INFO)

FROM
( SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +

maxalign - CASE -- Adiciona preenchimento ao cabeçalho da tupla de índice para alinhar

em MAXALIGN
QUANDO index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
FIM
+ nulldatawidth + maxalign - CASE -- Adiciona preenchimento aos dados para alinhar em
MAXALIGN
QUANDO nulldatawidth = 0 THEN 0
WHEN nulldatawidth :: integer% maxalign = 0 THEN maxalign
ELSE nulldatawidth :: integer% maxalign
FIM
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na , index_tuple_hdr_bm,
-- nulldatawidth -- (DEBUG INFO)
A PARTIR DE (
SELECIONAR

i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,

current_setting('block_size')::numeric AS bs, fillfactor, CASE -- MAXALIGN: 4 em

32 bits, 8 em 64 bits (e mingw32 ?)
QUANDO versão() ~ 'mingw32' OU versão() ~ '64-
bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign, /*
por cabeçalho de página, tamanho fixo: 20 para 7.X, 24 para outros */ 24 AS pagehdr, /*
por página btree dados opacos */ 16 AS pageopqdata, /* por cabeçalho de tupla: add
IndexAttributeBitMapData se algumas colunas forem nulas */

CASE WHEN max(coalesce(s.null_frac,0)) = 0 THEN 2 --

Tamanho IndexTupleData ELSE 2 + (( 32 + 8 - 1 ) / 8) --
Tamanho IndexTupleData + IndexAttributeBitMapData tamanho ( max num
arquivado por índice + 8 - 1/8)
END AS index_tuple_hdr_bm,
Machine Translated by Google

/* data len: removemos valores nulos economizamos espaço usando a parte fracionária das
estatísticas */ sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS

nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a JOIN ( SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples , idx.relpages, idx.relam,

indrelid, indexrelid, indkey::smallint[] AS attnum, coalesce(substring(

array_to_string(idx.reloptions, ' ') from

'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
DE pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid JOIN pg_class tbl
ON tbl.oid=pg_index.indrelid JOIN pg_namespace ON pg_namespace.oid
= idx.relnamespace WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND
idx.relpages >
0
) AS i ON a.attrelid = i.indexrelid JOIN pg_stats AS
s ON s.schemaname = i.nspname AND ((s.tablename = i.tblname
AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum,
TRUE)) -- estatísticas de tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))-- estatísticas de colunas funcionais

JOIN pg_type AS t ON a.atttypid = t.oid

WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9 ) AS s1 ) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE
am.amname = 'btree'

) AS sub --
WHERE NOT is_na
ORDER BY 2,3,4;

Tabelas inchadas para fazer Vacuumfull (operação de bloqueio)\pgrepack (reconstrução online)

SELECT current_database(), schemaname, tblname, bs*tblpages AS real_size,

(tblpages-est_tblpages)*bs AS extra_size,
CASE WHEN tblpages - est_tblpages > 0
ENTÃO 100 * (tblpages - est_tblpages)/tblpages::float
MAIS 0
END AS extra_ratio, fillfactor, (tblpages-est_tblpages_ff)*bs AS bloat_size, CASE WHEN
tblpages - est_tblpages_ff > 0 THEN 100 ELSE 0 END AS bloat_ratio, is_na , (pst).free_percent
+ (pst).dead_tuple_percent AS real_frag FROM ( SELECT ceil ( reltuples / ( (bs-page_hdr)/
tpl_size ) ) + ceil( toasttuples
* (tblpages - est_tblpages_ff)/tblpages::float

--

/ 4 ) AS est_tblpages,
ceil(reltuples / ((bs-page_hdr)*fillfactor/(tpl_size*100))) + ceil(
toasttuples / 4) AS is_tblpages_ff,
Machine Translated by Google

tblpages, fillfactor, bs, tblid, schemaname, tblname, heappages, toastpages, is_na ,

stattuple.pgstattuple(tblid) AS pst FROM ( SELECT
--

(4 + tpl_hdr_size + tpl_data_size + (2*ma)

- CASE WHEN tpl_hdr_size%ma = 0 THEN ma ELSE tpl_hdr_size%ma END
- CASE WHEN ceil(tpl_data_size)::int%ma = 0 THEN ma ELSE
ceil(tpl_data_size)::int%ma END
) AS tpl_size, bs - page_hdr AS size_per_block, (heappages +
toastpages) AS tblpages, heappages,
toastpages, reltuples, toasttuples, bs, page_hdr, tblid, schemaname, tblname, fillfactor, is_na

A PARTIR DE (
SELECIONAR

tbl.oid AS tblid, ns.nspname AS schemaname, tbl.relname AS tblname,

tbl.reltuples,
tbl.relpages AS heappages, coalesce(toast.relpages, 0) AS toastpages,
coalesce(toast.reltuples, 0) AS toasttuples, coalesce(substring(

array_to_string(tbl.reloptions, ' ')

FROM '%fillfactor=#"__#"%' FOR '#')::smallint, 100) AS fillfactor,
current_setting('block_size')::numeric AS bs,
CASE WHEN version()~'mingw32' OR version()~'64-
bit|x86_64|ppc64|ia64|amd64' THEN 8 ELSE 4 END AS ma,
24 AS página_hdr,
23 + CASE WHEN MAX(coalesce(null_frac,0)) > 0 THEN ( 7 + count(*) )
/ 8 ELSE 0::int END
+ CASE WHEN tbl.relhasoids THEN 4 ELSE 0 END AS tpl_hdr_size, sum( (1-
coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024) ) AS
tpl_data_size,
bool_or(att.atttypid = 'pg_catalog.name'::regtype) AS is_na FROM pg_attribute AS att

JOIN pg_class AS tbl ON att.attrelid = tbl.oid JOIN pg_namespace

AS ns ON ns.oid = tbl.relnamespace JOIN pg_stats AS s ON
s.schemaname=ns.nspname
AND s.tablename = tbl.relname AND s.inherited=false AND s.attname=att.attname

LEFT JOIN pg_class AS toast ON tbl.reltoastrelid = toast.oid

WHERE att.attnum> 0 AND NOT att.attisdropped AND tbl.relkind
= 'r'
GROUP BY 1,2,3,4,5,6,7,8,9,10, tbl.relhasoids ORDER BY 2,3 )
AS s ) AS s2 ) AS s3;

Tabelas inchadas em tempo real

selecione relname, n_live_tup, n_dead_tup, (n_dead_tup/

(n_dead_tup+n_live_tup)::float)*100 como "% of bloat", last_autovacuum, last_autoanalyze de
pg_stat_all_tables onde (n_dead_tup+n_live_tup) > 0 e (n_dead_tup/
(n_dead_tup+n_live_tup)) ::float)*100 > 0;
Machine Translated by Google

Obter nome e valor de pg_settings

selecione nome, configuração de pg_settings;

Índices nunca usados

COM table_scans como (

SELECT relíquia,
tables.idx_scan + tables.seq_scan como all_scans, ( tables.n_tup_ins
+ tables.n_tup_upd + tables.n_tup_del ) como
escreve,
pg_relation_size(relid) como table_size
DE pg_stat_user_tables como tabelas
),
tudo_escreve como (
SELECT sum(writes) como total_writes
FROM table_scans
),
indexa como
( SELECT idx_stat.relid, idx_stat.indexrelid, idx_stat.schemaname,
idx_stat.relname como tablename, idx_stat.indexrelname como indexname,
idx_stat.idx_scan, pg_relation_size(idx_stat.indexrelid) como index_bytes,
indexdef ~* 'USING btree' AS idx_is_btree

DE pg_stat_user_indexes como idx_stat

JOIN pg_index
USING (indexrelid)
JOIN pg_indexes como índices ON
idx_stat.schemaname = indexes.schemaname
AND idx_stat.relname = indexes.tablename AND
idx_stat.indexrelname = indexes.indexname ONDE
pg_index.indisunique = FALSE
),
index_ratios AS ( SELECT
schemaname, tablename, indexname, idx_scan, all_scans,
round(( CASE WHEN all_scans = 0 THEN
0.0::NUMERIC ELSE idx_scan::NUMERIC/all_scans * writes, round((CASE
WHEN writes = 0 THEN idx_scan: :NUMERIC ELSE 100 END),2) como index_scan_pct,
idx_scan::NUMERIC/writes END),2) como scans_per_write,

pg_size_pretty(index_bytes) como index_size,

pg_size_pretty(table_size) como table_size, idx_is_btree,
index_bytes
DE índices
JOIN table_scans
USANDO (relid)
),
index_groups AS (
SELECT 'Never Used Indexes' como motivo, *, 1 como grp
FROM index_ratios
ONDE
idx_scan = 0 e
idx_is_btree
Machine Translated by Google

UNIÃO TODOS
SELECT 'Low Scans, High Writes' como motivo, *, 2 como grp
FROM index_ratios
ONDE
scans_per_write <= 1 e
index_scan_pct < 10 e idx_scan >
0 e escreve > 100 e idx_is_btree

UNIÃO TODOS
SELECT 'Raramente usado índices grandes' como motivo, *, 3 como grp
FROM index_ratios
ONDE
index_scan_pct < 5 e
scans_per_write > 1 e idx_scan >
0 e idx_is_btree e index_bytes >
100000000 UNION ALL SELECT
'High-Write Large Non-Btree' como
motivo, index_ratios.*, 4 como grp FROM
index_ratios, all_writes WHERE

( writes::NUMERIC / ( total_writes + 1 ) ) > 0.02 AND NOT idx_is_btree

AND index_bytes > 100000000 ORDER BY grp, index_bytes DESC )

SELECT motivo, nome do esquema, nome da tabela, nome do índice,

index_scan_pct, scans_per_write, index_size, table_size
FROM index_groups;

Idade do banco de dados e tabelas

SELECT dataname, age(datfrozenxid) FROM pg_database;

SELECT c.oid::regclass como table_name,

greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age FROM pg_class c LEFT JOIN
pg_class t ON c.reltoastrelid = t.oid WHERE c.relkind IN ('r', 'm');

Índices duplicados

SELECT
indrelid::regclass AS
TableName ,array_agg(indexrelid::regclass) AS Indexes
DE pg_index
GROUP BY
indrelid,
indkey
TENDO CONTAGEM(*) > 1;

Consultas bloqueadas

SELECT bloqueado_locks.pid AS Blocked_pid,

Blocked_activity.usename AS Blocked_user, Blocking_locks.pid
AS Blocking_pid,
Machine Translated by Google

Blocking_activity.usename AS Blocking_user, Block_activity.query AS

Blocked_statement, Blocking_activity.querycurrent_statement_in_blocking_process
AS
FROM pg_catalog.pg_locks Blocked_locks JOIN pg_catalog.pg_stat_activity Blocked_activity ON
Block_activity.pid = Blocked_locks.pid JOIN pg_catalog.pg_locks blocking_locks

ON blocking_locks.locktype = block_locks.locktype E blocking_locks.DATABASE

NÃO É DISTINTO DE
bloqueado_locks.DATABASE
E a relação de bloqueios_bloqueio NÃO É DISTINTA DE
bloqueado_locks.relation
E blocking_locks.page NÃO É DISTINTO DE Blocks_locks.page E blocking_locks.tuple NÃO É
DISTINTO DE Blocks_locks.tuple E blocking_locks.virtualxid NÃO É DISTINTO DE

bloqueado_locks.virtualxid
E bloqueio_bloqueio.transactionid NÃO É DISTINTO DE bloqueado_bloqueio.transactionid
E bloqueio_bloqueio.classid NÃO É DISTINTO DE

bloqueado_locks.classid
E bloqueio_bloqueio.objid NÃO É DISTINTO DE bloqueado_bloqueio.objid E bloqueio_bloqueio.objsubid
NÃO É DISTINTO DE
block_locks.objsubid
E bloqueio_bloqueio.pid != bloqueio_bloqueio.pid
JOIN pg_catalog.pg_stat_activity bloqueando_atividade ON bloqueando_atividade.pid
= bloqueando_locks.pid WHERE NOT bloqueado_locks.GRANTED;

Sessão de bloqueio :
SELECT bl.pid AS
block_pid, a.query AS
block_statement, agora ( ) - ka.query_start AS
Blocking_duration, kl.pid AS blocking_pid, a.query AS Blocked_statement,
now ( ) - a.query_start AS Blocked_duration FROM pg_catalog. pg_locks
bl JOIN pg_catalog.pg_stat_activity a ON bl.pid = a.pid JOIN
pg_catalog.pg_locks kl JOIN pg_catalog.pg_stat_activity ka ON kl.pid =
ka.pid ON bl.transactionid = kl.transactionid

E bl.pid != kl.pid
ONDE NÃO bl.concedido; Consulta
de bloqueio: SELECT
bloqueado_locks.pid AS Blocked_pid,
Block_activity.usename AS Blocked_user, Blocking_locks.pid AS
Blocking_pid, Blocking_activity.usename
Block_activity.query
AS Blocking_user,AS
Blocked_statement, Block_activity.query AS
current_statement_in_blocking_process FROM Blocked_locks
pg_catalog.pg_locks
JOIN
pg_catalog.pg_stat_activity Blocked_activity ON Block_activity.pid = bloqueado_locks.pid JOIN
pg_catalog.pg_locks blocking_locks

ON blocking_locks.locktype = block_locks.locktype E blocking_locks.DATABASE

NÃO É DISTINTO DE
bloqueado_locks.DATABASE
Machine Translated by Google

E a relação de bloqueios_bloqueio NÃO É DISTINTA DE

bloqueado_locks.relation
E blocking_locks.page NÃO É DISTINTO DE Blocks_locks.page E blocking_locks.tuple NÃO É
DISTINTO DE Blocks_locks.tuple E blocking_locks.virtualxid NÃO É DISTINTO DE

bloqueado_locks.virtualxid
E bloqueio_bloqueio.transactionid NÃO É DISTINTO DE bloqueado_bloqueio.transactionid
E bloqueio_bloqueio.classid NÃO É DISTINTO DE

bloqueado_locks.classid
E bloqueio_bloqueio.objid NÃO É DISTINTO DE bloqueado_bloqueio.objid E bloqueio_bloqueio.objsubid
NÃO É DISTINTO DE
block_locks.objsubid
E bloqueio_bloqueio.pid != bloqueio_bloqueio.pid JOIN
pg_catalog.pg_stat_atividade bloqueio_atividade ON bloqueio_atividade.pid = bloqueio_bloqueio.pid WHERE NOT
bloqueio_bloqueio.GRANTADO;

Consultas em execução lenta no banco de dados dos últimos 5 minutos

selecione now()-query_start como Running_Since,pid, datname, usename, application_name, client_addr,

left(query,60) de pg_stat_activity onde state in ('active','idle in transaction') e (now() - pg_stat_activity.query_start ) >
intervalo '2 minutos';

Excluir valores duplicados em uma tabela usando CTID (pseudo coluna)

DELETE FROM engana

WHERE a.ctid <> (SELECT min(b.ctid)
FROM dupes b
WHERE a.key = b.key);

Número total de transações executadas em todos os bancos de dados

SELECT soma(xact_commit+xact_rollback) FROM pg_stat_database;

Consultas de privilégios de
objeto Esta seção fornece as consultas que você pode usar para obter privilégios em nível de objeto ou esquema.

Conceder privilégios em todas as mesas

SELECT 'concede selecionar, atualizar, usar em '||c.relname||' para nome de usuário;' FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace

WHERE c.relkind IN ('r',") AND n.nspname='schemaname' AND

pg_catalog.pg_get_userbyid(c.relowner)='username';

Verifique os privilégios nas mesas

SELECT n.nspname como "Schema", c.relname

como "Name", CASE c.relkind WHEN 'r'
THEN 'table' WHEN 'v' THEN 'view' QUANDO 'S' THEN
'sequence' END como "Type",
pg_catalog.array_to_string(c.relacl, E'\n') AS "Privilégios de acesso", pg_catalog.array_to_string(ARRAY( SELECT
attname || E':\n ' || pg_catalog.array_to_string (atacl, E'\n')
Machine Translated by Google

FROM pg_catalog.pg_attribute a WHERE

attrelid = c.oid AND NOT attisdropped AND attacl IS NOT NULL ), E'\n') AS "Privilégios de
acesso à coluna"
FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace ONDE c.relkind IN
('r') AND pg_catalog.pg_get_userbyid(c.relowner)='username' AND n.nspname='schemaname' ;

Encontre todas as funções com argumentos

SELECT n.nspname || '.' || p.proname || '(' ||

pg_catalog.oidvectortypes(p.proargtypes) || ')' as FunctionName,usename as OWNER FROM pg_proc
p LEFT JOIN pg_catalog.pg_namespace n ON n.oid = p.pronamespace, pg_user u WHERE
p.prorettype <> 'pg_catalog.cstring'::pg_catalog.regtype AND p.proargtypes[0] <>
'pg_catalog.cstring'::pg_catalog.regtype AND pg_catalog.pg_function_is_visible(p.oid) AND
p.proowner=u.usesysid AND n.nspname não em ('pg_catalog','sys');

selecione prona.me||'('||pg_get_function_arguments(pg_proc.oid)||')' como

function_arguments,usename,nspname de pg_proc,pg_user,pg_namespace onde
proowner=pg_user.usesysid e pronamespace=pg_namespace.oid e usename<> nspname e
nspname !~ '^pg_catalog|^information_schema|^sys';

Encontrar privilégios de um usuário em objetos

SELECT n.nspname como "Schema",

c.relname como "Name", CASE
c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' QUANDO 'S' THEN
'sequência' WHEN 'f' THEN 'tabela estrangeira' END como "Tipo",
pg_catalog.array_to_string(c.relacl, E'\n') AS "Privilégios de acesso",
pg_catalog.array_to_string(ARRAY( SELECT attname || E' :\n ' ||
pg_catalog.array_to_string(attacl, E'\n ')

FROM pg_catalog.pg_attribute a WHERE

attrelid = c.oid AND NOT attisdropped AND attacl IS NOT NULL ), E'\n') AS "Privilégios de
acesso à coluna"
FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind
IN ('r', 'v', 'S', 'f')
AND n.nspname !~ '^pg_' AND pg_catalog.pg_table_is_visible(c.oid) e
pg_catalog.pg_get_userbyid(c.relowner)='proprietário'
ORDEM POR 1, 2;

Concessão de privilégios em todos os procedimentos

selecione 'conceder executar no procedimento "CBF"."'||proname||'" ('||

pg_get_function_arguments(oid)||') para cbf_ctrl_user;' de pg_proc onde pronamespace=' <oid of
schema>' ;

Consultas em nível de
objeto Esta seção fornece as consultas que você pode usar para obter informações em nível de objeto.

Obter lista de todas as tabelas e sua contagem de linhas

Machine Translated by Google

SELECT
pgClass.relname AS tableName,
pgClass.reltuples AS rowCount FROM
pg_class pgClass LEFT JOIN pg_namespace
pgNamespace ON (pgNamespace.oid =
pgClass.relnamespace)

ONDE
pgNamespace.nspname NOT IN ('pg_catalog', 'information_schema') AND pgClass.relkind='r';

Verifique as tabelas em cada esquema definido pelo usuário

SELECT n.nspname como "Schema",

count(c.relname) como "Name"
FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
ONDE c.relkind IN ('r',")
AND n.nspname <> 'pg_catalog'
AND n.nspname <> 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid) agrupar por
n.nspname;

Localizar alterações de parâmetros para uma tabela

SELECT c.relname, pg_catalog.array_to_string(c.reloptions || array(selecione 'toast.' || x de

pg_catalog.unnest(tc.reloptions) x), ', ')
FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)
WHERE c.relname = 'teste'

Gerar um script para alterar ou renomear todos os nomes de tabela para letras minúsculas

SELECT 'alter table "'||c.relname||'" renomear para '||lower(c.relname)||';'

FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind ='r'

AND n.nspname='schemaname'
ORDEM POR 1;

Gerar um script para alterar ou renomear todas as colunas de uma tabela

Para Tabelas

SELECIONAR

'alter table "'||c.relname||'" renomear "'||a.attname||'" para '||lower(a.attname)||';'

A PARTIR DE

pg_class c
JOIN pg_attribute a ON a.attrelid = c.oid JOIN pg_type t ON
a.atttypid = t.oid LEFT JOIN pg_catalog.pg_constraint r ON
c.oid = r.conrelid AND r.conname = a.attname

ONDE
c.relnamespace = (selecione oid de pg_namespace onde nspname="schemaname")
Machine Translated by Google

AND a.attnum > 0 AND c.relkind in ('r', 'p')

AND c.relname = 'table_name'
ENCOMENDAR POR a.attnum

Para todas as tabelas em um esquema

SELECIONAR

'alterar tabela "'||c.relname||'" renomear "'||a.attname||'" para

'||inferior(a.attname)||';'
A PARTIR DE

pg_class c
JOIN pg_attribute a ON a.attrelid = c.oid JOIN pg_type t ON
a.atttypid = t.oid LEFT JOIN pg_catalog.pg_constraint r ON
c.oid = r.conrelid AND r.conname = a.attname

ONDE
c.relnamespace = (selecione oid de pg_namespace onde nspname="schemaname")

AND a.attnum > 0 AND

c.relkind in ('r', 'p')

ENCOMENDAR POR a.attnum

Encontrar chaves primárias em tabelas de um esquema

SELECT c2.relname, i.indisprimary, i.indisunique, i.indisvalid, pg_catalog.pg_get_indexdef(i.indexrelid,

0, true),
pg_catalog.pg_get_constraintdef(con.oid, true), contype
FROM pg_catalog.pg_class c, pg_catalog.pg_class c2, pg_catalog.pg_index i LEFT JOIN pg_catalog.pg_constraint
con ON (conrelid = i.indrelid AND
conindid = i.indexrelid AND contype IN ('p'))
WHERE c.relnamespace=(selecione oid de pg_namespace onde nspname="public")
AND c.oid = i.indrelid AND i.indexrelid = c2.oid ORDER BY i.indisprimary
DESC, i.indisunique DESC, c2.relname;

Encontrar sequências em um esquema

SELECT n.nspname como "Schema",

c.relname como "Name", CASE c.relkind
QUANDO 'r' THEN 'table' QUANDO 'v' THEN 'view' QUANDO 'm' THEN 'materialized view' QUANDO 'i'
THEN 'índice' QUANDO 'S' THEN 'sequência' QUANDO 's'
THEN 'especial' QUANDO 'f' THEN 'tabela estrangeira' END como "Tipo",
pg_catalog.pg_get_userbyid(c.relowner) como "Proprietário"
FROM pg_catalog.pg_class c LEFT
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
ONDE c.relkind IN ('S',”)
AND n.nspname='schemaname'
ORDEM POR 1,2;

Encontre as restrições

SELECT r.conname
FROM pg_catalog.pg_constraint r WHERE
r.connamespace = (selecione oid de pg_namespace onde nspname="public")
AND r.contype = 'c'
ORDEM POR 1;
Machine Translated by Google

Encontrar chaves estrangeiras

SELECT connome,
pg_catalog.pg_get_constraintdef(r.oid, true) as condef FROM
pg_catalog.pg_constraint r WHERE r.connamespace=(selecione oid de
pg_namespace onde nspname="public")
AND r.contype = 'f' ORDER BY 1;

Localizar pai para chave estrangeira

SELECT conname, conrelid::regclass, conindid::regclass,

pg_catalog.pg_get_constraintdef(r.oid, true) as condef FROM
pg_catalog.pg_constraint r WHERE r.connamespace=(selecione oid de
pg_namespace onde nspname="public")
AND r.contype = 'f' ORDER BY 1;

Consulta para encontrar a sequência DE PROPRIEDADE

selecione s.relname como "Sequência", n.nspname como "esquema", t.relname como "Propriedade da
tabela", a.attname como "Propriedade da coluna" de pg_class s

junte pg_depend d em d.objid=s.oid e d.classid='pg_class'::regclass e

d.refclassid='pg_class'::regclass
join pg_class t em t.oid=d.refobjid join
pg_namespace n em n.oid=t.relnamespace join pg_attribute
a em a.attrelid=t.oid e a.attnum=d.refobjsubid onde s.relkind='S'

Resumo Neste
capítulo, falamos sobre alguns erros que você vê quando começa a trabalhar no PostgreSQL e suas causas e resolução.
Isso será útil para os iniciantes. Além disso, fornecemos algumas consultas úteis que você pode usar diariamente. As
consultas de monitoramento são úteis para um administrador de banco de dados verificar a integridade de um banco de
dados.
Machine Translated by Google

Índice
UMA

Lista de controle de acesso (ACL)

alterar privilégios padrão evitar
abreviaturas de privilégio em
nível de coluna de esquema

público funções somente leitura

funções e grupos DDLs
transacionais

Administradores

bash_profile
arquivo psqlrc, configurando
informações do psqlrc
distribuir

Alterar privilégios padrão

Extensão de auditoria
Configuração de auditoria
Autenticação no HBA
HOSTSSL
senha
md5

LDAP
PEER e IDENT rejeitam

SCRAM
CONFIAR EM

Soluções de failover automático

Failover automático por meio do arquivo

de configuração repmgr, instalação do
registro do nó, teste de configuração,

failover automático

Operações

simultâneas de vácuo automático

Machine Translated by Google

lançador
parâmetros
autovacuum_max_workers
autovacuum_naptime
autovacuum_vacuum_cost_delay trabalhador
aspirador

E/S de vácuo automático

Parâmetros relacionados ao vácuo automático

B
Backups de
coleta de informações, configuração lógica

Consulte Backups lógicos

monitorando o físico

Consulte Backups físicos

PITR

estratégia
de retenção

de propósito, configurar
ferramentas

Barman

pgBackRest
Ferramenta de barman

Formatos básicos
de backup

pg_receivexlog/pg_receivewal função
pg_stop_backup
Consultas básicas
Instalação binária

C
Replicação em cascata
Pontos de verificação
ACLs de nível de coluna

Problemas comuns de replicação

Machine Translated by Google

Protocolo de controle de simultaneidade

Operações simultâneas Erros de
configuração Arquivos de configuração
pg_hba.conf pg_ident.conf postgresql.conf
Definições de configuração Erros de
conexão Parâmetros relacionados à
conexão/autenticação Pool de
conexão pgBouncer pgpool-II Extensão
central do PostgreSQL

D
Backups diários
Administradores de banco de dados (DBAs)
Falhas de banco de dados

Monitoramento de nível de banco de

dados diário/semanal
monitoramento frequente
Sistemas de gerenciamento de banco de dados (DBMSs)
Separação do cluster de dados
Instruções de linguagem de definição de dados (DDL)
Índices duplicados

E
Volumes de
impacto de
desempenho em

nível de instância de
backups de criptografia
Erros

Acionadores de eventos

F
Falhas
Machine Translated by Google

G
Coleta de lixo
Privilégios GRANT/REVOKE
GRANT privilégios

H
Alta disponibilidade (HA) melhor
coleta de informações da

solução de alta disponibilidade

soluções de failover automático
atraso crítico do data center

Especificações

do servidor primário da
solução HA, conexões de leitura, solução de
replicação de servidores em espera
Configuração de

servidores em espera
de data center único
RPO e RTO
RPO

Soluções simples de solução

de alta disponibilidade RTO nas ferramentas de

failover automático do Core PostgreSQL

Consulte Failover automático por meio do pool

de conexões de replicação em cascata
repmgr
Consulte Pool de conexões em
espera quente replicação de
streaming em espera quente/
envio de logs
Diretrizes de alta segurança e criptografia
Hot Standby
Páginas enormes

Eu, J, K
Machine Translated by Google

Fragmentação do índice
Operações de entrada/saída por segundo (IOPS)
Instalação, tamanho atual
binário do PostgreSQL e
crescimento esperado especificações da
máquina do sistema de arquivos pontos de
montagem sistema operacional Internet
pública

fonte
Consulte problemas de solução de

problemas de tipos de armazenamento

de instalação de origem

Criptografia no nível da instância

eu
Servidor LDAP
Níveis de monitoramento
Recomendações do sistema
operacional Linux enormes
páginas overcommits THP
vm.dirty_background_ratio
vm.dirty_ratio Memória virtual Linux
log_autovacuum_min_duration
log_checkpoints Arquivos de log
Parâmetros de log
log_autovacuum_min_duration
log_checkpoints log_connections e
log_disconnections log_line_prefix
log_lock_waits
log_min_duration_statement
Machine Translated by Google

log_temp_files motivos
para habilitar

Parâmetros relacionados ao registro

Limitações de exemplos
de backups lógicos
pg_dump

log_line_prefix
log_lock_waits
log_min_duration_statement
log_temp_files

M, N
Atividades de manutenção
autovacuum IO
autovacuum/vacuum
Consulte a tabela de

fragmentação de índice
de índices duplicados
Autovacuum e índices não
utilizados de inchaço de índice

Parâmetros relacionados à memória

Monitorando o nível do banco de
dados dos bancos de dados

Consulte os níveis de monitoramento em nível de banco

de dados

OS level

Veja o monitoramento do nível do SO

Monitorando a idade das
consultas de banco de dados e
tabelas de índice inchado
tabelas bloqueadas consultas

Tamanho

do banco de dados excluir valores

duplicados índices duplicados
obter nome/valores, pg_settings
Machine Translated by Google

tamanhos de
índice utilização de

índice maiores tabelas,

banco de dados índices
nunca usados tabelas inchadas

em tempo real consultas de

execução lenta tamanho da

tabela top 10 tabelas WRITE

número total, transações executadas
VÁCUO
Ferramentas de monitoramento/
relatório pgBadger extensão
pg_buffercache pgCluu

sar

Funções de monitoramento

Backups mensais
Comportamento do controle de simultaneidade multiversão
(MVCC)

Esquema de
gerenciamento de transações do PostgreSQL

O
Consultas em nível de
objeto alteram/renomeiam todos os nomes de tabela para
MINÚSCULAS alteram/renomeiam todas as colunas de todas as
tabelas em um esquema para tabelas verificar tabelas, restrições
de esquema definidas pelo usuário, localizar alterações de

parâmetros de localização para uma tabela localizar sequência

OWNED BY localizar sequências em um esquema chaves estrangeiras
get lista de todas as tabelas pai para chave estrangeira, encontrando
chaves primárias em tabelas, esquema
Machine Translated by Google

Consultas de privilégios de objeto

verificam privilégios, tabelas
localizam todas as funções, argumentos
localizam privilégios
GRANT privilégios
Instaladores de um clique

Processamento de transações online (OLTP)

Monitoramento do nível do SO
Sistema de arquivos de

utilização da CPU
IO

rede de
memória
Supercomprometimentos

P
Recomendações de parâmetros

configurações, tipos de parâmetros de revisão

conexões relacionadas ao autovacuum
relacionadas ao registro relacionadas à
memória relacionadas ao planejador

relacionadas à replicação relacionadas a

WAL ferramentas de ajuste Sistema de
autenticação baseado em senha
pgBackRest pgBadger pg_basebackup
pgBouncer extensão pg_buffercache

pgCluu monitora pgcrypto pg_dump pg_hba.conf

Machine Translated by Google

pg_ident.conf pgpool-

II Função

pg_start_backup Vantagens de backups

físicos formatos de verificação de erros

pg_basebackup parâmetros
anteriores replicação habilitada

script de amostra procedimentos

tradicionais logs de transações

Parâmetros relacionados ao

planejador Recuperação pontual

(PITR) postgresql.conf

Desenvolvedores PostgreSQL

criar servidor

detalhes do banco de

dados status do banco

de dados pgAdmin home

Layouts de sistema de arquivos de

armazenamento/disco PostgreSQL

separação de cluster de dados

arquivos de log tablespaces

separação de arquivos temporários

Os arquivos WAL separam um

cluster e banco de dados por localização e propriedade

corretas do servidor, escolhendo

Grupo de Desenvolvimento Global do PostgreSQL (PGDG)

Variáveis de ambiente relacionadas ao PostgreSQL

Procedimentos não confiáveis

Esquema público

Q
Erros de consulta
Machine Translated by Google

R
Função somente leitura

Objetivo do ponto de recuperação (RPO)

Objetivo de tempo de recuperação (RTO)
REINDEX

Atraso de replicação
Parâmetros relacionados à replicação
Restaurando backups lógicos
de banco de dados
arquivos de despejo de formato personalizado/
tar backups físicos de arquivo de despejo
simples
Reverter

Segurança em nível de linha (RLS)

Instalação de RPM

S
Mecanismo de autenticação de resposta de desafio salgado (SCRAM)
Mecanismos de segurança
ACLs

Consulte Autenticação de auditoria da

lista de controle de acesso (ACL)

Veja Autenticação no HBA

criptografia de gerenciamento de
usuário atual e eventos PCI
acionam implementação funções
de monitoramento configuração de
política de senha

PL confiável vs não
. confiável

Replicação do
PostgreSQL

Segurança em nível de linha RLS

Usuários SSL, criação

Machine Translated by Google

escrita e leitura, banco de dados

Binários e bibliotecas de
instalação de origem cluster
configure o arquivo baixado

do comando, descompacte
a opção -j

Arquivo de script da
ferramenta OpenSSL
libs pg_ctl, conteúdo
Despejos SQL
Conexões SSL

Servidor em espera
Replicação de streaming
Monitores de relatório de atividade do sistema (sar)

T
Inchaço de tabela e índice
Espaço de tabela

Separação de arquivos temporários

Vácuo do acelerador
DDLs transacionais

Buffer lookaside de tradução (TLB)

Páginas enormes transparentes (THP)
Solução de problemas
Autenticação TRUST
Ajustando os parâmetros do
SO após a instalação antes
da instalação

DENTRO

Índices não usados

DENTRO

Cronograma manual de
estratégias VACUUM

Memória virtual
Machine Translated by Google

W, X
Cópia de segurança WAL

Separação de arquivos WAL

Parâmetros relacionados ao WAL
Espera quente/quente
Espera quente/transporte de log
Backups semanais

Y, Z
Backups anuais