Actualización en línea de Hadoop2.0 sin detener el clúster de Hadoop

Introducción

La actualización continua de HDFS permite actualizar un único nodo hdfs (demonio). Por ejemplo, los nodos de datos se pueden actualizar individualmente sin afectar a los nodos de nombre. viceversa.

potenciar

En la versión hadoop2.0, hdfs admite la función ha de los servicios de nombres y es muy consistente. Estas dos características nos permiten tener la oportunidad de actualizar el clúster hdfs sin cerrar el servicio hdfs. Solo se pueden actualizar los clústeres de alta disponibilidad.
Si hay una nueva función en la nueva versión, y esta función no se puede utilizar en la versión anterior, siga los pasos a continuación:

1. 关闭新功能
2. 升级集群
3. 开启新功能

ps：Rolling update 仅在2.4.0版本以上支持

Un grupo ha tiene dos o más nn y múltiples dn, jn, zkns. Debido a que jns es relativamente estable y en la mayoría de los casos no es necesario actualizarlo al actualizar hdfs. La actualización continua es solo para actualizar nn, dn.
Actualización de un clúster no federal
Suponga que hay dos nodos maestros nn1 y nn2, y que están en estado activo y en espera respectivamente. Los pasos de actualización son los siguientes:

Listo para actualizar

Ejecutar para
hdfs dfsadmin -rollingUpgrade prepare
crear fsimage para la reversión.
el código se muestra a continuación:

        RollingUpgradeInfo startRollingUpgrade() throws IOException {
            checkSuperuserPrivilege(); //检查权限
            checkOperation(OperationCategory.WRITE);
            writeLock();
            try {
              checkOperation(OperationCategory.WRITE);
              long startTime = now();
              if (!haEnabled) { // for non-HA, we require NN to be in safemode
                startRollingUpgradeInternalForNonHA(startTime);
              } else { // for HA, NN cannot be in safemode
                checkNameNodeSafeMode("Failed to start rolling upgrade");
                startRollingUpgradeInternal(startTime);
              }getEditLog().logStartRollingUpgrade(rollingUpgradeInfo.getStartTime());
              if (haEnabled) {
                // roll the edit log to make sure the standby NameNode can tail
                getFSImage().rollEditLog();
              }
            } finally {
              writeUnlock();
            }

            getEditLog().logSync();// 同步jn节点 并且flush jn内存数据
            if (auditLog.isInfoEnabled() && isExternalInvocation()) {
              logAuditEvent(true, "startRollingUpgrade", null, null, null);
            }
            return rollingUpgradeInfo;
          }

correr

hdfs dfsadmin -rollingUpgrade query

Compruebe el estado de las imágenes de reversión hasta que aparezca "Continuar con la actualización progresiva". Indica listo.

  RollingUpgradeInfo queryRollingUpgrade() throws IOException {
    checkSuperuserPrivilege();
    checkOperation(OperationCategory.READ);
    readLock();
    try {
      if (rollingUpgradeInfo != null) {
        boolean hasRollbackImage = this.getFSImage().hasRollbackFSImage();// 有可以回滚的images就返回true
        rollingUpgradeInfo.setCreatedRollbackImages(hasRollbackImage);
      }
      return rollingUpgradeInfo;
    } finally {
      readUnlock();
    }
  }

Actualizar NN activos y en espera

Apague el servicio NN2 y actualice NN2 (si es una instalación de paquete tar, la actualización es para cambiar el directorio. Enlace suave del directorio hadoop a un directorio de versión alta)
开启 NN2 en espera con el
hdfs namenode -rollingUpgrade started.

ps：看了代码 这个hdfs name -rollingUpgrade started 和 hdfs name 一样 (CDH 5.3.3)除了日志处理部分，而且启动的时候 建议添加 nohup & 后台执行

Conmutación por error 切换， NN2: activo NN1 ： en espera ( hdfs haadmin -failover nn1 nn2)
Cierre el servicio de namenode en NN1:hadoop-daemon.sh stop namenode
Actualización del nodo namenode hadoop tar
开启 NN1 en espera con la hdfs namenode -rollingUpgrade startedopción.

Actualizar el nodo Datanode

Seleccione algunos nodos de nodo de datos designados (en el mismo bastidor)

Ejecutar hdfs dfsadmin -shutdownDatanode <DATANODE_HOST:IPC_PORT> upgradeclose datanode
Ejecutar hdfs dfsadmin -getDatanodeInfo <DATANODE_HOST:IPC_PORT>ver estado
Actualizar y reiniciar datanode
Realice el paso 123 en todos los nodos de datos y se completará toda la actualización

Finalizar actualización continua

Ejecutar en el nodo principal
hdfs dfsadmin -rollingUpgrade finalize

Precauciones

jn y nn y dn se separan mejor y no se cruzan, y no se ejecutan en la misma máquina
Haga una copia de seguridad de todos los registros de edición y fsimages en namenode.dir para problemas futuros
Para realizar una reversión o una degradación, consulte el siguiente proceso:

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsRollingUpgrade.html#namenode_-rollingUpgrade

Downgrade without Downtime
In a HA cluster, when a rolling upgrade from an old software release to a new software release is in progress, it is possible to downgrade, in a rolling fashion, the upgraded machines back to the old software release. Same as before, suppose NN1 and NN2 are respectively in active and standby states. Below are the steps for rolling downgrade:

Downgrade DNs
Choose a small subset of datanodes (e.g. all datanodes under a particular rack).
Run “hdfs dfsadmin -shutdownDatanode upgrade” to shutdown one of the chosen datanodes.
Run “hdfs dfsadmin -getDatanodeInfo ” to check and wait for the datanode to shutdown.
Downgrade and restart the datanode.
Perform the above steps for all the chosen datanodes in the subset in parallel.
Repeat the above steps until all upgraded datanodes in the cluster are downgraded.
Downgrade Active and Standby NNs
Shutdown and downgrade NN2.
Start NN2 as standby normally. (Note that it is incorrect to use the “-rollingUpgrade downgrade” option here.)
Failover from NN1 to NN2 so that NN2 becomes active and NN1 becomes standby.
Shutdown and upgrade NN1.
Start NN1 as standby normally. (Note that it is incorrect to use the “-rollingUpgrade downgrade” option here.)
Finalize Rolling Downgrade
Run “hdfs dfsadmin -rollingUpgrade finalize” to finalize the rolling downgrade.
Note that the datanodes must be downgraded before downgrading the namenodes since protocols may be changed in a backward compatible manner but not forward compatible, i.e. old datanodes can talk to the new namenodes but not vice versa.

Downgrade with Downtime
Administrator may choose to first shutdown the cluster and then downgrade it. The following are the steps:

Shutdown all NNs and DNs.
Restore the pre-upgrade release in all machines.
Start NNs with the “-rollingUpgrade downgrade” option.
Start DNs normally.

Enlace original: https://blog.csdn.net/leone911/article/details/51395874