Ceci est le deuxième article de blog sur la réplication Apache HBase. Le précédent article de blog, Présentation de la réplication HBase, traitait des cas d'utilisation, de l'architecture et des différents modes pris en charge dans la réplication HBase. Ce billet de blog est d'un point de vue opérationnel et abordera la configuration de la réplication HBase et les concepts clés de son utilisation, tels que l'amorçage, le changement de schéma et la tolérance aux pannes.
Configuration
Comme mentionné dans Présentation de la réplication HBase, le cluster maître envoie des WALEdits à un ou plusieurs clusters esclaves. Cette section décrit les étapes nécessaires pour configurer la réplication en mode maître-esclave.
- Toutes les tables/familles de colonnes à répliquer doivent exister sur les deux clusters.
- Ajoutez la propriété suivante dans $HBASE_HOME/conf/hbase-site.xml sur tous les nœuds des deux clusters ; définissez-le sur vrai.
hbase.replication
vrai
Sur le cluster maître, apportez les modifications supplémentaires suivantes :
- Définir l'étendue de la réplication (REPLICATION_SCOPE attribut) sur la famille de tables/colonnes à répliquer :
hbase shell> désactiver 'table'
hbase shell> alter 'table', {NAME => 'column-family', REPLICATION_SCOPE => 1}
hbase shell> activer 'table'
REPLICATION_SCOPE est un attribut au niveau de la famille de colonnes et sa valeur peut être 0 ou 1. Une valeur de 0 signifie que la réplication est désactivée et 1 signifie que la réplication est activée. Un utilisateur doit modifier chaque famille de colonnes avec la commande alter comme indiqué ci-dessus, pour toutes les familles de colonnes qu'il souhaite répliquer.
Si un utilisateur souhaite activer la réplication lors de la création d'une table, il doit utiliser la commande suivante :
hbase shell> créer 'table', 'column-family1', ''column-family2', {NAME => 'column-family1', REPLICATION_SCOPE => 1}
La commande ci-dessus activera la réplication sur « column-family1 » de la table ci-dessus.
2. Dans le shell hbase, ajoutez l'homologue esclave. Un utilisateur est censé fournir le quorum zookeeper du cluster esclave, son port client et le znode hbase racine, ainsi qu'un peerId :
shell hbase>add_peer 'peerId', "::"
Le peerId est une chaîne d'un ou deux caractères, et un znode correspondant est créé sous le znode des pairs, comme expliqué dans le blog précédent. Une fois qu'un utilisateur exécute la commande add_peer, le code de réplication instancie un objet ReplicationSource pour ce pair, et tous les serveurs de région du cluster maître tentent de se connecter aux serveurs de région du cluster esclave. Il récupère également le ClusterId du cluster esclave (UUID, enregistré sur le quorum zookeeper du cluster esclave). Le serveur de région du cluster maître répertorie les serveurs de région disponibles de l'esclave en lisant le nœud znode "/hbase/rs" et ses enfants sur le quorum zookeeper du cluster esclave, et établit une connexion avec celui-ci. Chaque serveur de région du cluster maître choisit un sous-ensemble parmi les serveurs de région esclaves, en fonction du ratio spécifié par « replication.source.ratio », avec une valeur par défaut de 0,1. Cela signifie que chaque serveur de région du cluster maître tentera de se connecter à 10 % du total des serveurs de région du cluster esclave. Lors de l'envoi du lot de transactions, le serveur de région du cluster maître choisira un serveur de région aléatoire parmi ces serveurs de région connectés. (Remarque :la réplication n'est pas effectuée pour les tables de catalogue, .META. et _ROOT_.)
Pour configurer un mode maître-maître, les étapes ci-dessus doivent être répétées sur les deux clusters.
Changement de schéma
Comme mentionné dans la section précédente, la table répliquée et la famille de colonnes doivent exister dans les deux clusters. Cette section décrit divers scénarios possibles quant à ce qui se passe lors d'un changement de schéma lorsque la réplication est toujours en cours :
a) Supprimer la famille de colonnes dans le maître :la suppression d'une famille de colonnes n'affectera pas la réplication des mutations en attente pour cette famille. En effet, le code de réplication lit le WAL et vérifie la portée de réplication des familles de colonnes pour chaque WALEdit. Chaque WALEdit a une carte des familles de colonnes activées pour la réplication ; la vérification est effectuée sur toute la famille de colonnes de la valeur-clé constitutive (qu'elles soient délimitées ou non). S'il est présent dans la carte, il est ajouté à l'envoi. L'objet WALEdit étant créé avant la suppression de la famille de colonnes, sa réplication ne sera pas affectée.
b) Supprimer la famille de colonnes dans l'esclave :les WALEdits sont expédiés du cluster maître à un serveur de région esclave particulier, qui le traite comme un client HBase normal (à l'aide d'un objet HTablePool). Étant donné que la famille de colonnes est supprimée, l'opération d'insertion échouera et cette exception est levée sur le cluster de serveurs de région maître.
Démarrer/Arrêter la réplication
Les commandes Start/Stop fonctionnent comme un coupe-circuit. Lorsque la commande stop_replication est exécutée sur le shell HBase, elle modifie la valeur de /hbase/replication/state en false. Cela empêchera tous les objets source de réplication de lire les journaux ; mais les entrées lues existantes seront expédiées. Si un utilisateur utilise la commande d'arrêt de la réplication, les journaux nouvellement générés ne seront pas mis en file d'attente pour la réplication. De même, l'émission d'une commande start_replication démarrera la réplication à partir du WAL actuel (qui peut contenir des transactions précédentes), et non à partir du moment où la commande a été émise.
La figure 1 explique le comportement de l'interrupteur marche-arrêt, où la séquence d'événements s'écoule dans le sens des flèches.
Compatibilité des versions
Les serveurs de région du cluster maître se connectent aux serveurs de région du cluster esclave en tant que clients HBase normaux. La même règle de compatibilité s'applique pour savoir si un client HBase sur la version xxx est pris en charge sur un serveur HBase sur la version yyy.
Sur un autre point, la réplication évoluant encore (de plus en plus de fonctionnalités y sont continuellement ajoutées), un utilisateur doit être conscient des fonctionnalités existantes. Par exemple, dans CDH4, qui est basé sur la branche HBase 0.92, il existe un support pour la réplication maître-maître et cyclique. L'activation/désactivation de la source de réplication au niveau homologue est ajoutée dans la branche HBase 0.94.
Boot strapping
La réplication fonctionne en lisant les WAL des serveurs de région du cluster maître. Si un utilisateur souhaite répliquer d'anciennes données, il peut exécuter une commande copyTable (définissant l'horodatage de début et de fin), tout en activant la réplication. La commande copyTable copiera les données délimitées par les horodatages de début/fin, et la réplication prendra soin des données actuelles. L'approche globale peut être résumée comme suit :
- Démarrez la réplication (notez l'horodatage).
- Exécutez la commande copyTable avec un horodatage de fin égal à l'horodatage ci-dessus.
- Étant donné que la réplication démarre à partir du WAL actuel, certaines valeurs-clés peuvent être copiées sur l'esclave à la fois par les tâches de réplication et de copyTable. C'est toujours acceptable, car il s'agit d'une opération idempotente.
Dans le cas d'une réplication maître-maître, il convient d'exécuter la tâche copyTable avant de démarrer la réplication. En effet, si un utilisateur démarre une tâche copyTable après avoir activé la réplication, le deuxième maître renverra les données au premier maître, car copyTable ne modifie pas le clusterId dans les objets de mutation. L'approche globale peut être résumée comme suit :
- Exécutez la tâche copyTable (notez l'horodatage de début de la tâche).
- Démarrez la réplication.
- Exécutez à nouveau copyTable avec une heure de début égale à l'heure de début notée à l'étape 1.
Cela implique également que certaines données soient poussées dans les deux sens entre les deux clusters ; mais il minimise sa taille.
Tolérance aux pannes
Basculement du serveur de la région du cluster maître
Tous les serveurs de région du cluster maître créent un znode sous "/hbase/replication/rs", comme mentionné dans la section Architecture. Un serveur de région ajoute un znode enfant pour chaque WAL, avec un décalage d'octet sous son znode dans la hiérarchie de réplication, comme illustré à la figure 1. Si un serveur de région échoue, les autres serveurs de région doivent prendre en charge les journaux du serveur de région mort, qui sont répertoriés sous ce znode de regionserver. Tous les serveurs de région surveillent les autres znodes de serveur de région ("/hbase/rs") znode ; Ainsi, lorsqu'un serveur de région tombe en panne, les autres serveurs de région reçoivent l'événement car le maître marque ce serveur de région comme mort. Dans ce cas, tous les autres serveurs de région s'empressent de transférer les WAL du znode de serveur de région mort vers leur znode, et lui attachent un préfixe avec l'identifiant de l'esclave et le nom du serveur de région mort, afin de se distinguer des autres journaux normaux. Une source de réplication distincte (instance NodeFailoverWorker) est instanciée pour les journaux transférés, qui meurt après le traitement de ces journaux transférés.
Si l'on considère la figure 1 de la vue d'ensemble de la réplication HBase comme la figure de base de la hiérarchie des znodes de réplication, la figure 2 montre la nouvelle hiérarchie des znodes de réplication au cas où le serveur foo1.bar.com meurt et foo2.bar.com reprend sa file d'attente. Notez le nouveau znode "1-foo1.bar.com,40020,1339435481973" qui est créé sous 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,1339435481973 /foo1.bar.com.1339435485769 :1243232
Figure 2. Hiérarchie des znodes de basculement du serveur de région
Pendant ce temps, le fractionnement des journaux peut se déclencher et peut archiver les journaux du serveur de la région morte. La source de réplication recherche les journaux dans le répertoire normal et archivé.
Cluster esclave lent/ne répondant pas (ou serveurs de région)
Lorsqu'un cluster esclave est arrêté ou s'il existe une partition réseau temporaire, les journaux qui ne sont pas encore répliqués sur l'esclave ne seront pas supprimés par le nettoyeur de journaux HBase.
Le nettoyage des journaux est géré par la classe LogCleaner, qui continue de s'exécuter après une durée configurée. Le code de réplication ajoute le plug-in ReplicationLogCleaner à la classe LogCleaner. Lorsque ce dernier essaie de supprimer un journal spécifique, ReplicationLogCleaner vérifie si ce journal existe dans la hiérarchie du znode de réplication (sous le /hbase/replication/rs/znode). Si le journal est trouvé, cela signifie que le journal n'a pas encore été répliqué et qu'il ignorera sa suppression. Une fois le journal répliqué, son znode sera supprimé de la hiérarchie de réplication. Lors de sa prochaine exécution, LogCleaner supprimera le fichier journal avec succès une fois qu'il sera répliqué.
Vérification
Pour une plus petite quantité de données, on peut simplement rechercher les lignes de la table à l'aide du shell hbase sur le cluster esclave pour vérifier si elles sont répliquées ou non. Une méthode standard de vérification consiste à exécuter le travail de mapreduce de verificationrep, fourni avec HBase. Il doit être exécuté sur le cluster maître et nécessiter l'ID de cluster esclave et le nom de la table cible. On peut également fournir des arguments supplémentaires tels que l'horodatage de début/d'arrêt et les familles de colonnes. Il imprime deux compteurs, à savoir GOODROWS et BADROWS, indiquant respectivement le nombre de lignes répliquées et non répliquées.
Métriques de réplication
Le cadre de réplication expose certaines métriques utiles qui peuvent être utilisées pour vérifier la progression de la réplication. Certains des plus importants sont :
- sizeOfLogQueue :nombre de HLogs à traiter (exclut celui qui est en cours de traitement) à la source de réplication
- shippedOpsRate :taux de mutations expédiées
- logEditsReadRate :taux de mutations lues à partir des HLogs à la source de réplication
- ageOfLastShippedOp :âge du dernier lot expédié par la source de réplication
Travail futur
Avec toutes les fonctionnalités actuelles présentes dans la réplication HBase actuelle, il y a encore place à l'amélioration. Cela varie des performances telles que la réduction du délai de réplication entre le maître et l'esclave, à une gestion plus robuste de la défaillance du serveur de région (HBase-2611). D'autres domaines d'amélioration incluent l'activation de la réplication de table au niveau homologue et la gestion appropriée de IncrementColumnValue (HBase-2804).
Conclusion
Cet article traite de la réplication HBase du point de vue d'un opérateur, y compris la configuration (de différents modes), l'amorçage d'un cluster existant, les effets des modifications de schéma et la tolérance aux pannes.
