Partilhar via

Use a ferramenta Apache HBase HBCK2

  • Artigo

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

Visão geral do HBCK2

HBCK2 é atualmente uma ferramenta simples que faz apenas uma coisa de cada vez. No hbase-2.x, o Mestre é o árbitro final de todos os estados, então um princípio geral para a maioria dos comandos HBCK2 é que ele pede ao Mestre para fazer todos os reparos.

Um Master deve estar instalado e em execução antes que você possa executar comandos HBCK2. A HBCK1 realizou análises e relatou seu cluster como bom ou ruim, mas a HBCK2 é menos presunçosa. No hbase-2.x, o operador determina o que precisa ser corrigido e, em seguida, usa ferramentas, incluindo HBCK2, para fazer reparos.

HBCK2 vs. HBCK1

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

O HBCK2 não funciona como o HBCK1 costumava funcionar, mesmo nos casos em que os comandos são nomeados de forma semelhante nas duas versões.

Obter HBCK2

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

Master UI: O Relatório HBCK

Uma página de Relatório HBCK adicionada ao Master na versão 2.1.6 mostra /hbck.jsp 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 buracos no hbase:meta, o CatalogJanitor lista o que encontrou. Outro processo em segundo plano chore compara o conteúdo do sistema de arquivos e .hbase:meta Se uma anomalia for encontrada, ele faz uma anotação em sua seção Relatório HBCK.

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

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

Ambos os comandos não recebem entradas.

Executar HBCK2

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

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

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

Comandos HBCK2

Nota

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.

Essa raw atribuição pode ser usada mesmo durante a inicialização do Mestre (se o -skip sinalizador for especificado). Ele contorna os coprocessadores e passa um ou mais nomes de região codificados. de00010733901a05f5a2a3a382e27dd4 é um exemplo da aparência de um nome de 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 criado AssignProcedures ou -1 se nenhum. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo 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.

Esse raw unassign pode ser usado mesmo durante a inicialização do Master (se o -skip sinalizador for especificado). Ele contorna os coprocessadores e passa um ou mais nomes de região codificados. de00010733901a05f5a2a3a382e27dd4 é um exemplo da aparência de um nome de região codificada por espaço de substituição de 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 criado UnassignProcedures ou -1 se nenhum. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo 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 preso.
  • -r,--recursive: Ignora o pai e seus filhos. Esta opção é lenta e cara.
  • -w,--lockWait: Espera milissegundos antes de desistir. Padrão=1.
  • -i,--inputFiles: Usa um ou mais arquivos de entrada de PIDs.

Ele passa por um ou mais PIDs de procedimento para pular para o término do procedimento. O pai do procedimento ignorado pula para o fim. As entidades são deixadas em um estado inconsistente e exigem reparo manual. Pode ser necessário reiniciar o Master para limpar os bloqueios que ainda estão mantidos. O bypass falha se o procedimento tiver filhos. Adicione recursive se tudo o que você tem é um PID pai para terminar o pai e os filhos. Esta opção é lenta e perigosa, por isso 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 esta opção quando as regiões estiverem ausentes, hbase:meta mas quando os diretórios ainda estiverem presentes no HDFS. Este 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 visão de quais regiões (se houver) seriam readicionadas ao hbase:meta, agrupadas por respetiva tabela ou namespace.

Para readicionar efetivamente regiões no meta, execute addFsRegionsMissingInMeta. Este comando tem de hbase:meta estar online. Para cada namespace/tabela passado como parâmetro, ele executa uma diferença entre as regiões disponíveis em hbase:meta relação aos dirs das regiões existentes no HDFS. Os dirs de região sem correspondências são impressos agrupados sob o nome da tabela relacionada. As tabelas sem regiões ausentes mostram uma mensagem "sem regiões ausentes". 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 aciona 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

Este 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 um parâmetro ou para cada tabela em namespaces especificados como um parâmetro. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo de entrada. Cada ficheiro 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: Usa um ou mais arquivos de entrada de nomes de tabelas de namespace para serem usados quando regiões estão ausentes, hbase:meta mas os diretórios ainda estão presentes no HDFS. Precisa hbase:meta estar online.

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

Se você estiver usando versões do hbase anteriores à 2.3.0, uma reinicialização contínua do HMasters é necessária antes de executar o conjunto de assigns saída. Este exemplo adiciona regiões ausentes para tabelas tbl_1 no namespace padrão, tbl_2 em namespace n1e 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

Ele retorna HBCK2 e um assigns comando com todas as regiões reinseridas. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo de entrada. Cada ficheiro 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 meta removendo todas as regiões extras encontradas.
  • -i,--inputFiles: Usa um ou mais arquivos de entrada de nomes de namespace ou tabela.

Ele relata regiões presentes, hbase:meta mas sem diretórios relacionados no sistema de arquivos. Precisa hbase:meta estar online. Para cada nome de tabela passado como parâmetro, ele executa a diferença entre regiões disponíveis e hbase:meta dirs de região no sistema de arquivos específico. Regiões extras seriam excluídas do Meta se passasse a --fix opção.

Nota

Antes de decidir usar a --fix opção, vale a pena verificar se as regiões adicionais relatadas estão sobrepostas às regiões válidas existentes. Se assim for, então extraRegionsInMeta --fix é a solução ideal. Caso contrário, o assigns comando é a solução mais simples. Ele recria os dirs das regiões no sistema de arquivos, se eles não existirem.

Este exemplo aciona relatórios de regiões extras para table_1 sob o 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 aciona relatórios de regiões extras para table_1 sob o 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 um parâmetro ou para cada tabela em namespaces especificados como um parâmetro. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivo de entrada. Cada ficheiro 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

Nota

Esta 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 incorreto ou inconsistente no hbase:meta. A interface do usuário principal tem uma nova HBCK Report guia correspondente que despeja relatórios gerados pela execução mais recente de catalogjanitor e um novo hbck chore.

É fundamental que hbase:meta primeiro se torne saudável antes de fazer qualquer outro reparo. Ele corrige holes e overlaps, criando diretórios de região (vazios) no HDFS para corresponder às regiões adicionadas ao hbase:meta.

Este comando não é o mesmo que o antigo comando hbck1 que tem um nome semelhante. Ele funciona contra os relatórios gerados pelo último catalog_janitor e hbck chore executa. Se não houver nada para corrigir, a execução é um loop. Caso contrário, se a HBCK Report interface do usuário relatar problemas, uma execução de fixMeta problemas será hbase:meta resolvida.

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

generateMissingTableDescriptorFile <NAMESPACE:TABLENAME>

Este comando tenta corrigir uma tabela órfã gerando um arquivo descritor de tabela ausente. Este 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, caso em que ele se recupera .tableinfo de acordo. Se TableDescriptor não estiver armazenado em cache no Master, ele criará um arquivo padrão .tableinfo com os seguintes itens:

  • O nome da tabela.
  • A lista da família de colunas determinada com base no sistema de arquivos.
  • As propriedades padrão para ambos TableDescriptor e ColumnFamilyDescriptors. Se o .tableinfo arquivo foi gerado usando parâmetros padrão, verifique as propriedades da tabela ou da família de colunas mais tarde. (Altere-os, se necessário.) Este método não altera nada no HBase. Ele apenas grava o novo .tableinfo arquivo no sistema de arquivos. Para tabelas órfãs, por exemplo, ServerCrashProcedures para permanecer, 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 quaisquer problemas de replicação encontrados.
  • -i,--inputFiles: Usa um ou mais arquivos de entrada de nomes de tabelas.

Ele procura filas de replicação não excluídas e as exclui se passar a --fix opção. Ele passa um nome de tabela para verificar se há uma barreira de replicação e limpar 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, ele passa um ou mais nomes de arquivo de entrada. Cada ficheiro 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.

Possíveis estados da região:

  • OFFLINE
  • ABERTURA
  • ABRIR
  • CLOSINA
  • FECHADO
  • DIVISÃO
  • DIVISÃO
  • FAILED_OPEN
  • FAILED_CLOSE
  • FUSÃO
  • MESCLADO
  • SPLITTING_NEW
  • MERGING_NEW
  • ABNORMALLY_CLOSED

Aviso

Esta opção arriscada destina-se a ser utilizada apenas como último recurso.

Cenários de exemplo incluem não atribuições ou atribuições que não podem avançar porque a região está em um estado inconsistente no hbase:meta. Por exemplo, o unassigns comando só pode prosseguir se tiver passado por uma região em um dos seguintes estados: SPLITTING, SPLIT, MERGEGING, OPEN ou CLOSING.

Antes de definir manualmente um estado de região com esse comando, certifique-se de que essa região não é manipulada por um procedimento em execução, como assign ou split. Você pode obter uma visão dos procedimentos em execução no shell do hbase usando o list_procedures comando. 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

Ele retorna 0 se o estado da região foi alterado e 1 de outra forma. Se -i or --inputFiles for especificado, passe um ou mais nomes de arquivo de entrada. Cada ficheiro 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 e estados de tabelas.

Os possíveis estados da tabela são ENABLED, DISABLED, DISABLENG e ENABLELING.

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

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

Um valor de x08x00 == ENABLED, x08x01 == DISABLED, etc. Ele também pode ser executado describe <TABLENAME> no prompt do shell. Este exemplo torna o usuário do nome da 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 qualquer que fosse o estado da tabela anterior. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo de entrada. Cada ficheiro 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 servidores.

Agende ServerCrashProcedure(SCP) para uma lista de RegionServers. Formate o nome do servidor como <HOSTNAME>,<PORT>,<STARTCODE>. (Consulte UI/logs do HBase.)

Este 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 criado ServerCrashProcedures ou -1 se nenhum procedimento for criado. (Consulte Logs mestre para saber por que isso não acontece.) O suporte a comandos é adicionado nas versões 2.0.3, 2.1.2, 2.2.0 ou mais recentes do HBase. Se -i or --inputFiles for especificado, ele passa um ou mais nomes de arquivo de entrada. Cada ficheiro 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 secção ajuda-o a resolver problemas comuns.

Princípios gerais

Ao fazer um reparo, verifique se ele hbase:meta é consistente antes de corrigir qualquer outro tipo de problema, como um desvio do sistema de arquivos. Desvios no sistema de arquivos ou problemas com a atribuição devem ser resolvidos após a hbase:meta colocação em ordem. Se hbase:meta tiver problemas, o Mestre não poderá fazer posicionamentos adequados quando adotar dados órfãos do sistema de arquivos ou fizer atribuições de região.

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

Quando fizer uma reparação, corrija as tabelas uma de cada vez.

Se uma tabela estiver DESABILITADA, não será possível atribuir uma região. Nos logs mestres, você vê que os relatórios mestre ignorados porque a tabela está DESABILITADA. Você pode atribuir uma região porque ela está atualmente no estado OPENING e deseja que ela esteja no estado CLOSED para que ela esteja de acordo com o estado DISABLED da tabela. Nessa situação, talvez seja necessário definir temporariamente o status da tabela como HABILITADO para que você possa fazer a atribuição. Em seguida, você defini-lo novamente após a instrução unassign . A HBCK2 tem a facilidade de permitir que você faça essa alteração. Consulte a saída de uso do HBCK2.

Atribuir e cancelar atribuição

Geralmente, ao atribuir, o Mestre persiste até ser bem-sucedido. Uma atribuição tem um bloqueio exclusivo na região. O bloqueio impede que uma atribuição ou desatribuição simultânea seja executada. Uma atribuição em relação a 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 Mestre não pode continuar a inicialização porque não há nenhum procedimento para atribuir hbase:meta (ou hbase:namespace). Para injetar um, utilize 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 hbase:meta região. Passe a opção para impedir que o -skip HBCK2 faça uma verificação de versão em relação ao mestre remoto. Se o mestre remoto não estiver ativo, a verificação de versão solicitará um Master is initializing response ou PleaseHoldException e descartará a tentativa de atribuição. O -skip comando evita a verificação de versão e aterra a atribuição agendada.

O mesmo pode acontecer com a tabela do hbase:namespace sistema. Procure o nome da região codificada hbase:namespace e tome medidas semelhantes ao que fizemos para hbase:metao . Neste último caso, o Mestre realmente imprime uma mensagem útil que se parece com 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 anotada hbase:namespace 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 de acordo com a implantação.)

Regiões ausentes em hbase:meta region/table restore/rebuild

Alguns casos incomuns tiveram regiões da tabela removidas da hbase:meta tabela. A triagem destes casos revelou que foram induzidos pelo operador. Os usuários executaram a obsoleta ferramenta HBCK1 OfflineMetaRepair em um cluster HBCK2. OfflineMetaRepair é uma ferramenta bem conhecida para corrigir hbase:meta problemas relacionados à tabela nas 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 pode ser executado via HBCK2.

Na maioria destes casos, as regiões acabam por faltar hbase:meta aleatoriamente, mas o hbase pode ainda estar operacional. Em tais situações, o problema pode ser resolvido com o Master online usando o addFsRegionsMissingInMeta comando em HBCK2. Este comando é menos perturbador para o hbase do que uma reconstrução completa hbase:meta , que é abordada mais tarde. Ele pode ser usado até mesmo para recuperar a região da tabela de namespace.

Regiões extras em hbase:meta region/table restore/rebuild

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

Tais problemas podem ser resolvidos com o Master online usando o extraRegionsInMeta --fix comando em HBCK2. Este comando é menos perturbador para o hbase do que uma reconstrução completa hbase:meta , que é abordada mais tarde. Também é útil quando isso acontece em versões que não suportam a fixMeta opção HBCK2 (quaisquer versões anteriores à 2.0.6, 2.1.6, 2.2.1, 2.3.0 ou 3.0.0).

Hbase online:meta rebuild receita

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

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

HBCK2 addFsRegionsMissingInMeta pode ser usado se a mensagem não mostrar erros. Ele lê informações de metadados de região disponíveis nos diretórios de região FS para recriar regiões no hbase:meta. Como ele pode ser executado com o hbase parcialmente operacional, ele tenta desabilitar tabelas online que são afetadas pelo problema relatado e vai readicionar regiões ao hbase:meta. Ele pode verificar tabelas ou namespaces específicos ou 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 n1e 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 que ele é concluído com êxito, mais etapas são necessárias para que as regiões readicionadas sejam atribuídas. Essas mensagens estão listadas da seguinte forma:

  • addFsRegionsMissingInMeta gera um comando de atribuição com todas as regiões que foram readicionadas. Este comando deve ser executado mais tarde, portanto, copie-o e salve-o por conveniência.
  • Para versões do HBase anteriores à 2.3.0, depois de addFsRegionsMissingInMeta concluídas com êxito e a saída ter sido salva, reinicie todos os HBase Masters em execução.

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

Nota

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

Se um cluster sofre uma perda catastrófica da hbase:meta tabela, uma reconstrução aproximada é possível usando a seguinte receita. Em linhas gerais, paramos o cluster. Execute a ferramenta HBCK2 OfflineMetaRepair, que lê diretórios e metadados lançados no sistema de arquivos e faz o melhor esforço para reconstruir uma tabela viável hbase:met . Reinicie o cluster. Injete uma atribuição para colocar a tabela de namespace do sistema online. Por fim, reatribua as tabelas de espaço do usuário que você deseja ativar. (A reconstruída hbase:meta cria uma tabela com todas as tabelas offline e sem regiões atribuídas.)

Receita de reconstrução detalhada

Nota

Utilize esta opção apenas como último recurso. Nós não recomendamos.

  • Pare o cluster.

  • Execute o comando rebuild hbase:meta a partir de HBCK2. Este comando afasta o original hbase:meta e coloca no lugar um recém-reconstruído. Este exemplo mostra como executar a ferramenta. Ele adiciona o -details sinalizador para que a ferramenta despeje informações sobre as 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. Não vai arrancar totalmente. Ele está preso 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 mestre do HBase 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á porque PleaseHoldException o Mestre ainda não está ativo. (Está aguardando que a tabela de namespace fique online antes de se declarar "up".) Você precisa usar o comando HBCK2 assigns. Para atribuir, você precisa do nome codificado do namespace. Ele mostra no log citado. 725a0fe6c2c869d3d0a9ed82bfa80fa3 É o caso. Você tem que passar o -skip comando para ignorar a verificação de versão Master. (Sem ele, sua invocação HBCK2 provoca o PleaseHoldException porque o Mestre ainda não acabou.) 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 Mestre está de pé? O Mestre é desligado depois de um tempo se não puder inicializar-se. Reinicie o cluster/Master e execute novamente o comando assigns.

  • Quando as atribuições são executadas com êxito, você vê que ele emite algo semelhante ao exemplo a seguir. O 48 no final é o PID do cronograma de procedimento de atribuição. Se o PID retornado for -1, a inicialização Master não progrediu o suficiente, então 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 mestres. O Mestre deveria ter surgido. Você vê a conclusão bem-sucedida do PID=48. Procure uma linha como este exemplo para verificar uma inicialização Master bem-sucedida:

    master.HMaster: Master has completed initialization 132.515sec

    Pode demorar um pouco para aparecer.

    A reconstrução do adiciona as tabelas do hbase:meta usuário no estado DISABLED e as regiões no modo CLOSED. Reative as tabelas através do shell para colocar todas as regiões da tabela online novamente. Faça isso um de cada vez ou veja o comando enable all ".*" para habilitar todas as tabelas de uma só vez.

    O meta de reconstrução está faltando edições e pode precisar de reparo e limpeza subsequentes usando o recurso descrito anteriormente neste artigo.

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

HBCK2 pode verificar se há referências suspensas e arquivos corrompidos. Pode pedir-lhe para marginalizar ficheiros defeituosos, que podem ser necessários para ultrapassar corcovas onde as regiões não estão online ou as leituras estão a falhar. Consulte o comando file-system na listagem HBCK2. Passe um ou mais nomes de tabela (ou use none para verificar todas as tabelas). Arquivos incorretos são relatados. Passe a --fix opção de fazer reparos.

Reinício do procedimento

Como último recurso, se o Mestre estiver perturbado e todas as tentativas de reparo apenas aparecerem bloqueios inviáveis ou procedimentos que não podem terminar, ou se o conjunto de estiver crescendo sem limites, é possível limpar o estado do MasterProcWALs Mestre. Afaste o diretório sob a instalação do /hbase/MasterProcWALs/ HBase e reinicie o processo Master. Ele volta como um formato tabular sem memória.

Se no momento da eliminação todas as regiões foram alegremente atribuídas ou offline, na reinicialização do Mestre, o Mestre deve pegar e continuar como se nada tivesse acontecido. Mas se havia regiões em transição na altura, o operador tem de intervir para trazer atribuições pendentes ou não atribuídas para o seu ponto terminal.

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