Eu tenho a seguinte situação: Eu tenho três máquinas executando bancos de dados postgresql. Uma máquina mantém as informações da conta do cliente (chame esta máquina C), as outras duas máquinas mantêm as informações de log do cliente (chame essas L1 e L2). O motivo da divisão é separar o carregamento em várias máquinas (para que alguns clientes enviem informações de log para L1, alguns para L2 ... e talvez algum tempo para L3, L4, ...).
Ao recuperar informações de log, em geral, eu gostaria de ser JOIN entre as tabelas de log no Ln e as tabelas da conta do cliente no C. Na realidade, não posso fazer JOINs como este (e, mesmo que pudesse, gostaria de para evitar carregar C).
Meu pensamento é replicar as tabelas em C em cada um dos L1, L2, ... para que eu possa fazer as junções. No que diz respeito às tabelas de C, C é mestre e L1, L2, ... são escravos. Mas para as outras tabelas de L1, L2, ... essas máquinas são mestres. Não é exatamente a replicação mestre-mestre e não é exatamente mestre-escravo.
A replicação do postgres (estou executando a versão 9.1) pode ser persuadida a fazer isso ou, se não houver, existem outros pacotes que executariam o trabalho. Em último caso, posso escrever um código que sincronize periodicamente as tabelas (posso tolerar algum atraso), mas seria bom não!
Desde já, obrigado.
Respostas:
No PostgreSQL 9.3, você pode usar
postgres_fdwpara consultar de forma transparente a tabela estrangeira na outra máquina.Nas versões mais antigas,
dblinkpode ser uma opção conforme mencionado por Andrew.Outra opção é usar uma ferramenta como Londiste ou Slony-I para replicar as tabelas que você deseja. Eu recomendo usar o Londiste para isso, será muito mais simples. Ele cria gatilhos na tabela para detectar inserção / atualização / exclusão e os replica usando seu próprio cliente / servidor e um sistema de enfileiramento no outro banco de dados, onde faz a inserção / atualização / exclusão correspondente. Eu o uso na produção em vários sites de clientes e funciona muito bem.
Uma opção futura (espero que no PostgreSQL 9.5) seja a replicação lógica de streaming de log, a extração lógica do conjunto de alterações e a replicação bidirecional, que permitirá que bancos de dados ou tabelas individuais sejam replicados no nível SQL. Parte do trabalho foi comprometido com o PostgreSQL 9.4, mas não o suficiente para torná-lo útil para o que você deseja fazer.
fonte
Você deve usar dblinks e visualizações materializadas para conseguir isso. Ambos os recursos estão integrados nas versões mais recentes do Postgres:
http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html
http://www.postgresql.org/docs/9.3/static/dblink.html
Essencialmente, você cria um Mview em cada banco de dados L1, L2 ... com dados extraídos das tabelas em C e usa a atualização do Mview para atualizar periodicamente os Mviews com a frequência necessária. Os dados são armazenados localmente, portanto, o acesso é muito rápido. Isso é adequado apenas se os dados forem relativamente estáticos e você não se importar que os bancos de dados locais tenham ocasionalmente informações um pouco desatualizadas. Você deve definir as frequências de atualização para gerenciar isso adequadamente e, se não for aceitável, use um link de banco de dados e lide com a lentidão resultante.
Se você precisar de funcionalidade adicional, o projeto de instantâneos fornece recursos avançados, como atualizações rápidas e logs de instantâneo:
http://pgfoundry.org/projects/snapshot/
Com isso, você pode fazer as atualizações apenas atualizando linhas que precisam de atualização, o que pode torná-las extremamente rápidas para conjuntos de dados grandes e inelásticos, minimizando as interrupções no seu aplicativo. Por padrão, os Mviews são completamente descartados e recriados no Postgres, o que pode prejudicar o desempenho por razões óbvias.
fonte