Tenho uma situação com uma tabela específica que agora pensa conter 4 petabytes de dados. Eu sei que parece legal, mas garanto que é apenas em uma partição de 60 GB.
Esta tabela possui 9 campos. Um deles é um domain_idcampo. É o melhor campo para identificar as linhas, pois existem apenas aproximadamente 6.300 delas. A única outra opção de campo para igualar tem mais de 2 milhões de registros, e isso é apenas mais difícil.
Não consigo fazer um mysqldump direto porque ele tentará gerar todos os 4 PB de dados e preencher a unidade muito antes de chegar perto disso, então preciso remover cirurgicamente as coisas boas, destruir o banco de dados e recriá-lo.
Acredito que se eu puder fazer um despejo para cada domain_idregistro, obterei dele a maior parte dos dados utilizáveis. Isto é o que estou tentando usar:
mysqldump -u root --skip-opt -q --no-create-info --skip-add-drop-table \
--max_allowed_packet=1000000000 database table --where="domain_id=10" \
> domains10.sql
Usando isso, espero que todas as linhas domain_id 10sejam exportadas.
Porém, quando verifico a exportação, estou obtendo apenas 1 linha, mas quando olho para o banco de dados, há muitas linhas. É como se o operador simplesmente encontrasse um e depois desistisse.
Eu tentei vários operadores. Usando o <ou >consigo obter mais dados, mas a exportação é interrompida em determinadas linhas onde os dados foram comprometidos. Com mais de 6.000 para analisar, não consigo restringir quais linhas estão sendo afetadas na exportação com bastante facilidade.
Então, o que eu preciso é de um operador que basicamente faça o que pensei que =faria, simplesmente me forneça uma exportação de todos os registros que correspondam ao campo específico.
Observe também que a única maneira de tornar esse banco de dados acessível é através de uma recuperação de força innodb 3. Então, preciso fazer isso direito, porque depois que isso for feito, tenho que descartar o banco de dados para tornar o mysql funcional novamente.
Ansioso por quaisquer respostas úteis.
Responder1
Pelo que você escreve, parece que o banco de dados foi corrompido (pensar em 4 PB em vez de 60 GB é uma espécie de dádiva).
Duvido que você possa obter qualquer garantia de confiabilidade das informações recuperadas, a menos que repare o banco de dados primeiro. Você já tentou isso?
Caso contrário, o que acontece se você usar a tecla "-f" - para continuar mesmo se forem encontrados erros?
Responder2
Qual o tamanho que você acha que a mesa deveria ter?
Você poderia tentar convertê-lo para myisam:
alter table ggg engine=myisam;
No entanto, parece que você tem um banco de dados corrompido.
O melhor plano seria entrar em contato com o pessoal do innodb para obter suporte.
Responder3
Não sou administrador de banco de dados, então talvez essa ideia seja totalmente equivocada, mas há dados no dump que devem ser consistentes em todos os registros com uma string de texto? Gostaria de saber se é possível fazer um dump do seu banco de dados de "4 petabytes" e redirecioná-lo através de um filtro grep/strings para que, se os dados corrompidos não forem uma string válida, eles não serão gravados no disco. Isso dependeria se os dados corrompidos eram apenas lixo incompreensível ...
Caso contrário, alguém aqui terá que sugerir uma ferramenta de reparo para tentar consertar o banco de dados.
Responder4
Tente adicionar --skip-extended-insert. É possível que as coisas fiquem confusas ao gravar no arquivo.