Após a configuração do ambiente, observe os diretórios que ele envolve nas variáveis de ambiente.
export PGHOME=/usr/local/pgsql/
export PGUSER=postgres
export PGPORT=5432
export PGDATA=/app/pgsql/data
export PGLOG=/app/pgsql/log/postgres.log
export PATH=$PGHOME/bin:$PATH:$HOME/bin
export LD_LIBRARY_PATH=$PGHOME/lib:$LD_LIBRARY_PATH
PATH=/usr/local/pgsql/bin:$PATH
export PATH
Estrutura e função do diretório
Diretório de instalação de software
/usr/local/pgsql/ Equivalente ao diretório de instalação do software /app/oracle da Oracle, alguns comandos que podem ser executados pelo psql, pg_ctl e outros softwares estão abaixo.
[postgres@yuan ~]$ cd /usr/local/pgsql/
[postgres@yuan pgsql]$ ll
total 16
drwxr-xr-x 2 root root 4096 Jul 9 17:54 bin
drwxr-xr-x 6 root root 4096 Jul 9 17:54 include
drwxr-xr-x 4 root root 4096 Jul 9 17:54 lib
lrwxrwxrwx 1 root root 26 Jul 9 17:56 postgresql-12.4 -> /usr/local/postgresql-12.4
drwxr-xr-x 6 root root 4096 Jul 9 17:54 share
[postgres@yuan pgsql]$ cd bin
[postgres@yuan bin]$ ll
total 12348
-rwxr-xr-x 1 root root 73808 Jul 9 17:54 clusterdb
-rwxr-xr-x 1 root root 73552 Jul 9 17:54 createdb
-rwxr-xr-x 1 root root 78416 Jul 9 17:54 createuser
-rwxr-xr-x 1 root root 68944 Jul 9 17:54 dropdb
-rwxr-xr-x 1 root root 68920 Jul 9 17:54 dropuser
-rwxr-xr-x 1 root root 975928 Jul 9 17:54 ecpg
-rwxr-xr-x 1 root root 142520 Jul 9 17:54 initdb
-rwxr-xr-x 1 root root 44344 Jul 9 17:54 pg_archivecleanup
-rwxr-xr-x 1 root root 130528 Jul 9 17:54 pg_basebackup
-rwxr-xr-x 1 root root 172512 Jul 9 17:54 pgbench
-rwxr-xr-x 1 root root 66984 Jul 9 17:54 pg_checksums
-rwxr-xr-x 1 root root 42880 Jul 9 17:54 pg_config
-rwxr-xr-x 1 root root 61376 Jul 9 17:54 pg_controldata
-rwxr-xr-x 1 root root 76888 Jul 9 17:54 pg_ctl
-rwxr-xr-x 1 root root 422888 Jul 9 17:54 pg_dump
-rwxr-xr-x 1 root root 109376 Jul 9 17:54 pg_dumpall
-rwxr-xr-x 1 root root 73064 Jul 9 17:54 pg_isready
-rwxr-xr-x 1 root root 93208 Jul 9 17:54 pg_receivewal
-rwxr-xr-x 1 root root 93832 Jul 9 17:54 pg_recvlogical
-rwxr-xr-x 1 root root 71256 Jul 9 17:54 pg_resetwal
-rwxr-xr-x 1 root root 187840 Jul 9 17:54 pg_restore
-rwxr-xr-x 1 root root 109784 Jul 9 17:54 pg_rewind
-rwxr-xr-x 1 root root 49216 Jul 9 17:54 pg_test_fsync
-rwxr-xr-x 1 root root 39152 Jul 9 17:54 pg_test_timing
-rwxr-xr-x 1 root root 148952 Jul 9 17:54 pg_upgrade
-rwxr-xr-x 1 root root 103904 Jul 9 17:54 pg_waldump
-rwxr-xr-x 1 root root 8227064 Jul 9 17:53 postgres
lrwxrwxrwx 1 root root 8 Jul 9 17:53 postmaster -> postgres
-rwxr-xr-x 1 root root 615376 Jul 9 17:54 psql
-rwxr-xr-x 1 root root 78032 Jul 9 17:54 reindexdb
-rwxr-xr-x 1 root root 86968 Jul 9 17:54 vacuumdb
diretório de dados
/app/pgsql/data É equivalente ao diretório de dados especificado pela Oracle ao construir o banco de dados.Os arquivos de parâmetros e arquivos de dados exigidos pelo banco de dados estão todos abaixo.
[postgres@yuan include]$ cd /app/pgsql/data
[postgres@yuan data]$ ll
total 60
drwx------ 5 postgres postgres 41 Jul 9 18:02 base
drwx------ 2 postgres postgres 4096 Jul 9 18:06 global
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_commit_ts
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_dynshmem
-rw------- 1 postgres postgres 4789 Jul 9 18:03 pg_hba.conf
-rw------- 1 postgres postgres 1636 Jul 9 18:02 pg_ident.conf
drwx------ 4 postgres postgres 68 Jul 9 18:10 pg_logical
drwx------ 4 postgres postgres 36 Jul 9 18:02 pg_multixact
drwx------ 2 postgres postgres 18 Jul 9 18:05 pg_notify
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_replslot
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_serial
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_snapshots
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_stat
drwx------ 2 postgres postgres 63 Jul 9 20:50 pg_stat_tmp
drwx------ 2 postgres postgres 18 Jul 9 18:02 pg_subtrans
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_tblspc
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_twophase
-rw------- 1 postgres postgres 3 Jul 9 18:02 PG_VERSION
drwx------ 3 postgres postgres 60 Jul 9 18:02 pg_wal
drwx------ 2 postgres postgres 18 Jul 9 18:02 pg_xact
-rw------- 1 postgres postgres 88 Jul 9 18:02 postgresql.auto.conf
-rw------- 1 postgres postgres 26659 Jul 9 18:03 postgresql.conf
-rw------- 1 postgres postgres 53 Jul 9 18:05 postmaster.opts
-rw------- 1 postgres postgres 74 Jul 9 18:05 postmaster.pid
Descrição do arquivo e diretório:
pg_hba.conf：#认证配置文件，配置了允许哪些IP访问数据库，及认证方式等信息。
pg_ident.conf：#"ident"认证方式的用户映射文件。
PG_VERSION：#记录了数据库版本号信息。
postgresql.auto.conf：#作用同 postgresql.conf ，优先级高于 postgresql.conf，在数据库中通过alter命令更改的参数记录在此文件中。
postgresql.conf：#数据库实例主配置文件，基本上所有的数据库参数配置都在此文件中。
postmaster.opts：#记录数据库启动命令。
postmaster.pid：#数据库进程文件，数据库启动时被创建，关闭时消失。
base：#该目录包含数据库用户所创建的各个数据库，同时也包括postgres、template0和template1的pg_defaulttablespace。
global：#该目录包含集群范围的各个表和相关视图。(pg_database、pg_tablespace）
pg_dynshmem：#该目录包含动态共享内存子系统使用的文件。
pg_commit_ts：#该目录包含已提交事务的时间。
pg_logical：#该目录包含逻辑解码的状态数据。
pg_multixact：#该目录包含多事务状态数据。（等待锁定的并发事务）
pg_notify：#该目录包含LISTEN/NOTIFY状态数据。
pg_replslot：#该目录包含复制槽数据。
pg_snapshots：#该目录包含导出的快照。
pg_stat：#该目录包含统计子系统的永久文件。
pg_stat_tmp：#该目录包含统计子系统的临时文件。
pg_subtrans：#该目录包含子事务状态数据。
pg_tblspc：#该目录包含表空间的符号链接。
pg_twophase：#该目录包含预备事务的状态文件。
pg_wal：#该目录包含wal日志。
pg_xact：#该目录包含事务提交状态数据。
Diretório de registros
O caminho /app/pgsql/log/ é personalizado. Você pode configurar vários logs do banco de dados aqui. Este ambiente configura apenas os logs de inicialização e desligamento do banco de dados.
[postgres@yuan log]$ cd /app/pgsql/log/
[postgres@yuan log]$ ll
total 4
-rw------- 1 postgres postgres 1006 Jul 9 21:21 postgres.log
O texto acima é uma introdução à estrutura de diretórios e suas funções.
Explicação detalhada do arquivo de configuração postgresql.conf
Após a conclusão da inicialização do PostgreSql, um arquivo de configuração é gerado em PGDATA postgresql.conf . Sem fazer nenhuma alteração, o banco de dados pode ser iniciado sem problemas após a conclusão da inicialização. Observando o arquivo de configuração, pode-se descobrir que a maioria dos parâmetros de configuração foram comentados , e eles são incorporados ao banco de dados por padrão, e apenas alguns parâmetros restantes não foram comentados e foram reescritos pelo sistema (diferentes versões do banco de dados podem ter diferentes parâmetros de reescrita).Por exemplo, os seguintes parâmetros foram reescritos na página 12.4. Os parâmetros padrão podem ser usados no ambiente de teste, mas quando usados na produção, alguma otimização e configuração dos parâmetros padrão são necessárias. Consulte os melhores experimentos do Alibaba Cloud e o manual oficial da página para aprender e organizar as configurações que podem ser usadas em o ambiente de produção.
max_connections = 100
shared_buffers = 128MB
dynamic_shared_memory_type = posix
max_wal_size = 1GB
min_wal_size = 80MB
log_timezone = 'PRC'
datestyle = 'iso, mdy'
timezone = 'PRC'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
Roteiro de posicionamento
Para o script a seguir, basta alterar alguns parâmetros de acordo com o ambiente shared_buffersreal .effective_cache_sizelog_directory
#connection control
listen_addresses = '*'
max_connections = 2000
superuser_reserved_connections = 10
tcp_keepalives_idle = 60
tcp_keepalives_interval = 10
tcp_keepalives_count = 10
password_encryption = md5
#memory management
shared_buffers = 16GB #推荐操作系统物理内存的1/4
max_prepared_transactions = 2000
work_mem = 8MB
maintenance_work_mem = 2GB
autovacuum_work_mem = 1GB
dynamic_shared_memory_type = posix
max_files_per_process = 24800
effective_cache_size = 32GB #推荐操作系统物理内存的1/2
#write optimization
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
bgwriter_flush_after = 512kB
effective_io_concurrency = 0
max_worker_processes = 256
max_parallel_maintenance_workers = 6
max_parallel_workers_per_gather = 0
max_parallel_workers = 28
#wal optimization
synchronous_commit = remote_write
full_page_writes = on
wal_compression = on
wal_writer_delay = 10ms
wal_writer_flush_after = 1MB
commit_delay = 10
commit_siblings = 5
checkpoint_timeout = 30min
max_wal_size = 32GB
min_wal_size = 16GB
archive_mode = on
max_wal_senders = 64
wal_keep_segments = 15
wal_sender_timeout = 60s
max_replication_slots = 64
hot_standby_feedback = off
#log optimization
log_destination = 'csvlog'
logging_collector = on
log_directory = '/pg12.4/logs' # 日志存放路径，提前规划在系统上创建好
log_filename = 'postgresql-%a.log'
log_file_mode = 0600
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 1GB
#audit settings
log_min_duration_statement = 5s
log_checkpoints = on
log_connections = on
log_disconnections = on
log_error_verbosity = verbose
log_line_prefix = '%m [%p] %q %u %d %a %r %e '
log_statement = 'ddl'
log_timezone = 'PRC'
track_io_timing = on
track_activity_query_size = 2048
#autovacuum
autovacuum = on
vacuum_cost_delay = 0
old_snapshot_threshold = 6h
log_autovacuum_min_duration = 0
autovacuum_max_workers = 8
autovacuum_vacuum_scale_factor = 0.02
autovacuum_analyze_scale_factor = 0.01
autovacuum_freeze_max_age = 1200000000
autovacuum_multixact_freeze_max_age = 1250000000
autovacuum_vacuum_cost_delay = 0ms
#system environment
datestyle = 'iso, mdy'
timezone = 'Asia/Shanghai'
lc_messages = 'en_US.utf8'
lc_monetary = 'en_US.utf8'
lc_numeric = 'en_US.utf8'
lc_time = 'en_US.utf8'
default_text_search_config = 'pg_catalog.english'
Descrição detalhada
Configurações de conexão
- listen_addresses: Especifica os endereços TCP/IP nos quais o servidor escuta conexões de clientes. O valor padrão é localhost, que permite apenas conexões locais.
- max_connections: Determina o número máximo de conexões simultâneas para o banco de dados. O valor padrão geralmente é 100 conexões. Se as configurações do kernel não suportarem (determinado durante o initdb), pode ser menor que esse número.
- superuser_reserved_connections: O número de conexões reservadas para superusuários. O padrão é 3 e não pode ser menor
max_connections.
configurações de memória
shared_buffers: A memória compartilhada que o servidor de banco de dados usará. O padrão geralmente é 128M. Se as configurações do kernel não suportarem (determinado durante o initdb), pode ser menor. Essa configuração deve ter pelo menos 128 kilobytes. O valor recomendado para shared_buffers é 25% da memória do sistema. Como o PostgreSQL também depende dos buffers de alta velocidade do sistema operacional, definir shared_buffers como 40% a mais que a memória do sistema pode causar uma carga maior.
max_prepared_transactions: Define o número máximo de transações que podem estar no estado "preparado" ao mesmo tempo. Definir este parâmetro como zero (que é a configuração padrão) desabilitará o recurso de transações preparadas. Para usar transações preparadas, defina max_prepared_transactions como pelo menos tão grande quanto max_connections.
work_mem: a memória máxima que pode ser usada por uma única operação de consulta (como classificação ou tabela hash). O valor padrão é 4 MB. ORDER BY, DISTINCT e junções de mesclagem usam operações de classificação, junções de hash, agregação baseada em hash e hash agregação baseada em hash.As tabelas hash são usadas no processamento de subconsulta hash IN.
Maintenance_work_mem: a memória máxima usada em operações de manutenção (como VACUUM, CREATE INDEX e ALTER TABLE ADD FOREIGN KEY). Seu valor padrão é 64 M. Configurações maiores podem melhorar o desempenho da limpeza e restauração de dumps do banco de dados.
autovacuum_work_mem: A quantidade máxima de memória que cada processo de trabalho do autovacuum pode usar. Seu valor padrão é -1, o que significa que o valor de Maintenance_work_mem é usado em seu lugar. Recomenda-se alocá-lo separadamente, pois os recursos alocados por Maintenance_work_mem também serão utilizados para construção de índices e outras operações.
dynamic_shared_memory_type: O método de gerenciamento de memória usado pelo servidor. Os valores possíveis são posix (para memória compartilhada POSIX alocada usando shm_open), sysv (para memória compartilhada System V alocada via shmget), windows (para memória compartilhada do Windows) e mmap (usado para memória compartilhada armazenada no diretório de dados) Memória arquivos mapeados simulam memória compartilhada). Nem todos os valores são suportados em todas as plataformas, a primeira opção suportada em uma plataforma é o seu valor padrão. A opção mmap não é o padrão em nenhuma plataforma e seu uso geralmente é desencorajado porque o sistema operacional gravará repetidamente as páginas modificadas de volta no disco, aumentando assim a carga de E/S no sistema. No entanto, é útil quando o diretório pg_dynshmem está armazenado em um disco RAM ou quando nenhuma outra funcionalidade de memória compartilhada está disponível.
efetivo_cache_size: A estimativa do planejador do tamanho efetivo do buffer de disco disponível para uma única consulta. Valores mais altos aumentarão a probabilidade de uso de varreduras de índice, valores mais baixos aumentarão a probabilidade de uso de varreduras sequenciais. Este parâmetro não tem efeito sobre o tamanho da memória compartilhada alocada pelo PostgreSQL, nem preserva o buffer do disco do kernel. Ele é usado apenas para fins de estimativa. O valor padrão é 4 GB e o valor recomendado é 50% da memória do sistema ou superior.
Configurações de E/S
bgwriter_delay: Atraso entre as rodadas de atividade do gravador em segundo plano. Em cada rodada, o escritor emite gravações para um certo número de buffers sujos, após os quais ele dorme para bgwriter_delay e repete. Quando não há buffers sujos no buffer pool, ele irá dormir por mais tempo, independentemente de bgwriter_delay. O valor padrão é 200 ms.
bgwriter_lru_maxpages: Não mais do que esse número de buffers serão gravados pelo gravador em segundo plano em cada rodada. Definir este parâmetro como zero desativa a gravação em segundo plano. O valor padrão é 100 buffers.
bgwriter_lru_multiplier: O número médio de buffers exigidos recentemente multiplicado por bgwriter_lru_multiplier pode ser usado para estimar o número de buffers que serão necessários na próxima rodada. Buffers sujos serão gravados até que haja muitos buffers limpos e reutilizáveis (no entanto, o número de buffers gravados em cada rodada não excederá bgwriter_lru_maxpages). Portanto, uma configuração de 1,0 representa uma estratégia "suficiente" que grava apenas o número de buffers que correspondem aos valores previstos. Um valor maior pode fornecer algum buffer de demanda de pico. O valor padrão é 2,0.
eficaz_io_concurrency: se esse valor for definido, a leitura antecipada do disco será inválida. Tanto as verificações sequenciais quanto as verificações de índice podem usar a leitura antecipada do disco. É recomendável desativá-lo. O valor padrão é 1.
max_worker_processes: O número máximo de processos em segundo plano que o sistema pode suportar. O valor padrão é 8. Ao alterar esse valor, considere também ajustar max_parallel_workers, max_parallel_maintenance_workers, max_parallel_workers_per_gather.
max_parallel_workers: Defina o número máximo de paralelismo suportado pelo sistema. O valor padrão é 8. Observe que definir esse valor maior que max_worker_processes não terá efeito porque os processos de trabalho paralelos são retirados do pool de processos de trabalho estabelecido por max_worker_processes.
max_parallel_maintenance_workers: O número máximo de paralelos que podem ser iniciados por um único comando do utilitário. O comando utilitário que atualmente suporta o uso de trabalhadores paralelos é CREATE INDEX, e somente ao construir índices de árvore B em paralelo, e VACUUM não possui uma opção FULL. Trabalhadores paralelos são retirados do pool de processos criado por max_worker_processes, o número é controlado por max_parallel_workers, o valor padrão é 2.
max_parallel_workers_per_gather: defina o número máximo de consultas paralelas permitidas. Consultas paralelas podem consumir mais recursos do que consultas não paralelas. Definir esse valor como 0 desativará a execução de consultas paralelas. O valor padrão é 2.
wal_compression: Quando este parâmetro estiver ativado, se full_page_writes estiver ativado (o valor padrão está ativado) ou durante um backup básico, o servidor PostgreSQL compactará a imagem de página inteira gravada no WAL. As imagens de página compactadas serão descompactadas durante a reprodução do WAL. O valor padrão está desativado. Somente superusuários podem alterar essa configuração. Ativar esse parâmetro pode reduzir o espaço ocupado pelo WAL sem correr o risco de corrupção irrecuperável dos dados, mas ao custo de sobrecarga adicional da CPU para compactação durante a gravação do WAL e durante a reprodução do WAL.
wal_writer_delay: especifica a frequência com que o gravador WAL libera o WAL, em unidades de tempo. Depois de liberar o WAL, o gravador irá dormir pelo período de tempo determinado por wal_writer_delay, a menos que seja acordado mais cedo por uma transação confirmada de forma assíncrona. Se a última liberação ocorrer antes de wal_writer_delay e for menor que o valor de wal_writer_flush_after WAL, então o WAL será gravado apenas no sistema operacional e não será descarregado no disco. O valor padrão é 200ms.
commit_delay: commit_delay adiciona um atraso de tempo antes que uma liberação WAL seja iniciada. Se a carga do sistema for alta o suficiente para que transações adicionais estejam prontas para confirmação dentro de um determinado intervalo, o rendimento de confirmação do grupo poderá ser melhorado, permitindo que mais transações sejam confirmadas com uma única liberação do WAL. No entanto, também aumenta a latência de cada liberação do WAL para um máximo de commit_delay. Como um atraso é desperdiçado se nenhuma outra transação estiver pronta para confirmação, um atraso só será executado se houver pelo menos commit_siblings (padrão 5) outras transações ativas quando uma liberação estiver prestes a ser iniciada. Além disso, se o fsync estiver desabilitado, nenhum atraso será executado.
checkpoint_timeout: o tempo máximo entre os pontos de verificação automáticos do WAL. O intervalo razoável é entre 30 segundos e 1 dia. O padrão é 5 minutos. Aumentar o valor deste parâmetro aumenta o tempo necessário para a recuperação de falhas.
max_wal_size: O tamanho máximo que o WAL pode crescer entre os pontos de verificação automáticos do WAL. Este é um limite flexível e o tamanho do WAL pode exceder max_wal_size em circunstâncias especiais, como sob carga pesada, falha no archive_command ou uma configuração alta de wal_keep_size. O padrão é 1 GB. Aumentar este parâmetro pode aumentar o tempo necessário para recuperação de falhas.
min_wal_size: Enquanto o uso do disco WAL permanecer abaixo desta configuração, os arquivos WAL antigos serão sempre reciclados para uso futuro em pontos de verificação, em vez de serem excluídos diretamente. Isso pode ser usado para garantir que espaço suficiente do WAL seja reservado para lidar com picos de uso do WAL, como a execução de grandes trabalhos em lote. Se o valor for especificado sem unidades, ele estará em megabytes, cujo padrão é 80 MB.
archive_mode: Quando archive_mode está habilitado, segmentos WAL concluídos podem ser enviados para armazenamento de arquivo definindo o comando archive_command. Além de desligado para desabilitar, existem dois modos: ligado e sempre. Durante a operação normal, não há diferença entre os dois modos, mas quando definido como sempre, o arquivador WAL também é habilitado na recuperação de arquivo ou no modo fallback. No modo sempre, todos os arquivos restaurados do arquivo ou transferidos por cópia de streaming serão arquivados (novamente). Quando wal_level está definido como mínimo, archive_mode não pode ser ativado.
max_replication_slots: O número máximo de slots de replicação que o servidor pode suportar. O valor padrão é 10. Definir esse valor com menos slots de replicação do que os disponíveis atualmente impedirá a inicialização do servidor. Além disso, para permitir o uso de slots de réplica, wal_level deve ser definido como réplica ou superior.
descrição do parâmetro synchronous_commit
Existem 5 opções: ligado, desligado, local, remote_write e remote_apply.
Ambiente de instância única:
on: Quando o banco de dados confirma uma transação, o wal primeiro grava no buffer do wal e depois no arquivo de log do wal. Configurá-lo como ativado significa que, ao enviar uma transação, você precisa esperar que o wal local grave no log do wal antes devolvendo sucesso ao cliente. Ativado é a configuração padrão, o banco de dados é muito seguro, mas o desempenho está comprometido.
local: O significado de local é semelhante a on, o que significa que ao enviar uma transação, você precisa esperar que o wal local seja escrito antes de retornar sucesso ao cliente.
off: Quando o banco de dados confirma uma transação, ele não precisa esperar que o buffer wal local seja gravado no log wal e então retorna sucesso ao cliente. Desligá-lo trará alguns riscos ao banco de dados: um pequeno O número das últimas transações enviadas pode ser perdido quando o banco de dados cair e o banco de dados for reiniciado.Mais tarde, essas transações serão consideradas encerradas de forma anormal e serão revertidas. É adequado para cenários onde a precisão do banco de dados não é necessária e o desempenho do banco de dados é buscado.
Ambiente de replicação de streaming:
on: Indica que quando o banco de dados mestre de replicação de streaming envia uma transação, ele precisa esperar que o banco de dados standby receba o fluxo de log wal enviado pelo banco de dados primário e grave-o no arquivo wal antes de retornar o sucesso ao cliente. Simplificando, on significa que o wal local foi colocado no disco e o banco de dados de espera. O wal também foi colocado no disco e há dois wals persistentes, mas o banco de dados de backup não foi refeito neste momento. Esta opção resulta em tempos de resposta de transação mais elevados.
remote_write: indica que quando o banco de dados mestre de replicação de streaming envia uma transação, ele precisa esperar que o banco de dados de espera receba o fluxo de log enviado pelo banco de dados primário e grave-o no cache do sistema operacional do nó de espera e, em seguida, retorne o sucesso ao cliente. Nesse caso, o banco de dados em espera é encerrado de forma anormal. Não há risco de perder o wal log transferido. No entanto, se o sistema operacional em espera travar de forma anormal, há o risco de perder o wal transferido. Neste momento, wal pode não ser completamente gravado no arquivo wal do nó de espera. Simplificando, remote_write significa local O wal foi colocado no disco e o wal do banco de dados de espera ainda está no cache do sistema operacional de espera, o que significa que há apenas uma parede persistente. Esta opção resulta em tempos de resposta de transação mais baixos.
remote_apply: Indica que quando o banco de dados mestre de replicação de streaming envia uma transação, ele precisa esperar que o banco de dados standby receba o fluxo wal enviado pelo banco de dados primário e grave-o no arquivo wal. Ao mesmo tempo, o banco de dados standby foi concluído refazer antes de retornar o sucesso ao cliente. Simplificando, remote_apply significa que o WAL local foi colocado no disco e o WAL do banco de dados de espera foi colocado no disco e foi refeito. Essa configuração garante que haja duas cópias persistentes do WAL e o banco de dados standby também foi refeito. Esta opção resulta no maior tempo de resposta da transação.
Configurações de registro
log_destination: Existem três métodos de saída, stderr, csvlog, syslog; eventlog também é compatível com Windows. O padrão é stderr. Se csvlog for usado, logging_collector deverá estar habilitado. Você também pode usar csvlog e stderr ao mesmo tempo, e os logs em ambos os formatos serão gravados.
logging_collector: Coletor de log, é um processo em segundo plano que captura mensagens de log enviadas para stderr e redireciona essas mensagens para o arquivo de log. O padrão é OFF.
log_directory: Caminho para salvar o log. Quando logging_collector está habilitado, este parâmetro determina o diretório no qual o arquivo de log será criado.
log_filename: formato do nome do log, o padrão é postgresql-%Y-%m-%d_%H%M%S.log.
log_file_mode: A permissão padrão é 0600, o que significa que somente o proprietário do servidor pode ler ou gravar o arquivo de log. Outra configuração comumente usada é 0640, que permite que membros do grupo do proprietário leiam o arquivo. Observe, entretanto, que você precisa modificar log_directory para armazenar os arquivos em algum lugar fora do diretório de dados do cluster para aproveitar essa configuração. Em qualquer caso, não é aconselhável tornar os arquivos de log legíveis por qualquer pessoa porque os arquivos de log podem conter dados confidenciais.
log_truncate_on_rotation: Quando logging_collector está habilitado, este parâmetro fará com que o PostgreSQL trunque (substitua em vez de anexar) quaisquer arquivos de log existentes com o mesmo nome. No entanto, o truncamento ocorre apenas quando um novo arquivo é aberto devido à rotação baseada em tempo, e não à rotação baseada em tamanho. Se fechado, em todos os casos os arquivos existentes anteriormente serão anexados.
log_rotation_age: Quando logging_collector está habilitado, este parâmetro determina o tempo máximo que um único arquivo de log é usado antes que um novo arquivo de log seja criado. O padrão é 24 horas. Definir esse parâmetro como zero desabilitará a criação de novos arquivos de log com base no tempo.
log_rotation_size: Quando logging_collector está habilitado, este parâmetro determina o tamanho máximo de um arquivo de log individual. Quando esta quantidade de dados for enviada para um arquivo de log, um novo arquivo de log será criado. O valor padrão é 10M. Defina como zero para desabilitar a criação de novos arquivos de log com base no tamanho.
log_min_duration_statement: O limite de tempo para registrar SQL lento. SQL que exceder esse tempo será registrado no log. O valor padrão é -1 e SQL lento não será registrado.
log_checkpoints: Controla se os pontos de verificação e de reinicialização são registrados no log do servidor. Algumas estatísticas também são incluídas na mensagem de log, incluindo os dados gravados no buffer e o tempo gasto para gravá-los. O valor padrão é desativado.
log_connections: controla se as informações de conexão são registradas. As tentativas de conexão com o servidor são registradas e a conclusão bem-sucedida da autenticação do cliente também é registrada. Não pode ser alterado durante a sessão. O padrão é desativado.
log_disconnections: controla se os encerramentos de sessão são registrados. A saída de log fornece informações semelhantes a log_connections, mas mais a duração da sessão, que não pode ser alterada durante a sessão e o padrão é desativado.
log_error_verbosity: Os valores válidos são TERSE, DEFAULT e VERBOSE. TERSE exclui o registro de mensagens de erro DETAIL, HINT, QUERY e CONTEXT. A saída VERBOSE inclui o código de erro SQLSTATE e o nome do arquivo do código-fonte, o nome da função e o número da linha onde o erro ocorreu. O padrão é PADRÃO.
log_line_prefix: Defina o conteúdo do log. O valor padrão é ’%m [%p] 'registrar o carimbo de data e hora e o ID do processo.
log_statement: controla quais instruções SQL são registradas. Os valores válidos são nenhum (desativado), ddl, mod e todos (todas as instruções). O mod registra todas as instruções ddl, além de instruções de modificação de dados, como INSERT, UPDATE, DELETE, TRUNCATE e COPY FROM. PREPARE, EXECUTE e EXPLAIN ANALYZE também serão registrados se contiverem comandos do tipo apropriado. O padrão é nenhum.
log_timezone: define o fuso horário para carimbos de data e hora gravados nos logs do servidor. O valor padrão é GMT.
descrição do caractere do formato log_filename
%a #星期的英文单词的缩写：如星期一， 则返回 Mon
%A #星期的英文单词的全拼：如星期一，返回 Monday
%b #月份的英文单词的缩写：如一月， 则返回 Jan
%B #月份的引文单词的缩写：如一月， 则返回 January
%c #返回datetime的字符串表示，如03/08/15 23:01:26
%d #返回的是当前时间是当前月的第几天
%f #微秒的表示： 范围: [0,999999]
%H #以24小时制表示当前小时
%I #以12小时制表示当前小时
%j #返回 当天是当年的第几天 范围[001,366]
%m #返回月份 范围[0,12]
%M #返回分钟数 范围 [0,59]
%P #返回是上午还是下午–AM or PM
%S #返回秒数 范围 [0,61]。。。手册说明的
%U #返回当周是当年的第几周 以周日为第一天
%W #返回当周是当年的第几周 以周一为第一天
%w #当天在当周的天数，范围为[0, 6]，6表示星期天
%x #日期的字符串表示 ：03/08/15
%X #时间的字符串表示 ：23:22:08
%y #两个数字表示的年份 15
%Y #四个数字表示的年份 2015
%z #与utc时间的间隔 （如果是本地时间，返回空字符串）
%Z #时区名称（如果是本地时间，返回空字符串）
descrição do caractere do formato log_line_prefix
%a #应用名
%u #用户名
%d #数据库名
%r #远程主机名或 IP 地址，以及远程端口
%h #远程主机名或 IP 地址
%b #后端类型
%p #进程 ID
%t #无毫秒的时间戳
%m #带毫秒的时间戳
%n #带毫秒的时间戳（作为 Unix 时代）
%i #命令标签：会话当前命令的类型
%e #SQLSTATE 错误代码
%c #会话 ID：见下文
%l #对每个会话或进程的日志行号，从 1 开始
%s #进程开始的时间戳
%v #虚拟事务 ID (backendID/localXID)
%x #事务 ID （如果未分配则为 0）
%q #不产生输出，但是告诉非会话进程在字符串的这一点停止；会话进程忽略
%% #纯文字%
configurações de vácuo automático
autovacuum: Controla se o servidor executa o processo em segundo plano do iniciador de limpeza automática. O padrão é ativado, mas para que a limpeza automática funcione corretamente, track_counts precisa estar ativado (ativado por padrão). Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor. A limpeza automática pode ser desabilitada para uma tabela alterando os parâmetros de armazenamento da tabela. Observe que mesmo que esse parâmetro esteja desabilitado, o sistema iniciará um processo de limpeza quando necessário para evitar a reversão do ID da transação.
old_snapshot_threshold: Defina o tempo mínimo que um instantâneo de consulta pode ser usado para evitar o risco de erros de "instantâneo muito antigo" ao usar instantâneos. Os dados que excederem esse limite de tempo serão apagados, o que pode ajudar a evitar o uso de instantâneos de longo prazo. A inflação do instantâneo, o valor padrão é -1 (desativa esse recurso), define efetivamente o limite de idade do instantâneo para o infinito.
log_autovacuum_min_duration: As ações de limpeza automática que excederem esse limite de tempo serão registradas. Definir este parâmetro como 0 registrará todas as ações de limpeza automática. O valor padrão é -1 (desativa a gravação de ações de limpeza automática). Além disso, quando este parâmetro for definido com qualquer valor exceto -1, se uma ação de limpeza automática for ignorada devido a uma violação de bloqueio ou exclusão simultânea, uma mensagem será registrada para isso. Ativar esse parâmetro é útil para rastrear atividades de limpeza automática, mas essa configuração pode ser substituída para tabelas individuais alterando os parâmetros de armazenamento da tabela.
autovacuum_max_workers: Defina o número máximo de processos de autovacuum (exceto o iniciador de autovacuum) que podem ser executados simultaneamente. O valor padrão é 3.
autovacuum_vacuum_scale_factor: a proporção de dml que aciona operações de limpeza automática de vácuo. O valor padrão é 0,2. Quando as operações dml na tabela ocupam 20% do volume de dados da tabela, a operação de limpeza automática de vácuo é acionada. Para evitar tabelas com pequenos volumes de dados sejam limpos com frequência, está relacionado a autovacuum_vacuum_threshold (Altere o valor padrão do parâmetro para 50. A limpeza automática a vácuo será acionada somente quando pelo menos 50 dados na tabela forem enviados para a operação dml.) Os parâmetros trabalhar juntos.
autovacuum_analyze_scale_factor: a proporção DML que aciona a operação automática de análise de vácuo. O valor padrão é 0,1. Quando a operação DML na tabela ocupa 10% do volume de dados da tabela, a operação automática de análise de vácuo é acionada. Para evitar tabelas com pequenos volumes de dados sejam analisados com frequência, está relacionado a autovacuum_analyze_threshold (Altere o valor padrão do parâmetro para 50. Vacuum (análise automática) será acionado somente quando pelo menos 50 dados na tabela forem enviados para a operação dml. O parâmetros funcionam juntos.
autovacuum_freeze_max_age: O valor máximo de pg_class.relfrozenxid de uma tabela. Se esse valor for excedido, o xid será redefinido. O valor padrão é 200 milhões. Observe que mesmo se a limpeza automática estiver desativada, o sistema iniciará um processo de limpeza automática para evitar a reversão.
autovacuum_multixact_freeze_max_age: O valor máximo de pg_class.relminmxid de uma tabela. Se esse valor for excedido, o xid será redefinido. O valor padrão é 400 milhões. Observe que mesmo se a limpeza automática estiver desativada, o sistema iniciará um processo de limpeza automática para evitar a reversão.
autovacuum_vacuum_cost_delay: Especifica o valor de atraso de custo usado em operações automáticas de VACUUM. Se -1 (valor padrão) for especificado, o valor de vácuo_cost_delay (valor padrão 2ms) será usado.
Informações adicionais
Como cada tabela de negócios no ambiente de produção tem diferentes funções, frequência de uso, taxa de crescimento de "tuplas mortas", etc., é recomendado definir valores de parâmetros separadamente para tabelas de negócios de produção importantes com base nas condições de negócios.
-
Para tabelas com operações dml particularmente frequentes, faça configurações semelhantes às seguintes:
ALTER TABLE mytable SET (autovacuum_vacuum_scale_factor = 0.01);
-
Para campos de índice e tabelas com operações DML particularmente frequentes, faça configurações semelhantes às seguintes:
ALTER TABLE mytable SET (fillfactor=80);
-
Insira apenas na tabela do banco de dados e faça configurações semelhantes às seguintes:
ALTER TABLE mytable SET (autovacuum_freeze_max_age = 10000000);
Configurações de ambiente do sistema
datestyle: define o formato de exibição para valores de data e hora, bem como regras para interpretar valores de entrada de data ambíguos. Por razões históricas, esta variável contém duas partes separadas: a declaração do formato de saída (ISO, Postgres, SQL ou Alemão) e a ordem de entrada/saída ano/mês/dia (DMY, MDY ou YMD). Eles podem ser definidos de forma independente ou em conjunto. As palavras-chave Euro e European são sinônimos de DMY; as palavras-chave US, NonEuro e NonEuropean são sinônimos de MDY. Os padrões integrados são ISO, MDY, mas o initdb inicializará o arquivo de configuração com configurações correspondentes ao comportamento do fuso horário lc_time selecionado.
fuso horário: Defina o fuso horário usado para exibir e interpretar carimbos de data/hora. O padrão interno é GMT, mas isso geralmente é substituído no postgresql.conf; o initdb instalará uma configuração correspondente ao seu ambiente de sistema.
lc_messages: Defina o idioma para exibição de mensagens. Os valores aceitáveis dependem do sistema. Se esta variável for definida como uma string vazia (padrão), o valor será herdado do ambiente de execução do servidor de maneira dependente do sistema.
Em alguns sistemas, esta classificação de zona não existe. Você ainda pode definir esta variável, ela simplesmente não terá nenhum efeito. Da mesma forma, podem não existir mensagens de tradução para o idioma desejado. Nesse caso, você continuará vendo mensagens em inglês.
Somente o superusuário pode alterar esta configuração. Porque afeta tanto as mensagens enviadas para o log do servidor quanto para o cliente. Um valor incorreto pode reduzir a legibilidade do log do servidor.
lc_monetary: Define a área usada para formatar valores monetários, como usar a família de funções to_char. Os valores aceitáveis dependem do sistema. Se esta variável for definida como uma string vazia (padrão), o valor será herdado do ambiente de execução do servidor de maneira dependente do sistema.
lc_numeric: Defina a área usada para formatar números, como usar a família de funções to_char. Os valores aceitáveis dependem do sistema. Se esta variável for definida como uma string vazia (padrão), o valor será herdado do ambiente de execução do servidor de maneira dependente do sistema.
lc_time: Defina a área usada para formatar datas e horas, como usar a família de funções to_char. Os valores aceitáveis dependem do sistema. Se esta variável for definida como uma string vazia (padrão), o valor será herdado do ambiente de execução do servidor de maneira dependente do sistema.
default_text_search_config: Seleciona a configuração de pesquisa de texto usada pelas variantes da função de pesquisa de texto que não possuem um parâmetro explícito para especificar a configuração. O padrão integrado é pg_catalog.simple, mas se uma região correspondente puder ser identificada, o initdb usará a configuração correspondente ao arquivo de configuração de inicialização das configurações regionais lc_ctype selecionado.