confiantemente grava o despejo de banco de dados diretamente no sistema de arquivos remoto (Linux)

1

Eu preciso mover um banco de dados muito grande (~ 320 GB) de server1 para server2 (Linux). Devido às diferentes versões de extensão, o banco de dados só pode ser restaurado em server2 a partir de um arquivo de despejo, conforme descrito aqui .

O problema é que eu não tenho espaço suficiente em server1 para primeiro escrever um arquivo de despejo lá, então copiá-lo para server2 e verificar somas. Preciso de uma maneira confiável de gravar os dados diretamente em server2 , minimizando o risco de corrupção.

Eu tentei:

  • Pipando o despejo de server1 para server2 usando nc .
  • Escrevendo um arquivo de despejo diretamente para um sistema de arquivos server2 que é montado em server1 usando sshfs .

Ambos os arquivos de despejo parecem ter sido corrompidos (tamanho substancialmente diferente e erros relacionados à corrupção em diferentes estágios da importação).

Eu migrei bancos de dados como este (mas muito menores) sem problemas. Alguém pode sugerir uma maneira melhor e mais confiável de fazer essa grande transferência?

UPDATE: Tentei NFS com os mesmos resultados. Sistemas de arquivos claramente remotos não conseguem lidar com esse volume de dados. Os blocos estão visivelmente ausentes do arquivo SQL resultante, causando erros de sintaxe durante a importação. Partes diferentes do arquivo são corrompidas toda vez que eu tento.

    
por kontextify 12.08.2015 / 12:05

4 respostas

0

Tenho a melhor resposta aqui . A melhor maneira de fazer isso é criar o arquivo de despejo diretamente no servidor de recebimento, descarregando o banco de dados de origem remotamente:

pg_dump -h remoteserver -U remoteuser remotedbname -Fc -f my_old_server_backup.dump

Isso é muito mais confiável do que gravar um arquivo SQL enorme em um sistema de arquivos de rede. Agora tenho um banco de dados migrado em funcionamento!

    
por 14.08.2015 / 10:58
0

Que tal montar um compartilhamento NFS externo primeiro no sever1 e montar no servidor2 após o despejo? Essa é a maneira que eu executo backups de dados e RMAN do banco de dados Oracle (semelhante aos seus dumps) com melhores resultados duplicando o servidor de produção (server1) para testar o servidor (server2) e restaurando backups. Nosso NFS externo depende de um NAS, mas qualquer Gnu / Linux fará o trabalho, apenas instale os pacotes necessários

Siga estas etapas para o Debian e depois de configurar o compartilhamento monte-o no server1 e server2 via / etc / fstab

nfs_server:/path/to/share /server1or2filesystem/mountpoint nfs rw,hard,intr,timeo=600,actimeo=0,proto=tcp,bg,rsize=262144,wsize=262144 0 0

Eu nunca tive problemas de corrupção com despejos em compartilhamentos NFS (a menos que ocorra uma falha de conectividade) e se você encontrar corrupção novamente testando NFS você pode tentar um despejo parcial local para descartar erros de configuração na ferramenta de despejo se esse despejo local for corrompido também.

    
por 12.08.2015 / 13:38
0

Teste o AFS ( Andrew FS ). Este sistema de arquivos é per se projetado para ser escalável e orientado para rede e pode fornecer uma boa solução para o seu problema. No caso do Ubuntu , use OpenAFS . Tenha em mente que isso exigirá alguma configuração e configuração, antes de estabelecer uma conexão confiável.

    
por 12.08.2015 / 13:51
0

você pode tentar importá-lo diretamente por meio deste oneliner:

mysqldump --add-drop-table --extended-insert --force --log-error = erro.log -uUSER -pPASS OLD_DB_NAME | ssh -C user @ newhost "mysql-uUSER -pPASS NEW_DB_NAME"

mas não é capaz de copiar confiável pela rede. Tem certeza de que não há problemas de rede ou de sistema de arquivos?

    
por 13.08.2015 / 13:21