Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Iniciar una tolerancia de fallos a tu aparato de réplica

Puedes tener tolerancia de fallos en un aparato de réplica GitHub Enterprise Server por medio de la línea de comando para mantenimiento y pruebas, o si falla el aparato principal.

El tiempo requerido para la tolerancia de fallos depende de cuánto le tome para impulsar la réplica y redireccionar el tráfico de forma manual. El tiempo promedio varía entre 20 y 30 minutos.

Promover una réplica no configura la replicación para aplicativos existentes automáticamente. Despues de promoverla, si así lo quieres, puedes configurar la replicacion desde el nuevo aplicativo principal hacia uno existente y hacia el aplicativo primario previo.

  1. Si el aplicativo principal está disponible, para permitir que la replicación finalice antes de que cambies tus aplicativos, pon el aplicativo primario en modo de mantenimiento.

    • Pon el aplicativo en modo de mantenimiento.

    • Cuando la cantidad de operaciones activas de Git, consultas de MySQL y jobs de Resque lleguen a cero, espera 30 segundos.

      Note

      Nomad siempre tendrá trabajos en ejecución, incluso en modo de mantenimiento, para que puedas omitir estos trabajos de forma segura.

    • Para comprobar todos los canales de replicación que notifica OK, use el comando ghe-repl-status -vv.

      ghe-repl-status -vv

  2. Habilite el modo de mantenimiento en todos los dispositivos de réplica activa. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

  3. En el dispositivo de réplica al que desea conmutar por error, para detener la replicación y promover el dispositivo de réplica al estado principal, use el comando ghe-repl-promote.

    ghe-repl-promote

    Note

    Si el nodo principal no está disponible, pueden producirse advertencias y tiempos de espera, pero se pueden omitir.

  4. Actualiza el registro de DNS para que apunte a la dirección IP de la réplica. El tráfico es direccionado a la réplica después de que transcurra el período TTL. Si estás utilizando un balanceador de carga, asegúrate de que esté configurado para enviar el tráfico a la réplica.

  5. Notifica a los usuarios que pueden retomar las operaciones normales.

  6. Si se desea, configura una replicación desde el aparato principal nuevo al aparato existente y el principal anterior. Para obtener más información, vea «Acerca de la configuración de alta disponibilidad».

  7. Los aplicativos en los que no pretendas configurar la replicación que eran parte de la configuración de disponibilidad alta antes de la recuperación del fallo deberán eliminarse de dicha configuración de disponibilidad alta a través de UUID.

    • En los dispositivos anteriores, obtenga su UUID mediante cat /data/user/common/uuid.

      cat /data/user/common/uuid

    • En la nueva réplica principal, quite los UUID mediante ghe-repl-teardown. Reemplace UUID por un UUID que ha recuperado en el paso anterior.

      ghe-repl-teardown -u  UUID

Información adicional