Replicação de Banco de Dados

FACULDADE DE TECNOLOGIA SENAC GOIÁS Gestão da Tecnologia da Informação Replicação de Banco de Dados Elias Ferreira GOIÂNIA, 2017

Definição de replicação de banco de dados: A replicação de banco de dados consiste em um processo de transmitir um conjunto de dados, objetos ou o próprio banco para outras máquinas (hosts ou servidores), e automatizar esse processo para que os dados entrem em sincronia, ou seja, quando um dado for alterado em uma das máquinas a(s) outra(s) capture(m) essa alteração mantendo a mesma estrutura tornando a informação correta em todas. Esse tipo de processo fornece uma maior consistência e disponibilidade do banco de dados. A replicação de um banco de dados pode ocorrer de duas formas: 1) (Lógica): Pode ocorrer na máquina local, onde o administrador pode replicar os dados no seu próprio ambiente, em vários diretórios e partições distintas. 2) (Física): Pode ocorrer em várias máquinas diferentes, localizadas em diversos pontos, com um servidor master controlando as versões e a coexistência da replicação. Essa medida se torna mais segura, sendo que caso ocorra de uma das máquinas, por qualquer motivo, parar de funcionar o serviço continua disponível para as outras. Essas duas formas de replicação precisam manter os dados precisos em todas as máquinas, para isso a sincronização dos dados precisa ser confiável e rápida, pelo fato de que os dados, dependendo do ambiente, podem ser alterados com frequência. Para isso existem dois tipos de sincronização: Replicação Síncrona: É uma replicação onde qualquer alteração que for realizada em uma das máquinas que estão sincronizadas, é capturada de forma instantânea pelas outras, essa replicação só permite que o usuário continue com a ação depois que os dados forem replicados em todas máquinas. Uma das desvantagens dessa replicação, é a exigência de uma maior largura de banda, pelo fato de que dependendo do volume dos dados a sincronização pode se tornar lenta e perder estabilidade. Esse tipo de replicação é mais comum em sistemas onde os dados precisam estar sincronizados todo o tempo, Ex: Bolsa de Valores, Aeroportos, sites de compras, etc. Replicação Assíncrona: Nessa replicação o Administrador cria um arquivo, geralmente uma trigger, estabelecendo o tempo ou sob que ações a replicação deve ocorrer entre as bases. A replicação so ira ocorre quando a condição for comprida, podendo ser algumas horas ou dias. Uma das desvantagens visíveis dessa replicação é o fato de as informações ficarem um certo tempo desatualizadas. Esse tipo de replicação é mais comum em sistemas que precisam de uma confirmação para continuarem a ação, Ex: Alguns serviços de Bancos, Transportadoras, etc. A replicação é um conjunto de tecnologias utilizadas para copiar e distribuir objetos e dados de um banco de dados para um outro banco de dados, sincronizando estes dados com a finalidade de se manter a consistência. Replicação de dados entre servidores:

Suporte na melhoria na escalabilidade e disponibilidade; Armazenamento de dados e geração de relatórios; Integração de dados de diversos sites. Replicação de dados entre servidores e clientes: Suporte a troca de dados com usuários móveis; Utilizado a aplicativos de ponto de vendas para o consumidor; Integração de dados em diversos sites. Componentes de topologia de replicação: Publicador; Distribuidor; Assinantes; Publicações; Artigos; Assinaturas. Tipos de Replicação: Replicação de Instantâneo (snapshot Publication) Replicação de Transacional (Transactional Publication) Replicação de Mesclagem (Merge Publication) Uma das vantagens de se trabalhar com replicação de dados é a capacidade de realizar manutenção de várias cópias de um banco em várias base de dados (SGBD), esse tipo de processo fornece uma alta redundância do banco de dados o que torna o gerenciamento do banco de dados mais confiável, sendo que caso o servidor onde o banco está hospedado ( master ) falhe, uma cópia ( slave ) deste assume o papel registrando as informações e replicando os dados para outras máquinas, esse processo pode funcionar como um backup do banco. Outra vantagem é que pode ser proporcionado um balanceamento de carga, uma vez que todos as réplicas estão sincronizadas, o acesso ao banco pode ser distribuído. Para que a replicação de dados seja possível o PostgreSQL utiliza uma ferramenta específica, existem várias soluções para essas atualmente, dentre elas as principais são: PgCluster Essa é uma ferramenta de replicação síncrona de composição multi-master para PostgreSQL, é uma das mais utilizadas, por sua agilidade no processo de replicação, nesse tipo de composição um usuário pode configurar mais de um servidor para ser replicado em sua base de dados. O PgCluster pode trabalhar de duas formas. através do compartilhamento de acesso, onde é criado um sistema para minimizar o volume de processamento nos acessos ao servidor master, distribuindo essa carga entre as cópias na cluster, esse sistema pode ser construído em um servidor balanceador de carga, que será responsável por fazer a distribuição do acesso. Essa ferramenta também trabalha com a alta disponibilidade, sendo que quando uma das réplicas falhar ela encaminha o acesso a outra, e quando este for restabelecido, os dados são automaticamente copiados para esta.

O PgCluster trabalha com o reconhecimento das linguagens SQL, sendo que, quando um comando é inserido as cópias capturam essa instrução. PgPool Essa ferramenta é semelhante ao PgCluster, no que diz respeito a replicação síncrona e balanceamento de carga, uma de suas funções é estabelecer uma conexão entre o servidor (PostgreSQL) e as máquinas que serão replicadas e realizar cache de todas as conexões que são estabelecidas, ou seja, possui um desempenho melhor, sendo que toda máquina conectada fica registrada em cache. PgReplicator É uma ferramenta de replicação assíncrona, é responsável por receber e encaminhar as replicações, e trabalha com scripts em SQL. Daffodil Replicator Consiste em uma ferramenta que realiza replicação com suporte bidirecional, ou seja, o servidor replica os dados, e pode ser realizada uma sincronização das alterações realizadas em ambas as máquinas, servidor master e máquinas subscritoras. Essa ferramenta pode ser utilizada em sistemas de lojas e bancos, que necessitam acessar uma informação que pode estar registrada em outra máquina. Um das grandes vantagens do Daffodil Replicator é a replicação em SGBDs diferentes, ou seja, essa ferramenta torna possível a replicação entre SGBDs Oracle, SQL Server, Firebird, PostgreSQL, etc. o que fornece uma maior acessibilidade desta ferramenta em vários ambientes. O Daffodil Replicator é baseado na arquitetura cliente servidor, onde existe um servidor master que é responsável pelas tabelas necessárias para a replicação, e o cliente que pode realizar cópias e alterações das tabelas do servidor. Baseado nessa arquitetura e no conceito de trabalhar com SGBDs diferentes, a imagem seguinte mostra um servidor master (publisher database) enviando dados para os servidores cliente (subscriber databases) que utilizam SGBDs heterogêneos:

Imagem 1: Estrutura Daffodil Replicator Slony - I Essa é uma ferramenta que trabalha com replicação assíncrona, e permite a atribuição de diferentes permissões para os clientes. Uma outra vantagem dessa ferramenta é a alta-disponibilidade dos dados, funcionando da seguinte forma, caso um servidor master venha a falhar, um dos clientes assume o lugar deste com os mesmos privilégios de um servidor master. dbexperts Desenvolvido pela empresa dbexperts, essa ferramenta consiste em realizar transações distribuídas, partindo do conceito de que a replicação deve funcionar independentemente de aplicação, Sistema Operacional ou volume de dados. Essa ferramenta permite que a replicação seja realizada utilizando o protocolo TCP/IP e que funcione em qualquer rede. O dbexpert, assim como o pgreplicator, pode operar de modo assíncrono, ou seja, envia os dados em intervalos pré-determinados. Podendo ser realizada também de forma síncrona, dependendo do grau de confiança na conexão com o banco de dados. Assim como outras ferramentas o dbexpert, possui uma alta disponibilidade dos dados, sendo que, caso o servidor master falhe por algum motivo, uma máquina com a mesma estrutura do banco, slave, é replicada em tempo real, assumindo a função do servidor principal e garantindo a disponibilidade dos dados. A ferramenta também trabalha com o conceito de Cluster e distribuição de Carga, mencionados acima. Outro processo permitido pelo dbexpert é a centralização dos dados, onde todos os dados remotos podem ser conciliados em um servidor central, e são disponibilizados para todos os usuários, de acordo com as configurações pré definidas, garantindo uma alta disponibilidade dos dados. TIPOS DE REPLICAÇÃO: - REPLICAÇÃO DE INSTANTÂNEO (snapshot Publication) A replicação de Instantâneo realiza o envio dos dados de forma imediata para uma pasta definida pelo administrador, com mesmo formato ao longo do processo em que são alterados ou criados, essa pasta é conhecida como arquivo de instantâneo, esse processo da criação dos instantâneos é responsável por capturar os dados necessários para a replicação. Essa replicação não monitora as atualizações nos dados, assim que uma sincronização acontece todos os dados são enviados para as máquinas programadas. O uso da replicação de instantâneo é mais recomendável em sistemas onde as alterações ocorrem raramente, e a replicação de pequenos volumes de dados e um grande volume de alterações ocorre por um curto período de tempo, ou seja, esse tipo de replicação é mais útil em sistemas onde as alterações de dados possuem uma certa importância, porém são pouco frequentes. Por exemplo, na alteração de preços de um rede de supermercado, tabela de funcionário de uma empresa, etc. Essas alterações, podem ser realizadas em um período específico com o uso de uma replicação instantâneo.

Como funciona: A replicação de Instantâneo assim como a transacional utilizam um Distribution Agent, para replicar os arquivos nas máquinas clientes. Os Instantâneos, arquivos que foram montados para serem replicados, podem ser executados logo após a programação ser definida. O Snapshot Agent é responsável por preparar as tabelas, os arquivos que estão no instantâneo e os objetos do banco, armazená-los no publicador e registrar o rastreamento de informações do banco no distribuidor. Pode ser especificado um diretório padrão para os arquivos de Instantâneo. Abaixo segue uma imagem do funcionamento da replicação de Instantâneo.

Figura 2: Estrutura da Replicação de Instantâneo O Snapshot Agent executa os seguintes passos: 1) É estabelecida uma conexão entre o publicador e o distribuidor, em sequência leva os bloqueios em tarefas publicadas; 2) Salva uma cópia do esquema de cada tabela em cada artigo em um arquivo, caso outros objetos do banco sejam publicados, um novo arquivo de script é gerado; 3) É realizado uma cópia dos dados no publicador e os dados são gravados na pasta de Instantâneo, o instantâneo é gerado como uma cópia do conjunto de arquivos; 4) Para o instantâneo e as publicações transacionais, são acrescentadas informações a respeito das máquinas replicadoras, scripts de replicações instantâneo, entre outras informações a respeito da replicação e do assinante, nas tabelas do banco de dados de distribuição; 5) Libera qualquer bloqueio existente em tabelas publicadas. o Distribution Agent tem a função de distribuir um novo instantâneo, gerado pelo Snapshot, para cada host que ainda não está sincronizado para a replicação, esse processo ocorre da seguinte forma: 1) O Distribution Agent estabelece uma conexão com o Distribuidor; 2) Examina as tabelas do banco de dados de distribuição, analisando os dados de sincronização do assinante com o local dos arquivos de instantâneo; 3) Aplica o esquema e os comandos do banco de dados, realizando a replicação. - REPLICAÇÃO TRANSACIONAL (Transactional Publication) A replicação transacional é realizada através de um instantâneo e do banco de dados de publicação. Quando os arquivos de instantâneo são recolhidos, as alterações nos dados e as modificações nos esquemas são efetuadas pelo publicador, e replicadas para os assinantes no mesmo instante em que ocorrem, acontecendo a replicação síncrona, essas replicações são distribuídas de acordo com a ordem em que as alterações ocorrem, o que atribui uma maior segurança a esse processo. Esse tipo de replicação é mais comum em ambientes servidor para servidor. O seu uso pode trazer mais vantagens em ambientes onde as alterações realizadas devem ser replicadas para os assinantes de forma instantânea, e o software que utiliza o banco de dados requer uma resposta a cada alteração ocorrida, onde o publicador possui uma grande quantidade de movimento no banco: inserções, atualizações e exclusões e existem SGBDs heterogêneos na rede. Como já mencionado a Replicação Transacional permite que os assinantes apenas visualizem e atualizem os dados, pelo fato de trabalhar com arquitetura servidor para servidor, as alterações inserção e exclusão executadas pelo slave não são propagadas de volta para o publicador. Como funciona:

O Snapshot na replicação transacional prepara os arquivos de instantâneo, contendo todas as informações e objetos referentes ao banco de dados, armazena esses arquivos na pasta de instantâneo, mencionada acima, e registra as funções e ações de sincronização no banco de dados de distribuição, O Log Reader Agent, mostrado na imagem abaixo, realiza a monitoração do log das ações de cada host configurado para a replicação transacional, e faz a transferência dos arquivos marcados para a replicação do log de transações no banco de dados de distribuição, essa transferência é realizada em uma fila confiável, armazenando e avançando. O Distribution Agent, assim como na replicação de instantâneo, realiza a transferência dos arquivos de instantâneo para a pasta inicial, e em sequência as transações presentes nas tabelas do banco de distribuição para os hosts replicadores na rede, ou seja, ele faz todas as transferências das alterações realizadas no publicador para os assinantes são programadas pelo Distribution Agent de forma contínua. Como as alterações nos dados são realizadas somente pelo publicador os conflitos de dados não costumam ocorrer, assim todos os assinantes obtém os mesmos valores do publicador, Porém caso as atualizações sejam usadas com a replicação transacional, as alterações podem ser realizadas pelo assinante o que pode gerar conflitos. A imagem abaixo demonstra como funciona o processo de replicação transacional:

Figura 3: Estrutura de Replicação Transacional Abaixo segue alguns conceitos sobre os principais componentes utilizados nos Tipos de replicação: Conjunto de dados inicial: Antes que o processo de replicação das alterações no dados possa ocorrer, o assinante deve ter as tabelas com a mesma estrutura do publicador, para que a transferência dos dados possam ocorrer sem erros ou conflitos, o conjunto de dados inicial, conforme mencionado acima, consiste em um instantâneo criado pelo Snapshot Agent, e possui a distribuição gerenciada pelo Distribution Agent. esse conjunto de dados também pode ser fornecido por backup.

No momento da replicação, os instantâneos só serão distribuídos para os hosts que estiverem programados, aqueles que estiverem na rede, mas não estiverem na programação, não receberam as replicações. Processamento Simultâneo de Instantâneos Existem alguns bloqueios compartilhados nas tabelas publicadas gerados pela replicação de instantâneo, esses bloqueios podem impedir que algumas alterações sejam realizadas pelos assinantes. O processamento Simultâneo de instantâneo, é capaz de liberar essas barreiras, retirando-os durante a geração do instantâneo, o que permite que os assinantes possam trabalhar com o banco de dados sem interrupções. Snapshot Agent O Snapshot Agent, é responsável por fazer com que o Agente de Instantâneo implemente o instantâneo inicial na replicação, alocando as informações a respeito do assinante, e posteriormente enviando as replicações atualizadas. Modificação de dados e o Log Reader Agent O Agente leitor de log é executado pelo distribuidor de forma contínua, de acordo com a programação pré-estabelecida pelo administrador, a execução do Log Reader Agent acontece da seguinte forma: 1) O Log Reader Agent lê o log de transação de publicação, o mesmo utilizado para o monitoramento das ações no banco de dados; 2) Identifica as instruções de INSERT, UPDATE e DELETE, entre outras ações realizadas no banco de dados que foi configurado para a replicação; 3) Sequentemente o agente copia as transações para o banco o Distribuidor, é utilizado um procedimento de armazenamento interno para obter, em sequência, os conjuntos de comandos marcados para a replicações. Somente as transações marcadas são enviadas ao banco de dados de distribuição; 4) Quando a fila das transações termina e as aprovadas são gravadas no banco de dados de distribuição, a replicação é confirmada; 5) Após a confirmação das partições de transações para o distribuidor, o Log Reader marca onde a replicação foi concluída. Finalizando o agente define as linhas (dados), que serão executadas. Todas as informações sobre a replicação são armazenadas no banco de dados do replicador, até que o processo seja efetuado em todos os hosts programados, ou até o tempo pré-determinado, Os assinantes recebem os dados na sequência que foi definida pelo publicador. Agente de Distribuição O Distribution Agent é responsável por encaminhar as transações do Distribuidor para os Assinantes, caso algum host tenha uma assinatura marcada para validação, o Agente de distribuição verifica se os dados que serão transferidos para o assinante são os mesmos marcados pelo Publicador.

- REPLICAÇÃO DE MESCLAGEM (Merge Publication) A replicação de mesclagem, assim como na tradicional, é realiza através de um instantâneo dos objetos e dos dados do banco de dados de publicação, As atualizações e modificações realizadas no publicador e nos assinantes são monitoradas através de triggers. Os hosts replicadores (assinantes), estabelecem uma sincronia com o publicador quando estão conectados na rede e buscam todas os dados que foram alterados desde a última sincronização, ou seja, realiza replicação assíncrona. A replicação de mesclagem é mais utilizada em ambientes do tipo servidor para cliente, o seu uso é mais comum nas seguintes situações: Vários hosts replicadores realizam atualizações nos mesmos dados repetidas vezes, e copia essas para outros hosts e para o publicador; Os assinantes necessitam realizar alterações offline, receber dados e posteriormente sincronizar as alterações como o publicador e os outros hosts; Cada host replicador necessita de uma partição diferente de dados; O uso do monitoramento através de triggers, possibilita ao administrador buscar uma possível solução para a detecção de um problema; Em situações em que a replicação requer a alteração nos dados da rede no lugar do acesso, caso tenha acontecido alguma alteração na rede enquanto a sincronização estava offline, para que todos os dados sejam replicados quando uma nova sincronização acontecer. A replicação de mesclagem possibilita que vários sites de serviços trabalhem de forma própria, sem dependências, e que as atualizações posteriores de mesclagem sejam realizadas e atinjam seus resultados, devido ao fato do processo de replicação ser realizado entre várias máquinas, e os dados podem ser atualizados tanto pelo publicador quanto pelo assinante. Portanto isso pode gerar conflitos quando as atualizações forem sincronizadas, por que a replicação de mesclagem fornece vários meios de se obter um resultado. Essa replicação é implementada pelo SQL Server, Agent de Instantâneo e Agent de mesclagem. a publicação nesse tipo pode ser realizada de duas formas, filtrada e não filtrada, caso a replicação não utilize filtros o Agent instantâneo cria um único arquivo com os dados a serem replicados, se for utilizado filtros o Agente de Instantâneo criará um instantâneo para cada partição de dados. O Agente de mesclagem aplica os instantâneos iniciais e as alterações incrementais de dados, realizadas pelo publicador ou por outros hosts aos assinantes, detectando e solucionando qualquer conflito que houver entre os dados. Para que o monitoramento das alterações realizadas possa ser possível, a replicação de mesclagem identifica cada linha em cada tabela publicada, para isso a replicação adiciona uma coluna a cada tabela, contendo as informações sobre as últimas alterações e quem as realizou. caso a tabela seja descartada da publicação essa coluna é automaticamente removida, contudo se a coluna tiver sido usada em algum rastreamento, ela não será excluída. A imagem abaixo demonstra como o processo de replicação de mesclagem pode ser realizado:

Figura 4: Estrutura de Replicação de Mesclagem Vantagens e Desvantagens da Replicação de Dados Vantagens: Baixo Custo: Não requer aquisição de licenças de uso para servidores e usuários, atualizações e contratos complicados de upgrade. Custo de implantação e suporte adequados às necessidades e tamanho de sua empresa. Recuperação de Desastres: Resposta imediata em casos de parada do sistema, recuperação de arquivos e backup.

Redundância: Pode-se trabalhar com o conceito de espelhamento de servidor, além dos sistemas de backups já existentes. Distribuição de Processamento: O sistema nunca ficará sobrecarregado. Com a distribuição dos trabalhos entre servidores haverá um melhor balanceamento com melhoras de performance sem estressar o sistema. Controle e Monitoramento: Mantém um log completo das transações, o monitoramento pode ser remoto ou local. Acesso Global a Dados: Pode-se replicar as informações de várias filiais em um único servidor para se ter acesso às informações na tomada de decisões e ferramentas de BI. Desvantagens: Custo de desenvolvimento de software. Potencial maior de problemas. Redução de desempenho de processamento. Redundância de dados. Espaço adicional para armazenamento. Complexidade e custo de atualização. Na redundância de dados, quanto mais dados forem replicados, mais tempo adicional é requerido para as atualizações. No Espaço adicional para armazenamento, em relação a replicação, quanto mais dados forem replicados, maior vai ser a necessidade de espaço para o armazenamento dos dados. Já na Complexidade e custo de atualização, quanto maior a complexidade do software TUTORIAL DE CONFIGURAÇÃO DO SERVIDOR PARA REPLICAÇÃO: O tutorial a seguir demonstra as configurações necessárias que devem ser realizadas no PostgreSQL para realizar um replicação síncrona, de modo simples, sem a necessidade de uma ferramenta específica. A configuração foi realizada em máquinas Ubuntu, versão 16.06, que já tinham o tinham o SGBD PostgreSQL pré-instalado. Caso o teste seja realizado em uma máquina Linux que não possui o Postgres, o seguinte comando pode ser utilizado para fazer a instalação: Linux: Debian / Ubuntu # apt-get install postgresql Derivados Red Hat: Fedora / CentOS #yum install postgresql-server

Informações sobre a configuração: Host Server - Master: 192.168.101.65 Host Slave: 192.168.101.76 As configurações devem ser realizadas nos dois hosts: Master: Máquina onde o banco de dados a ser replicado ficará hospedado e Slave: Máquina onde o banco será replicado. A primeira configuração deve ser feita no Servidor Master onde deve ser executado os seguintes passos: Servidor Master: 1) Deve ser aberto um terminal no Linux, onde a primeira modificação deve ser realizada no arquivo de configuração do Postgres, o caminho é mostrado na imagem abaixo: 2) Após abrir o arquivo de configuração, as seguintes linhas devem ser modificadas: #listen_addresses = * Essa configuração especifica com qual hosts o Servidor Master postgresql, pode realizar conexão, nesse caso todos na rede. Caso o administrador prefira especificar os hosts que podem estabelecer conexão, deve ser especificado o ip dos hosts, separados por vírgula, conforme mostra o seguinte comando: #listen_addresses= 127.0.0.1, IP1, IP2...

#wal_level = hot_standby Por padrão essa opção vem como minimal, portanto para que a replicação possa ser executada sem erros essa opção deve ser alterada para hot_standby. #max_wal_senders = 1 Essa linha especifica a quantidade de máquinas a serem replicadas na rede; #wal_keep_segments=20 Especificação da quantidade de segmentos que podem ser gerados durante a replicação. 3) Após a modificação das linhas o arquivo deve ser salvo, e o deve ser realizada uma configuração no arquivo pg_hba.conf, conforme mostra a imagem abaixo: A linha demarcada pela seta, especifica que o usuário = replicador possui parâmetro replication, ou seja, este é um usuário capaz de realizar replicações. Detalhe, o usuário replicador ainda não foi criado.

O endereço IP: 192.168.101.76/24 especifica o host da máquina Slave que terá acesso ao banco de dados. a opção trust, define que o administrador poderá realizar a replicação sem a necessidade de um login com senha. Caso a opção marcada seja peer ou md5 o processo exigirá autenticação. 4) Após essas configurações terem sido realizadas, deve ser criado o usuário replicador com o privilégio replication, dentro do PostgreSQL, conforme mostra a imagem abaixo: 5) Com as configurações realizadas no servidor master, é preciso reiniciar o serviço. #service postgresql restart ou #/etc/init.d/postgresql restart Servidor Slave: 1) O primeiro passo a ser executado é parar o serviço, antes das configurações #service postgresql stop ou #/etc/init.d/postgresql stop 2) Após a interrupção do SGBD, a base de dados atual do PostgreSQL deve ser deletada, utilizando o seguinte comando: #rm -rf /var/lib/postgresql/9.5/main/* 3) Em seguida, com o diretório da base de dados do Postgres vazia, deve ser criado uma nova base de dados, a partir do servidor master, utilizando a ferramenta pg_basebackup, própria do PostgreSQL, conforme mostra a imagem abaixo:

As linhas demarcadas especificam o comando para a remoção da base de dados atual do postgres, e a execução do backup a partir do host do Server Master: 192.168.101.65, utilizando o usuário: replicador, criado anteriormente no Servidor Master. Após a execução do comando uma nova base de dados é gerada no postgresql, a partir do servidor master, sincronizando o host slave com o master. 4) O próximo passo é gerar o arquivo recovery.conf, responsável por fazer as adaptações necessárias para a replicação do banco, o arquivo deve estar no seguinte diretório: #/var/lib/postgresql/9.5/main/ recovery.conf, e deve possuir o conteúdo da imagem abaixo: O conteúdo da imagem acima especifica que o host slave está em modo standby on, e possui algumas informações do Server-Master, e atribui um nome ao host replicador: slave. 5) Após a criação do arquivo recovery.conf, deve-se iniciar o serviço no Host-Slave: #service postgresql start ou #/etc/init.d/postgresql start 6) Após iniciar o serviço, para fazer as testar se o serviço realmente está funcionando, tanto no slave quanto no Master, execute o comando da imagem abaixo: Server - Master

O primeiro comando demarcado pela seta: ps aux grep postgres, retorna o atual estado do serviço PostgreSQL, como demonstra a segunda demarcação, o atual estado do servidor master é streaming, ou seja, ele está pronto para ser replicado nas máquinas configuradas. A terceira demarcação mostra o comando, table pg_stat_replication, executado no terminal do postgres, que retorna algumas informações a respeito da replicação das máquinas que estão sendo replicadas, neste caso apenas uma, que possui o nome slave, criado acima no arquivo recovery.conf. Host Slave A linha demarcada mostra que o Host-Slave, mostra o número do processo que está executando, e pronto para receber as replicações, ou seja, todos o hosts Slave configurado estão prontos para replicar os bancos de dados que serão criados pelo Server-Master. Referencias: https://pelosini.com.br/visao-conceitual-de-replicacao-de-banco-de-dados http://www.devmedia.com.br/introducao-a-replicacao-e-alta-disponibilidade-no-postgresql/61 40 http://www.devmedia.com.br/replicacao-no-postgresql/11335

https://msdn.microsoft.com/pt-br/library/ms151832.aspx