Início / dba / Perguntas / 130622
Accepted
foobar0100
Asked: 2016-02-27 16:09:05 +0800 CST

Para uma carga de trabalho em espera de consultas analíticas de execução longa, é melhor ativar hot_standby_feedback ou definir as configurações de max_standby_*_delay como -1?

  • 772

Ao ativar um servidor de espera ativa especificamente para propósitos de BI/Analytics, onde consultas longas podem ser comuns, é melhor ativar hot_standby_feedbackou definir as max_standby_*_delayconfigurações como -1?

Meu entendimento é que hot_standby_feedbackimpede o mestre de fazer coisas como VACUUMaté que seja seguro fazer o mesmo no modo de espera, onde as max_standby_*_delayconfigurações permitem VACUUMiniciar no mestre, mas o modo de espera, se necessário, aguarda para aplicar qualquer limpeza a vácuo que possa entrar em conflito com um longo consulta em execução.

Além disso, os documentos afirmam para hot_standby_feedback:

Existem possibilidades corretivas se o número de cancelamentos de consultas em espera for considerado inaceitável. A primeira opção é definir o parâmetro hot_standby_feedback, que evita que o VACUUM remova as linhas mortas recentemente e, portanto, não ocorram conflitos de limpeza. Se você fizer isso, observe que isso atrasará a limpeza de linhas mortas no primário, o que pode resultar em um inchaço indesejável da tabela. No entanto, a situação de limpeza não será pior do que se as consultas em espera estivessem sendo executadas diretamente no servidor primário, e você ainda obteria o benefício de descarregar a execução no modo de espera.

E para max_standby_*_delayos documentos, estado:

Se o servidor em espera for designado como um servidor adicional para consultas de suporte à decisão, pode 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.

Ainda não está claro para mim qual é o melhor e quais são os prós e contras exatos de cada um.

postgresql replication

2 respostas

  1. Best Answer

    Com hot_standby_feedbackativado, o vácuo ainda pode ser feito, mas será menos eficaz, pois algumas tuplas que seriam aspiradas agora precisam ser adiadas para um vácuo posterior. A única desvantagem real que eu conheço é o aumento do inchaço. O quanto isso é uma desvantagem depende inteiramente do seu uso. O pior caso é se seu banco de dados tiver tabelas pequenas e intensamente atualizadas, como uma tabela de fila de trabalho. Esses podem ficar extremamente inchados. Se você não tiver esse tipo de mesa, provavelmente não terá problemas.

    Os problemas com max_standby_*_delay são que outras consultas em execução no modo de espera também estão tendo seu horizonte retido por quantidades potencialmente grandes e que, se você segurar o modo de espera por tempo suficiente, os arquivos WAL não repetidos acumulados encherão seu disco rígido e você perderá o stand-by.

    • 4

  2. hot_standby_feedbackafeta a atividade do servidor principal, enquanto max_standby_*_delayafeta a atividade do servidor em espera.

    Contras de hot_standby_feedbacké óbvio: Primário não pode remover tuplas mortas enquanto o conflito ocorre.

    max_standby_*_delaysão para servidores em espera e não afetam a atividade do primário. Este é um dos prós desses parâmetros. Os contras deles são os seguintes: Quando ocorre um conflito em standby, seu standby suspende a repetição do log do WAL por até max_standby_*_delay. Portanto, se um conflito ocorrer por uma consulta, as consultas subsequentes lerão dados antigos (instantâneo do banco de dados pouco antes de ocorrer o conflito), não poderão ler os dados mais recentes, pois o modo de espera suspende a reprodução do WAL.

    Se você executar apenas uma consulta no modo de espera, acho que pode definir -1como max_standby_*_delay.

    • 0

relate perguntas