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, consulte "Configuración de la alta disponibilidad de 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, consulte "Configuración de la alta disponibilidad de un clúster".
Iniciar una conmutación por error a tu clúster de réplica
-
Ingresa por SSH en cualquier nodo pasivo en el datacenter secundario para tu clúster. Para obtener más información, consulte "Acceso al shell administrativo (SSH)".
-
Inicializa la conmutación por error al clúster secundario y configúrala para que se comporte como los nodos activos.
ghe-cluster-failover -
Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.
Finished cluster configuration -
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.