Alterei a porta do Postgres para 2345e tenho o socket em:
/tmp/.s.PGSQL.2345
Se eu executar psql, recebo este erro:
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
como passar o caminho do soquete?
Eu quero atualizar/mover um cluster de escala de tempo em execução gerenciado pelo Patroni usando o PostgreSQL 13 para um novo hardware com o PostgreSQL 14, o conjunto de dados é de ~ 40 GB, mas está demorando muito para fazer um backup usando:
pg_dump -j 8 -Fd -f /tmp/promscale.back -v promscale
O mesmo se estiver usandots-dump
Portanto, querendo saber se eu poderia usar pg_basebackup? Atualmente estou tentando algo como:
pb_basebackup -h 10.1.2.3 -U replicator -P -D /db/data14 -S slot1 -X stream --checkpoint=fast
Mas só recebo isso e nenhum progresso:
waiting for checkpoint
Alguma idéia sobre como eu poderia acelerar o despejo ou atualizar com o mínimo de tempo de inatividade zero?
Eu preciso executar uma instrução alter, mas gostaria de evitar travar/parar o cluster. Os documentos Galera aconselharam usar:
SET wsrep_OSU_method='RSU';
Em seguida, execute a instrução ALTER, uma vez finich:
SET wsrep_OSU_method='TOI';
O problema é que isso precisa ser executado em todos os nós e eu só tenho acesso a um nó atrás de um balanceador de carga, alguma alternativa ou solução alternativa?
O Galera usa uma replicação baseada em certificação para obter uma consistência forte.
Ao fazer uma transação, depois de fazer um, COMMITos outros nós irão certificar e se estiver ok, será confirmado com sucesso.
Mas o que acontece no caso de perder um nó que certificou o commit, mas ainda está buscando os dados, por exemplo, ao escrever um big blob?
Do meu entendimento, o processo de certificação é síncrono, mas a transferência de dados é assíncrona, o que significa que o cliente/usuário pode pensar que seus dados estão armazenados em todos os nós após a execução com sucesso COMMIT, mas enquanto na realidade está acontecendo no backend é que os dados ainda podem estar sincronizando entre os nós e em caso de interrupção da rede e dependendo do tipo de transação o nó pode estar em conflito, correto?
Se este for o caso, como o cluster poderia ser configurado para se auto-recuperar de possíveis conflitos ou imaginando se existe uma maneira de obter uma consistência forte, mesmo que isso impacte o tempo de retorno de cada COMMIT, já que só deve ser bem-sucedido após os dados serem full transmitido em todos os nós.