A replicação do Apache HBase é uma maneira de copiar dados de um cluster HBase para um cluster HBase diferente e possivelmente distante. Ele funciona com base no princípio de que as transações do cluster de origem são enviadas para outro cluster. No jargão do HBase, o cluster que faz o push é chamado de mestre e aquele que recebe as transações é chamado de escravo. Esse push de transações é feito de forma assíncrona e essas transações são agrupadas em um tamanho configurável (o padrão é 64 MB). O modo assíncrono incorre em sobrecarga mínima no mestre e as edições de envio em um lote aumentam a taxa de transferência geral.
Esta postagem do blog discute os possíveis casos de uso, a arquitetura subjacente e os modos de replicação do HBase com suporte no CDH4 (que é baseado na versão 0.92). Discutiremos a configuração de replicação, bootstrapping e tolerância a falhas em uma postagem de blog de acompanhamento.
Casos de uso
A replicação do HBase oferece suporte à replicação de dados entre datacenters. Isso pode ser usado para cenários de recuperação de desastres, onde podemos fazer com que o cluster escravo atenda ao tráfego em tempo real caso o site mestre esteja inativo. Como a replicação do HBase não se destina ao failover automático, o ato de alternar do cluster mestre para o escravo para começar a servir o tráfego é feito pelo usuário. Depois, quando o cluster mestre estiver ativo novamente, pode-se fazer um trabalho CopyTable para copiar os deltas para o cluster mestre (fornecendo os carimbos de data/hora de início/parada) conforme descrito na postagem do blog CopyTable.
Outro caso de uso de replicação é quando um usuário deseja executar tarefas MapReduce de carga intensa em seu cluster HBase; pode-se fazê-lo no cluster escravo, tendo uma ligeira diminuição de desempenho no cluster mestre.
Arquitetura
O princípio subjacente da replicação do HBase é reproduzir todas as transações do mestre para o escravo. Isso é feito reproduzindo os WALEdits (entradas de registro de gravação antecipada) nos WALs (log de gravação antecipada) do cluster mestre, conforme descrito na próxima seção. Esses WALEdits são enviados para os servidores da região do cluster escravo, após a filtragem (se uma edição específica tem escopo para replicação ou não) e envio em um tamanho de lote personalizado (o padrão é 64 MB). Caso o WAL Reader chegue ao final do WAL atual, ele enviará quaisquer WALEdits que tenham sido lidos até então. Como esse é um modo assíncrono de replicação, o cluster escravo pode ficar para trás em relação ao mestre em um aplicativo pesado de gravação na ordem de minutos.
WAL/WALEdits/Memstore
No HBase, todas as operações de mutação (Puts/Deletes) são gravadas em um memstore que pertence a uma região específica e também anexadas a um arquivo de log de gravação antecipada (WAL) na forma de um WALEdit. Um WALEdit é um objeto que representa uma transação e pode ter mais de uma operação de mutação. Como o HBase oferece suporte a uma única transação em nível de linha, um WALEdit pode ter entradas para apenas uma linha. Os WALs são rolados repetidamente após um período de tempo configurado (o padrão é 60 minutos) de modo que, a qualquer momento, haja apenas um WAL ativo por servidor de região.
IncrementColumnValue, uma operação CAS (verificar e substituir), também é convertida em Put quando gravada no WAL.
Um memstore é um mapa classificado na memória contendo valores-chave da região de composição; há um memstore por cada família de colunas por região. O memstore é liberado para o disco como um HFile quando atinge o tamanho configurado (o padrão é 64 MB).
A gravação no WAL é opcional, mas é necessária para evitar a perda de dados porque, caso um servidor de região falhe, o HBase pode perder todos os memstores hospedados nesse servidor de região. Em caso de falha do servidor de região, seus WALs são reproduzidos por um processo de divisão de log para restaurar os dados armazenados nos WALs.
Para que a replicação funcione, a gravação em WALs deve estar habilitada.
ID do cluster
Cada cluster HBase tem um clusterID, um tipo de UUID gerado automaticamente pelo HBase. Ele é mantido no sistema de arquivos subjacente (geralmente HDFS) para que não seja alterado entre as reinicializações. Isso é armazenado dentro do znode /hbase/hbaseid. Este id é usado para obter a replicação mestre-mestre/acíclica. Um WAL contém entradas para várias regiões hospedadas no servidor de regiões. O código de replicação lê todos os valores-chave e filtra os valores-chave com escopo para replicação. Ele faz isso observando o atributo da família de colunas do valor-chave e correspondendo-o à estrutura de dados do mapa da família de colunas do WALEdit. No caso de um valor-chave específico ter escopo para replicação, ele edita o parâmetro clusterId do valor-chave para o ID do cluster HBase.
ReplicationSource
O ReplicationSource é um objeto java Thread no processo regionserver e é responsável por replicar entradas WAL para um cluster escravo específico. Ele tem uma fila de prioridade que contém os arquivos de log que devem ser replicados. Assim que um log é processado, ele é removido da fila. A fila de prioridade usa um comparador que compara os arquivos de log com base em seu registro de data e hora de criação (que é anexado ao nome do arquivo de log); portanto, os logs são processados na mesma ordem em que foram criados (os logs mais antigos são processados primeiro). Se houver apenas um arquivo de log na fila de prioridade, ele não será excluído, pois representa o WAL atual.
Função do tratador
O Zookeeper desempenha um papel fundamental na Replicação do HBase, onde gerencia/coordena quase todas as principais atividades de replicação, como registrar um cluster escravo, iniciar/parar a replicação, enfileirar novos WALs, manipular o failover do servidor de regiões, etc. Quorum do Zookeeper (pelo menos 3 ou mais nós) para mantê-lo funcionando o tempo todo. O Zookeeper deve ser executado de forma independente (e não pelo HBase). A figura a seguir mostra uma amostra da estrutura de znodes relacionada à replicação no cluster mestre (o texto após os dois pontos é o data do znode):
/hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68 …. /hbase/rs/foo1.bar.com,40020,1339435481742: /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
Figura 1. Hierarquia de znodes de replicação
De acordo com a Figura 1, há três servidores de região no cluster mestre, a saber, foo[1-3].bar.com. Existem três znodes relacionados à replicação:
- estado :Este znode informa se a replicação está habilitada ou não. Todas as etapas fundamentais (como enfileirar um log recém-rolado em uma fila de replicação, ler um arquivo de log para fazer remessas de WALEdits etc.), verifique esse valor booleano antes do processamento. Isso é definido pela configuração da propriedade “hbase.replication” como true no hbase-conf.xml. Outra maneira de alterar seu valor é usar o comando “iniciar/parar replicação” no shell hbase. Isso será discutido na segunda postagem do blog.
- colegas :Este znode tem os peers/slaves conectados como filhos. Na figura, há um escravo com o peerId =1, e seu valor é a string de conexão (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), onde o Zookeeper_quorum_of_slave é uma lista separada por vírgulas de servidores zookeeper. O nome do znode peerId é o mesmo fornecido ao adicionar um par.
- rs :Este znode contém uma lista de servidores de regiões ativos no cluster mestre. Cada znode do regionserver tem uma lista de WALs que devem ser replicados, e o valor desses znodes de log é nulo (caso o log ainda não esteja aberto para replicação) ou o deslocamento de byte até o ponto em que o log foi lido. O valor de deslocamento de byte para um znode WAL indica o deslocamento de byte do arquivo WAL correspondente até o qual ele foi lido e replicado. Como pode haver mais de um cluster escravo e o progresso da replicação pode variar entre eles (um pode estar inativo, por exemplo), todos os WALs são autocontidos em um znode peerId sob rs. Assim, na figura acima, os znodes WALs estão sob o are /rs//1, onde “1” é o peerId.
Modos de replicação
Existem três modos para configurar a replicação do HBase:
- Mestre-Escravo:neste modo, a replicação é feita em uma única direção, ou seja, as transações de um cluster são enviadas por push para outro cluster. Observe que o cluster escravo é como qualquer outro cluster e pode ter suas próprias tabelas, tráfego etc.
- Mestre-Mestre:Neste modo, a replicação é enviada em ambas as direções, para tabelas diferentes ou iguais, ou seja, ambos os clusters estão atuando como mestre e escravo. No caso de estarem replicando a mesma tabela, pode-se pensar que isso pode levar a um loop sem fim, mas isso é evitado definindo o clusterId de uma Mutação (Put/Delete) para o clusterId do cluster de origem. A Figura 2 explica isso usando dois clusters, a saber, Sol e Terra. Na figura 2, temos dois blocos representando os dois clusters HBase. Eles têm clusterId 100 e 200, respectivamente. Cada um dos clusters possui uma instância de ReplicationSource, correspondente ao cluster escravo para o qual deseja replicar; ele conhece o cluster #Ids de ambos os clusters.
Figura 2. Sol e Terra, dois clusters HBase
Digamos que cluster#Sun receba uma mutação M nova e válida em uma tabela e família de colunas com escopo para replicação em ambos os clusters. Ele terá um clusterID padrão (0L). A instância de origem de replicação ReplicationSrc-E definirá seu cluster#Id igual ao ID do originador (100) e o enviará para cluster#Earth. Quando cluster#Earth recebe a mutação, ele a reproduz e a mutação é salva em seu WAL, conforme o fluxo normal. O cluster#Id da mutação é mantido intacto neste arquivo de log em cluster#Earth. A instância de origem de replicação em cluster#Earth, (ReplicationSrc-S, lerá a mutação e verificará seu cluster#ID com o slaveCluster# (100, igual a cluster#Sun). Como eles são iguais, ele ignorará esta entrada WALEdit. - Cíclico:nesse modo, há mais de dois clusters HBase que participam da configuração da replicação, e é possível ter várias combinações possíveis de mestre-escravo e mestre-mestre configuradas entre quaisquer dois clusters. Os dois acima cobrem bem esses casos; uma situação de canto é quando configuramos um ciclo
Figura 3. Uma replicação circular configurada
A Figura 3. mostra uma configuração de replicação circular, em que cluster#Sun está replicando para cluster#Earth, cluster#Earth está replicando para cluster#Venus e cluster#Venus está replicando para cluster#Sun.
Digamos cluster#Sun recebe uma nova mutação M e tem como escopo a replicação em todos os clusters acima. Ele será replicado para cluster#Earth conforme explicado acima na replicação mestre mestre. A instância de origem de replicação em cluster#Earth, ReplicationSrc-V, lerá o WAL e verá a mutação e a replicará para cluster#Venus. O cluster#Id da mutação é mantido intacto (a partir de cluster#Sun), em cluster#Venus. Nesse cluster, a instância de origem de replicação para cluster#Sun, ReplicationSrc-S, verá que a mutação tem o mesmo clusterId que seu slaveCluster# (a partir de cluster#Sun) e, portanto, pule isso da replicação.
Conclusão
A Replicação HBase é uma funcionalidade poderosa que pode ser usada em um cenário de recuperação de desastres. Ele foi adicionado como um recurso de visualização na versão 0.90 e vem evoluindo junto com o HBase em geral, com adição de funcionalidades como replicação mestre-mestre, replicação acíclica (ambas adicionadas na versão 0.92) e habilitação e desabilitação da replicação em nível de peer (adicionado em 0,94).
Na próxima postagem do blog, discutiremos vários recursos operacionais, como configuração, etc., e outras pegadinhas com o HBase Replication.
