O ndb_restore do cluster do MySQL falha sem erros

0

Eu tenho trabalhado para migrar nosso atual banco de dados de instância única para um novo banco de dados clusterizado executando o cluster MySQL.

É um grande banco de dados (vários bilhões de registros) e, embora pareça estar funcionando razoavelmente bem, estou tendo dificuldades em restaurar um backup (para uma segunda réplica de desenvolvimento de site)

O backup contém apenas cerca de 800 milhões de relatórios, que o hardware deve ser capaz de manipular bem. No entanto, quando tento restaurar o backup (o que pode levar horas a dias!), Algumas das restaurações do nó simplesmente param - sem motivo aparente e sem nada óbvio nos logs.

Eu pesquisei no Google da melhor maneira possível e não consigo encontrar ninguém que tenha enfrentado esse problema.

O banco de dados em questão contém cerca de 30 tabelas, uma das quais contém a maioria dos relatórios. Eu posso restaurar todos os metadados das tabelas bem, e todos, mas a tabela grande (usando o sinalizador exclude-table). Mas quando eu tento restaurar a tabela grande eu recebo este problema onde o ndb_restore pára.

Estou usando o cluster 5.6.23 do MySQL com ndb-7.4.5 O cluster é construído com 6 nós de dados (executando ndbmtd), 1 nó de gerenciamento e 3 nós de API (cada um com 3 conexões logicamente 9 nós de API em 3 servidores )

Todas as tabelas envolvidas são tabelas de dados de disco, o espaço de tabela é grande o suficiente para conter todo o conjunto de dados, e o sistema possui RAM suficiente para manter os índices e colunas indexadas.

Qualquer ajuda com isso seria muito apreciada (se você precisar de mais informações, por favor, pergunte!)

    
por egmackenzie 07.04.2015 / 11:33

1 resposta

0

Acho que encontrei a solução.

Eu tenho executado o ndb_restore através de um script que eu tenho executado através de uma conexão SSH, pois atualmente não tenho acesso físico aos servidores. Assim, quando a sessão SSH morre, o ndb_restore recebe um SIGHUP. Eu acredito que isso é o que está causando o processo para parar sem qualquer aviso ou mensagens de log.

Eu já descobri que posso evitar isso, uma vez que o script tenha sido em segundo plano (ctrl + z; bg), executando:

disown [job id]

Para mais detalhes, veja:

por 07.04.2015 / 15:04