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. |
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"