Esta es la segunda publicación de blog sobre la replicación de Apache HBase. La publicación de blog anterior, Descripción general de la replicación de HBase, analizó los casos de uso, la arquitectura y los diferentes modos admitidos en la replicación de HBase. Esta publicación de blog es desde una perspectiva operativa y abordará la configuración de replicación de HBase y los conceptos clave para usarla, como arranque, cambio de esquema y tolerancia a fallas.
Configuración
Como se mencionó en Descripción general de la replicación de HBase, el clúster maestro envía envíos de WALEdits a uno o más clústeres esclavos. Esta sección describe los pasos necesarios para configurar la replicación en modo maestro-esclavo.
- Todas las familias de tablas/columnas que se van a replicar deben existir en ambos clústeres.
- Agregue la siguiente propiedad en $HBASE_HOME/conf/hbase-site.xml en todos los nodos de ambos clústeres; establecerlo en verdadero.
hbase.replicación
verdadero
En el clúster principal, realice los siguientes cambios adicionales:
- Establecer ámbito de replicación (REPLICATION_SCOPE atributo) en la tabla/familia de columnas que se va a replicar:
hbase shell> desactivar 'tabla'
hbase shell> alter 'table', {NAME => 'column-family', REPLICATION_SCOPE => 1}
hbase shell> habilitar 'tabla'
REPLICATION_SCOPE es un atributo de nivel de familia de columnas y su valor puede ser 0 o 1. Un valor de 0 significa que la replicación está deshabilitada y 1 significa que la replicación está habilitada. Un usuario tiene que modificar cada familia de columnas con el comando alter como se muestra arriba, para todas las familias de columnas que desea replicar.
Si un usuario desea habilitar la replicación mientras crea una tabla, debe usar el siguiente comando:
hbase shell> crear 'tabla', 'columna-familia1', 'columna-familia2', {NOMBRE => 'columna-familia1', REPLICATION_SCOPE => 1}
El comando anterior habilitará la replicación en 'column-family1' de la tabla anterior.
2. En el shell de hbase, agregue el par esclavo. Se supone que un usuario debe proporcionar el quórum zookeeper del clúster esclavo, su puerto de cliente y el znode hbase raíz, junto con un peerId:
hbase shell>add_peer ‘peerId’, “::”
El peerId es una cadena de uno o dos caracteres de largo, y se crea un znode correspondiente bajo el znode de pares, como se explicó en el blog anterior. Una vez que un usuario ejecuta el comando add_peer, el código de replicación crea una instancia de un objeto ReplicationSource para ese par, y todos los servidores regionales del clúster maestro intentan conectarse a los servidores regionales del clúster esclavo. También obtiene el ClusterId del clúster esclavo (UUID, registrado en el quórum del cuidador del zoológico del clúster esclavo). El servidor de regiones del clúster maestro enumera los servidores de regiones disponibles del esclavo leyendo "/hbase/rs" znode y sus hijos en el quórum zookeeper del clúster esclavo, y se conecta a él. Cada servidor de regiones en el clúster maestro elige un subconjunto de los servidores de regiones esclavos, según la proporción especificada por "replication.source.ratio", con el valor predeterminado 0.1. Esto significa que cada servidor regional del clúster maestro intentará conectarse al 10 % del total de servidores regionales del clúster esclavo. Al enviar el lote de transacciones, el servidor regional del clúster principal seleccionará un servidor regional aleatorio de estos servidores regionales conectados. (Nota:la replicación no se realiza para tablas de catálogo, .META. y _ROOT_.)
Para configurar un modo maestro-maestro, los pasos anteriores deben repetirse en ambos clústeres.
Cambio de esquema
Como se mencionó en la sección anterior, la tabla replicada y la familia de columnas deben existir en ambos clústeres. Esta sección analiza varios escenarios posibles sobre lo que sucede durante un cambio de esquema cuando la replicación aún está en curso:
a) Eliminar la familia de columnas en el maestro:la eliminación de una familia de columnas no afectará la replicación de las mutaciones pendientes para esa familia. Esto se debe a que el código de replicación lee el WAL y verifica el ámbito de replicación de las familias de columnas para cada WALEdit. Cada WALEdit tiene un mapa de las familias de columnas habilitadas para replicación; la verificación se realiza en toda la familia de columnas de valores clave que constituyen (ya sea que tengan o no alcance). Si está presente en el mapa, se añade al envío. Dado que el objeto WALEdit se crea antes de que se elimine la familia de columnas, su replicación no se verá afectada.
b) Eliminar la familia de columnas en el esclavo:los WALEdits se envían desde el clúster maestro a un servidor de regiones esclavo en particular, que lo procesa como un cliente HBase normal (usando un objeto HTablePool). Debido a que se elimina la familia de columnas, la operación de colocación fallará y esa excepción se generará en el clúster de servidores regionales principal.
Iniciar/Detener replicación
Los comandos de inicio/parada funcionan como un interruptor de emergencia. Cuando se ejecuta el comando stop_replication en el shell de HBase, cambiará el valor de /hbase/replication/state a falso. Evitará que todos los objetos de origen de replicación lean los registros; pero se enviarán las entradas de lectura existentes. Si un usuario usa el comando detener la replicación, los registros recién transferidos no se pondrán en cola para la replicación. De manera similar, emitir un comando start_replication iniciará la replicación desde el WAL actual (que puede contener algunas transacciones anteriores), y no desde el momento en que se emitió el comando.
La figura 1 explica el comportamiento del interruptor de inicio y parada, donde la secuencia de eventos fluye en la dirección de las flechas.
Compatibilidad de versiones
Los servidores regionales del clúster maestro se conectan a los servidores regionales del clúster esclavo como clientes HBase normales. Se aplica la misma regla de compatibilidad en cuanto a si un cliente HBase en la versión xxx es compatible con un servidor HBase en la versión yyy.
En otro punto, dado que la replicación aún está evolucionando (cada vez se le agregan más funcionalidades), un usuario debe conocer las funcionalidades existentes. Por ejemplo, en CDH4, que se basa en la rama HBase 0.92, hay soporte para replicación maestro-maestro y cíclica. La habilitación/deshabilitación de la fuente de replicación a nivel de pares se agrega en la rama HBase 0.94.
Ajuste de botas
La replicación funciona leyendo los WAL de los servidores regionales del clúster maestro. Si un usuario desea replicar datos antiguos, puede ejecutar un comando copyTable (que define la marca de tiempo de inicio y finalización), mientras habilita la replicación. El comando copyTable copiará los datos incluidos en el ámbito de las marcas de tiempo de inicio/finalización, y la replicación se encargará de los datos actuales. El enfoque general se puede resumir como:
- Inicie la replicación (tenga en cuenta la marca de tiempo).
- Ejecute el comando copyTable con una marca de tiempo de finalización igual a la marca de tiempo anterior.
- Dado que la replicación comienza desde el WAL actual, puede haber algunos valores clave que se copian al esclavo mediante trabajos de replicación y copia de tabla. Esto todavía está bien, ya que es una operación idempotente.
En el caso de la replicación maestro-maestro, se debe ejecutar el trabajo copyTable antes de iniciar la replicación. Esto se debe a que si un usuario inicia un trabajo de copyTable después de habilitar la replicación, el segundo maestro volverá a enviar los datos al primer maestro, ya que copyTable no edita el clusterId en los objetos de mutación. El enfoque general se puede resumir como:
- Ejecute el trabajo de copyTable (tenga en cuenta la marca de tiempo de inicio del trabajo).
- Iniciar la replicación.
- Ejecute copyTable de nuevo con una hora de inicio igual a la hora de inicio indicada en el paso 1.
Esto también implica que algunos datos se transfieran de un lado a otro entre los dos clústeres; pero minimiza su tamaño.
Tolerancia a fallos
Conmutación por error del servidor de la región del clúster principal
Todos los servidores regionales en el clúster principal crean un znode en "/hbase/replication/rs", como se menciona en la sección Arquitectura. Un servidor de regiones agrega un znode secundario para cada WAL, con un desplazamiento de bytes debajo de su znode en la jerarquía de replicación, como se muestra en la Figura 1. Si un servidor de regiones falla, otros servidores de regiones deben ocuparse de los registros del servidor de regiones muerto, que se enumeran debajo de ese znode de regionserver. Todos los servidores regionales vigilan otros znodes de servidores regionales ("/hbase/rs") znode; por lo tanto, cuando un servidor de regiones falla, otros servidores de regiones obtendrán el evento como el maestro marca este servidor de regiones como inactivo. En este caso, todos los demás servidores de regiones compiten para transferir los WAL del znode del servidor de regiones muerto a su znode, y adjuntar un prefijo con la identificación del esclavo y el nombre del servidor de regiones muerto, para distinguirlo de otros registros normales. Se crea una instancia de una fuente de replicación separada (instancia de NodeFailoverWorker) para los registros transferidos, que muere después de procesar estos registros transferidos.
Si se considera la Figura 1 de la descripción general de la replicación de HBase como la figura base de la jerarquía de znodes de replicación, la Figura 2 muestra la nueva jerarquía de znodes de replicación en caso de que el servidor foo1.bar.com fallezca y foo2.bar.com se haga cargo de su cola. Tenga en cuenta el nuevo znode "1-foo1.bar.com,40020,1339435481973" que se crea en 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,13819435 /foo1.bar.com.1339435485769:1243232
Figura 2. Jerarquía de znodes de conmutación por error del servidor de regiones
Mientras tanto, la división de registros puede activarse y archivar los registros del servidor de la región inactiva. La fuente de replicación busca los registros tanto en el directorio normal como en el archivado.
Clúster esclavo lento o que no responde (o servidores regionales)
Cuando un clúster esclavo está inactivo, o si hay una partición de red temporal, el limpiador de registros de HBase no eliminará los registros que aún no se hayan replicado en el esclavo.
La limpieza de registros está a cargo de la clase LogCleaner, que continúa ejecutándose después de un tiempo configurado. El código de replicación agrega el complemento ReplicationLogCleaner a la clase LogCleaner. Cuando este último intente eliminar un registro específico, ReplicationLogCleaner buscará si ese registro existe en la jerarquía de znode de replicación (bajo /hbase/replication/rs/znode). Si se encuentra el registro, significa que aún no se ha replicado y se omitirá su eliminación. Una vez que se replica el registro, su znode se eliminará de la jerarquía de replicación. En su próxima ejecución, LogCleaner eliminará el archivo de registro con éxito una vez que se replique.
Verificación
Para una cantidad menor de datos, uno puede simplemente buscar las filas de la tabla usando el shell hbase en el clúster esclavo para verificar si están replicadas o no. Una forma estándar de verificar es ejecutar el trabajo de verificación mapreduce, que viene con HBase. Debe ejecutarse en el clúster maestro y requerir el ID de clúster esclavo y el nombre de la tabla de destino. También se pueden proporcionar argumentos adicionales, como la marca de tiempo de inicio/detención y las familias de columnas. Imprime dos contadores, a saber, GOODROWS y BADROWS, que representan el número de filas replicadas y no replicadas, respectivamente.
Métricas de replicación
El marco de replicación expone algunas métricas útiles que se pueden usar para verificar el progreso de la replicación. Algunos de los más importantes son:
- sizeOfLogQueue:número de HLogs a procesar (excluye el que se está procesando) en la fuente de replicación
- shippedOpsRate:tasa de mutaciones enviadas
- logEditsReadRate:tasa de mutaciones leídas de HLogs en la fuente de replicación
- ageOfLastShippedOp:antigüedad del último lote enviado por la fuente de replicación
Trabajo futuro
Con todas las características actuales presentes en la replicación actual de HBase, todavía hay margen para mejoras adicionales. Varía desde el rendimiento, como la disminución del tiempo de replicación entre el maestro y el esclavo, hasta un manejo más sólido de la falla del servidor de la región (HBase-2611). Otras áreas de mejora incluyen la habilitación de la replicación de tablas a nivel de pares y el manejo adecuado de IncrementColumnValue (HBase-2804).
Conclusión
Esta publicación discutió la replicación de HBase desde el punto de vista de un operador, incluida la configuración (de varios modos), el arranque de un clúster existente, los efectos de los cambios de esquema y la tolerancia a fallas.
