Apache HBase Replication es una forma de copiar datos de un clúster HBase a un clúster HBase diferente y posiblemente distante. Funciona según el principio de que las transacciones del clúster de origen se envían a otro clúster. En la jerga de HBase, el clúster que realiza la inserción se denomina maestro y el que recibe las transacciones se denomina esclavo. Esta inserción de transacciones se realiza de forma asincrónica, y estas transacciones se agrupan en lotes en un tamaño configurable (el valor predeterminado es 64 MB). El modo asincrónico incurre en una sobrecarga mínima en el maestro y el envío de ediciones en un lote aumenta el rendimiento general.
Esta publicación de blog analiza los posibles casos de uso, la arquitectura subyacente y los modos de replicación de HBase compatibles con CDH4 (que se basa en 0.92). Discutiremos la configuración de replicación, el arranque y la tolerancia a fallas en una publicación de blog de seguimiento.
Casos de uso
La replicación de HBase admite la replicación de datos entre centros de datos. Esto se puede usar para escenarios de recuperación de desastres, donde podemos hacer que el clúster esclavo sirva tráfico en tiempo real en caso de que el sitio maestro esté inactivo. Dado que la replicación de HBase no está diseñada para la conmutación por error automática, el usuario realiza el acto de cambiar del clúster maestro al esclavo para comenzar a atender el tráfico. Luego, una vez que el clúster principal vuelve a estar activo, se puede hacer un trabajo de CopyTable para copiar los deltas en el clúster principal (proporcionando las marcas de tiempo de inicio/finalización) como se describe en la entrada de blog de CopyTable.
Otro caso de uso de replicación es cuando un usuario desea ejecutar trabajos MapReduce de carga intensiva en su clúster HBase; uno puede hacerlo en el clúster esclavo mientras sufre una ligera disminución del rendimiento en el clúster maestro.
Arquitectura
El principio subyacente de la replicación HBase es reproducir todas las transacciones del maestro al esclavo. Esto se hace reproduciendo las WALEdits (entradas de registro de escritura anticipada) en las WAL (registro de escritura anticipada) del clúster maestro, como se describe en la siguiente sección. Estos WALEdits se envían a los servidores de la región del clúster esclavo, después del filtrado (ya sea que una edición específica esté o no en el ámbito de la replicación) y se envían en un tamaño de lote personalizado (el valor predeterminado es 64 MB). En caso de que WAL Reader llegue al final del WAL actual, enviará los WALEdit que se hayan leído hasta ese momento. Dado que se trata de un modo de replicación asíncrono, el clúster esclavo puede retrasarse con respecto al maestro en una aplicación con gran cantidad de escritura en el orden de minutos.
WAL/WALEdits/Memstore
En HBase, todas las operaciones de mutación (Puts/Deletes) se escriben en un memstore que pertenece a una región específica y también se adjuntan a un archivo de registro de escritura anticipada (WAL) en forma de WALEdit. Un WALEdit es un objeto que representa una transacción y puede tener más de una operación de mutación. Dado que HBase admite transacciones de nivel de fila única, un WALEdit puede tener entradas para una sola fila. Los WAL se acumulan repetidamente después de un período de tiempo configurado (el valor predeterminado es 60 minutos) de modo que, en un momento dado, solo hay un WAL activo por servidor de región.
IncrementColumnValue, una operación CAS (comprobar y sustituir), también se convierte en Put cuando se escribe en WAL.
Un memstore es un mapa ordenado en memoria que contiene valores clave de la región que lo compone; hay un memstore por cada familia de columnas por región. El almacén de memoria se descarga en el disco como un archivo HF una vez que alcanza el tamaño configurado (el valor predeterminado es 64 MB).
Escribir en WAL es opcional, pero es necesario para evitar la pérdida de datos porque, en caso de que un servidor de región falle, HBase puede perder todas las tiendas de memoria alojadas en ese servidor de región. En caso de falla del servidor regional, sus WAL se reproducen mediante un proceso de división de registros para restaurar los datos almacenados en los WAL.
Para que la replicación funcione, la escritura en WAL debe estar habilitada.
ID de clúster
Cada clúster de HBase tiene un ID de clúster, un tipo de UUID generado automáticamente por HBase. Se mantiene en el sistema de archivos subyacente (generalmente HDFS) para que no cambie entre reinicios. Esto se almacena dentro del znode /hbase/hbaseid. Esta identificación se utiliza para lograr la replicación maestro-maestro/acíclica. Un WAL contiene entradas para varias regiones que están alojadas en el servidor de regiones. El código de replicación lee todos los valores clave y filtra los valores clave que están en el ámbito de la replicación. Para ello, observa el atributo de familia de columnas del valor clave y lo compara con la estructura de datos del mapa de familia de columnas de WALEdit. En el caso de que un valor clave específico esté en el ámbito de la replicación, edita el parámetro clusterId del valor clave al Id. de clúster de HBase.
Fuente de replicación
ReplicationSource es un objeto Thread de Java en el proceso del servidor de regiones y es responsable de replicar las entradas de WAL en un clúster esclavo específico. Tiene una cola de prioridad que contiene los archivos de registro que se van a replicar. Tan pronto como se procesa un registro, se elimina de la cola. La cola de prioridad utiliza un comparador que compara los archivos de registro en función de su marca de tiempo de creación (que se adjunta al nombre del archivo de registro); por lo tanto, los registros se procesan en el mismo orden en que se crearon (los registros más antiguos se procesan primero). Si solo hay un archivo de registro en la cola de prioridad, no se eliminará ya que representa el WAL actual.
Papel del cuidador del zoológico
Zookeeper juega un papel clave en la replicación de HBase, donde administra/coordina casi toda la actividad de replicación principal, como el registro de un clúster esclavo, el inicio/detención de la replicación, la puesta en cola de nuevos WAL, el manejo de la conmutación por error del servidor de regiones, etc. Quórum de Zookeeper (al menos 3 o más nodos) para tenerlo en funcionamiento todo el tiempo. Zookeeper debe ejecutarse de forma independiente (y no por HBase). La siguiente figura muestra una muestra de la estructura de znodes relacionada con la replicación en el clúster maestro (el texto después de los dos puntos es el datos del znodo):
/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. Jerarquía de znodes de replicación
Según la Figura 1, hay tres servidores regionales en el clúster principal, a saber, foo[1-3].bar.com. Hay tres znodes relacionados con la replicación:
- estado :Este znode indica si la replicación está habilitada o no. Todos los pasos fundamentales (como poner en cola un registro recién rodado en una cola de replicación, leer un archivo de registro para realizar envíos de WALEdits, etc.), verifique este valor booleano antes de procesarlo. Esto se establece mediante la configuración de la propiedad "hbase.replication" en verdadero en hbase-conf.xml. Otra forma de alterar su valor es usar el comando "iniciar/detener la replicación" en el shell de hbase. Esto se discutirá en la segunda entrada del blog.
- compañeros :Este znode tiene los pares/esclavos conectados como hijos. En la figura, hay un esclavo con peerId =1, y su valor es la cadena de conexión (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), donde Zookeeper_quorum_of_slave es una lista separada por comas de servidores zookeeper. El nombre del znode peerId es el mismo que se proporcionó al agregar un par.
- rs :este znode contiene una lista de servidores regionales activos en el clúster principal. Cada znode de regionerver tiene una lista de WAL que se van a replicar, y el valor de estos znodes de registro es nulo (en caso de que el registro aún no esté abierto para la replicación) o el byte compensado hasta el punto donde se ha leído el registro. El valor de desplazamiento de bytes para un znode WAL indica el desplazamiento de bytes del archivo WAL correspondiente hasta el cual se ha leído y replicado. Como puede haber más de un clúster esclavo y el progreso de la replicación puede variar entre ellos (por ejemplo, uno puede estar inactivo), todos los WAL están autocontenidos en un znode peerId bajo rs. Por lo tanto, en la figura anterior, los znodos de WAL están bajo /rs//1, donde "1" es el peerId.
Modos de replicación
Hay tres modos para configurar la replicación de HBase:
- Maestro-Esclavo:en este modo, la replicación se realiza en una sola dirección, es decir, las transacciones de un clúster se envían a otro clúster. Tenga en cuenta que el clúster esclavo es como cualquier otro clúster y puede tener sus propias tablas, tráfico, etc.
- Maestro-maestro:en este modo, la replicación se envía en ambas direcciones, para tablas diferentes o iguales, es decir, ambos clústeres actúan como maestros y esclavos. En el caso de que estén replicando la misma tabla, uno puede pensar que puede conducir a un bucle sin fin, pero esto se evita configurando el ID de clúster de una mutación (Poner/Eliminar) en el ID de clúster del clúster de origen. La Figura 2 explica esto mediante el uso de dos grupos, a saber, el Sol y la Tierra. En la figura 2, tenemos dos bloques que representan los dos clústeres de HBase. Tienen clusterId 100 y 200 respectivamente. Cada uno de los clústeres tiene una instancia de ReplicationSource, correspondiente al clúster esclavo al que desea replicar; conoce los ID de clúster de ambos clústeres.
Figura 2. Sol y Tierra, dos clústeres HBase
Digamos que cluster#Sun recibe una mutación M nueva y válida en una familia de tablas y columnas que tiene como alcance la replicación en ambos clusters. Tendrá un ID de clúster predeterminado (0L). La instancia de origen de replicación ReplicationSrc-E establecerá su ID de clúster igual a la ID del originador (100) y lo enviará a la Tierra de clúster. Cuando cluster#Earth recibe la mutación, la reproduce y la mutación se guarda en su WAL, según el flujo normal. El Id. de clúster de la mutación se mantiene intacto en este archivo de registro en cluster#Earth. La instancia de origen de replicación en cluster#Earth (ReplicationSrc-S) leerá la mutación y verificará su ID de clúster con el n.º de clúster esclavo (100, igual a cluster#Sun). Dado que son iguales, omitirá esta entrada de WALEdit.
- Cíclico:en este modo, hay más de dos clústeres de HBase que participan en la configuración de la replicación, y uno puede tener varias combinaciones posibles de configuración maestro-esclavo y maestro-maestro entre dos clústeres cualesquiera. Los dos anteriores cubren bien esos casos; una situación de esquina es cuando hemos configurado un ciclo
Figura 3. Configuración de una réplica circular
La Figura 3. muestra una configuración de replicación circular, donde el clúster#Sol se replica en el clúster#Tierra, el clúster#Tierra se replica en el clúster#Venus y el clúster#Venus se replica en el clúster#Sol.
Digamos que el clúster#Sol recibe una nueva mutación M y tiene como alcance la replicación en todos los grupos anteriores. Se replicará en cluster#Earth como se explicó anteriormente en la replicación maestra maestra. La instancia de fuente de replicación en cluster#Earth, ReplicationSrc-V, leerá el WAL y verá la mutación y la replicará en cluster#Venus. El n.° de identificación del grupo de la mutación se mantiene intacto (a partir del n.° de grupo Sol), en el n.° de grupo Venus. En este clúster, la instancia de origen de la replicación para el clúster n.º Sun, ReplicationSrc-S, verá que la mutación tiene el mismo ID de clúster que su n.º de clúster esclavo (a partir del clúster n.º Sun) y, por lo tanto, omitirá la replicación.
Conclusión
HBase Replication es una potente funcionalidad que se puede utilizar en un escenario de recuperación ante desastres. Se agregó como una función de vista previa en la versión 0.90 y ha ido evolucionando junto con HBase en general, con la adición de funcionalidades como la replicación maestro-maestro, la replicación acíclica (ambas agregadas en 0.92) y la activación y desactivación de la replicación a nivel de pares. (agregado en 0.94).
En la próxima publicación de blog, analizaremos varias funciones operativas, como la configuración, etc., y otros problemas con la replicación de HBase.
