Esta versión de GitHub Enterprise Server se discontinuará el 2024-09-24. 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.

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

Si se produce un error en el clúster de GitHub Enterprise Server, puedes conmutar por error a la réplica.

En este artículo

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

Si el centro de datos del clúster activo experimenta un error y has configurado la alta disponibilidad, puedes conmutar por error al clúster de réplica.

La conmutación por error al clúster de réplica lo promueve al nuevo clúster activo y desacopla el nuevo clúster activo del clúster activo anterior. Los nodos del clúster activo antiguo se colocan en modo de mantenimiento si están en un estado lo suficientemente correcto para que se realice esta operación.

Después de la conmutación por error, tendrás dos clústeres independientes sin alta disponibilidad configurada. Puedes volver a configurar la replicación desde el nuevo clúster activo. Para obtener más información, vea «Configurar la replicación con disponibilidad alta para un clúster».

Requisitos previos

Para conmutar por error a los nodos de réplica, debes haber configurado la replicación de alta disponibilidad para el clúster. Para obtener más información, vea «Configurar la replicación con disponibilidad alta para un clúster».

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

Note

En una instancia de una configuración de clúster, los nodos principales anteriores podían acceder a los nodos recién promocionados después de la migración tras error. Esto se corrigió en la versión de revisión 3.10.10 . Para obtener más información, consulta «Notas de la versión.»

Como resultado de esta corrección, ghe-cluster-failover identifica las direcciones IP que se van a bloquear del clúster principal anterior y las escribe en /data/user/common/cluster-ip-blocklist. Una vez completada la migración tras error, el comando ejecuta ghe-cluster-block-ips para bloquear las direcciones IP en el nuevo clúster activo.

Asimismo, también se introdujeron los comandosghe-cluster-block-ips, ghe-cluster-block-ip, ghe-cluster-unblock-ips y ghe-cluster-unblock-ip en estas versiones de revisión. Con estos comandos, puede controlar manualmente qué direcciones IP pueden acceder al nuevo clúster promocionado y evitar la ejecución de configuración potencialmente larga asociada con la ejecución de todo el comando ghe-cluster-failover. Para obtener más información, vea "Utilidades de la ea de comandos."

SSH al nodo MySQL principal del clúster de réplica. Para obtener más información, vea «Acceder al shell administrativo (SSH)».
Para iniciar la conmutación por error al clúster secundario y configurar los nodos para responder a las solicitudes, ejecuta el siguiente comando.
```
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 el registro de DNS para que apunte a la dirección IP del equilibrador de carga para el clúster de réplica. Una vez expirado el período de TTL, las solicitudes se dirigirán al clúster de réplica.

Una vez que GitHub Enterprise Server te devuelva al símbolo del sistema y las actualizaciones de DNS se propaguen, habrás terminado de conmutar por error. Los usuarios pueden acceder a GitHub Enterprise Server mediante el nombre de host habitual para el clúster.