Re: [pgbr-geral] Dúvidas sobre replicação no PostgreSQL 9.4

[Lucas Viecelli]

>>
> Essa configuração fará com que em caso de perda de comunicação entre o
master-slave, quando a comunicação retornar os segmentos de wal necessários
para continuar a replicação estejam lá, caso contrário irá falhar o
"recovery" no servidor slave, pois o sincronismo nada mais é do que um
processo eterno de recovey no slave.
>>
>>

Isso eu entendi, mas ao aumentar esse valor.. tem alguma perca de
desempenho ou algo nesse sentido?

-- 

Atenciosamente.

Lucas Viecelli
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação no PostgreSQL 9.4

[Sebastian Webber]

Em 26 de novembro de 2015 10:37, Lucas Viecelli 
escreveu:

Oi,  boa tarde, tudo bem?


> PostgreSQL 9.4, ubuntu-server 15.10
>
> Estou estudando replicação hot_standby do PostgreSQL, configurei um
> mestre-slave. Tudo funcionou normalmente, mas ainda tenho algumas dúvidas,
> espero que alguém possa me ajudar.
>
> wal_keep_segments - Fiz alguns testes com volume de dados e simulando
> situação que o "slave parou", e resolvi deixar o valor  do
> wal_keep_segments meio alto para evitar uma perca de sincronismo.. qual o
> impacto disso? tem pessoas que dizem que só usa mais espaço em disco e etc,
> não tem impacto significativo no desempenho?
>

Na pratica esse parametro[1] quer dizer quantos segmentos de WAL que o
postgresql irá manter. Isso previne que o slave fique sem os WALs
necessários para sincronizar. Quanto mais arquivos, mais espaço em disco
será ocupado. Note que se o banco não puder gerar arquivos na pasta do
pg_xlog ele vai parar.

Recomendo que tu dê uma olhadinha nos replications slots[4]


>
> archive_command - Algumas pessoas dizem que não é recomendável colocar um
> servidor em produção sem a devida configuração do archive_command e
> restore_command, alguém tem alguma história que me conversa que é
> necessário?
>

archive_command é o quando a ser utilizando quando tu setar o wal_level
para archive e a cada criação de novo arquivo wal na pasta pg_xlog, o banco
efetua o arquivamento do wal anterior. Se tua fila (wal_keep_segments) for
grande o bastante, não é necessário utilizar ele, mas quanto os servidores
rodam em vários datacenters (multi-region) é comum de combinar as duas
soluções: usar o SR pra replicação, e quando a fila não tiver os wal
necessários, tentar importar os wal necessários. Isso pode ser configurado
no recovery.conf sem nenhum programa de terceiros.

Detalhes sobre standby que utilizam arquivamento estão na doc[3].



>
> pg_start_backup - Se o meu servidor Slave perder o sincronismo eu devo
> executar um "select pg_start_backup('foo');" para o servidor
> do PostgreSQL se preparar para replicar os dados pro slave, e após isso um
> "stop", com isso eu posso replicar o BD e deixar ele online, isso está
> correto?  pelo que estudei até agora, essa é a melhor forma de fazer o
> slave recuperar os dados perdidos.
>

Se tem slave não tenha os WALs necessários para importar do master e também
não tenha os wals arquivados, tu vai ter que fazer a copia dos dados
novamente seja através do pg_basebackup ou do processo manual
(pg_start_backup ; copia ; pg_stop_backup). Não tem jeito. mesmo.


>
> hot_standby - Este tipo de replicação o PostgreSQL irá utilizar os dois
> servidores para consultas?
>

hot_standby[2] é um nome que damos ao servidor standby que permite abrir o
banco em readonly. Seria possivel utiliza-lo para consultas, porém tens que
utilizar alguma solução de balanceamento para dividir a carga entre os
servidores. Balancear  os servidores gera alguns desafios quanto a
sincronização dos dados .


Escrevi muita coisa na corrida. Espero ter ajudado. =)

[1]
http://www.postgresql.org/docs/current/static/runtime-config-replication.html
[2] http://www.postgresql.org/docs/9.4/static/hot-standby.html
[3] http://www.postgresql.org/docs/9.4/static/warm-standby.html
[4]
http://www.postgresql.org/docs/9.4/static/warm-standby.html#STREAMING-REPLICATION-SLOTS

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação no PostgreSQL 9.4

[Lucas Viecelli]

>
>
> Oi,  boa tarde, tudo bem?
>

Opa, tudo ótimo e ai?


> wal_keep_segments - Fiz alguns testes com volume de dados e simulando
>> situação que o "slave parou", e resolvi deixar o valor  do
>> wal_keep_segments meio alto para evitar uma perca de sincronismo.. qual o
>> impacto disso? tem pessoas que dizem que só usa mais espaço em disco e etc,
>> não tem impacto significativo no desempenho?
>>
>
> Na pratica esse parametro[1] quer dizer quantos segmentos de WAL que o
> postgresql irá manter. Isso previne que o slave fique sem os WALs
> necessários para sincronizar. Quanto mais arquivos, mais espaço em disco
> será ocupado. Note que se o banco não puder gerar arquivos na pasta do
> pg_xlog ele vai parar.
>
> Recomendo que tu dê uma olhadinha nos replications slots[4]
>


 Pelo que eu li na documentação que tu me passou e no blog do Michel [1],
era exatamente isso que eu precisava. Com slots, ele faz o controle de
armazenar os WALs que não foram replicados, sem a necessidade de configurar
archive_command e etc, claro que existem situações que isso é necessário,
mas para o meu que é um simples Master-Slave.. acredito que os slots já
resolvem.


[1] -
http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-replication-slots/


>> archive_command - Algumas pessoas dizem que não é recomendável colocar um
>> servidor em produção sem a devida configuração do archive_command e
>> restore_command, alguém tem alguma história que me conversa que é
>> necessário?
>>
>
> archive_command é o quando a ser utilizando quando tu setar o wal_level
> para archive e a cada criação de novo arquivo wal na pasta pg_xlog, o
> banco efetua o arquivamento do wal anterior. Se tua fila
> (wal_keep_segments) for grande o bastante, não é necessário utilizar ele,
> mas quanto os servidores rodam em vários datacenters (multi-region) é comum
> de combinar as duas soluções: usar o SR pra replicação, e quando a fila não
> tiver os wal necessários, tentar importar os wal necessários. Isso pode ser
> configurado no recovery.conf sem nenhum programa de terceiros.
>
> Detalhes sobre standby que utilizam arquivamento estão na doc[3].
>

Acredito que com os slots não preciso usar archive_command e
restore_command.


hot_standby - Este tipo de replicação o PostgreSQL irá utilizar os dois
>> servidores para consultas?
>>
>
> hot_standby[2] é um nome que damos ao servidor standby que permite abrir o
> banco em readonly. Seria possivel utiliza-lo para consultas, porém tens que
> utilizar alguma solução de balanceamento para dividir a carga entre os
> servidores. Balancear  os servidores gera alguns desafios quanto a
> sincronização dos dados .
>
>
Vou dedicar um tempo para estudar mais a fundo o pgpool, mas de início
balancear os servidores não é o foco.



> Escrevi muita coisa na corrida. Espero ter ajudado. =)
>

Obrigado pelas dicas, meu ajudou a bastante em trocar umas idéias e ler
mais a fundo a questão dos slots.


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação no PostgreSQL 9.4

[Euler Taveira]

On 26-11-2015 10:33, Lucas Viecelli wrote:
>>>
>> Essa configuração fará com que em caso de perda de comunicação entre o
> master-slave, quando a comunicação retornar os segmentos de wal
> necessários para continuar a replicação estejam lá, caso contrário irá
> falhar o "recovery" no servidor slave, pois o sincronismo nada mais é do
> que um processo eterno de recovey no slave.
>>>
>>>
> 
> Isso eu entendi, mas ao aumentar esse valor.. tem alguma perca de
> desempenho ou algo nesse sentido?
> 
Aumento de espaço em disco. Isso se a comunicação for interrompida entre
os servidores, ele vaiarmazenar a quantidade atual (depende dos
parâmetros de checkpoint) mais wal_keep_segmentos arquivos.

Uma maneira mais fácil de garantir que não vai precisar refazer o
servidor secundário é utilizar replication slots (disponível a partir da
9.4). Em versões anteriores, prefira a combinação archive_command e
pg_archivecleanup em relação a wal_keep_segments (principalmente se o
seu agrupamento de dados tiver um tamanho considerável -- refazer a
replicação vai lhe custar várias horas de trabalho).


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação no PostgreSQL 9.4

[Lucas Viecelli]

>
>
> > Isso eu entendi, mas ao aumentar esse valor.. tem alguma perca de
> > desempenho ou algo nesse sentido?
> >
> Aumento de espaço em disco. Isso se a comunicação for interrompida entre
> os servidores, ele vaiarmazenar a quantidade atual (depende dos
> parâmetros de checkpoint) mais wal_keep_segmentos arquivos.
>

Interessante, queria tirar a dúvida de que isso não ia prejudicar de alguma
forma a performance.


> Uma maneira mais fácil de garantir que não vai precisar refazer o
> servidor secundário é utilizar replication slots (disponível a partir da
> 9.4). Em versões anteriores, prefira a combinação archive_command e
> pg_archivecleanup em relação a wal_keep_segments (principalmente se o
> seu agrupamento de dados tiver um tamanho considerável -- refazer a
> replicação vai lhe custar várias horas de trabalho).


Vou utilizar a versão 9.4, estão vou usar replication slots, com isso vai
ficar show.

-- 

Atenciosamente.

*Lucas Viecelli*


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Leandro Guimarães Faria Corce DUTRA]

Le 2011-O-20  20h59, Leonardo Carneiro a écrit :
 2011/10/20 Euler Taveira de Oliveira eu...@timbira.com
 mailto:eu...@timbira.com

 Então ele vai precisar de _outra_ máquina. Replicação *não* funciona em
 arquitetura diferentes.

Nem pensei que pudessem ser máquinas de arquiteturas diferentes.  Achei, 
sem pensar muito a respeito, que fossem simplesmente instalações 
diferentes.  Afinal, hoje em dia quase tudo é AMD64 (vulgo x86_64, 
depois que a Intel copiou…).


 Esse setup (master x86 e slave x86_64) é apenas um cenário que eu montei
 com o que tinha em mãos para pode validar os testes. No cenário em
 produção as máquinas tem a mesma arquitetura. Mesmo compilando o slave
 em 32 (para não ter o trabalho de formatar uma máquina de
 desenvolvimento) não vai funcionar, como sugeriu o Leandro?

Se sugeri, sugeri errado… só sugeri usar os pacotes porque não vejo 
vantagens, no caso geral, em compilar; e sugeri instalar 64 bits porque 
creio que é mais vantajoso que compilar na mão.  Mas, se uma das 
máquinas fôr 32 bits, de fato as únicas opções são reinstalar a 64 em 32 
bits, ou compilar o PostgreSQL em 32 bits no sistema 64.


 Essa
 necessidade da mesma arquitetura do cluster é em relação a arquitetura
 do pg ou a arquitetura da máquina, ou ainda de ambas? =)

Do PostgreSQL.  A máquina só determina em que arquitetura o PostgreSQL 
pode ser compilado e rodar.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Dúvidas sobre replicação

[Leonardo Carneiro]

Boa tarde pessoal,

Estou (tentando) realizar testes com replicação, e surgiram algumas dúvidas.
Segue uma descrição do cenário.

Master:
SO: Ubuntu Desktop 11.10 x86
PostgreSQL: 9.1.1, compilado direto do fonte

Slave
SO: Ubuntu Server 11.10 x86_64
PostgreSQL: 9.1.1, compilado direto do fonte

Minha (tentativa de) replicação está sendo feita via WAN, usando apenas log
shipping no momento (não estou usando streaming replication). Já é possível
ver pelo cenário que eu cometi um erro ao escolher as arquiteturas. Enquanto
ainda estou trabalhando nisso, tenho algumas dúvidas quanto ao envio dos
logs, e também sobre o streaming, caso venho a usar. Minha base em produção
tem uma carga de escrita razoavel, escrevendo cerca de 140 arquivos de log
por hora. Fazendo a matemática básica, eu teria de ter um link de pelo menos
6,5Mbps para manter a o slave atual em relação ao master. Meu objetivo é
reduzir esse número.

Dúvida 1: Envio do log
A documentação do Postgres fornece um exemplo (http://goo.gl/gyjnA) usando
os comandos 'test' e 'cp' para o envio dos logs. Como estou fazendo através
da WAN, estou usando 'scp' com troca de chaves, ao invés de 'cp'. Existe
algum problema em usar um comando compactando o arquivo, para diminuir o
volume de dados no link? Algo como:

tar cjf - %p | ssh remotehost  ( cd /destination/path ; tar xjf - ) 


Dúvida 2: Envio do banco para sincronização inicial
Como não estou configurando streaming replication no momento, não estou
usando o pg_basebackup para enviar o banco. Estou usando o comando SELECT
pg_start_backup('sync_inicial'); Realizo uma cópia com 'cp -a' e uso o
comando SELECT pg_stop_backup(); para voltar a operação normal. Como nesse
momento, os logs já estão sendo enviados, não vou perder nada de dados,
mesmo que demore um pouco para enviar o banco após enviar o comando 'stop'.
Existe problema em enviar os dados de maneira compactada, como na dúvida
anterior?

Dúvida 3: Envio via streaming
O streaming, tanto para o envio do basebackup quanto para envio dos logs,
usa algum tipo de compactação? Se sim, isso é configurável de alguma
maneira? Eu não tenho a necessidade de manter meu slave 100% sincronizado em
tempo real em relação ao master, então a janela de tempo que o log shipping
tem em relação ao streaming replication não seria um ponto tão negativo,
caso não seja possível compactar o tráfego do streaming. Em testes, os
arquivos de logs compactados usando bz2 consomem cerca de 20% do tamanho
total descompactado.

Abs!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Flavio Henrique Araque Gurgel]

 Master:
 SO: Ubuntu Desktop 11.10 x86
 PostgreSQL: 9.1.1, compilado direto do fonte
 Slave
 SO: Ubuntu Server 11.10 x86_64
 PostgreSQL: 9.1.1, compilado direto do fonte
 Minha (tentativa de) replicação está sendo feita via WAN, usando apenas log
 shipping no momento (não estou usando streaming replication). Já é possível
 ver pelo cenário que eu cometi um erro ao escolher as arquiteturas. Enquanto

É, cometeu.
Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar
nenhum dos S.Os.

 ainda estou trabalhando nisso, tenho algumas dúvidas quanto ao envio dos
 logs, e também sobre o streaming, caso venho a usar. Minha base em produção
 tem uma carga de escrita razoavel, escrevendo cerca de 140 arquivos de log
 por hora. Fazendo a matemática básica, eu teria de ter um link de pelo menos
 6,5Mbps para manter a o slave atual em relação ao master. Meu objetivo é
 reduzir esse número.

Seu banco escreve em torno de 5 arquivos WAL / 5 min de checkpoint.

 Dúvida 1: Envio do log
 A documentação do Postgres fornece um exemplo (http://goo.gl/gyjnA) usando
 os comandos 'test' e 'cp' para o envio dos logs. Como estou fazendo através
 da WAN, estou usando 'scp' com troca de chaves, ao invés de 'cp'. Existe
 algum problema em usar um comando compactando o arquivo, para diminuir o
 volume de dados no link? Algo como:

 tar cjf - %p | ssh remotehost  ( cd /destination/path ; tar xjf - ) 

Você pode colocar num script também. Não há problema lógico algum, só
que você terá que fazer o inverso no Slave pra descompactar.
Note que a compactação por gzip consome um bocado de CPU e pode
interferir com sua operação normal de SGBD.
Você pode também fazer um túnel ssh com compactação. O resultado será
similar e a complexidade reduzida.
Você também pode trocar o scp por rsync com a opção -z. É o mesmíssimo
resultado e é o que eu costumo usar em produção.


 Dúvida 2: Envio do banco para sincronização inicial
 Como não estou configurando streaming replication no momento, não estou

Por que não quer usar streaming replication? É tão mais simples...

 usando o pg_basebackup para enviar o banco. Estou usando o comando SELECT
 pg_start_backup('sync_inicial'); Realizo uma cópia com 'cp -a' e uso o
 comando SELECT pg_stop_backup(); para voltar a operação normal. Como nesse

Você terá de usar scp ou rsync né? O servidor slave é remoto. Ou você
fará isso num passo a parte?

 momento, os logs já estão sendo enviados, não vou perder nada de dados,
 mesmo que demore um pouco para enviar o banco após enviar o comando 'stop'.
 Existe problema em enviar os dados de maneira compactada, como na dúvida
 anterior?

Não há problema lógico algum. Atente para o consumo de CPU da
compactação. Já vi gente sentar servidor de produção por esse
descuido. Ou use uma máquina intermediária que faça esse trabalho.

 Dúvida 3: Envio via streaming
 O streaming, tanto para o envio do basebackup quanto para envio dos logs,
 usa algum tipo de compactação? Se sim, isso é configurável de alguma
 maneira? Eu não tenho a necessidade de manter meu slave 100% sincronizado em
 tempo real em relação ao master, então a janela de tempo que o log shipping
 tem em relação ao streaming replication não seria um ponto tão negativo,
 caso não seja possível compactar o tráfego do streaming. Em testes, os
 arquivos de logs compactados usando bz2 consomem cerca de 20% do tamanho
 total descompactado.

Nativamente não há compactação. Use um túnel ssh com opção -X para ele
compactar os dados on-the-fly, ou alguma estratégia de VPN com
compactação.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Leandro Guimarães Faria Corce DUTRA]

Le 2011-O-20  19h51, Flavio Henrique Araque Gurgel a écrit :
 Master:
 SO: Ubuntu Desktop 11.10 x86
 PostgreSQL: 9.1.1, compilado direto do fonte
 Slave
 SO: Ubuntu Server 11.10 x86_64
 PostgreSQL: 9.1.1, compilado direto do fonte

 Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar
 nenhum dos S.Os.

Acho que não vale a pena… que me lembre, os ganhos de ter o sistema em 
64 bits são maiores que os de compilar.  Melhor reinstalar mesmo, e usar 
pacotes.

Ou já não é bem assim?




-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Euler Taveira de Oliveira]

On 20-10-2011 19:06, Leandro Guimarães Faria Corce DUTRA wrote:
 Le 2011-O-20  19h51, Flavio Henrique Araque Gurgel a écrit :
 Master:
 SO: Ubuntu Desktop 11.10 x86
 PostgreSQL: 9.1.1, compilado direto do fonte
 Slave
 SO: Ubuntu Server 11.10 x86_64
 PostgreSQL: 9.1.1, compilado direto do fonte

 Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar
 nenhum dos S.Os.

 Acho que não vale a pena… que me lembre, os ganhos de ter o sistema em
 64 bits são maiores que os de compilar.  Melhor reinstalar mesmo, e usar
 pacotes.

Então ele vai precisar de _outra_ máquina. Replicação *não* funciona em 
arquitetura diferentes.


-- 
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Leonardo Carneiro]

2011/10/20 Euler Taveira de Oliveira eu...@timbira.com

 On 20-10-2011 19:06, Leandro Guimarães Faria Corce DUTRA wrote:
  Le 2011-O-20  19h51, Flavio Henrique Araque Gurgel a écrit :
  Master:
  SO: Ubuntu Desktop 11.10 x86
  PostgreSQL: 9.1.1, compilado direto do fonte
  Slave
  SO: Ubuntu Server 11.10 x86_64
  PostgreSQL: 9.1.1, compilado direto do fonte
 
  Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar
  nenhum dos S.Os.
 
  Acho que não vale a pena… que me lembre, os ganhos de ter o sistema em
  64 bits são maiores que os de compilar.  Melhor reinstalar mesmo, e usar
  pacotes.
 
 Então ele vai precisar de _outra_ máquina. Replicação *não* funciona em
 arquitetura diferentes.



Oi Euler,

Esse setup (master x86 e slave x86_64) é apenas um cenário que eu montei com
o que tinha em mãos para pode validar os testes. No cenário em produção as
máquinas tem a mesma arquitetura. Mesmo compilando o slave em 32 (para não
ter o trabalho de formatar uma máquina de desenvolvimento) não vai
funcionar, como sugeriu o Leandro? Essa necessidade da mesma arquitetura do
cluster é em relação a arquitetura do pg ou a arquitetura da máquina, ou
ainda de ambas? =)

Agradeço pelas dicas, e também ao Leandro e ao Flávio, a quem esqueci de
agradecer no outro email =D


 --
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Euler Taveira de Oliveira]

On 20-10-2011 19:59, Leonardo Carneiro wrote:
 Esse setup (master x86 e slave x86_64) é apenas um cenário que eu montei com o
 que tinha em mãos para pode validar os testes. No cenário em produção as
 máquinas tem a mesma arquitetura. Mesmo compilando o slave em 32 (para não ter
 o trabalho de formatar uma máquina de desenvolvimento) não vai funcionar, como
 sugeriu o Leandro? Essa necessidade da mesma arquitetura do cluster é em
 relação a arquitetura do pg ou a arquitetura da máquina, ou ainda de ambas? =)

Leia [1].


[1] 
http://www.postgresql.org/docs/current/static/warm-standby.html#STANDBY-PLANNING


-- 
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Danilo Silva]

Pessoal só uma dúvida, a replicação não roda em arquiteturas diferentes, mas
isso é referente somente ao sistema operacional ou vale também pela
arquitetura de diretórios? A replicação roda se no master o $PGDATA estiver
em /dados/postgresql/ e no slave em /usr/pgsql?

Obrigado.

Em 20 de outubro de 2011 22:05, Euler Taveira de Oliveira eu...@timbira.com
 escreveu:

 On 20-10-2011 19:59, Leonardo Carneiro wrote:
  Esse setup (master x86 e slave x86_64) é apenas um cenário que eu montei
 com o
  que tinha em mãos para pode validar os testes. No cenário em produção as
  máquinas tem a mesma arquitetura. Mesmo compilando o slave em 32 (para
 não ter
  o trabalho de formatar uma máquina de desenvolvimento) não vai funcionar,
 como
  sugeriu o Leandro? Essa necessidade da mesma arquitetura do cluster é em
  relação a arquitetura do pg ou a arquitetura da máquina, ou ainda de
 ambas? =)
 
 Leia [1].


 [1]

 http://www.postgresql.org/docs/current/static/warm-standby.html#STANDBY-PLANNING


 --
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Euler Taveira de Oliveira]

On 20-10-2011 21:24, Danilo Silva wrote:
 Pessoal só uma dúvida, a replicação não roda em arquiteturas diferentes, mas
 isso é referente somente ao sistema operacional ou vale também pela
 arquitetura de diretórios? A replicação roda se no master o $PGDATA estiver em
 /dados/postgresql/ e no slave em /usr/pgsql?

Você leu o link enviado? O $PGDATA das duas máquinas pode ser diferente. No 
entanto, se você estiver utilizando tablespaces, o caminho das mesmas deve ser 
idêntico em ambas as máquinas.


-- 
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Danilo Silva]

Opa Euler, li sim mas só depois, e uma coisa não ficou clara, em ambientes
linux a replicação roda com distribuições diferentes? de ubuntu para ubuntu
server, ou de centos para redhat?

Valeu

Em 20 de outubro de 2011 22:35, Euler Taveira de Oliveira eu...@timbira.com
 escreveu:

 On 20-10-2011 21:24, Danilo Silva wrote:
  Pessoal só uma dúvida, a replicação não roda em arquiteturas diferentes,
 mas
  isso é referente somente ao sistema operacional ou vale também pela
  arquitetura de diretórios? A replicação roda se no master o $PGDATA
 estiver em
  /dados/postgresql/ e no slave em /usr/pgsql?
 
 Você leu o link enviado? O $PGDATA das duas máquinas pode ser diferente. No
 entanto, se você estiver utilizando tablespaces, o caminho das mesmas deve
 ser
 idêntico em ambas as máquinas.


 --
Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Leandro Guimarães Faria Corce DUTRA]

Le 2011-O-21  00h1, Danilo Silva a écrit :
 Opa Euler, li sim mas só depois, e uma coisa não ficou clara, em
 ambientes linux a replicação roda com distribuições diferentes? de
 ubuntu para ubuntu server, ou de centos para redhat?

As distribuições são irrelevantes para a replicação.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvidas sobre replicação

[Danilo Silva]

Valeu


Em 21 de outubro de 2011 00:10, Leandro Guimarães Faria Corce DUTRA 
lean...@dutras.org escreveu:

 Le 2011-O-21  00h1, Danilo Silva a écrit :

  Opa Euler, li sim mas só depois, e uma coisa não ficou clara, em
 ambientes linux a replicação roda com distribuições diferentes? de
 ubuntu para ubuntu server, ou de centos para redhat?


 As distribuições são irrelevantes para a replicação.




 --
 skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
 +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
 +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
 BRAZIL GMT-3  MSN: 
 msnim:chat?contact=leandro@**dutra.fastmail.fmlean...@dutra.fastmail.fm

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral