Uma breve observação, mais para mim, sobre pequenos truques para recuperação de dados no Elasticsearch. Como corrigir o índice vermelho se não houver backup, o que fazer se eu excluir os documentos e não sobrar cópia - infelizmente, na documentação oficial, eles não mencionam esses recursos.
Backups
A primeira coisa a fazer é configurar backups de dados importantes. Como isso é feito está descrito na
documentação oficial .
Em suma, nada complicado. Na versão mais simples, crie uma bola em outro servidor, monte-a em todos os nós elásticos de qualquer maneira conveniente (nfs, smbfs, qualquer que seja). Em seguida, use cron, seu aplicativo ou qualquer coisa para enviar solicitações de instantâneos periódicos.
O primeiro instantâneo será longo, os subsequentes conterão apenas o delta entre os estados do índice. Observe que, se você fizer periodicamente uma
exclusão , o delta será enorme e, consequentemente, o tempo
necessário para criar uma captura instantânea será semelhante à primeira vez.
O que considerar:
- Verifique o status dos backups, por exemplo, usando _cat:
curl localhost:9200/_cat/snapshots/ yourbackuprepo / . Instantâneos parciais ou com falha não são seu irmão. - A partir do ES 6.x, o elástico é muito exigente nos cabeçalhos de solicitação. Se você as fizer manualmente (não por meio da API), verifique se o
Content-Type: application/json , caso contrário, todas as suas solicitações serão interrompidas e o backup não ocorrerá - O instantâneo não pode ser restaurado para um índice aberto. Ele deve ser fechado ou removido primeiro. No entanto, você pode restaurar o instantâneo lado a lado usando rename_pattern, rename_replacement ( veja o exemplo no dock ). Além disso, quando um instantâneo é restaurado, suas configurações também são restauradas, incluindo aliases, número de réplicas etc. Se você não precisar disso, adicione index_settings ( consulte o dock para obter um exemplo ) com as alterações necessárias na solicitação de restauração.
- Os repositórios (bola) com instantâneos podem ser conectados a mais de um cluster e restaurar instantâneos de qualquer cluster para outro. O principal é que as versões elásticas são compatíveis.
Em geral, observe a documentação, esse tópico é mais ou menos divulgado.
Elasticdump
Um pequeno utilitário no nodejs que permite copiar dados de um índice para outro índice, cluster, arquivo, stdout.
A propósito, a saída para um arquivo ou stdout pode ser usada como um método alternativo de backup - a saída é um json válido regular (algo como sql dump), que pode ser reutilizado conforme desejado. Por exemplo, você pode colocar a saída em um canal, onde seu script transformará os dados de alguma forma e os enviará para outro repositório, como a clickhouse. As conversões js mais simples podem ser feitas diretamente pelo elasticdump, existe uma chave correspondente
--transform . Em geral, um vôo de fantasia.
Das armadilhas:
- Como método de backup, é muito mais lento que os instantâneos. Além disso, o backup é estendido ao longo do tempo, portanto, o resultado de um índice que muda frequentemente pode ser inconsistente. Tenha em mente.
- Não use o nodejs do repositório debian, há uma versão muito antiga que afeta negativamente a estabilidade das ferramentas.
- A estabilidade pode variar, especialmente se uma das partes estiver sobrecarregada. Não tente fazer backup de um servidor para outro executando a ferramenta na máquina do escritório - todo o tráfego fluirá através dela.
- Fig copiando mapeamentos. Se você tiver algo complicado lá, crie o índice manualmente e somente então preencha os dados nele.
- Às vezes, faz sentido alterar o tamanho do bloco (parâmetro --limit). Esta opção afeta diretamente a velocidade da cópia.
Para mesclar um grande número de índices ao mesmo tempo, existe um despejo multielastic com um conjunto simplificado de opções, mas todos os índices se mesclam em paralelo.
Nota! O autor do utilitário disse que ele não tem mais tempo para oferecer suporte, então o
programa está procurando um novo mantenedor .
Por experiência pessoal: utilidade útil, resgatada mais de uma vez. Velocidade e estabilidade são tão tão, eu gostaria de uma substituição adequada, mas até agora nada está no horizonte.
Checkindex
Então, começamos a nos aproximar do lado sombrio. Situação: o índice ficou vermelho. Nos logs - algo deu errado, a verificação não corresponde à quantidade, você provavelmente tem uma memória ou disco:
org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)Obviamente, isso nunca acontece com os administradores mãe, porque eles têm hardware de ponta com replicação tripla, memória superECC com correção de absolutamente todos os níveis de erro em tempo real e, geralmente, os instantâneos são configurados a cada segundo.
Mas, infelizmente, a realidade às vezes solicita essas opções, quando o backup é relativamente longo (se você tem gigabytes por hora indexados, o backup é antigo demais 2 horas atrás?), Não há lugar para restaurar os dados, a replicação não tinha tempo e tudo mais.
Obviamente, se houver um instantâneo, backup ou algo parecido. - Excelente, desenrole e não se preocupe. E se não? Felizmente, pelo menos alguns dos dados ainda podem ser salvos.
Primeiro, feche o índice e / ou desative o elástico, faça uma cópia de backup do fragmento com falha.
O Lucene (ou seja, funciona como um back-end na pesquisa elástica) possui um maravilhoso método CheckIndex. Só precisamos convocá-lo sobre um fragmento quebrado. O Lucene irá verificar todos os seus segmentos e remover os danificados. Sim, os dados serão perdidos, mas pelo menos não tudo. Embora tenha muita sorte.
Existem pelo menos 2 maneiras.
Método 1: Diretamente no site
Um script tão simples nos ajudará.
Chamando-o sem parâmetros, temos algo parecido com isto:
ERROR: index path not specified Usage: java org.apache.lucene.index.CheckIndex pathToIndex [-exorcise] [-crossCheckTermVectors] [-segment X] [-segment Y] [-dir-impl X] -exorcise: actually write a new segments_N file, removing any problematic segments -fast: just verify file checksums, omitting logical integrity checks -crossCheckTermVectors: verifies that term vectors match postings; THIS IS VERY SLOW! -codec X: when exorcising, codec to write the new segments_N file with -verbose: print additional details -segment X: only check the specified segments. This can be specified multiple times, to check more than one segment, eg '-segment _2 -segment _a'. You can't use this with the -exorcise option -dir-impl X: use a specific FSDirectory implementation. If no package is specified the org.apache.lucene.store package will be used. **WARNING**: -exorcise *LOSES DATA*. This should only be used on an emergency basis as it will cause documents (perhaps many) to be permanently removed from the index. Always make a backup copy of your index before running this! Do not run this tool on an index that is actively being written to. You have been warned! Run without -exorcise, this tool will open the index, report version information and report any exceptions it hits and what action it would take if -exorcise were specified. With -exorcise, this tool will remove any segments that have issues and write a new segments_N file. This means all documents contained in the affected segments will be removed. This tool exits with exit code 1 if the index cannot be opened or has any corruption, else 0.
Na verdade, podemos simplesmente executar o teste de índice ou fazer com que o CheckIndex o “conserte”, cortando tudo o que está danificado.
O índice Lutsen vive de maneira semelhante: / var / lib / elasticsearch / nós / 0 / índices / str4ngEHashVa1uE / 0 / index /, em que 0 e 0 são o número do nó no servidor e o número do shard no nó. O valor assustador entre eles - o nome interno do índice - pode ser obtido na saída do curl localhost: 9200 / _cat / indices.
Normalmente, faço uma cópia para outro diretório e reparo no local. Então eu reinicio o elasticsearch. Como regra, tudo é captado, embora com perda de dados. Às vezes, o índice ainda não deseja ser lido devido aos arquivos * corrompidos * na pasta shards. Mova-os para um local seguro por um tempo.
Método 2: Lucas
(imagem da Internet)
Existe uma grande utilidade para trabalhar com Lucene
chamado Luke .
Ainda é mais simples aqui. Descubra a versão Lucene na sua pesquisa elástica:
$ curl localhost:9200 { "name" : "node00", "cluster_name" : "main", "cluster_uuid" : "UCbEivvLTcyWSQElOipgTQ", "version" : { "number" : "6.2.4", "build_hash" : "ccec39f", "build_date" : "2018-04-12T20:37:28.497551Z", "build_snapshot" : false, "lucene_version" : "7.2.1", "minimum_wire_compatibility_version" : "5.6.0", "minimum_index_compatibility_version" : "5.0.0" }, "tagline" : "You Know, for Search" }
Tome a mesma versão de Lucas. Abrimos nele um índice (cópia, é claro) com um daw
Não abra o IndexReader (ao abrir o índice corrompido) . Em seguida, clique em Ferramentas / Verificar índice. Primeiro eu recomendo ficar seco, e só então no modo de reparo. Ações adicionais são semelhantes - copie de volta o elástico, reinicie / abra o índice.
Recuperar documentos excluídos
Situação: você executou uma consulta destrutiva que excluiu muitos / todos os dados necessários. E nenhum lugar para restaurar, ou muito caro. Bem, é claro, SSZB que não há backups, mas isso também acontece.
Infelizmente ou felizmente, Lucene nunca remove nada diretamente. Sua filosofia está mais próxima de CoW, portanto, os dados excluídos não são realmente excluídos, mas apenas marcados como excluídos. A exclusão ocorre durante a otimização do índice - os dados ao vivo dos segmentos são copiados para segmentos recém-criados, os segmentos antigos são simplesmente excluídos. Em geral, embora o status do índice excluído não seja 0, há chances de obtê-lo.
$ curl localhost:9200/_cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open data.0 R0fgvfPnTUaoI2KKyQsgdg 5 1 7238685 1291566 45.1gb 22.6gb
Após forcemerge, não há chance.
Então, primeiro, feche o índice, pare o elástico, copie o índice (arquivos) para um local seguro.
Não é possível retirar um documento excluído individual. Você só pode recuperar todos os documentos excluídos no segmento especificado.
Para as versões Lucene abaixo de 4, tudo é muito simples. A API Lucene possui uma função chamada undeleteAll. Você pode chamá-la diretamente de
Lucas no parágrafo anterior.
Para versões mais recentes, infelizmente, a funcionalidade foi cortada. Mas ainda há um caminho. As informações sobre documentos ativos são armazenadas em arquivos * .liv. No entanto, simplesmente removê-los tornará o índice ilegível. Você precisa corrigir o arquivo segmentos_N para que ele se esqueça completamente da existência deles.
Abra o arquivo segmentos_N (N é um número inteiro) no seu editor Hex favorito. A
documentação oficial nos ajudará a navegar:
segments_N: Header, LuceneVersion, Version, NameCounter, SegCount, MinSegmentLuceneVersion, <SegName, SegID, SegCodec, DelGen, DeletionCount, FieldInfosGen, DocValuesGen, UpdatesFiles>SegCount, CommitUserData, Footer
Por tudo isso, precisamos dos valores de DelGen (Int64) e DeletionCount (Int32). O primeiro deve ser definido como -1 e o segundo 0.
Não é difícil encontrá-los, eles estão logo atrás do SegCodec, que é uma string muito visível como o Lucene62. Nesta captura de tela, você pode ver que o DelGen possui um valor 3 e DeletionCount - 184614. Substitua o primeiro por 0xFFFFFFFFFFFFFFFFFF e o segundo por 0x00000000. Repita para todos os segmentos necessários, salve.
No entanto, o índice fixo não deseja carregar, citando um erro de soma de verificação. Ainda é mais simples aqui. Pegue Luke, carregue o índice com o IndexReader desativado, Ferramentas / Verificar índice. Fazemos um teste e imediatamente capturamos que segmentos_N estão danificados. Tal e tal verificação é esperada, mas tal e tal é recebida.
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) : expected=51fbdb5c actual=6e964d17
Bobagem! Tomamos a soma de verificação esperada e a inserimos nos últimos 4 bytes do arquivo.
Salve. Executamos o CheckIndex novamente para garantir que tudo esteja OK e o índice esteja carregando.
Et voilà!