Eu tenho uma situação com uma tabela específica que agora acredita que contém 4 petabytes de dados. Eu sei que soa legal, mas garanto-lhe, é apenas em uma partição de 60GB.
Esta tabela possui 9 campos. Um deles é um campo domain_id . É o melhor campo para identificar as linhas, pois existem apenas aproximadamente 6300 delas. A única outra opção de campo para combinar tem mais de 2 milhões de registros, e isso é mais difícil.
Eu não posso fazer um mysqldump direto porque ele tentará produzir todos os 4PB de dados e preencher a unidade muito antes de chegar perto disso, então eu preciso remover cirurgicamente as coisas boas, destruir o banco de dados e recriá-lo. / p>
Acredito que, se eu puder fazer um dump para cada registro de domain_id , eu tirarei a maioria dos dados utilizáveis. É isso 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 com domain_id 10 sejam exportadas.
No entanto, quando eu verificar a exportação, estou recebendo apenas 1 linha, quando no entanto eu olho para o banco de dados, há muitas muitas linhas. É como se o operador apenas encontrasse um e desistisse.
Eu tentei vários operadores. Usando o < ou > , consigo obter mais dados, mas a exportação é interrompida em determinadas linhas em que os dados foram comprometidos. Com mais de 6000 para passar, não posso restringir quais linhas estão sendo afetadas na exportação com facilidade.
Então, o que eu preciso é de um operador que faça basicamente o que eu acho que = faria, simplesmente me dê uma exportação de todos os registros que correspondam ao campo específico.
Observe também que a única maneira de obter esse DB até mesmo acessível é através de uma recuperação de força innodb 3. Então, preciso fazer isso direito, porque depois disso, eu tenho que soltar o banco de dados para tornar o mysql funcional novamente .
Ansioso para obter respostas úteis.
Do que você escreve, parece que o banco de dados foi corrompido (pensar em 4PB em vez de 60GB é uma espécie de distribuição).
Eu duvido que você possa obter qualquer garantia de confiabilidade das informações recuperadas, a menos que você repare o db primeiro. Você já tentou isso?
Caso contrário, o que acontece se você fizer a chave "-f" - para continuar, mesmo se erros forem encontrados?
Qual a sua opinião sobre a mesa?
Você poderia tentar convertê-lo em 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 os caras do innodb para obter suporte.
Eu não sou um administrador de banco de dados, então talvez essa ideia esteja 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 despejo do seu banco de dados de "4 petabyte" e redirecioná-lo através de um filtro grep / strings para que, se os dados corrompidos não forem válidos, não sejam gravados no disco. Isso dependeria se os dados corrompidos eram apenas lixo incompreensível, embora ...
Caso contrário, alguém aqui terá que sugerir uma ferramenta de reparo para tentar consertar o banco de dados.
Tente adicionar --skip-extended-insert . É possível que as coisas fiquem desconcertadas ao gravar no arquivo.