backups CouchDB e clonagem de banco de dados

Question

Nós estamos olhando para CouchdDB para uma aplicação CMS-ish. Quais são alguns padrões comuns, melhores práticas e conselhos de fluxo de trabalho que cercam o backup de nosso banco de dados de produção?

Eu estou particularmente interessado no processo de clonagem do banco de dados para uso em desenvolvimento e testes.

É suficiente apenas copiar os arquivos no disco debaixo de uma instância em execução ao vivo? Você pode clonar dados de banco de dados entre duas instâncias em execução ao vivo?

Aconselhamento e descrição das técnicas que uso será muito apreciada.

Answer 1

CouchDB suporta replicação, então apenas replicar para outra instância do CouchDB e backup a partir daí, evitando perturbar onde você escreve alterações.

http://wiki.apache.org/couchdb/FrequentlyAskedQuestions#how_replication

Você literalmente enviar um pedido POST para sua instância CouchDB dizendo-lhe onde para replicar para, e ele funciona (tm)

EDIT:. Você pode apenas cp os arquivos de sob o banco de dados rodando enquanto você pode aceitar o hit I / O

Answer 2

Outra coisa a ter em conta é que você pode copiar arquivos para fora sob um banco de dados ao vivo. Dado que você pode ter um grande banco de dados, possivelmente, você só poderia copiá-lo OOB do computador de teste / produção para outra máquina.

Dependendo da carga de gravação das máquinas pode ser aconselhável para desencadear uma replicação após a cópia para recolher quaisquer gravações que estavam em curso quando o arquivo foi copiado. Mas a replicação de alguns registros ainda seria mais rápido do que a replicação de todo o banco de dados.

Para referência ver: http://wiki.apache.org/couchdb/FilesystemBackups

Answer 3

CouchDB também funciona muito bem com instantâneos de sistemas de arquivos oferecidos pelos sistemas de arquivos modernos como ZFS . Como o arquivo de banco de dados é sempre em um estado consistente você pode tomar o instantâneo do arquivo a qualquer momento, sem enfraquecer as garantias de integridade fornecidos pelo CouchDB.

Isso resulta em quase nenhuma sobrecarga I / O. No caso de você ter por exemplo apagados acidentalmente um documento do banco de dados você pode mover o instantâneo para outra máquina e extrair os dados em falta lá. Você pode até ser capaz de replicar de volta para o banco de dados de produção, mas eu nunca tentei isso.

Mas sempre certifique-se de usar exatamente as mesmas revisões couchdb quando se deslocam arquivos de banco de dados. O formato em disco ainda está evoluindo de maneiras incompatíveis.

Answer 4

Eu gostaria de sugestão segundo Paulo: Apenas cp seus arquivos de banco de dados de debaixo do servidor ao vivo se você pode tomar a batida I / O-carga. Se você executar uma cópia replicada qualquer maneira, você com segurança pode copiar de que também, sem afetar o desempenho do seu mestre.

Answer 5

replicação

CouchDB é horrível. Eu geralmente faço tar que é muito melhor.

1. Pare o serviço CouchDB no host de origem
2. tar.gz a arquivos de dados.
3. Em meus servidores Ubuntu é normalmente em / var / lib / couchdb (às vezes em um subdiretório com base na versão Couch). Se você não tem certeza de onde esses arquivos são, você pode encontrar o caminho em seus arquivos de configuração CouchDB, ou muitas vezes, fazendo uma -A ps w para ver o comando completo que começou CouchDB. Certifique-se de obter os subdiretórios que começam com . quando você arquivar os arquivos.
4. Reinicie o serviço couchdb no host de origem.
5. scp o arquivo tar.gz para o host de destino e descompactá-los em um local temporário lá.
6. chown os arquivos para o usuário e grupo que possui os arquivos já no diretório do banco de dados do destino. Isto é provável couchdb: couchdb. Isso é importante, como bagunçar as permissões de arquivo é a única maneira que eu consegui atrapalhar este processo até agora.
7. Parar CouchDB no host de destino.
8. cp os arquivos para o diretório de destino. Novamente em meus anfitriões este tem sido / var / lib / couchdb.
9. Verifique as permissões de arquivo em sua nova casa.
10. Restart CouchDB no host de destino.