HBase
 sql >> Base de Dados >  >> NoSQL >> HBase

Replicação do Apache HBase:visão geral operacional


Esta é a segunda postagem do blog sobre a replicação do Apache HBase. A postagem anterior do blog, Visão geral da replicação do HBase, discutiu os casos de uso, a arquitetura e os diferentes modos compatíveis com a replicação do HBase. Esta postagem do blog é de uma perspectiva operacional e abordará a configuração de replicação do HBase e os principais conceitos para usá-la, como bootstrapping, alteração de esquema e tolerância a falhas.

Configuração


Conforme mencionado em Visão geral da replicação do HBase, o cluster mestre envia o envio de WALEdits para um ou mais clusters escravos. Esta seção descreve as etapas necessárias para configurar a replicação no modo mestre-escravo.
  1. Todas as tabelas/famílias de colunas que devem ser replicadas devem existir em ambos os clusters.
  2. Adicione a seguinte propriedade em $HBASE_HOME/conf/hbase-site.xml em todos os nós em ambos os clusters; defina como verdadeiro.

         
               hbase.replication
                verdadeiro
         

No cluster mestre, faça as seguintes alterações adicionais:

  1. Definir escopo de replicação (REPLICATION_SCOPE atributo) na tabela/família de colunas que deve ser replicada:

    hbase shell> desabilita 'tabela'
     hbase shell> alter 'table', {NAME => 'column-family', REPLICATION_SCOPE => 1}
     hbase shell> habilita 'tabela'

REPLICATION_SCOPE é um atributo de nível de família de colunas e seu valor pode ser 0 ou 1. Um valor 0 significa que a replicação está desabilitada e 1 significa que a replicação está habilitada. Um usuário deve alterar cada família de colunas com o comando alter conforme mostrado acima, para todas as famílias de colunas que deseja replicar.

Se um usuário quiser habilitar a replicação ao criar uma tabela, ele deve usar o seguinte comando:

hbase shell> cria ‘table’, ‘column-family1’, ‘‘column-family2’, {NAME => ‘column-family1’, REPLICATION_SCOPE => 1}

O comando acima habilitará a replicação em 'column-family1' da tabela acima.

       2.    No shell hbase, adicione o peer escravo. Um usuário deve fornecer o quorum do zookeeper do cluster escravo, sua porta do cliente e o znode hbase raiz, juntamente com um peerId:

hbase shell>add_peer ‘peerId’, “::”

O peerId é uma string de um ou dois caracteres e um znode correspondente é criado sob o znode de peers, conforme explicado no blog anterior. Depois que um usuário executa o comando add_peer, o código de replicação instancia um objeto ReplicationSource para esse peer e todos os servidores de região do cluster mestre tentam se conectar aos servidores de região do cluster escravo. Ele também busca o ClusterId do cluster escravo (UUID, registrado no quorum de zookeeper do cluster escravo). O servidor de regiões do cluster mestre lista os servidores de regiões disponíveis do escravo lendo “/hbase/rs” znode e seus filhos no quorum de zookeeper do cluster escravo e faz conexão com ele. Cada regionserver no cluster mestre escolhe um subconjunto dos servidores de regiões escravos, dependendo da proporção especificada por “replication.source.ratio”, com valor padrão 0,1. Isso significa que cada servidor de região de cluster mestre tentará se conectar a 10% do total de servidores de região de cluster escravo. Ao enviar o lote de transações, o servidor de regiões do cluster mestre selecionará um servidor de regiões aleatório desses servidores de regiões conectados. (Observação:a replicação não é feita para tabelas de catálogo, .META. e _ROOT_.)

Para configurar um modo mestre-mestre, as etapas acima devem ser repetidas em ambos os clusters.

Mudança de esquema


Conforme mencionado na seção anterior, a tabela replicada e a família de colunas devem existir em ambos os clusters. Esta seção discute vários cenários possíveis sobre o que acontece durante uma alteração de esquema quando a replicação ainda está em andamento:

a) Excluir a família de colunas no mestre:a exclusão de uma família de colunas não afetará a replicação de quaisquer mutações pendentes para essa família. Isso ocorre porque o código de replicação lê o WAL e verifica o escopo de replicação das famílias de colunas para cada WALEdit. Cada WALEdit tem um mapa das famílias de colunas habilitadas para replicação; a verificação é feita em toda a família de colunas do keyvalue constituinte (sejam eles com escopo ou não). Se estiver presente no mapa, é adicionado ao envio. Como o objeto WALEdit é criado antes da exclusão da família de colunas, sua replicação não será afetada.

b) Exclua a família de colunas no escravo:Os WALEdits são enviados do cluster mestre para um servidor de região escravo específico, que o processa como um cliente HBase normal (usando um objeto HTablePool). Como a família de colunas é excluída, a operação put falhará e essa exceção será lançada para o cluster master regionserver.

Iniciar/Parar a replicação


Os comandos Start/Stop funcionam como um kill switch. Quando o comando stop_replication é executado no shell do HBase, ele altera o valor de /hbase/replication/state para false. Ele impedirá que todos os objetos de origem de replicação leiam os logs; mas as entradas de leitura existentes serão enviadas. Se um usuário usar o comando parar replicação,  os registros recém-rolados não serão enfileirados para replicação. Da mesma forma, emitir um comando start_replication iniciará a replicação a partir do WAL atual (que pode conter algumas transações anteriores) e não a partir do momento em que o comando foi emitido.


A Figura 1 explica o comportamento da chave start-stop, onde a sequência de eventos flui na direção das setas.

Compatibilidade de versão

Os servidores de regiões de cluster mestre conectam-se a servidores de região de cluster escravos como clientes HBase normais. A mesma regra de compatibilidade se aplica se um cliente HBase na versão xxx é suportado em um servidor HBase na versão yyy.

Em outro ponto, como a replicação ainda está em evolução (mais e mais funcionalidades são continuamente adicionadas a ela), o usuário deve estar ciente das funcionalidades existentes. Por exemplo, no CDH4, que é baseado na ramificação HBase 0.92, há suporte para replicação mestre-mestre e cíclica. A habilitação/desabilitação da fonte de replicação no nível de peer é adicionada na ramificação HBase 0.94.

Inicialização

A replicação funciona lendo os WALs dos servidores de região do cluster mestre. Se um usuário deseja replicar dados antigos, ele pode executar um comando copyTable (definindo o carimbo de data/hora inicial e final), enquanto habilita a replicação. O comando copyTable copiará os dados no escopo dos carimbos de data/hora de início/término e a replicação cuidará dos dados atuais. A abordagem geral pode ser resumida como:

  1. Inicie a replicação (observe o carimbo de data/hora).
  2. Execute o comando copyTable com um carimbo de data/hora de término igual ao carimbo de data/hora acima.
  3. Como a replicação começa no WAL atual, pode haver alguns valores-chave que são copiados para o escravo por tarefas de replicação e copyTable. Isso ainda é bom, pois é uma operação idempotente.

No caso de replicação master-master, deve-se executar o trabalho copyTable antes de iniciar a replicação. Isso ocorre porque se um usuário iniciar um trabalho copyTable após habilitar a replicação, o segundo mestre reenviará os dados para o primeiro mestre, pois copyTable não edita o clusterId nos objetos de mutação. A abordagem geral pode ser resumida como:

  1. Execute o trabalho copyTable (observe o carimbo de data/hora de início do trabalho).
  2. Inicie a replicação.
  3. Execute o copyTable novamente com starttime igual ao starttime anotado na etapa 1.

Isto também envolve alguns dados sendo empurrados para frente e para trás entre os dois clusters; mas minimiza seu tamanho.

Tolerância a falhas

Failover do servidor da região do cluster mestre
 Todos os servidores de região no cluster mestre criam um znode em “/hbase/replication/rs”, conforme mencionado na seção Arquitetura. Um regionserver adiciona um znode filho para cada WAL, com um deslocamento de byte sob seu znode na hierarquia de replicação, conforme mostrado na Figura 1. znode do servidor de regiões. Todos os servidores de região ficam de olho em outros znodes de servidor de região (“/hbase/rs”) znode; portanto, quando um servidor de região falhar, outros servidores de região receberão o evento como master marca este servidor de região como morto. Nesse caso, todos os outros servidores de regiões correm para transferir os WALs do znode do servidor de regiões morto para seu znode e anexam um prefixo a ele com o ID do escravo e o nome do servidor de regiões morto, a fim de distinguir de outros logs normais. Uma fonte de replicação separada (instância NodeFailoverWorker) é instanciada para os logs transferidos, que morre após o processamento desses logs transferidos.

Se considerarmos a Figura 1 da Visão geral da replicação do HBase como a figura base da hierarquia de znodes de replicação, a Figura 2. mostra a nova hierarquia de znodes de replicação caso o servidor foo1.bar.com morra e foo2.bar.com assuma sua fila. Observe o novo znode “1-foo1.bar.com,40020,1339435481973” que é criado em foo2.bar.com znode

/hbase/hbaseid:b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo2.bar.com,40020,1339435481973:/hbase/rs/foo3.bar.com,40020,1339435486713:/hbase/replication:/hbase/replication/state:true /hbase/replication/peers:/hbase/replication/peers/1:zk.quorum.slave:281:/hbase /hbase/replication/rs:/hbase/replication/rs/foo1.bar.com.com,40020,1339435084846:/hbase/replication/ rs/foo1.bar.com,40020,1339435481973/1:/hbase/replication/rs/foo1.bar.com,40020, 1339435481973/1/foo1.bar.com.1339435485769:1243232 /hbase/replication/rs/foo3 .bar.com,40020,1339435481742:/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1:/hbase/replication/rs/foo3.bar.com,40020, 1339435481742/1/foo3.bar ..com.1339435485769:1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550:/hbase/replication/rs/foo2.bar.com,40020,1339435481742/1:/hbase/replication/rs/ foo2.bar.com,40020, 1339435481742/1/foo2.bar..com.13394354343443:1909033 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1-foo1.bar.com,40020,133943548197/1-foo1.bar.com,40020,133943548197 /foo1.bar.com.1339435485769:1243232

Figura 2. Hierarquia de znodes de failover do servidor de regiões

Enquanto isso, a divisão de logs pode ser iniciada e pode arquivar os logs do servidor da região morta. A fonte de replicação procura os logs no diretório regular e arquivado.

Cluster escravo lento/sem resposta (ou servidores de região)
 Quando um cluster escravo estiver inativo ou se houver uma partição de rede temporária, os logs que ainda não foram replicados para o escravo não serão excluídos pelo limpador de log do HBase.

A limpeza de log é feita pela classe LogCleaner, que continua em execução após um tempo configurado. O código de replicação adiciona o plug-in ReplicationLogCleaner à classe LogCleaner. Quando o último tenta excluir um log específico, o ReplicationLogCleaner verificará se esse log existe na hierarquia de znode de replicação (sob o /hbase/replication/rs/ znode). Se o log for encontrado, significa que o log ainda não foi replicado e ignorará sua exclusão. Depois que o log for replicado, seu znode será excluído da hierarquia de replicação. Em sua próxima execução, o LogCleaner excluirá o arquivo de log com sucesso assim que for replicado.

Verificação


Para uma quantidade menor de dados, pode-se simplesmente procurar as linhas da tabela usando o shell hbase no cluster escravo para verificar se elas são replicadas ou não. Uma maneira padrão de verificar é executar o trabalho checkrep mapreduce, que vem com o HBase. Ele deve ser executado no cluster mestre e exigir clusterId escravo e o nome da tabela de destino. Também é possível fornecer argumentos adicionais, como timestamp de início/parada e famílias de colunas. Ele imprime dois contadores, GOODROWS e BADROWS, significando o número de linhas replicadas e não replicadas, respectivamente.

Métricas de replicação


A estrutura de replicação expõe algumas métricas úteis que podem ser usadas para verificar o progresso da replicação. Alguns dos importantes são:
  1. sizeOfLogQueue:número de HLogs a serem processados ​​(exclui aquele que está sendo processado) na origem da replicação
  2. shippedOpsRate:taxa de mutações enviadas
  3. logEditsReadRate:taxa de mutações lidas de HLogs na origem de replicação
  4. ageOfLastShippedOp:idade do último lote enviado pela origem de replicação

Trabalho futuro

Com todos os recursos atuais presentes na replicação atual do HBase,  ainda há espaço para melhorias. Varia desde o desempenho, como diminuir o atraso de replicação entre mestre e escravo, até um tratamento mais robusto de falha do servidor regional (HBase-2611). Outras áreas de aprimoramento incluem habilitar a replicação de tabela em nível de peer e o manuseio adequado de IncrementColumnValue (HBase-2804).

Conclusão
 Esta postagem discutiu a replicação do HBase do ponto de vista de um operador, incluindo configuração (de vários modos), inicialização de um cluster existente, efeitos de alterações de esquema e tolerância a falhas.