Anthony O's questions

DO $$
DECLARE
    rec RECORD;
    outcome BOOLEAN;
    rule TEXT;
BEGIN
    -- Assume the record references a single row that contains the columns under test in the rule
    rule := 'columnA > 30 OR columnB < 50';
END;
$$
 LANGUAGE plpgsql;

Aqui está um bloco conciso com um exemplo da regra que gostaria de avaliar em relação ao registro. Imagino que precise de EXECUTEuma instrução SQL dinâmica.

Quero determinar o tipo do registro dinamicamente em tempo de execução, pois tenho acesso fácil a outra string com o nome da tabela. Eu imaginei lançar para table_name%ROWTYPE. Pelo que entendi, não consigo converter dinamicamente um RECORD para um tipo composto em tempo de execução.

Pensei então em usar row_to_json(rec), mas precisaria avaliar a regra em relação a esse objeto JSON. Não estou familiarizado com como fazer isso em PL/pgSQL.

Estou buscando de um CURSOR para um RECORD porque quero um iterador que possa passar para diferentes funções que não tenha a sobrecarga de uma TEMPORARY TABLE. Sou bastante novo em PL/pgSQL, diria apenas alguns milhares de LOC na linguagem, então ainda estou aprendendo como trabalhar com suas estruturas de controle. Estou pensando que talvez precise fazer backup um pouco e escolher diferentes controles e/ou estruturas de dados para o problema. Como você abordaria esse problema?

A definição de failback de acordo com os documentos da IBM é “o processo de retornar a produção ao seu local original após um desastre ou um período de manutenção programado”.

Pela minha leitura das postagens da comunidade postgresql, colocar um servidor primário antigo online novamente após o failover como um modo de espera que segue o novo primário também pode ser considerado failover.

Isso pode ocorrer porque é amplamente aceito que ter servidores de banco de dados idênticos é uma prática recomendada. No entanto, esta opção não está disponível para mim.

Tenho 2 servidores: Costanza e Kramer. Costanza é um servidor de alto desempenho. Kramer não.

Aqui está o cenário que estou tentando otimizar, passo a passo:

1. Costanza está em modo de falha irrecuperável (típico)
2. Kramer é promovido a primário
3. Costanza está disponível novamente e o PGDATA está intacto
4. Sincronize Costanza e Kramer de forma que nenhum dado gravado em Kramer seja perdido
5. Promover Costanza de volta ao status primário
6. Estabeleça Kramer como reserva

Estou focado nas etapas 4 e 5.

Ao executar o pg_rewind para reproduzir arquivos WAL, parece que "as modificações que ocorreram no servidor de origem após o último ponto de verificação comum são ignoradas - elas serão recuperadas de qualquer maneira quando o servidor de destino se tornar um modo de espera do servidor de origem". - veja esta pergunta SO

Deduzo disso que simplesmente executar pg_rewind não sincronizará Costanza e Kramer (etapa 4) porque as gravações em Kramer podem ter ocorrido após o último ponto de verificação comum. Isso também é o que observamos ao perfurar failbacks.

Minha solução para a etapa 4 é:

4a. Execute pg_rewind para sincronizar cronogramas divergentes

4b. Estabeleça o Costanza como um standby do Kramer e permita que ele acompanhe o atraso de replicação (assumindo que existam pontos de verificação pós-WALs)

Então

5. Desligue Kramer e promova Costanza para primário (novamente causando divergência na linha do tempo)

6a. Execute pg_rewind com Kramer como alvo

6b. Estabeleça Kramer como um standby do Costanza e permita que ele acompanhe o atraso de replicação (novamente, assumindo que existam pontos de verificação pós-WALs)

Este é um cenário pouco frequente. Mas não sei quais modos de falha encontrarei e se o PGDATA estará intacto ou não.

Este é um banco de dados muito grande e quero evitar mover dados por meio de backup de base sempre que possível.

Essa abordagem parece ineficiente para mim porque devo executar o pg_rewind duas vezes e tenho que estabelecer o Costanza como um modo de espera apenas para aplicar as modificações que ocorreram no ponto de verificação pós-comum de Kramer.

Devo minimizar a perda de dados e esta solução parece fazer isso com transferência mínima de dados.

(Um aparte: devo me preocupar com a criação adicional da linha do tempo? Isso parece inevitável, assim como ocorre na promoção de um banco de dados para primário)

Existe alguma maneira de aplicar as modificações no posto de controle comum de Kramer para Costanza sem estabelecer Costanza como reserva de Kramer?

Existe um caminho mais curto para um resultado equivalente? Ou existe um caminho que você pode julgar "mais fácil" de seguir em um cenário de falha de banco de dados?

  WITH aux_results AS (
    SELECT id
    FROM vendors
  )
  SELECT c.id
  FROM customers AS c
  WHERE c.vendor IN (SELECT * FROM aux_results);

Aqui está um exemplo ingênuo e simples de um CTE. A instrução auxiliar usa SELECT para recuperar ids. Para filtrá-los, tenho que usar SELECT ou uma exceção é lançada.

Por que isso é um padrão diferente de usar uma subconsulta para fazer a mesma consulta geral?

Ver:

https://www.postgresql.org/docs/current/functions-subquery.html#FUNCTIONS-SUBQUERY-IN

Parece que o objeto retornado por uma subconsulta é diferente do objeto retornado pela instrução auxiliar CTE. A maneira como você deve consultar é diferente, portanto a interface externa é diferente, mas ambas podem ser consideradas tabelas transitórias.

Como um aparte, há algum impacto no desempenho? (duvido) Devo usar apenas uma subconsulta? (duvido)

Eu tenho 2 clusters de banco de dados que operam de forma independente. No futuro, pode ser necessário mover os registros de um cliente do cluster 1 para o 2. Tenho um script bash onde faço a cópia do lado do servidor dos registros da tabela em arquivos CSV do cluster 1 e depois os restauro no cluster 2.

As associações entre os dados usam IDs sequenciais. Esses IDs não são exclusivos nas duas instâncias. Parece que existem duas possibilidades:

1. Não estou usando as melhores ferramentas para meu caso de uso. Existem outras ferramentas que me permitem fazer isso com muito menos problemas. Eu encobri os wrappers de dados estrangeiros. Não quero fazer um dump porque preciso apenas de alguns registros.

2. Eu preciso apenas absorver e usar UUIDs que são exclusivos em meu conjunto de dados.