Início / dba / Perguntas / 114357
Accepted
francs
Asked: 2015-09-08 05:04:40 +0800 CST

write_location e flush_location da exibição pg_stat_replication

  • 772

Estou confuso sobre write_location e flush_location de pg_stat_replication view . O documento diz, write_location significa a última posição do log de transações gravada no disco por este servidor em espera, flush_location significa a última posição do log de transações liberada no disco por este servidor em espera, isso faz alguma diferença?

Consulte a exibição pg_stat_replication no banco de dados primário

sent_location :      Last transaction log position sent on this connection
write_location:      Last transaction log position written to disk by this standby server
flush_location:      Last transaction log position flushed to disk by this standby server
replay_location:     Last transaction log position replayed into the database on this standby server

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 23453
usesysid         | 24619
usename          | repuser
application_name | node1
client_addr      | 192.168.2.37
client_hostname  | 
client_port      | 58412
backend_start    | 2015-09-07 20:56:13.141438+08
backend_xmin     | 
state            | streaming
sent_location    | 2/3D397B1C
write_location   | 2/3D397B1C
flush_location   | 2/3D397B1C
replay_location  | 2/3D390954
sync_priority    | 1
sync_state       | sync
postgresql

1 respostas

  1. Best Answer

    As duas colunas em pg_stat_replication estão basicamente apontando a diferença entre write(2)efsync(2)

    Da página de write(2)manual:

    write() escreve para contar bytes do buffer apontado buf para o arquivo referenciado pelo descritor de arquivo fd.

    O número de bytes gravados pode ser menor que o contador se, por exemplo, houver espaço insuficiente no meio físico subjacente ou o limite de recurso RLIMIT_FSIZE for encontrado (consulte setrlimit(2)) ou a chamada for interrompida por um manipulador de sinal após tendo escrito menos de contagem de bytes. (Veja também tubo(7).)

    Para um arquivo pesquisável (ou seja, um ao qual lseek(2) pode ser aplicado, por exemplo, um arquivo normal) a gravação ocorre no deslocamento do arquivo atual e o deslocamento do arquivo é incrementado pelo número de bytes realmente gravados. Se o arquivo foi aberto (2) com O_APPEND, o deslocamento do arquivo é definido primeiro no final do arquivo antes da gravação. O ajuste do deslocamento do arquivo e a operação de gravação são executados como uma etapa atômica.

    O POSIX requer que um read(2) que pode ser comprovado após um write() ter retornado, retorne os novos dados. Observe que nem todos os sistemas de arquivos são compatíveis com POSIX.

    Na fsync(2)página de manual:

    fsync() transfere ("libera") todos os dados in-core modificados (ou seja, páginas de cache de buffer modificadas para) o arquivo referenciado pelo descritor de arquivo fd para o dispositivo de disco (ou outro dispositivo de armazenamento permanente) onde esse arquivo reside. A chamada é bloqueada até que o dispositivo informe que a transferência foi concluída. Ele também libera as informações de metadados associadas ao arquivo (consulte stat(2)).

    Chamar fsync() não garante necessariamente que a entrada no diretório que contém o arquivo também alcançou o disco. Para isso, também é necessário um fsync() explícito em um descritor de arquivo para o diretório.

    fdatasync() é semelhante a fsync(), mas não libera metadados modificados, a menos que esses metadados sejam necessários para permitir que uma recuperação de dados subsequente seja tratada corretamente. Por exemplo, alterações em st_atime ou st_mtime (respectivamente, hora do último acesso e hora da última modificação; consulte stat(2)) não requerem liberação porque não são necessárias para uma leitura de dados subsequente ser tratada corretamente. Por outro lado, uma mudança no tamanho do arquivo (st_size, como feito por digamos ftruncate(2)), exigiria uma limpeza de metadados.

    O objetivo do fdatasync() é reduzir a atividade do disco para aplicativos que não requerem que todos os metadados sejam sincronizados com o disco.

    Em operação normal por padrão, o PostgreSQL chama fsync (ou fdatasync, se você estiver no linux), para garantir que os dados em um segmento WAL sejam bem e verdadeiramente gravados no disco.

    Em operação normal, quando uma chamada de gravação acontece, ela basicamente copia esses dados do PostgreSQL para o cache do sistema de arquivos, que é apenas mais um bit de RAM. Se o servidor travar, você ainda perderá esses dados, porque ainda estão na RAM, embora seja apenas uma parte diferente da RAM.

    Em COMMIT, porém, o PostgreSQL chama fsync, o que força os dados do segmento WAL a serem gravados no disco, não apenas no cache do sistema de arquivos na RAM. O que garante que, após uma falha, os dados confirmados ainda sejam confirmados e possam ser reproduzidos.

    Ele também tem a vantagem adicional de precisar chamar fsyncmenos vezes para os arquivos de dados, porque todos os dados necessários para reproduzir adequadamente as alterações nesses arquivos estão contidos nos segmentos WAL, que são persistidos de forma durável no disco.

    Uma boa descrição desse comportamento no Linux pode ser encontrada no artigo Flushing Disk Buffers .

    O comportamento de sincronização pode ser controlado com wal_sync_method e fsync

    Espero que ajude a responder sua pergunta. =)

    • 1

relate perguntas