Compartilhar via

Usar a ferramenta HBCK2 do Apache HBase

  • Artigo

Este artigo mostra como usar a ferramenta HBCK2 do Apache HBase. O HBCK2 é a ferramenta de reparo para clusters do Apache HBase.

Visão geral do HBCK2

O HBCK2 é atualmente uma ferramenta simples que faz apenas uma coisa de cada vez. No hbase-2.x, o Master é o árbitro final de todo o estado, portanto, um princípio geral para a maioria dos comandos do HBCK2 é que ele solicita que o Master afete todos os reparos.

Um Master deve estar em execução antes de executar comandos HBCK2. O HBCK1 executou a análise e relatou seu cluster como bom ou ruim, mas o HBCK2 é menos presunçoso. No hbase-2.x, o operador determina o que precisa ser corrigido e usa ferramentas, incluindo o HBCK2, para fazer reparos.

HBCK2 versus HBCK1

O HBCK2 é o sucessor do HBCK, a ferramenta de reparo fornecida com o hbase-1.x (também conhecido como HBCK1). Use o HBCK2 no lugar do HBCK1 para fazer reparos em clusters do hbase-2.x. O HBCK1 não deve ser executado em uma instalação hbase-2.x porque pode causar danos. Sua instalação de gravação (-fix) foi removida. Ele pode relatar o estado de um cluster do hbase-2.x, mas suas avaliações são imprecisas, pois não entende o funcionamento interno de um hbase-2.x.

O HBCK2 não funciona da maneira que o HBCK1 costumava funcionar, mesmo nos casos em que os comandos têm nomes semelhantes nas duas versões.

Obter o HBCK2

Você pode encontrar a versão no diretório de distribuição do HBase. Para obter mais informações, confira a página de downloads do HBase.

Interface do usuário mestre: relatório HBCK

Uma página de Relatório do HBCK adicionada ao Master na versão 2.1.6 em /hbck.jsp, que mostra a saída de duas inspeções executadas pelo Master em um intervalo. Um deles é a saída pelo CatalogJanitor sempre que ele é executado. Se forem encontradas sobreposições ou espaços no hbase:meta, o CatalogJanitor lista o que encontrou. Outro processo em segundo plano chore compara o conteúdo do sistema de arquivos e o hbase:meta. Se uma anomalia for encontrada, ele faz uma anotação na seção Relatório HBCK.

Para executar o CatalogJanitor, execute o comando no shell do hbase: catalogjanitor_run.

Para executar o hbck chore, execute o comando no shell do hbase: hbck_chore_run.

Ambos os comandos não recebem nenhuma entrada.

Executar o HBCK2

Você pode executar o comando hbck iniciando-o por meio do script $HBASE_HOME/bin/hbase. Por padrão, ao executar bin/hbase hbck, as ferramentas internas do HBCK1 são executadas. Para executar o HBCK2, você precisa apontar para um jar do HBCK2 criado usando a opção -j, como neste exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar

Esse comando imprime a ajuda do HBCK2, sem passar opções ou argumentos.

Comandos do HBCK2

Observação

Teste esses comandos em um cluster de teste para entender a funcionalidade antes de executá-los em um ambiente de produção.

assigns [OPTIONS] <ENCODED_REGIONNAME/INPUTFILES_FOR_REGIONNAMES>... | -i <INPUT_FILE>...

Opções:

  • -o,--override: substitui a propriedade por outro procedimento.
  • -i,--inputFiles: usa um ou mais nomes de região codificados.

Uma atribuição raw que pode ser usada mesmo durante a inicialização do Master (se o sinalizador -skip for especificado). Ele contorna os coprocessadores e passa um ou mais nomes de região codificados. de00010733901a05f5a2a3a382e27dd4 é um exemplo de como é o nome de uma região codificada no espaço do usuário. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns de00010733901a05f5a2a3a382e27dd4

Ele retorna os PIDs do AssignProcedures criado ou -1 se não houver nenhum. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém nomes de região codificados, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -i fileName1 fileName2

unassigns [OPTIONS] <ENCODED_REGIONNAME>...| -i <INPUT_FILE>...

Opções:

  • -o,--override: substitui a propriedade por outro procedimento.
  • -i,--inputFiles: usa um ou mais arquivos de entrada de nomes codificados.

Um cancelamento de atribuição raw que pode ser usado mesmo durante a inicialização do Master (se o sinalizador -skip for especificado). Ele contorna os coprocessadores e passa um ou mais nomes de região codificados. de00010733901a05f5a2a3a382e27dd4 é um exemplo de como é o nome de uma região codificada no espaço de substituição do usuário. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassign de00010733901a05f5a2a3a382e27dd4

Ele retorna os PIDs do UnassignProcedures criado ou -1 se não houver nenhum. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém nomes de região codificados, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassigns fileName1 -i fileName2

bypass [OPTIONS] <PID>...

Opções:

  • -o,--override: substitui se o procedimento estiver em execução ou travado.
  • -r,--recursive: ignora o pai e seus filhos. Essa opção é lenta e cara.
  • -w,--lockWait: aguarda milissegundos antes de desistir. Padrão=1.
  • -i,--inputFiles: usa um ou mais arquivos de entrada de PIDs.

Passe um ou mais PIDs de procedimentos para pular para a conclusão do procedimento. O pai do procedimento ignorado pula para a conclusão. As entidades são deixadas em um estado inconsistente e exigem reparo manual. Talvez seja necessário reiniciar o Master para limpar os bloqueios que ainda estão mantidos. O bypass falhará se o procedimento tiver filhos. Adicione recursive se tudo o que você tiver for um PID pai para concluir pai e filhos. Essa opção é lenta e perigosa, portanto, use-a seletivamente. Nem sempre funciona.

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass <PID>

Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivo de entrada. Cada arquivo contém PIDs, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass -i fileName1 fileName2

reportMissingRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Opção:

  • i,--inputFiles: usa um ou mais arquivos de entrada de nomes de namespace ou tabela.

Use essa opção quando as regiões estiverem ausentes de hbase:meta mas quando os diretórios ainda estiverem presentes no HDFS. Esse comando é apenas um método de verificação. Ele foi projetado para fins de relatório e não executa nenhuma correção. Ele fornece uma exibição de quais regiões (se houver) seriam adicionadas novamente a hbase:meta, agrupadas por respectiva tabela ou namespace.

Para ler efetivamente as regiões no meta, execute addFsRegionsMissingInMeta. Esse comando precisa de hbase:meta para estar online. Para cada namespace/tabela passado como parâmetro, ele executa uma comparação diff entre as regiões disponíveis nohbase:meta em relação a diretórios de regiões existentes no HDFS. Diretórios de região sem correspondências são impressos agrupados sob o nome da tabela relacionada. As tabelas sem regiões ausentes mostram a mensagem "nenhuma região ausente". Se nenhum namespace ou tabela for especificado, ele verificará todas as regiões existentes.

Ele aceita uma combinação de vários namespaces e tabelas. Os nomes de tabela devem incluir a parte do namespace, mesmo para tabelas no namespace padrão. Caso contrário, ele assume um valor de namespace. Este exemplo dispara relatórios de regiões ausentes para as tabelas table_1 e table_2, em um namespace padrão:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 default:table_2

Esse exemplo aciona um relatório de regiões ausentes para a tabela table_1 em um namespace padrão e para todas as tabelas do namespace ns1:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 ns1

Ele retorna uma lista de regiões ausentes para cada tabela passada como parâmetro ou para cada tabela em namespaces especificados como parâmetro. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém <NAMESPACE|NAMESPACE:TABLENAME>, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta -i fileName1 fileName2

addFsRegionsMissingInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Opção:

  • -i,--inputFiles: recebe um ou mais arquivos de entrada de nomes de tabelas de namespace a serem usados quando as regiões estão ausentes de hbase:meta, mas os diretórios ainda estão presentes no HDFS. Precisa de hbase:meta para estar online.

Para cada nome de tabela passado como parâmetro, ele executa a comparação diff entre as regiões disponíveis em hbase:meta e diretórios de região no HDFS. Em seguida, para diretórios sem correspondências hbase:meta, ele lê o arquivo de metadados regioninfo e recria uma região específica em hbase:meta. As regiões são recriadas no estado CLOSED na tabela hbase:meta, mas não no cache Masters. Eles também não são atribuídos. Para colocar essas regiões online, execute o comando assigns do HBCK2 impresso quando essa execução de comando for concluída.

Se estiver usando versões do hbase anteriores à 2.3.0, uma reinicialização sem interrupção do HMasters será necessária antes da execução do conjunto de saída assigns. Este exemplo adiciona regiões ausentes para tabelas tbl_1 no namespace padrão, tbl_2 no namespace n1 e para todas as tabelas do namespace n2:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

Retorna ao HBCK2 um comando assigns com todas as regiões reinseridas. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém <NAMESPACE|NAMESPACE:TABLENAME>, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta -i fileName1 fileName2

extraRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Opções:

  • -f, --fix: corrige o meta removendo todas as regiões extras encontradas.
  • -i,--inputFiles: usa um ou mais arquivos de entrada com nomes de namespace ou tabela.

Relata regiões presentes em hbase:meta, mas sem diretórios relacionados no sistema de arquivos. Precisa de hbase:meta para estar online. Para cada nome de tabela passado como parâmetro, executa a comparação entre as regiões disponíveis em hbase:meta e diretórios de região no sistema de arquivos fornecido. As regiões extras seriam excluídas do Meta se a opção --fix fosse aprovada.

Observação

Antes de decidir sobre o uso da opção --fix, verifique se as regiões extras relatadas estão se sobrepondo às regiões válidas existentes. Nesse caso, extraRegionsInMeta --fix é a solução ideal. Caso contrário, o comando assigns é a solução mais simples. Ele recria os diretórios das regiões no sistema de arquivos, se eles não existirem.

Este exemplo dispara relatórios de regiões extras para table_1 no namespace padrão e para todas as tabelas do namespace ns1:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta default:table_1 ns1

Este exemplo dispara relatórios de regiões extras para table_1 no namespace padrão e para todas as tabelas do namespace ns1: com a opção de correção:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -f default:table_1 ns1

Ele retorna uma lista de regiões extras para cada tabela passada como parâmetro ou para cada tabela em namespaces especificados como parâmetro. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivo de entrada. Cada arquivo contém <NAMESPACE|NAMESPACE:TABLENAME>, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -i fileName1 fileName2

fixMeta

Observação

Essa opção não funciona bem com o HBase 2.1.6. Não recomendamos seu uso em um cluster HBase 2.1.6.

Faça uma correção do lado do servidor de estado inválido ou inconsistente em hbase:meta. A interface do usuário Master tem uma nova guia HBCK Report correspondente que despeja os relatórios gerados pela execução mais recente de catalogjanitor e um novo hbck chore.

É fundamental que hbase:meta esteja íntegro antes de fazer outros reparos. Ele corrige holes e overlaps, criando diretórios de região (vazios) no HDFS para corresponder às regiões adicionadas ao hbase:meta.

Esse comando não é o mesmo que o antigo comando hbck1 que tem o mesmo nome. Ele funciona com os relatórios gerados pela última execução de catalog_janitor e hbck chore. Se não houver nada para corrigir, a execução se torna um loop. Caso contrário, se a interface do usuário de HBCK Report relatar problemas, uma execução de fixMeta resolverá os problemas de hbase:meta.

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar fixMeta

generateMissingTableDescriptorFile <NAMESPACE:TABLENAME>

Esse comando tenta corrigir uma tabela órfã gerando um arquivo descritor de tabela ausente. Esse comando não terá efeito se a pasta da tabela estiver ausente ou se .tableinfo estiver presente. (Não substituímos os descritores de tabela existentes.) Esse comando primeiro verifica se TableDescriptor está armazenado em cache no HBase Master e, nesse caso, ele recupera .tableinfo de acordo. Se TableDescriptor não for armazenado em cache no Master, ele criará um arquivo .tableinfo padrão com os seguintes itens:

  • O nome da tabela.
  • A lista de família de colunas é determinada com base no sistema de arquivos.
  • As propriedades padrão para TableDescriptor e ColumnFamilyDescriptors. Se o arquivo .tableinfo foi gerado usando parâmetros padrão, verifique as propriedades da tabela ou da família de colunas posteriormente. (Altere-as se necessário.) Esse método não altera nada no HBase. Ele apenas grava o novo arquivo .tableinfo no sistema de arquivos. Para que as tabelas órfãs, por exemplo, ServerCrashProcedures sejam mantidas, talvez seja necessário corrigir o erro depois de gerar os arquivos de informações da tabela ausentes.
hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar generateMissingTableDescriptorFile namespace:table_name

replication [OPTIONS] [<NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...]

Opções:

  • -f, --fix: corrige os problemas de replicação encontrados.
  • -i,--inputFiles: usa um ou mais arquivos de entrada de nomes de tabela.

Ele procura filas de replicação não excluídas e as exclui se a opção --fix for aprovada. Ele passa um nome de tabela para verificar se há uma barreira de replicação e limpa se --fix.

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication namespace:table_name

Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém <TABLENAME>, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication -i fileName1 fileName2

setRegionState [<ENCODED_REGIONNAME> <STATE> | -i <INPUT_FILE>...]

Opção:

  • -i,--inputFiles: usa um ou mais arquivos de entrada de nomes e estados de região codificados.

Estados de região possíveis:

  • OFFLINE
  • OPENING
  • OPEN
  • CLOSIN
  • CLOSED
  • SPLITTING
  • SPLIT
  • FAILED_OPEN
  • FAILED_CLOSE
  • MERGING
  • MERGED
  • SPLITTING_NEW
  • MERGING_NEW
  • ABNORMALLY_CLOSED

Aviso

Essa opção arriscada deve ser usada apenas como último recurso.

Os cenários de exemplo incluem cancelamentos de atribuição/atribuições que não podem avançar porque a região está em um estado inconsistente em hbase:meta. Por exemplo, o comando unassigns só poderá continuar se tiver sido passada uma região em um dos seguintes estados: SPLITTING, SPLIT, MERGING, OPEN ou CLOSING.

Antes de definir manualmente um estado de região com esse comando, certifique-se de que essa região não é tratada por um procedimento em execução, como assign ou split. Você pode obter uma exibição dos procedimentos em execução no shell do hbase usando o comando list_procedures. Este exemplo define a região de00010733901a05f5a2a3a382e27dd4 como CLOSING:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState de00010733901a05f5a2a3a382e27dd4 CLOSING

Se o estado da região for alterado, ele retornará 0, caso contrário, retornará 1. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivo de entrada. Cada arquivo contém <ENCODED_REGIONNAME> <STATE>, um par por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState -i fileName1 fileName2

setTableState [<TABLENAME> <STATE> | -i <INPUT_FILE>...]

Opção:

  • -i,--inputFiles: usa um ou mais arquivos de entrada de nomes de tabela e estados.

Os estados de tabela possíveis são ENABLED, DISABLED, DISABLING e ENABLING.

Para ler o estado da tabela atual no shell hbase, execute:

hbase> get 'hbase:meta', '<TABLENAME>', 'table:state'

Um valor de x08x00 == ENABLED, x08x01 == DISABLED etc. Também é possível executar describe <TABLENAME> no prompt do shell. Este exemplo torna o usuário de nome de tabela ENABLED:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState users ENABLED

Ele retorna o estado anterior da tabela. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém <TABLENAME> <STATE>, um par por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState -i fileName1 fileName2

scheduleRecoveries <SERVERNAME>... | -i <INPUT_FILE>...

Opção:

  • -i,--inputFiles: usa um ou mais arquivos de entrada de nomes de servidor.

Agendamento ServerCrashProcedure(SCP) para uma lista de RegionServers. Formate o nome do servidor como <HOSTNAME>,<PORT>,<STARTCODE>. (Confira Interface do usuário/logs do HBase.)

Esse exemplo usa RegionServer a.example.org, 29100,1540348649479:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries a.example.org,29100,1540348649479

Ele retorna os PIDs do ServerCrashProcedures criado ou -1 se nenhum procedimento for criado. (Confira os logs do Master para saber por que ele não faz isso.) O suporte a comandos foi adicionado nas versões 2.0.3, 2.1.2, 2.2.0 ou mais recentes do HBase. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivos de entrada. Cada arquivo contém <SERVERNAME>, um por linha. Por exemplo:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries -i fileName1 fileName2

Corrigir problemas

Esta seção ajuda você a solucionar problemas comuns.

Noções básicas gerais

Ao fazer o reparo, primeiro certifique-se de que hbase:meta é consistente, antes de corrigir qualquer outro tipo de problema, como desvios do sistema de arquivos. Desvios no sistema de arquivos ou problemas de atribuição devem ser resolvidos depois que hbase:meta for colocado em ordem. Se hbase:meta tiver problemas, o Master não poderá fazer posicionamentos adequados ao adotar dados órfãos do sistema de arquivos ou fazer atribuições de região.

Uma região não poderá ser atribuída se estiver no estado CLOSING (ou no inverso, não atribuído se estiver no estado OPENING) sem primeiro fazer a transição via CLOSED. As regiões sempre devem passar de CLOSED, para OPENING, para OPEN e, em seguida, para CLOSING e CLOSED.

Ao fazer um reparo, corrija tabelas uma de cada vez.

Se uma tabela estiver DISABLED, você não poderá atribuir uma região. Nos logs do Master, você verá que os relatórios do Master foram ignorados porque a tabela está DISABLED. Você pode atribuir uma região porque ela está atualmente no estado OPENING e você a quer no estado CLOSED para que ela concorde com o estado DISABLED da tabela. Nessa situação, talvez seja necessário definir temporariamente o status da tabela como ENABLED para que você possa fazer a atribuição. Em seguida,defina-o novamente após a instrução para cancelar a atribuição. O HBCK2 permite fazer essa alteração. Confira a saída de uso do HBCK2.

Atribuir e cancelar atribuição

Geralmente, na atribuição, o Master persiste até ser bem-sucedido. Uma atribuição usa um bloqueio exclusivo na região. O bloqueio impede a execução de uma atribuição ou desatribuição simultânea. Uma atribuição em uma região bloqueada aguarda até que o bloqueio seja liberado antes de progredir.

Master startup cannot progress, in holding-pattern until region online:

2018-10-01 22:07:42,792 WARN org.apache.hadoop.hbase.master.HMaster: hbase:meta,1.1588230740 isn't online; state={1588230740 state=CLOSING, ts=1538456302300, server=ve1017.example.org,22101,1538449648131}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region online.

O Master não pode continuar a inicialização porque não há procedimento ao qual atribuir hbase:meta (ou hbase:namespace). Para injetar um, use a ferramenta HBCK2:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -skip 1588230740

Neste exemplo, 1588230740 é o nome codificado da região hbase:meta. Passe a opção -skip para impedir que o HBCK2 faça uma verificação de versão no Master remoto. Se o Master remoto não estiver ativo, a verificação de versão solicitará um Master is initializing response ou PleaseHoldException e removerá a tentativa de atribuição. O comando -skip evita a verificação de versão e coloca a atribuição agendada.

O mesmo pode acontecer com a tabela do sistema hbase:namespace. Procure o nome codificado da região hbase:namespace e faça algo semelhante ao que fizemos para hbase:meta. Nesse último caso, o Master realmente imprime uma mensagem útil semelhante a este exemplo:

2019-07-09 22:08:38,966 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562733904278.9559cf72b8e81e1291c626a8e781a6ae. isn't online; state={9559cf72b8e81e1291c626a8e781a6ae state=CLOSED, ts=1562735318897, server=null}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region onlined.

Para agendar uma atribuição para a tabela hbase:namespace mencionada na linha de log anterior:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 9559cf72b8e81e1291c626a8e781a6ae

Passe o nome codificado para a região do namespace. (O nome codificado difere por implantação.)

Regiões ausentes na restauração/recompilação de tabela/região do hbase:meta

Alguns casos incomuns tiveram regiões de tabela removidas da tabela hbase:meta. A triagem nesses casos revelou que eles foram induzidos pelo operador. Os usuários executaram a ferramenta obsoleta HBCK1 OfflineMetaRepair em um cluster HBCK2. O OfflineMetaRepair é uma ferramenta conhecida para corrigir problemas relacionados a tabelas hbase:meta em versões do HBase 1.x. A versão original não é compatível com o HBase 2.x ou versões superiores e passou por alguns ajustes. Em situações extremas, agora ele pode ser executado via HBCK2.

Na maioria desses casos, as regiões acabam ausentes aleatoriamente no hbase:meta, mas o hbase ainda pode estar operacional. Nessas situações, o problema pode ser resolvido com o Master online usando o comando addFsRegionsMissingInMeta no HBCK2. Esse comando é menos disruptivo ao hbase do que uma recompilação completa do hbase:meta, que será abordada posteriormente. Ele pode ser usado até mesmo para recuperar a região da tabela de namespace.

Regiões extras na restauração/recompilação de tabela/região do hbase:meta

Também pode haver situações em que as regiões da tabela foram removidas no sistema de arquivos, mas ainda há entradas relacionadas na tabela hbase:meta. Esse cenário pode ocorrer devido a problemas na divisão, erros de operação manual (como excluir ou mover o diretório da região manualmente) ou até mesmo problemas de perda de informações de metadados, como o HBASE-21843.

Esses problemas podem ser resolvidos com o Master online usando o comando extraRegionsInMeta --fix no HBCK2. Esse comando é menos disruptivo ao hbase do que uma recompilação completa do hbase:meta, que será abordada posteriormente. Também é útil quando isso acontece em versões que não dão suporte à opção HBCK2 fixMeta (qualquer versão anterior a 2.0.6, 2.1.6, 2.2.1, 2.3.0 ou 3.0.0).

Receita de recompilação online do hbase:meta

Se a corrupção do hbase:meta não for muito crítica, o hbase ainda poderá colocá-lo online. Mesmo que a região do namespace esteja entre as regiões ausentes, é possível examinar o hbase:meta durante o período de inicialização, em que o Master está aguardando a atribuição do namespace. Para verificar essa situação, um comando de verificação dohbase:meta pode ser executado. Se ele não atingir o tempo limite ou mostrar erros, o hbase:meta estará online:

echo "scan 'hbase:meta', {COLUMN=>'info:regioninfo'}" | hbase shell

O addFsRegionsMissingInMeta do HBCK2 pode ser usado se a mensagem não mostrar erros. Ele lê informações de metadados de região disponíveis nos diretórios da região FS para recriar regiões no hbase:meta. Como ele pode ser executado com o hbase parcialmente operacional, ele tenta desabilitar as tabelas online que são afetadas pelo problema relatado e vai ler as regiões para hbase:meta. Ele pode verificar tabelas ou namespaces específicos, bem como todas as tabelas de todos os namespaces. Este exemplo mostra a adição de regiões ausentes para tabelas tbl_1 no namespace padrão, tbl_2 no namespace n1 e para todas as tabelas do namespace n2:

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

Como ele opera independentemente do Master, depois de concluído com êxito, são necessárias mais etapas para que as regiões lidas sejam atribuídas. Essas mensagens são listadas da seguinte maneira:

  • addFsRegionsMissingInMeta gera um comando assigns com todas as regiões que foram adicionadas novamente. Esse comando precisa ser executado posteriormente, portanto, copie e salve-o para sua conveniência.
  • Para versões do HBase anteriores à 2.3.0, depois que addFsRegionsMissingInMeta for concluído com sucesso e a saída for salva, reinicie todos os HBase Masters em execução.

Depois que os Masters forem reiniciados e hbase:meta já estiver online (verifique se a interface do usuário da Web está acessível), execute o comando de atribuição a partir da saída de addFsRegionsMissingInMeta salva anteriormente.

Observação

Se a região do namespace estiver entre as regiões ausentes, você precisará adicionar o sinalizador --skip no início do comando de atribuição retornado.

Se um cluster sofrer uma perda catastrófica da tabela hbase:meta, uma recompilação aproximada será possível usando a receita a seguir. Na estrutura de tópicos, paramos o cluster. Execute a ferramenta OfflineMetaRepair do HBCK2, que lê diretórios e metadados armazenados no sistema de arquivos e faz o melhor esforço para recompilar uma tabela hbase:met viável. Reinicie seu cluster. Injete uma atribuição para colocar a tabela de namespace do sistema online. Por fim, reatribua tabelas de espaço do usuário que você deseja habilitar. (A recompilação de hbase:meta cria uma tabela com todas as tabelas offline e nenhuma região atribuída.)

Receita de recompilação detalhada

Observação

Use essa opção apenas como último recurso. Não recomendamos isso.

  • Interrompa o cluster.

  • Execute o comando rebuild hbase:meta do HBCK2. Isso deixa de lado o hbase:meta original e coloca em prática uma compilada recentemente. Esse exemplo mostra como executar a ferramenta. Ele adiciona o sinalizador -details para que a ferramenta despeje informações nas regiões encontradas no HDFS:

    hbase --config /etc/hbase/conf -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar org.apache.hbase.hbck1.OfflineMetaRepair -details

  • Inicie o cluster. Ele não será iniciado completamente. Está travado porque a tabela de namespace não está online e não há nenhum procedimento de atribuição no repositório de procedimentos para essa contingência. O log do HBase Master mostra esse estado. Este exemplo mostra o que ele registra:

    2019-07-10 18:30:51,090 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562808216225.725a0fe6c2c869d3d0a9ed82bfa80fa3. isn't online; state={725a0fe6c2c869d3d0a9ed82bfa80fa3 state=CLOSED, ts=1562808619952, server=null}; ServerCrashProcedures=false. Master startup can't progress, in holding-pattern until region onlined.

    Para atribuir a região da tabela de namespace, você não pode usar o shell. Se você usar o shell, ele falhará com PleaseHoldException porque o Master ainda não está pronto. (Ele está aguardando a tabela de namespace ficar online antes de se declarar "ativo". Você precisa usar o comando de atribuição do HBCK2. Para atribuir, você precisa do nome codificado no namespace. Ele é exibido no log entre aspas. Nesse caso, use 725a0fe6c2c869d3d0a9ed82bfa80fa3. Você precisa passar o comando -skip para ignorar a verificação de versão do Master. (Sem ele, sua invocação do HBCK2 provoca o PleaseHoldException porque o Master ainda não está pronto). Este exemplo adiciona uma atribuição da tabela de namespace:

    hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3

    Se a invocação voltar com Connection refused, o Master está ativo? O Master é desativado após algum tempo se não conseguir se inicializar. Basta reiniciar o cluster/Master e executar novamente o comando de atribuição.

  • Quando as atribuições são executadas com êxito, você vê que ela emite algo semelhante ao exemplo a seguir. O 48 no final é o PID do agendamento do procedimento de atribuição. Se o PID retornado for -1, a inicialização do Master não progrediu o suficiente. Portanto, tente novamente. Ou o nome da região codificada pode estar incorreto. Portanto, verifique esse problema.

    hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3

    18:40:43.817 [main] WARN  org.apache.hadoop.util.NativeCodeLoader - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
18:40:44.315 [main] INFO  org.apache.hbase.HBCK2 - hbck sufpport check skipped
[48]

  • Verifique os logs do Master. O Master deveria ter aparecido. Você verá a conclusão bem-sucedida de PID=48. Procure uma linha como este exemplo para verificar se a inicialização do Master foi bem-sucedida:

    master.HMaster: Master has completed initialization 132.515sec

    Pode levar um tempo para aparecer.

    A recompilação de hbase:meta adiciona as tabelas de usuário no estado DISABLED e nas regiões no modo CLOSED. Habilite novamente as tabelas por meio do shell para colocar todas as regiões da tabela novamente online. Faça isso uma de cada vez ou veja o comando habilitar todos ".*" para habilitar todas as tabelas de uma vez.

    A meta de recompilação está faltando edições e pode precisar de reparos e limpeza subsequentes usando o recurso descrito anteriormente neste artigo.

Arquivos de referência descartados, arquivo hbase.version ausente e arquivos corrompidos

O HBCK2 pode verificar se há referências pendentes e arquivos corrompidos. Você pode solicitar que ele deixe de lado os arquivos inválidos, o que pode ser necessário para superar obstáculos nos quais as regiões não estão online ou as leituras estão falhando. Confira o comando do sistema de arquivos na listagem do HBCK2. Passe um ou mais nomes de tabelas (ou use none para verificar todas as tabelas). Arquivos inválidos são relatados. Passe a opção --fix para fazer reparos.

Reinicialização do procedimento

Como último recurso, se o Master estiver em estado crítico e todas as tentativas de reparo resultarem em bloqueios irreversíveis ou procedimentos que não podem ser concluídos, ou se o conjunto de MasterProcWALs estiver crescendo sem limites, será possível apagar completamente o estado do Master. Mova o diretório /hbase/MasterProcWALs/ para o lado da instalação do HBase e reinicie o processo do Master. Ele volta como um formato tabular sem memória.

Se, no momento da eliminação, todas as regiões estiverem bem atribuídas ou desativadas, ao reiniciar o Master, ele deve simplesmente continuar como se nada tivesse acontecido. Mas se houver regiões em transição no momento, o operador precisará intervir para trazer atribuições ou desatribuições pendentes ao ponto terminal.

Leia as colunas hbase:meta info:state conforme descrito para determinar o que precisa ser atribuído ou não atribuído. Depois que todo o histórico for apagado, deixando de lado o MasterProcWALs, nenhuma das entidades deve ser bloqueada. Portanto, você estará livre para atribuir ou cancelar a atribuição em massa.