admin/projeto-importado
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
projeto-importado/docs/replicacao_sgdb_ipm_cliente.md
T
admin 5cd1348e69 Commit inicial automático
2025-11-28 00:29:42 -03:00

505 lines
24 KiB
Markdown
Raw Permalink Blame History

# Replicação Banco de Dados (Data Center IPM x Cliente)
>
> Documentação do passo a passo para ativação da replicação do banco de dados entre a estrutura do Data Center da IPM com a estrutura da Prefeitura do cliente já atualizado para a versão do PostgreSQL 16.
>
<b> OBS: O manual abaixo refere-se a instalação inicial da replicação. Caso você esteja recriando a mesma devido a algum erro na transferencia ou corrupções de arquivos, utilize o manual sobre a reativação:</b>
[` Reativar a Replicação:`](./reativar_replicacao_sgdb_ipm_cliente.md)
### Pré-requisitos
#### Ambas as partes
- Utilizar Template com PostgreSQL 16.3
- PostgreSQL na mesma versão nos dois lados
- Rsync nos dois lados
#### Ambiente Cliente (Prefeitura)
- No cliente, NAT na porta 61100 para porta 22 do servidor SGDB
#### Ambiente Data Center IPM
- Criação de alias para o endereço IP do cliente
- Liberação saída na porta 61100 no FW do cliente no Data Center
## 00000-cliente-afw-01-0260.atende.net
Para iniciar o processo de Replicação do banco de dados entre o Data Center da IPM e a Estrutura do cliente, será necessário algumas configurações no Firewall na estrutura do cliente no DC IPM.
Para acessar o mesmo, conecte via interface INT_RT com a Porta padrão no navegador
https://172.16.XXX.XXX:9080 ou https://172.24.XXX.XXX:9080
As credenciais de acesso devem ser consultadas através da ferramenta GTT (https://datacenter.ipm.com.br)
Será necessário realizar a criação de um Aliases para o IP Público do Cliente:
Acesse: Firewall > Aliases > IP
Adicione um novo IP
Name: Cliente_DC
Type: Host(s)
IP or FQDN: XXX.XXX.XXX.XXX Descrição: Replicacao (Deve ser criado informando o IP Público passado pelo cliente)
![Aliases Firewall](../img/aliases_ip_replicacao.png)
Após a criação do Aliases, será necessário criar uma regra de Firewall na interface LAN, seguindo o padrão abaixo:
Action: Pass
Interface: LAN
Address Family: IPV4
Protocol: TCP/UDP
Source: LAN NET
Source Port Range: From Any to Any
Destination: Singles host or alias (Cliente_DC) - Informar o nome do Aliases criado no passo anterior
Destination Port Range: From Other 61100 To Other 61100 - Liberando o acesso apenas para o IP e Porta específico que esta configurado no cliente
Description: Replicacao
![Regras LAN Firewall](../img/regra_lan_replicacao.png)
<i>IMPORTANTE: Lembre-se sempre de após criar uma regra no Firewall, de ajustar a ordem/sequencia da mesma acima das regras de Bloqueio IPV4 e IPV6 para que a mesma funcione de forma adequada.</i>
Ajustar o nome do servidor no DNS Forwarder do Firewall
Acesse Services > DNS Forwarder
Host: 01611-pinhais-bdp-01-1600-master
Domain: atende.net
IP: 192.168.XXX.XXX
## 00000-cliente-bdp-01-1600-slave.atende.net (Ambiente Destino - Cliente/Prefeitura)
Para que seja possível conectar no banco de dados no ambiente da Prefeitura do cliente, você deve conectar inicialmente no Banco de Dados Principal (Em produção no Data Center da IPM)
Acesse o mesmo através da interface INT_RT Porta padrão 9032
Abra o putty
Informe o IP da INT_RT: 172.16.XXX.XXX ou 172.24.XXX.XXX Porta 9032
Será solicitado as credenciais:
Usuário: ipm
Senha: deve ser consultada via datacenter.ipm.com.br
Após conectar execute o comando abaixo passando as informações do Usuário/Senha/IP passadas pelo cliente:
ssh ipm@0.1.2.3 -p 61000
Será exibido a mensagem abaixo e solicitado a senha:
The authenticity of host '0.1.2.3 (0.1.2.3)' can't be established.
ED25519 key fingerprint is SHA256:MN8C+wPjLZUq2Zppy8c9qCsrHhnhTqTaY1fyKJO8+RI.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '0.1.2.3' (ED25519) to the list of known hosts.
Informe a senha para conexão:
ipm@0.1.2.3's password:
Após conectado, você deve se tornar root para realizar as configurações no ambiente mencionadas abaixo:
su - root
Senha: Credenciais devem ter sido passadas pelo cliente
Verificar particionamento para garantir que tenha espaco suficiente para o banco.
# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 294M 2,2M 292M 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 40G 6,2G 34G 16% /
tmpfs 1,5G 1,1M 1,5G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
/dev/sda2 2,0G 300M 1,7G 15% /boot
/dev/sda1 1,1G 6,1M 1,1G 1% /boot/efi
/dev/mapper/ubuntu--vg-lv--var--log 40G 2,1G 38G 6% /var/log
/dev/mapper/ubuntu--vg-lv--home 10G 104M 9,9G 2% /home
/dev/mapper/postgresql--vg02-lv--dados 120G 969M 119G 1% /var/lib/postgresql
/dev/mapper/postgresql--vg01-lv--indice 80G 604M 80G 1% /var/lib/postgresql/16/tablespaces/indice
/dev/mapper/postgresql--vg03-lv--archived 200G 1,5G 199G 1% /var/lib/postgresql/16/tablespaces/archived
tmpfs 294M 0 294M 0% /run/user/1000
No caso do servidor clonado deve-se expandir as partições LVM.
/dev/mapper/postgresql--vg02-lv--dados 120G 969M 119G 1% /var/lib/postgresql
/dev/mapper/postgresql--vg01-lv--indice 80G 604M 80G 1% /var/lib/postgresql/16/tablespaces/indice
/dev/mapper/postgresql--vg03-lv--archived 200G 1,5G 199G 1% /var/lib/postgresql/16/tablespaces/archived
Procedimento de expansão de disco no padrão do PostgreSQL 16
# Expandir ampliando o disco existente
# Listar os discos:
lsblk
# Realizar o resize dos discos:
pvresize /dev/sdb
pvresize /dev/sdc
pvresize /dev/sdd
# Listar os discos e os espaços livres:
pvscan
# Alocar 100% do espaço livre em cada disco:
lvextend -l +100%FREE /dev/postgresql-vg03/lv-archived
lvextend -l +100%FREE /dev/postgresql-vg02/lv-dados
lvextend -l +100%FREE /dev/postgresql-vg01/lv-indice
# Expandir o Sistema de arquivos:
xfs_growfs /var/lib/postgresql
xfs_growfs /var/lib/postgresql/16/tablespaces/indice
xfs_growfs /var/lib/postgresql/16/tablespaces/archived
# Listas discos:
lsblk
# Listar pontos de montagens no Linux! (Verifique se a expansão ocorreu de forma adequada.)
df -h
Após ajustes de disco, deve ser executado todos os procedimentos da planilha BDP16 para realizar a configuração do servidor conforme os padrões IPM:
Arquivo para seguir o Checklist de Configuração:
Alexsandre Constantino de Paula > CheckList > Manutenção Servidores - 15082024 v1.xlsx > BDP16
Após a configuração da VM seguindo o checklist acima, deve ser alterado o arquivo postgresql.conf
cd /etc/postgresql/16/main/
cp postgresql.conf postgresql.bkp-26022025
vim postgresql.conf
# Parâmetro para alterar
max_locks_per_transaction = 1000
Depois de configurar o ambiente conforme os padrões, será necessário a criação do diretório que receberá a replicação:
mkdir /var/lib/postgresql/16/replicacao
chown postgres.postgres /var/lib/postgresql/16/replicacao -R
chmod 700 /var/lib/postgresql/16/replicacao -R
Realizar o download dos scripts e configurações para ativar a replicação.
cd /root
rm -rf /root/replicacao*
wget https://datacenter.atende.net/updates/replicacao_16.zip
unzip replicacao_16.zip
cp /root/replicacao/slave/* /etc/postgresql/16/main/
chown postgres.postgres /etc/postgresql/16/main/postgresql.auto.conf /etc/postgresql/16/main/*.sh
Ajustar pg_hba.conf, liberando somente os endereços IP internos informados pelo cliente.
vim /etc/postgresql/16/main/pg_hba.conf
Deve ser criado um usuário fora do padrão para cópia no servidor SLAVE, utilizar a nomenclatura rep00000, sendo 00000 o código do cliente
useradd rep00000
passwd rep00000
Após criado, realize o login com o mesmo para criação da pasta SSH
su - rep00000
ssh ipm@127.0.0.1 (yes)
Retorno:
rep00000@000000-cliente-bdp-01-1600-slave:~$ ssh ipm@127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:MN8C+wPjLZUq2Zppy8c9qCsrHhnhTqTaY1fyKJO8+RI.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '127.0.0.1' (ED25519) to the list of known hosts.
ipm@127.0.0.1's password:
Permission denied, please try again.
Após o permission denied, cancele o comando com o ctrl + c
Após executado, execute um exit para voltar para o usuário root
exit
Ainda com o usuário root, coloque o usuário rep00000 no mesmo grupo e pasta de usuario do postgres:
vim /etc/passwd
postgres:x:121:125:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
rep00000:x:121:125:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
Após a execução de todos os passos acima, iremos parar o banco de dados até que a cópia inicial esteja concluída.
systemctl stop postgresql.service
Confira o nome do Servidor Slave, garantindo que tenha o sufixo "slave" no final no seguintes arquivos:
vim /etc/hosts
00000-cliente-bdp-01-1600-slave
vim /etc/hostname
00000-cliente-bdp-01-1600-slave.atende.net
Após efetuado todo o procedimento, execute dois comandos de exit para voltar para o banco Master:
exit ( Voltar para o usuário rep00000 )
exit ( Desconectar do servidor SLAVE )
## 00000-cliente-bdp-01-1600-master.atende.net (Ambiente Origem - Cliente/DataCenter IPM)
Para realizar a configuração no servidor Master, deve-se realizar o acesso ao mesmo!
Obs. Caso você esteja seguindo o manual, você executou os dois exits informados acima e automaticamente já estará no banco de Produção. Porém caso tenha fechado a sessão ou algo atípico tenha ocorrido, você pode realizar uma nova conexão ao mesmo seguindo os passos abaixo:
Através da INT_RT Porta padrão 9032
172.16.XXX.XXX 9032 ou 172.24.XXX.XXX 9032
Usuário: ipm (somente o usuário IPM terá acesso via SSH)
Senha: deve ser consultada via datacenter.ipm.com.br
Após conectado, você deve se tornar root para alterar as configurações seguintes:
su - root
Senha: deve ser consultada via datacenter.ipm.com.br
Alterar os arquivos abaixo, adicionando o sufixo "master" no final
vim /etc/hosts
00000-clean-bdp-01-1600-master
vim /etc/hostname
00000-clean-bdp-01-1600-master.atende.net
Devido a adição do sufixo acima, precisamos garantir que o nome com o sufixo "master" esteja também alterado na configuração do DNS Forwarder do Firewall do cliente.
Para conferir, basta acessar o Firewall do cliente através do IP da INT_RT Porta 9080 e acessar a aba Services > DNS Forwarder
No banco master com o usuário root, crie os diretórios para armazenar os arquivos a serem transferidos para o servidor SLAVE e suas devidas permissões:
mkdir /var/lib/postgresql/16/replicacao
chown postgres.postgres /var/lib/postgresql/16/replicacao -R
chmod 700 /var/lib/postgresql/16/replicacao -R
Realizar o download dos scripts e configurações para ativar a replicação.
cd /root
wget https://datacenter.atende.net/updates/replicacao_16.zip
unzip replicacao_16.zip
cp /root/replicacao/master/* /etc/postgresql/16/main/
chown postgres.postgres /etc/postgresql/16/main/postgresql.auto.conf /etc/postgresql/16/main/*.sh
Ajustar as configurações do script de replicação alterando os valores da variável "connection", para o nome do usuário e endereço IP do cliente.
vim /etc/postgresql/16/main/replicacao_archive.sh
connection=rep00000@0.1.2.3
<b>IMPORTANTE
No primeiro momento, não adicionaremos um disco para a pg_wal.
</b>
Desativar a execuçãodo vaccumm e reindex antes da execução e ao final deve-se ativar novamente, pois manter a execução dos mesmos pode causar problemas na ativação da replicação (PALIATIVO)
vim bkp_remoto/bkp_remoto.sh
comentar linhas:
2103 e 2104
Após isso, faça um backup do arquivo postgresql.auto.conf
mv /var/lib/postgresql/16/main/postgresql.auto.conf /var/lib/postgresql/16/main/postgresql.auto.bkp
Em seguida, iremos gerar a chave pública no servidor de MASTER com o usuário postgres para realizarmos a conexão com o banco de dados Slave que esta localizado no ambiente da Prefeitura do Cliente sem senha:
su - postgres
ssh-keygen -t rsa
Após gerado a chave pública, iremos realizar a copia da mesma entre o servidor MASTER para SLAVE
Conecte com o usuário rep00000 e a senha definida informando o IP/Porta do servidor Slave
ssh rep00000@0.1.2.3 -p 61100
"Será solicitado a senha do mesmo"
exit
Após teste de conexão com o usuário rep00000 do servidor Master para o Slave, realizaremos a copia da chave:
cat .ssh/id_rsa.pub | ssh rep00000@0.1.2.3 -p 61100 'cat >> .ssh/authorized_keys'
Após a copia da chave, a conexão entre o servidor Master e Slave logado com o usuário postgres deverá ocorre sem senha!
## Copia dos diretórios e arquivos (Processo da replicação)
Após ter configurado os servidores Master (Origem) e Slave (Destino), seguiremos com a copia dos arquivos para posterior ativação da replicação.
Após a execução dos processos acima, iremos realizar a copia dos arquivos entre os ambientes conforme os passos abaixo.
Obs. Sempre fique atento a qual servidor cada processo deve ser executado!
### Servidor Slave - Processo de Limpeza
Realizamos a conexão com o servidor Slave através do Servidor Master utilizando a chave pública criada anteriormente.
Conecte no servidor master com o usuário ipm informando a INT_RT e porta padrão:
Através da INT_RT Porta padrão 9032
172.16.XXX.XXX 9032 ou 172.24.XXX.XXX 9032
Usuário: ipm (somente o usuário IPM terá acesso via SSH)
Senha: deve ser consultada via datacenter.ipm.com.br
Após conectado, você deve se tornar root e posterior login via postgres
su - root
Senha: deve ser consultada via datacenter.ipm.com.br
Agora logaremos com o usuário postgres no Master não havendo a necessidade de senha:
su - postgres
E após a conexão com usuário postgres, iremos chamar o comando de SSH para o banco Slave também sem necessidade de passar a senha:
ssh rep00000@0.1.2.3 -p 61100
Inicialmente, realizaremos a parada do serviço do PostgreSQL e a limpeza do servidor Slave antes de copiar os arquivos do banco de dados Master:
su - root
systemctl stop postgresql.service
rm -rf /var/lib/postgresql/16/main/*
rm -rf /var/lib/postgresql/16/wal/*
rm -rf /var/lib/postgresql/16/tablespaces/archived/*
rm -rf /var/lib/postgresql/16/tablespaces/fast/*
rm -rf /var/lib/postgresql/16/tablespaces/indice/*
rm -rf /var/lib/postgresql/16/replicacao/*
exit ( Voltar para o usuário rep00000 )
exit ( Desconectar do servidor SLAVE )
### Servidor Master - Processos
Ativar Replicação
ln -s /etc/postgresql/16/main/postgresql.auto.conf /var/lib/postgresql/16/main/postgresql.auto.conf ( Deve se rexecutado no servidor master com o usuário POSTGRES )
exit ( Voltar para o usuário root no servidor MASTER )
Reiniciar o banco de dados Master (Esse procedimento deve ocorrer fora de horário de expediente, evitando paradas ao ambiente de Produção do cliente)
systemctl restart postgresql.service
Conectar via pgadmin no database template1 e iniciar o modo backup: (alterar o label para o nome desejado)
<i>IMPORTANTE: Após o start, manter a sessão (janela) no pgadmin aberta com o start até a finalização de todo o processo </i>
SELECT pg_backup_start('rep00000',true);
Iniciar a cópia do cluster para Slave em partes. Deve ser substituido o usuário rep00000 e o IP passado pelo cliente.
Essa copia deve ser realizada com o usuário postgres no banco de dados Master:
su - postgres
cd /var/lib/postgresql/16/tablespaces/
tar -zcvf - fast/ |ssh -p 61100 rep00000@0.1.2.3 "cat > /var/lib/postgresql/16/tablespaces/fast.tgz"
tar -zcvf - archived/ |ssh -p 61100 rep00000@0.1.2.3 "cat > /var/lib/postgresql/16/tablespaces/archived.tgz"
tar -zcvf - indice/ |ssh -p 61100 rep00000@0.1.2.3 "cat > /var/lib/postgresql/16/tablespaces/indice.tgz"
cd /var/lib/postgresql/16/
tar -zcvf - main/base main/current_logfiles main/global main/pg_commit_ts main/pg_dynshmem main/pg_logical main/pg_multixact main/pg_notify main/pg_replslot main/pg_serial main/pg_snapshots main/pg_stat main/pg_stat_tmp main/pg_subtrans main/pg_tblspc main/pg_twophase main/PG_VERSION main/pg_wal main/pg_xact main/postmaster.opts wal/pg_wal |ssh -p 61100 rep00000@0.1.2.3 "cat > /var/lib/postgresql/16/main.tgz"
### Servidor Slave
Após a compactação de toda a transferencia ter finalizado, conecte no servidor "SLAVE" para realizar a descompactação dos arquivos tranferidos.
ssh rep00000@0.1.2.3 -p 61100
cd /var/lib/postgresql/16/tablespaces/
tar -xzvf fast.tgz
tar -xzvf archived.tgz
tar -xzvf indice.tgz
cd /var/lib/postgresql/16/
tar -xzvf main.tgz
Iremos realizar a configuração de atalhos (links) para a pg_wal e também para a postgresql.auto.conf e a criação do arquivo standby.signal
cd /var/lib/postgresql/16/main
ln -s /etc/postgresql/16/main/postgresql.auto.conf /var/lib/postgresql/16/main/postgresql.auto.conf
touch /var/lib/postgresql/16/main/standby.signal
ls -la
Será necessário também a criação de uma pasta para armazenar os arquivos enviados até o momento pelo banco Master até o Slave:
mv /var/lib/postgresql/16/replicacao /var/lib/postgresql/16/replicacao_tx
mkdir -p /var/lib/postgresql/16/replicacao
chmod 700 /var/lib/postgresql/16/replicacao -R
chown postgres.postgres /var/lib/postgresql/16/replicacao -R
Após a criação da pasta, executaremos o script que descompactará todos os arquivos da pasta /var/lib/postgresql/16/replicacao_tx para /var/lib/postgresql/16/main/pg_wal:
cd /etc/postgresql/16/main/
./replicacao_restore_all.sh >> /var/log/postgresql/postgresql-restore-all.log &
tail -f /var/log/postgresql/postgresql-restore-all.log (acompanhar até finalizar a extração completa do arquivos na pasta replicacao_tx)
Após a execução do Script, com o root iremos subir o banco no servidor Slave
su - root
systemctl start postgresql.service
O comando de "start" ficará aguardando por um tempo e depois será liberado. Para acompanhar o processo, pode ser verificado os arquivos de logs:
tail -f /var/log/postgresql/postgresql-2024-11-12_145135.log
Acompanhar até aparecer "database system is ready to accept read-only connections"
2024-11-12 15:01:25.660 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: redo in progress, elapsed time: 590.00 s, current LSN: 525/82DDC190
2024-11-12 15:01:26.880 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: restartpoint complete: wrote 45663 buffers (5.8%); 0 WAL file(s) added, 92 removed, 0 recycled; write=3.985 s, sync=0.133 s, total=4.349 s; sync files=1386, longest=0.008 s, average=0.001 s; distance=1502862 kB, estimate=1502862 kB; lsn=525/4E72B480, redo lsn=525/2DAA1658
2024-11-12 15:01:26.880 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: recovery restart point at 525/2DAA1658
2024-11-12 15:01:26.880 -03,"",1748352,2024-11-12 14:51:35 -03,,,,DETAIL: Last completed transaction was at log time 2024-11-12 14:05:39.870876-03.
2024-11-12 15:01:26.884 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: restartpoint starting: wal
2024-11-12 15:01:27.890 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: consistent recovery state reached at 525/B4FFF5A8
2024-11-12 15:01:27.890 -03,"",1748350,2024-11-12 14:51:34 -03,,,,LOG: database system is ready to accept read-only connections
Após essa etapa ele começará a restaurar os arquivos da pasta "replicacao"
2024-11-12 15:01:28.365 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000B5" from archive
2024-11-12 15:01:28.826 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000B6" from archive
2024-11-12 15:01:29.227 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000B7" from archive
2024-11-12 15:01:29.662 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000B8" from archive
2024-11-12 15:01:30.170 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000B9" from archive
2024-11-12 15:01:30.699 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000BA" from archive
2024-11-12 15:01:31.229 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000BB" from archive
2024-11-12 15:01:31.713 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000525000000BC" from archive
Neste momento é possível executar o SQL SELECT pg_backup_stop(); no MASTER via pgadmin (Na mesma sessão que foi solicitado manter aberta durante todo o processo de replicação)
via pgadmin
SELECT pg_backup_stop();
Quando nos logs começarem a aparecer que alguns arquivos não foram encontrados, todo o processo de importação de arquivos wal estará completo.
2024-11-12 15:09:44.198 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FA" from archive
2024-11-12 15:09:44.805 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FB" from archive
2024-11-12 15:09:45.419 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FC" from archive
2024-11-12 15:09:46.028 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FD" from archive
2024-11-12 15:09:46.215 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: restartpoint complete: wrote 63060 buffers (8.0%); 0 WAL file(s) added, 47 removed, 0 recycled; write=30.049 s, sync=0.040 s, total=30.192 s; sync files=1258, longest=0.003 s, average=0.001 s; distance=773534 kB, estimate=1045990 kB; lsn=528/B4B424D8, redo lsn=528/7B8F6478
2024-11-12 15:09:46.215 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: recovery restart point at 528/7B8F6478
2024-11-12 15:09:46.215 -03,"",1748352,2024-11-12 14:51:35 -03,,,,DETAIL: Last completed transaction was at log time 2024-11-12 15:09:38.6537-03.
2024-11-12 15:09:46.233 -03,"",1748352,2024-11-12 14:51:35 -03,,,,LOG: restartpoint starting: wal
2024-11-12 15:09:46.546 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FE" from archive
bzip2: Can't open input file /var/lib/postgresql/16/replicacao/0000000100000528000000FF: No such file or directory.
2024-11-12 15:09:47.072 -03,"",1748354,2024-11-12 14:51:35 -03,,,,LOG: restored log file "0000000100000528000000FE" from archive
bzip2: Can't open input file /var/lib/postgresql/16/replicacao/0000000100000528000000FF: No such file or directory.
Após a importação finalizar com sucesso, pode-se realizar o processo de limpeza
cd /var/lib/postgresql/16/tablespaces
rm -rf *.tgz
cd /var/lib/postgresql/16
rm -rf *.tgz
rm -rf replicacao_tx/
exit
exit ( Voltar para o usuário rep00000 )
exit ( Desconectar do servidor SLAVE )
### Servidor master
Após a execução dos dois exits acima, estaremos novamente no banco de dados Master, onde agora devemos retornar a configuração de Vacuum e Reindex no processo de Backup (PALIATIVO)
vim bkp_remoto/bkp_remoto.sh
descomentar linhas:
2103 e 2104
### Considerações
O alerta "Too Many WAL Files" pode existir na segunda-feira pela manhã já que no final de semana a rotina de VACUUM gera uma grande movimentação no banco
Reference in New Issue View Git Blame Copy Permalink