Esta versión de GitHub Enterprise se discontinuó el 2021-09-23. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Iniciar una conmutación por error a tu clúster de réplica

Si tu clúster de GitHub Enterprise Server falla, puedes recuperarte del fallo a la réplica pasiva.

Acerca de la conmutación por error a tu clúster de réplica

En caso de que haya una falla en tu datacenter primario, puedes recuperarte de dicho fallo hacia los nodos de réplica en el datacenter secundario si configuras un nodo de réplica pasivo para cada nodo en tu clúster activo.

El tiempo que se requiere para recuperarse del fallo dependerá de qué tanto tiempo se necesite para promover el clúster de réplica manualmente y redirigir así el tráfico.

El promover un clúster de réplica no configura automáticamente la replicación al clúster existente. Después de promover un clúster de réplica, puedes reconfigurar la replicación desde el clúster activo nuevo. Para obtener más información, consulta la sección "Configurar la disponibilidad alta para un clúster".

Prerrequisitos

Para recuperarse de un fallo hacia los nodos de réplica pasivos, debes haber configurado la disponibilidad alta para tu clúster. Para obtener más información, consulta la sección "Configurar la disponibilidad alta para un clúster".

Iniciar una conmutación por error a tu clúster de réplica

  1. Ingresa por SSH en cualquier nodo pasivo en el datacenter secundario para tu clúster. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."

  2. Inicializa la conmutación por error al clúster secundario y configúrala para que se comporte como los nodos activos.

    ghe-cluster-failover
  3. Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.

    Configuración de clúster finalizada
  4. Actualiza elregistro de DNS para que apunte a las direcciones IP del balanceador de carga para tu clúster pasivo. El tráfico es direccionado a la réplica después de que transcurra el período TTL.

Después de que GitHub Enterprise Server te regrese al prompt y de que se hayan propagado las actualizaciones de tu DNS, habrás terminado de recuperarte del fallo. Los usuarios pueden acceder a GitHub Enterprise Server utilizando el nombre de host habitual para tu clúster.