O novo recurso Hot Standby no próximo PostgreSQL 9.0 permite a execução de consultas em nós de espera que anteriormente não faziam nada além de executar um processo de recuperação. Duas expectativas comuns que ouvi de usuários antecipando esse recurso é que ele permitirá a distribuição de consultas curtas em ambos os nós ou a execução de relatórios longos no modo de espera sem usar recursos no mestre. Ambos são possíveis de fazer agora, mas a menos que você entenda as compensações envolvidas em como o Hot Standby funciona, pode haver algum comportamento imprevisto aqui.
Consultas padrão de longa duração
Um dos problemas tradicionais em um banco de dados que usa MVCC, como o PostgreSQL, é que uma consulta de longa duração precisa manter aberto um recurso – referido como um instantâneo na implementação atual do Postgres – para evitar que o banco de dados remova os dados que a consulta precisa operar. Por exemplo, só porque outro cliente excluiu uma linha e se comprometeu, se uma consulta já em execução precisar dessa linha para ser concluída, você ainda não poderá limpar os blocos de disco físico relacionados a essa linha. Você precisa esperar até que nenhuma consulta aberta que espera que essa linha esteja visível ainda esteja disponível.
Limitações do Hot Standby
Se você tiver uma consulta de longa duração que deseja que o Hot Standby execute, há alguns tipos de coisas ruins que podem acontecer quando o processo de recuperação está aplicando atualizações. Eles são descritos em detalhes na Documentação do Hot Standby. Algumas dessas coisas ruins farão com que as consultas executadas no modo de espera sejam canceladas por motivos que podem não ser intuitivamente óbvios:
- Uma atualização HOT ou atualização relacionada a VACUUM chega para excluir algo que a consulta espera que seja visível
- Uma exclusão de árvore B é exibida
- Há um problema de bloqueio entre a consulta que você está executando e quais bloqueios são necessários para que a atualização seja processada.
A situação de bloqueio é difícil de lidar, mas não é muito provável que aconteça na prática por tanto tempo se você estiver apenas executando consultas somente leitura no modo de espera, porque elas serão isoladas via MVCC. Os outros dois não são difíceis de encontrar. O básico a entender é que qualquer UPDATE ou DELETE no mestre pode levar à interrupção de qualquer consulta no modo de espera; não importa se as alterações estão relacionadas ao que a consulta está fazendo.
Bom, rápido, barato:escolha dois
Essencialmente, há três coisas que as pessoas podem querer priorizar:
- Evite a limitação do mestre:permita que xids e snapshots associados avancem sem limites no mestre, para que VACUUM e limpezas semelhantes não sejam retidas pelo que o standby está fazendo
- Consultas ilimitadas:execute consultas em espera por qualquer período de tempo arbitrário
- Recuperação atual:mantenha o processo de recuperação em espera atualizado com o que está acontecendo no mestre, permitindo failover rápido para HA
Em qualquer situação com Hot Standby, é literalmente impossível ter todos os três ao mesmo tempo. Você só pode escolher o seu trade-off. Os parâmetros ajustáveis disponíveis já permitem otimizar de algumas maneiras:
- Desativar todas essas configurações de atraso/adiamento otimiza a recuperação sempre atual, mas você descobrirá que as consultas têm mais probabilidade de serem canceladas do que o esperado.
- max_standby_delay otimiza para consultas mais longas, à custa de manter a recuperação atualizada. Isso atrasa a aplicação de atualizações no modo de espera quando uma que causará um problema (HOT, VACUUM, B-tree delete, etc.) aparece.
- vacuum_defer_cleanup_age e alguns hacks de snapshot podem introduzir alguma limitação principal para melhorar os outros dois problemas, mas com uma interface de usuário fraca para fazer isso. vacuo_defer_cleanup_age está em unidades de IDs de transação. Você precisa ter uma ideia da quantidade média de xid churn em seu sistema por unidade de tempo para transformar a maneira como as pessoas pensam sobre esse problema (“adiar por pelo menos 1 hora para que meus relatórios sejam executados”) em uma configuração para esse valor. A taxa de consumo xid simplesmente não é uma coisa comum ou mesmo razoável para medir/prever. Como alternativa, você pode abrir um instantâneo no primário antes de iniciar uma consulta de longa duração no modo de espera. dblink é sugerido na documentação do Hot Standby como uma forma de fazer isso. Teoricamente, um daemon no modo de espera poderia ser escrito na terra do usuário, vivendo no primário, para contornar esse problema também (Simon tem um design básico para um). Basicamente, você inicia uma série de processos em que cada um adquire um instantâneo e depois dorme por um período antes de liberá-lo. Ao espaçar por quanto tempo cada um deles dormiu, você pode garantir que os instantâneos xid nunca avançassem muito rapidamente no mestre. Já deve parecer óbvio o quanto isso seria um hack terrível.
Melhorias potenciais
O único deles que você pode realmente fazer algo de forma limpa é apertar e melhorar a interface do usuário para a limitação principal. Isso transforma isso no problema tradicional já presente no banco de dados:uma consulta de longa duração mantém aberto um instantâneo (ou pelo menos limita o avanço de IDs de transação relacionados à visibilidade) no mestre, impedindo que o mestre remova coisas necessárias para essa consulta completo. Alternativamente, você pode pensar nisso como um vácuo_defer_cleanup_age de autoajuste.
A questão é como tornar o primário respeite as necessidades de consultas de longa duração no standby . Isso pode ser possível se mais informações sobre os requisitos de visibilidade da transação do standby forem compartilhadas com o mestre. Fazer esse tipo de troca seria realmente algo mais apropriado para a nova implementação do Streaming Replication compartilhar. A forma como um servidor Hot Standby simples é provisionado não fornece nenhum feedback para o mestre adequado para que esses dados sejam trocados, além de abordagens como o já mencionado dblink hack.
Com o PostgreSQL 9.0 chegando à quarta versão alfa, pode haver ainda há tempo para ver algumas melhorias nesta área ainda antes do lançamento 9.0. Seria bom ver o Hot Standby e o Streaming Replication realmente integrados de uma maneira que realiza coisas que nenhum dos dois é totalmente capaz de fazer sozinho antes que a codificação nesta versão congele completamente.
