Cadastre seu e-mail para receber as novidades desse blog. Você pode cancelar a qualquer momento.

Delivered by FeedBurner

Assista ao vídeo descritivo acima; depois clique na imagem abaixo para adquirir o seu GUIA PRÁTICO PARA PASSAR EM CONCURSO PÚBLICO EM UM ANO.

Google Website Translator

Postagem em destaque

Automação Residencial com arduíno

Já pensou em criar sua própria casa inteligente, com automações em todos os cômodos? Sem gastar muito? Sem ser um engenheiro ou algo parecid...

Pesquise nesse Blog e na WEB com o Google

terça-feira, 27 de outubro de 2015

Replicação de Dados com PostgreSQL

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".
Passo 2: parar o servidor master:

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".
Passo 4: editar o arquivo pg_hba.conf, localizado normalmente na pasta \data do SGBD.

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.
Passo 5: ativar o servidor master.

Clique com o botão direito em "PostgreSQL 9.3 (localhost: 5432)" e em seguida em "Start Service"
A configuração do servidor master está concluída.





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"