Quando o parâmetro hot_standby está definido como on em um servidor em-espera, ele começará a aceitar conexões assim que a restauração trouxer o sistema a um estado consistente e estiver pronto para o modo Hot-Standby. Todas estas conexões são estritamente de leitura-apenas; nem mesmo tabelas temporárias podem ser criadas.

Os dados no servidor em-espera levam algum tempo até chegarem do servidor primário, portanto haverá um atraso mensurável entre o servidor primário e o servidor em-espera. A execução da mesma consulta quase simultaneamente no servidor primário e no servidor em-espera poderá, portanto, retornar resultados diferentes. Diz-se que os dados no servidor em-espera são por fim consistentes com os do servidor primário. Assim que o registro de efetivação de uma transação for reproduzido no servidor em-espera, as alterações feitas por esta transação ficarão visíveis para quaisquer novos instantâneos obtidos no servidor em-espera. Os instantâneos podem ser obtidos no início de cada instrução, ou no início de cada transação, dependendo do nível de isolamento da transação corrente. Para obter mais detalhes, veja Isolamento de transação.

As transações iniciadas durante o modo Hot-Standby podem executar os seguintes comandos:

As transações iniciadas durante o modo Hot-Standby nunca recebem um ID de transação, e não podem ser escritas no registro de transação (WAL) do sistema. Portanto, as seguintes instruções produzirão mensagens de erro:

Na operação normal, as transações de “leitura-apenas” podem usar as instruções LISTEN e NOTIFY, portanto as sessões Hot-Standby operam sob restrições um pouco mais severas do que as sessões comuns de leitura-apenas. É possível que algumas dessas restrições sejam afrouxadas em uma versão futura.

Durante o modo Hot-Standby, o parâmetro transaction_read_only é sempre true, e não pode ser alterado. Mas, desde que nenhuma tentativa seja feita para modificar o banco de dados, as conexões iniciadas durante o Hot-Standby se comportarão como qualquer outra conexão de banco de dados. Se ocorrer a comutação (failover), ou a promoção (switchover), o servidor de banco de dados alternará para o modo de processamento normal. As sessões permanecerão conectadas enquanto o servidor muda de modo. Assim que o modo Hot-Standby terminar, será possível iniciar transações de leitura-escrita (mesmo em uma sessão iniciada durante o modo Hot-Standby).

Os usuários podem determinar se o modo Hot-Standby está ativo no momento para sua sessão executando SHOW in_hot_standby. (Nas versões de servidor anteriores a 14, o parâmetro in_hot_standby não existia; um método substituto viável para servidores mais antigos é SHOW transaction_read_only;.) Além disso, um conjunto de funções (Tabela 9.98) permite que os usuários acessem informações sobre o servidor em-espera. Estas funções permitem que se escrevam programas que estão cientes do estado corrente do servidor de banco de dados. Podem ser usadas para monitorar o progresso da restauração, ou para permitir que se escrevam programas complexos que restauram o banco de dados para determinados estados.

Os servidores primário e em-espera estão de muitas maneiras fracamente conectados. As ações no servidor primário terão efeito no servidor em-espera. Como resultado, há potencial para interações negativas ou conflitos entre eles. O conflito mais fácil de entender é o de desempenho: se estiver ocorrendo uma grande carga de dados no servidor primário, isto irá gerar um fluxo semelhante de registros de transação no servidor em-espera, portanto as consultas no servidor em-espera podem disputar por recursos do sistema, como E/S.

Existem também tipos adicionais de conflito que podem ocorrer com Hot-Standby. Estes conflitos são difíceis de resolver, no sentido de que instruções podem precisar ser canceladas e, em alguns casos, as sessões desconectadas, para resolvê-los. São dadas ao usuário várias maneiras de lidar com estes conflitos. Os casos de conflito incluem:

No servidor primário, estes casos simplesmente resultam em espera; e o usuário pode optar por cancelar qualquer uma das ações conflitantes. Entretanto, no servidor em-espera não há escolha: a ação registrada no WAL já ocorreu no servidor primário, portanto o servidor em-espera não pode deixar de aplicá-la. Além disso, permitir que a reprodução do WAL aguarde indefinidamente pode ser muito prejudicial, porque o estado do servidor em-espera ficará cada vez mais distante do servidor primário. Portanto é fornecido um mecanismo para forçar o cancelamento de consultas no servidor em-espera que entrem em conflito com os registros de transação a serem aplicados.

Um exemplo dessa situação problemática é o administrador no servidor principal executar o comando DROP TABLE em uma tabela que está sendo consultada no momento no servidor em-espera. Claramente, a consulta no servidor em-espera não poderá continuar se o comando DROP TABLE for aplicado neste servidor. Se esta situação ocorresse no servidor primário, o comando DROP TABLE aguardaria até que a outra instrução terminasse. Mas quando o comando DROP TABLE é executado no servidor primário, ele não possui informações sobre quais consultas estão sendo executadas no servidor em-espera e, portanto, não irá aguardar por nenhuma consulta no servidor em-espera. Os registros de alteração do WAL passam para o servidor em-espera enquanto a consulta no servidor em-espera permanece sendo executada, causando conflito. O servidor em-espera deverá atrasar a reprodução do registro de transação (e tudo depois dele também), ou então cancelar a consulta conflitante para que o comando DROP TABLE possa ser aplicado.

Quando a consulta conflitante é curta, normalmente é desejável permitir que seja concluída atrasando um pouco a aplicação do WAL; mas um atraso longo na reprodução do WAL geralmente não é desejável. Portanto, o mecanismo de cancelamento possui os parâmetros max_standby_archive_delay e max_standby_streaming_delay, que definem o atraso máximo permitido na reprodução do WAL. As consultas conflitantes serão canceladas assim que demorarem mais do que o valor configurado de atraso permitido para aplicar quaisquer dados do WAL recém-recebidos. Existem dois parâmetros, para poderem ser especificados valores diferentes de atraso para o caso de leitura de dados do WAL de um arquivo (ou seja, restauração inicial de uma cópia de segurança base, ou “restaurando” um servidor em-espera que ficou muito para trás), versus leitura de dados de registro de WAL via replicação por fluxo.

Em um servidor em-espera que exista principalmente para alta disponibilidade, é melhor definir os parâmetros de atraso relativamente curtos, para que o servidor não fique muito atrás do servidor primário devido a atrasos causados por consultas conflitantes. Entretanto, se o servidor em-espera for destinado à execução de consultas de execução longa, um valor de atraso alto, ou mesmo infinito, poderá ser preferível. Lembre-se, no entanto, de que uma consulta de execução longa pode fazer com que outras sessões no servidor em-espera não vejam as alterações recentes no servidor primário, se isto atrasar a reprodução dos registros de transação.

Assim que o atraso especificado por max_standby_archive_delay ou max_standby_streaming_delay for excedido, as consultas conflitantes serão canceladas. Isto geralmente resulta apenas em um erro de cancelamento, embora no caso da reprodução de um comando DROP DATABASE toda a sessão conflitante será encerrada. Além disso, se o conflito for devido a um bloqueio mantido por uma transação ociosa (idle), a sessão conflitante será encerrada (este comportamento poderá mudar no futuro).

As consultas canceladas poderão ser repetidas imediatamente (após iniciar uma nova transação, é claro). Como o cancelamento da instrução depende da natureza dos registros de transação que estão sendo reproduzidos, uma consulta que foi cancelada poderá ser bem-sucedida se for executada novamente.

Deve-se ter em mente que os parâmetros de atraso são relativos ao tempo decorrido desde que os dados do WAL foram recebidos pelo servidor em-espera. Assim, o período de tolerância permitido para qualquer consulta no servidor em-espera nunca é maior do que o valor do parâmetro de atraso, podendo ser consideravelmente menor, se o servidor em-espera já estiver atrasado como resultado da espera pela conclusão de consultas anteriores, ou como resultado de ser incapaz de acompanhar uma carga de atualização pesada.

O motivo mais comum para haver conflito entre as consultas no servidor em-espera e a reprodução dos registros de transação, é a “limpeza precoce”. Normalmente, o PostgreSQL permite a limpeza de versões de linhas antigas quando não há transações que precisem vê-las, para garantir a visibilidade correta dos dados segundo as regras de MVCC (controle de concorrência multiversão). Entretanto, estas regras só podem ser aplicada para transações executadas no servidor primário. Por isto, é possível que a limpeza no servidor primário remova versões de linha que ainda devam estar visíveis para uma transação no servidor em-espera.

A limpeza de versões de linha não é a única causa possível de conflitos com consultas em servidor em-espera. Todas as varreduras apenas de índice (incluindo aqueles que operam noa servidores em-espera) devem usar um instantâneo do MVCC que “esteja de acordo” com o mapa de visibilidade. Consequentemente, surgem conflitos sempre que o VACUUM define uma página como inteiramente visível no mapa de visibilidade contendo uma ou mais linhas não visíveis a todas as consultas em servidor em-espera. Portanto, até mesmo executar o VACUUM em uma tabela sem linhas atualizadas ou excluídas que exijam limpeza pode levar a conflitos.

Os usuários devem estar cientes de que as tabelas atualizadas de forma regular e intensa no servidor principal causarão rapidamente o cancelamento de consultas em execução mais longas no servidor em-espera. Nesses casos, a configuração de um valor finito para max_standby_archive_delay ou max_standby_streaming_delay pode ser considerado semelhante à configuração de statement_timeout.

Existem possibilidades para remediar se o número de cancelamentos de consultas no servidor em-espera for considerado inaceitável. A primeira opção é definir o parâmetro hot_standby_feedback, que evita que o comando VACUUM remova linhas mortas recentemente e, portanto, não ocorram conflitos de limpeza. Se isto for feito, deve-se observar que atrasará a limpeza das linhas mortas no servidor primário, o que poderá resultar em um inchamento indesejável da tabela. Entretanto, a situação de limpeza não será pior do que se as consultas no servidor em-espera estivessem sendo executadas diretamente no servidor primário, e ainda seria obtido o benefício de descarregar a execução no servidor em-espera. Se os servidores em espera se conectarem e desconectarem com frequência, convém fazer ajustes para lidar com o período em que o hot_standby_feedback não está sendo retornado. Por exemplo, deve-se considerar aumentar max_standby_archive_delay, para que as consultas não sejam canceladas rapidamente por conflitos em arquivos de WAL durante os períodos de desconexão. Também deve-se considerar aumentar max_standby_streaming_delay, para evitar cancelamentos rápidos devido ao fluxo de registros de transação recém-chegados após a reconexão.

O número de consultas canceladas, e o motivo, podem ser vistos através da visão do sistema pg_stat_database_conflicts no servidor em-espera. A visão do sistema pg_stat_database também contém informações resumidas.

Os usuários podem controlar se será gerada uma mensagem de registro quando a reprodução do WAL estiver aguardando por conflitos por um tempo superior a deadlock_timeout. Isto é controlado pelo parâmetro log_recovery_conflict_waits.

Se hot_standby estiver ativo (on) no arquivo postgresql.conf (o valor padrão), e houver um arquivo standby.signal presente, o servidor será executado no modo Hot-Standby. Entretanto, poderá levar algum tempo até que sejam permitidas conexões no servidor em Hot-Standby, porque o servidor não aceitará conexões até ter concluído uma quantidade de restauração suficiente para fornecer um estado consistente, no qual podem ser executadas consultas. Durante este período, os clientes que tentarem se conectar serão recusados com uma mensagem de erro. Para confirmar que o servidor foi ativado, deve ser feito um ciclo tentando se conectar a partir de uma aplicação, ou procurada mensagens semelhantes a estas nos arquivos de registro de eventos do servidor (log):

LOG:  entrando no modo em-espera

... então, algum tempo depois ...

LOG:  estado de restauração consistente alcançado
LOG:  o sistema de banco de dados está pronto para aceitar conexões ↵
      de leitura-apenas.

As informações de consistência são registradas uma vez por ponto de verificação no servidor no primário. Não é possível ativar o modo Hot-Standby ao ler arquivos de WAL escritos durante um período em que wal_level não estava definido como replica ou logical no servidor primário. Mesmo após atingir um estado consistente, o instantâneo de restauração poderá não estar pronto para o modo Hot-Standby se as seguintes condições não forem atendidas, atrasando a aceitação de conexões de leitura-apenas. Para ativar o modo Hot-Standby, transações de escrita de longa duração com mais de 64 subtransações precisam ser encerradas na instância primária.

Se estiver sendo usado envio de WAL baseado em arquivo (warm standby), poderá ser necessário aguardar até que o próximo arquivo de WAL chegue, o que poderá demorar tanto tempo quanto for a configuração de archive_timeout no servidor primário.

As configurações de alguns parâmetros determinam o tamanho da memória compartilhada para rastrear os IDs de transação, bloqueios, e transações preparadas. Estas estruturas de memória compartilhada não devem ser menores no servidor em-espera do que no servidor primário, para garantir que não fique faltando memória compartilhada no servidor em-espera durante a restauração. Por exemplo, se o servidor primário estiver usado transação preparada, mas o servidor em-espera não tiver alocado nenhuma memória compartilhada para rastrear as transações preparadas, a restauração não poderá continuar até que a configuração do servidor em-espera seja alterada. Os parâmetros afetados são:

A maneira mais fácil de garantir que isto não se torne um problema é ter estes parâmetros configurados nos servidores em-espera com valores iguais ou maiores que no servidor primário. Portanto, se for desejado aumentar estes valores, deve-se fazê-lo primeiro em todos os servidores em-espera, antes de aplicar as alterações no servidor primário. Ao contrário, se for desejado diminuir estes valores, deve-se fazê-lo primeiro no servidor primário, antes de aplicar as alterações a todos os servidores em-espera. Deve-se ter em mente que quando o servidor em-espera é promovido, ele se torna a nova referência para as configurações de parâmetros necessárias para os servidores em-espera que o seguem. Portanto, para evitar que isto se torne um problema durante uma promoção (switchover) ou comutação (failover), é recomendável manter estas configurações iguais em todos os servidores em-espera.

O WAL rastreia as alterações nesses parâmetros no servidor primário. Se um servidor no modo Hot-Standby processar um registro de transação indicando que o valor corrente no servidor primário é maior que seu próprio valor, ele irá registrar um aviso e pausar a restauração. Por exemplo:

AVISO:  hot standby não é possível devido a configurações de parâmetros ↵
        insuficientes.
DETALHE:  max_connections = 80 é uma configuração mais baixa do que a ↵
          do servidor primário, onde o valor era 100.
LOG:  restauração pausada.
DETALHE:  Se a restauração for retomada, o servidor será desligado.
DICA:  Você pode então reiniciar o servidor após realizar as alterações ↵
       de configuração necessárias.

Neste ponto, as configurações no servidor em-espera precisam ser atualizadas, e a instância reiniciada, antes que a restauração possa continuar. Se o servidor em-espera não for um servidor Hot-Standby, então, quando encontrar uma alteração de parâmetro incompatível, ele irá parar imediatamente, sem pausa, porque não fará sentido continuar em funcionamento.

É importante que o administrador selecione as configurações apropriadas para max_standby_archive_delay e max_standby_streaming_delay. As melhores escolhas variam segundo as prioridades da instalação. Por exemplo, se o servidor for usado principalmente como um servidor de alta disponibilidade, será desejado configurações de atraso baixas, talvez até zero, embora esta seja uma configuração muito agressiva. Se o servidor em-espera for designado como um servidor adicional para consultas de suporte à decisão, poderá ser aceitável definir os valores máximos de atraso para muitas horas, ou até mesmo -1, o que significa aguardar indefinidamente a conclusão das consultas.

Os "bits de dica" (hint bits) do status da transação escritos no servidor primário não são registrados no WAL, portanto, os dados no servidor em-espera provavelmente reescreverão as dicas novamente no servidor em-espera. Portanto, o servidor em-espera ainda executará escritas em disco, mesmo que todos os usuários sejam de leitura-apenas; nenhuma alteração ocorre nos próprios valores dos dados. Os usuários ainda vão escrever em arquivos temporários para grandes classificações, e vão gerar novamente arquivos de informações de recache, de modo que nenhuma parte do servidor de banco de dados é realmente de leitura-apenas durante o modo Hot-Standby. Note, também, que as escritas em bancos de dados remotos usando o módulo dblink, e outras operações fora do servidor de banco de dados usando funções escritas em linguagens procedurais, ainda serão possíveis, mesmo que a transação seja de leitura-apenas localmente.

Os seguintes tipos de comandos de administração não são aceitos durante o modo de restauração:

Novamente, note-se que alguns desses comandos são permitidos durante transações no modo de "leitura-apenas" no servidor primário.

Como resultado, não é possível criar índices adicionais que existam apenas no servidor em-espera, nem estatísticas que existam apenas no servidor em-espera. Se estes comandos de administração forem necessários, devem ser executados no servidor primário e, por fim, estas alterações serão propagadas para o servidor em-espera.

As funções pg_cancel_backend() e pg_terminate_backend() funcionam nos processos servidores (back-ends) do usuário, mas não no processo startup, que executa a restauração. pg_stat_activity não mostra as transações de restauração como ativas. Como resultado, pg_prepared_xacts está sempre vazio durante a restauração. Se for desejado lidar com transações preparadas questionáveis, deve-se consultar pg_prepared_xacts no servidor primário, e executar os comandos para corrigir o problema lá, ou corrigi-los após o término da restauração.

pg_locks mostrará bloqueios mantidos pelos processos servidores, como é o normal. pg_locks também mostra uma transação virtual gerenciada pelo processo startup, que possui todos os AccessExclusiveLocks mantidos por transações sendo reproduzidas pela restauração. Note que o processo startup não adquire bloqueios para fazer alterações no banco de dados e, portanto, bloqueios diferentes de AccessExclusiveLocks não aparecem em pg_locks para o processo startup; apenas se presume que existam.

O plug-in Nagios check_pgsql irá funcionar, porque as informações simples que ele verifica existem. O script de monitoramento check_postgres também irá funcionar, embora alguns valores relatados possam fornecer resultados diferentes ou confusos. Por exemplo, a hora do último VACUUM não será mantida, porque nenhum VACUUM ocorre no servidor em-espera. Os VACUUM em execução no servidor primário enviam suas alterações para o servidor em-espera.

Os comandos de controle de arquivos de WAL não funcionam durante a restauração como, por exemplo, pg_backup_start, pg_switch_wal etc.

Os módulos carregáveis dinamicamente funcionam, incluindo pg_stat_statements.

Os bloqueios informativos (advisory locks) (veja Bloqueios informativos e Funções de bloqueio consultivo) funcionam normalmente na restauração, incluindo a detecção de impasse (deadlock). Note que os bloqueios informativos nunca são registrados no WAL, portanto, é impossível que um bloqueio informativo no servidor primário ou no servidor em-espera entre em conflito com a reprodução do WAL. Também não é possível adquirir um bloqueio informativo no servidor primário, e fazer com que ele inicie um bloqueio informativo semelhante no servidor em-espera. Os bloqueios informativo referem-se apenas ao servidor no qual são adquiridos.

Os sistemas de replicação baseados em gatilho, como Slony-I, Londiste e Bucardo não executam no servidor em-espera, embora executem sem problemas no servidor primário, desde que as alterações não sejam enviadas aos servidores em-espera para serem aplicadas. A reprodução do WAL não é baseada em gatilho, portanto, não se pode retransmitir do servidor em-espera para qualquer sistema que precise de escritas adicionais ou use gatilhos.

Não podem ser atribuídos novos OIDs, embora alguns geradores de UUID ainda possam funcionar, desde que não dependam da escrita de novos status no banco de dados.

No momento, a criação de tabelas temporárias não é permitida durante transações de leitura-apenas, portanto, em alguns casos, os scripts existentes não serão executados corretamente. Esta restrição poderá ser relaxada em uma versão futura. Isto é um problema de conformidade com o padrão SQL e um problema técnico.

O comando DROP TABLESPACE só poderá ser bem sucedido se o espaço de tabelas estiver vazio. Alguns usuários do servidor em-espera podem estar usando ativamente o espaço de tabelas por meio do parâmetro temp_tablespaces. Havendo arquivos temporários no espaço de tabelas, todas as consultas ativas serão canceladas para garantir que os arquivos temporários sejam removidos, para que o espaço de tabelas possa ser removido, e a reprodução do WAL possa continuar.

Executar DROP DATABASE ou ALTER DATABASE ... SET TABLESPACE no servidor primário irá gerar uma entrada de WAL que fará com que todos os usuários conectados a este banco de dados no servidor em-espera sejam desconectados à força. Esta ação ocorre imediatamente, independentemente da configuração de max_standby_streaming_delay. Note que ALTER DATABASE ... RENAME não desconecta os usuários, o que passará geralmente despercebido, embora em alguns casos possa causar confusão no programa, se depender de alguma forma do nome do banco de dados.

No modo normal (não de restauração), se for executado DROP USER ou DROP ROLE para uma função de banco de dados (role) com privilégio de LOGIN enquanto este usuário ainda estiver conectado, nada acontecerá ao usuário conectado — ele permanecerá conectado. Entretanto, o usuário não poderá se reconectar. Este comportamento também se aplica à restauração, portanto, um comando DROP USER no servidor primário não desconecta este usuário no servidor em-espera.

O sistema de estatísticas cumulativas fica ativo durante a restauração. Todas as varreduras, leituras, bloqueios, usos de índice, etc., serão registrados normalmente no servidor em-espera. No entanto, a reprodução do WAL não incrementará contadores específicos de relação e de banco de dados. Ou seja, a reprodução não irá incrementar as colunas de pg_stat_all_tables (como n_tup_ins), nem as operações de leitura ou escrita realizadas pelo processo de inicialização serão rastreadas nas visões pg_statio_, nem as colunas associadas de pg_stat_database serão incrementadas.

O autovacuum não fica ativo durante a restauração, iniciando normalmente no final da restauração.

O processo de ponto de verificação e o processo de escrita em segundo plano ficam ativos durante a restauração. O processo de ponto de verificação executará pontos de reinício (semelhantes aos pontos de verificação no servidor primário), e o processo de escrita em segundo plano executará atividades normais de limpeza de bloco. Isto pode incluir atualizações das informações do bit de dica (hint bit) armazenadas no servidor em-espera. O comando CHECKPOINT é aceito durante a restauração, embora execute um ponto de reinício em vez de um novo ponto de verificação.

Vários parâmetros foram mencionados acima em Tratamento de conflitos de consulta e Visão geral do administrador.

No servidor primário pode ser usado o parâmetro wal_level. Os parâmetros max_standby_archive_delay e max_standby_streaming_delay não terão efeito se definido no servidor primário.

No servidor em-espera podem ser usados os parâmetros hot_standby, max_standby_archive_delay e max_standby_streaming_delay.

Existem várias limitações para o modo Hot-Standby, que podem, e provavelmente serão, corrigidas em versões futuras: