O Postgre, SGBD (Sistema Gerenciador de Banco de Dados) gratuito e muito popular, aceita replicação assíncrona de dados com um servidor master (mestre) e múltiplos servidores slave (escravo). Com a replicação assíncrona os dados não são sincronizados em tempo real entre os dois servidores, através de logs de transação. É permitido apenas um servidor master, com a quantidade de slaves necessária. O servidor principal (mestre) trata todas as transações de leitura e escrita, enquanto os servidores secundários (escravos) apenas replicam os dados do principal, e podem permitir operações apenas de leitura ou nenhuma operação. Se o servidor master falhar um servidor slave pode ser promovido a master e assumir a função, fazendo com que o serviço de dados não seja interrompido. Em uma loja virtual, por exemplo, a interrupção do serviço de banco de dados resulta em prejuízo financeiro, daí a importância de um servidor secundário assumir imediatamente a função do servidor principal que falhou.
O Postgre tem uma função nativa de replicação de dados entre servidores. Como já dito, replicação assíncrona com apenas um servidor master. Esse tutorial ensina de forma prática a configuração para replicação de dados. É bastante aconselhável que os dois computadores utilizados tenham a mesma versão do Postgre e do Windows ou Linux. O exemplo a seguir foi feito em Windows.
Servidor master:
Passo 1: criar um usuário chamado "replication" com permissão para replicação e senha de acesso, neste exemplo "2020". Isso pode ser feito facilmente através do pgadmin. Veja nas imagens abaixo:
Clique nas imagens para aumentar.
 |
| Clique com o botão direito do mouse em "Login Role" e em seguida em "New Login Role". |
 |
| Em "Role name" digite o nome de usuário "replication". |
 |
| Na guia "Definition" digite a senha "2020" duas vezes e em "Connection Limit" digite "-1". |
 |
| Na guia "Role privileges" marque todas as opções, inclusive "iniciar replicação e backups". Com isso o usuário "replication" tem total acesso ao SGBD. Clique em "OK". |
 |
| Clique com o botão direito em "PostgreSQL 9.3 (localhost: 5432)" e em seguida em "Stop Service". |
Passo 3: editar o arquivo postgresql.conf, localizado normalmente na pasta \data do SGBD.
 |
| No parâmetro "wal_level" coloque a configuração "hot_standby". |
 |
| No parâmetro "wal_keep_segments" coloque o valor "20". Quanto mais transações o banco de dados tiver maior deve ser esse número. |
 |
| No parâmetro "max_wal_senders" coloque o valor "1", ou a quantidade de servidores slave do cluster. |
 |
| Configurar os parâmetros "archive_mode" e "archive_command" conforme destacado na imagem. Nesse caso a configuração de "archive_command" é para Windows. Lembre-se de criar as pastas "C:\server" e "C:\server\archivedir". |
 |
| Adicione no arquivo pg_hba.conf as instruções destacadas em vermelho na imagem. Isso serve para liberar o acesso do servidor slave (Auditoria-SMS) ao servidor master. |
 |
| Clique com o botão direito em "PostgreSQL 9.3 (localhost: 5432)" e em seguida em "Start Service" |
Servidor slave:
Obs.: É aconselhável instalar o Postgre na raiz do HD do computador slave, para depois o comando promote conseguir ler o arquivo postmaster.pid, necessário para a realização da promoção. Na pasta "arquivos de programas" muitas vezes o Windows bloqueia o acesso a arquivos. Instale por exemplo em c:\PostgreSQL.
Passo 1: parar o servidor slave da mesma maneira que paramos o master.
Passo 2: editar o arquivo postgresql.conf, localizado normalmente na pasta \data do SGBD.
 |
| No parâmetro "wal_level" coloque a configuração "hot_standby". |
 |
| No parâmetro "wal_keep_segments" coloque o valor "20". |
 |
| No parâmetro "max_wal_senders" coloque o valor "1". |
 |
| No parâmetro "hot_standby" coloque a configuração "on". |
 |
| Descomente os parâmetros "max_standby_archive_delay" e "max_standby_streaming_delay", e deixe os valores padrão de 30 segundos. |
Passo 3: criar o arquivo recovery.conf na pasta \data do SGBD com o seguinte conteúdo:
standby_mode = 'on'
primary_conninfo = 'host=SES-PC port=5432 user=replication password=2020'
trigger_file='/tmp/pgtrigger'
O parâmetro "standby_mode" em "on" ativa o modo slave no servidor. O parâmetro "primary_conninfo" contém umas string de conexão ao servidor master. "trigger_file" contém o nome de um arquivo de gatilho. Se o servidor encontrar esse arquivo se torna master automaticamente.
Passo 4: Utilizar o aplicativo pg_basebackup encontrado na pasta \bin do SGBD para fazer o backup inicial (base) do servidor principal no HD do servidor secundário. Esse backup depois vai sendo atualizado através dos logs de transação do servidor principal.
Utilize a seguinte instrução no prompt de comando do servidor slave:
pg_basebackup -D /data/ -h 192.168.2.109 -U replication
-D diz a pasta local onde será feito o backup. -h diz o endereço IP do servidor master. -U diz o nome de usuário no servidor master. No lugar do endereço IP pode ser usado o nome de HOST do servidor principal. Após executar esse comando será pedida a senha do usuário replication no servidor principal. Digite "2020". Deve aparecer uma mensagem dizendo que o pg_backup_stop foi concluído. Nesse caso é criada no HD do servidor slave a pasta C:\data que contém o backup dos dados do servidor principal. Você deve apagar o conteúdo de C:\postgresql\9.3\data, com exceção dos arquivos de configuração, ou seja pg_hba.conf, postgresql.conf etc, e copiar no lugar as pastas contidas em C:\data, sem os arquivos de configuração, ou seja pg_hba.conf, postgresql.conf etc. Na verdade podemos copiar todo o conteúdo da pasta C:\data do backup para a pasta \data do postgre, e depois substituimos os arquivos de configuração que vieram no backup do servidor master por arquivos de configuração para servidores slave.
Passo 5: Iniciar o servidor slave da mesma maneira como inciou o servidor master.
Se tudo ocorrer bem a replicação começa imediatamente.
Para promover o servidor slave a master em caso de falha do servidor principal, utilize o aplicativo pg_ctl localizado na pasta \bin do SGBD. Utilize no prompt do servidor slave o seguinte comando:
pg_ctl promote -D "c:\caminho completo entre aspas duplas\data"
Bom dia!
ResponderExcluirfiz todo o procedimento acima citado, mas na hora de iniciar o postgresql no slave ele não inicia. Nocaso do recovery.conf o primary_conninfo = 'host=SES-PC, seria o nome do servidor master?
Isso mesmo, é o nome do servidor master.
ExcluirTive o mesmo problema na hora de iniciar o serviço no slave, ele não inicia.
ResponderExcluirTalvez o firewall do master esteja bloqueando a conexão do slave. Configure o firewall.
ExcluirComo eu posso permitir que o slave crie views ?
ResponderExcluirO slave é uma cópia exata do master. As views devem ser criadas no master, aí são replicadas no slave. O servidor de backup é somente leitura.
ExcluirMuito bom eu gostei muito o modo que vc apresentou, fiz algumas adaptações e também uso com linux agora, tenho uma duvida e eu pude perceber que a pasta c:\server\arqchivedir ela não limpa sozinha, então tive que colcoar o archive_cleanup_command = 'pg_archivecleanup -d no arquivo recovery.conf para ver se ele limpa a pasta sozinho, mas existe outro processo para que esta pasta fique limpa de forma automatica ?
ExcluirVocê também pode criar uma tarefa no agendador de tarefas do Windows para limpar a pasta de arquivamento de log.
ExcluirBoa tarde robson seu guia e foi ótimo e uma excelente ferramenta, eu e tres amigos amadurecemos muito ela mas funciona de forma perfeita, gostarai de sugerir o comadno que refaz a sincronia caso fique muito tempo offline, estamos usando ela no linux e atualmente estamos desenvolvendo um bash que faz a limpeza da pasta e um gatilho em uma ferramenta que faz o promote e sobe o IP do outro que caiu de forma automatica.
ResponderExcluirtenho uma duvida, caso o master parar, eu torno o slave em master ele fica como produção? se sim, caso eu volte o master antigo, esse segundo master(slave) se torna slave novamente, ou o primeiro master busca todas as atualizações do master(slave) e depois assume dali, ou ele simplesmente volta de onde parou e o master(slave) volta a ser slave e perde tudo que foi construido depois que o master principal parou
ResponderExcluirBoa tarde, eu fiz um na empresa e o seguinte, caso o primeiro venha a falhar o segundo assuma, e e necessário executar a inversão das configurações, no caso o seu segundo fica como primário e o seu primário agora fica sendo o segundo, sendo necesario executar o comando pg_basebackup -D /data/ -h 192.168.2.109 -U replication no primário para ele pegar a base oficial que esta no secundário que agora é primário, pode parecer confuso mas e bem tranquilo.
Excluir