Reemplazar un nodo de agrupación

Acerca del reemplazo de nodos de GitHub Enterprise Server clúster

Puede reemplazar un nodo funcional en un GitHub Enterprise Server clúster o puede reemplazar un nodo que ha fallado inesperadamente.

Después de reemplazar un nodo, tu instancia de GitHub Enterprise Server no distribuye automáticamente los trabajos al nuevo nodo. Puedes forzar que la instancia distribuya los trabajos entre los nodos. Para más información, consulta Reequilibrio de las cargas de trabajo del clúster.

Advertencia

Para evitar conflictos, no reutilices un nombre de host asignado previamente a un nodo del clúster.

Reemplazar un nodo funcional

Puedes reemplazar un nodo funcional existente en el clúster. Por ejemplo, puede que desee proporcionar a una máquina virtual (VM) recursos adicionales de CPU, memoria o almacenamiento.

Para reemplazar un nodo funcional, instale el GitHub Enterprise Server dispositivo en una nueva máquina virtual, configure una dirección IP, agregue el nuevo nodo al archivo de configuración del clúster, inicialice el clúster y aplique la configuración y, a continuación, quite el nodo que ha reemplazado sin conexión.

Nota:

Si vas a reemplazar el nodo principal de la base de datos, consulta Reemplazo del nodo principal de la base de datos.

Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.
Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.
Para agregar el nodo de reemplazo recién aprovisionado, en cualquier nodo, cluster.conf para quitar el nodo con error y agregar el de reemplazo. Por ejemplo, este archivo cluster.conf modificado reemplaza ghe-data-node-3 por el nodo recién aprovisionado, ghe-replacement-data-node-3:
```
[cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
```
Puede optar por diferir la propagación de la base de datos de un nuevo nodo de réplica de MySQL, lo que da lugar a que el dispositivo pueda abrir el dispositivo antes al tráfico. Para más información, consulta Diferir la carga inicial de la base de datos.
Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.
En el mismo nodo, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo del clúster y configurará cada nodo según el archivo cluster.conf modificado.
Para desconectar el nodo que va a reemplazar, ejecute el siguiente comando desde el nodo principal de MySQL del clúster.
```
ghe-remove-node NODE-HOSTNAME
```
Este comando evacuará los datos de los servicios de datos que se ejecutan en el nodo, marcará el nodo como sin conexión en la configuración y detendrá el tráfico que se enruta al nodo. Para más información, consulta Utilidades de la línea de comandos.

Reemplazar un nodo en una emergencia

Puedes reemplazar un nodo con errores en el clúster. Por ejemplo, un problema de software o hardware puede afectar a la disponibilidad de un nodo.

Nota:

Si vas a reemplazar el nodo principal de la base de datos, consulta Reemplazo del nodo principal de la base de datos.

Para reemplazar un nodo de emergencia, desconecte el nodo con errores, agregue el nodo de reemplazo al clúster y, a continuación, ejecute comandos para quitar las referencias a los servicios de datos en el nodo quitado.

Para quitar el nodo que experimenta problemas del clúster, ejecute el siguiente comando desde el nodo principal de MySQL del clúster. Reemplace NODE-HOSTNAME por el nombre de host del nodo que se va a desconectar.
```
ghe-remove-node --no-evacuate NODE-HOSTNAME
```
Este comando marcará el nodo como sin conexión en la configuración y detendrá el tráfico que se enruta al nodo. Puede ejecutar este comando en modo no-evacuate ahora porque, más adelante en este procedimiento, ejecutará comandos que indican a los servicios de datos en el nodo que copien las réplicas en los otros nodos disponibles del clúster. Para más información, consulta Utilidades de la línea de comandos.
Agregue el nodo de reemplazo al clúster.
1. Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.
2. Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.
3. Para agregar el nodo de reemplazo recién aprovisionado, en cualquier nodo, modifique el archivo cluster.conf para agregar el nodo de reemplazo. Por ejemplo, este archivo cluster.conf modificado agrega el nodo recién aprovisionado ghe-replacement-data-node-3:
```
[cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
```
4. Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.
5. En el mismo nodo, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo del clúster y configurará cada nodo según el archivo cluster.conf modificado.
Quite las referencias a los servicios de datos en el nodo que ha quitado.
1. Busque el UUID del nodo que ha quitado. Para buscar el UUID, ejecute el comando siguiente, reemplazando HOSTNAME por el nombre de host del nodo. Usará este UUID en el paso siguiente.
```
ghe-config cluster.HOSTNAME.uuid
```
2. Para quitar referencias a los servicios de datos, ejecute los siguientes comandos. Reemplace UUID por el UUID del nodo.
  
  Estos comandos indican a cada servicio que el nodo se quita permanentemente. Los servicios volverán a crear las réplicas contenidas en el nodo en los nodos disponibles del clúster.
  
  Nota:
  
  Estos comandos pueden provocar un aumento de la carga en el servidor mientras los datos se reequilibran entre réplicas.
  
  Para el servicio git-server (se usa para los datos del repositorio):
```
ghe-spokesctl server destroy git-server-UUID
```
  Para el pages-server servicio (usado para compilaciones del GitHub Pages sitio):
```
ghe-dpages remove pages-server-UUID
```
  Para el servicio storage-server (se usa para datos de Git LFS, imágenes de avatar, archivos adjuntos y archivos de versión):
```
ghe-storage destroy-host storage-server-UUID --force
```
Opcionalmente, elimine la entrada del nodo quitado en el archivo cluster.conf. Si lo hace, mantendrá el archivo cluster.conf organizado y ahorrará tiempo durante futuras ejecuciones config-apply.
1. Para quitar la entrada del archivo, ejecute el siguiente comando y reemplace HOSTNAME por el nombre de host del nodo quitado.
```
ghe-config --remove-section "cluster.HOSTNAME"
```
2. Para copiar la configuración en otros nodos del clúster, desde el shell administrativo del nodo donde modificó cluster.conf, ejecute ghe-cluster-config-apply.

Reemplazo del nodo de la base de datos principal (MySQL o MySQL y MSSQL)

Para proporcionar servicios de base de datos, su clúster requiere un nodo MySQL primario y al menos un nodo MySQL réplica. Para más información, consulta Acerca de los nodos de agrupación.

Si el clúster tiene GitHub Actions habilitado, también tendrá que tener en cuenta MSSQL en los siguientes pasos.

Si necesitas asignar más recursos al nodo principal de MySQL (o MySQL y MSSQL) o reemplazar un nodo con errores, puedes agregar un nuevo nodo al clúster. Para minimizar el tiempo de inactividad, agrega el nuevo nodo, replica los datos de MySQL (o MySQL y MSSQL) y, a continuación, promuévelo al nodo principal. Se requiere algún tiempo de inactividad durante el proceso de promoción.

Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.
Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.
Para conectarte a tu instancia de GitHub Enterprise Server, accede mediante SSH a cualquiera de los nodos del clúster. En la estación de trabajo, ejecuta el siguiente comando. Reemplaza HOSTNAME por el nombre de host del nodo. Para más información, consulta Acceder al shell administrativo (SSH).
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
Abra el archivo de configuración del clúster en /data/user/common/cluster.conf en un editor de texto. Por ejemplo, puedes utilizar Vim. Cree una copia de seguridad del archivo cluster.conf antes de editarlo.
Shell
```
sudo vim /data/user/common/cluster.conf
```
```
sudo vim /data/user/common/cluster.conf
```

       En el archivo de configuración del clúster se enumera cada nodo bajo un título <code>[cluster "<em>HOSTNAME</em>"]</code>. Agregue un nuevo encabezado para el nodo y escriba los pares clave-valor para la configuración, reemplazando los marcadores de posición por valores reales.

Asegúrese de incluir el par clave-valor mysql-server = true.
Si GitHub Actions está habilitado en el clúster, tendrá que incluir también el mssql-server = true par clave-valor.
La siguiente sección es un ejemplo y la configuración del nodo puede diferir.

...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...

Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.
Desde el shell administrativo del nodo donde ha modificado cluster.conf, ejecute ghe-cluster-config-apply. El nodo recién agregado se convertirá en un nodo mySQL de réplica y cualquier otro servicio configurado se ejecutará allí.

Nota:

El fragmento de código anterior no asume que GitHub Actions está habilitado en el clúster.
Espere a que finalice la replicación de MySQL. Para supervisar la replicación de MySQL desde cualquier nodo del clúster, ejecute ghe-cluster-status -v.

Si GitHub Actions está habilitado en el clúster, tendrá que esperar a que se complete la replicación de MSSQL.

Poco después de agregar el nodo al clúster, es posible que vea un error para el estado de replicación mientras la replicación se actualice. La replicación puede tardar horas en función de la carga de la instancia, la cantidad de datos de la base de datos y la última vez que la instancia generó una semilla de base de datos.
Durante la ventana de mantenimiento programado, habilite el modo de mantenimiento. Para más información, consulta Habilitar y programar el modo de mantenimiento.
Asegúrate de que la replicación de MySQL (o MySQL y MSSQL) haya finalizado desde cualquier nodo del clúster mediante la ejecución de ghe-cluster-status -v.

Advertencia

Si no esperas a que finalice la replicación de MySQL (o MySQL y MSSQL), corres el riesgo de pérdida de datos en la instancia.
Para establecer el nodo principal de MySQL actual en modo de solo lectura, ejecuta el siguiente comando desde el nodo principal de MySQL.
Shell
```
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
```
```
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
```
Espere hasta que los Identificadores Globales de Transacción (GTIDs) establecidos en los nodos MySQL primario y réplica sean idénticos. Para comprobar los GTID, ejecute el siguiente comando desde cualquier nodo de clúster.
Shell
```
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
```
```
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
```
- Para comprobar que la variable global de MySQL se estableció correctamente, ejecuta el siguiente comando.
Shell
```
 echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
```
```
 echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
```
Si GitHub Actions está habilitado en el clúster, conéctese por SSH al nodo que se convertirá en el nuevo principal de MSSQL.
Shell
```
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
```
```
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
```
- Desde una sesión de screen ejecuta el siguiente comando para promover MSSQL al nuevo nodo.
Shell
```
/usr/local/share/enterprise/ghe-mssql-repl-promote
```
```
/usr/local/share/enterprise/ghe-mssql-repl-promote
```
Se intentará acceder al nodo MSSQL principal actual y ejecutar una conmutación por error sin interrupciones
Después de que los GTID de los nodos MySQL principal y réplica coincidan, actualice la configuración del clúster al abrir el archivo de configuración del clúster en /data/user/common/cluster.conf en un editor de texto.
- Cree una copia de seguridad del archivo cluster.conf antes de editarlo.
- En la sección de nivel superior [cluster], elimine el nombre de host del nodo que ha reemplazado del par clave-valor mysql-master y, a continuación, asigne el nuevo nodo en su lugar. Si el nuevo nodo también es uno principal de Redis, ajuste el par clave-valor redis-master.
- Si GitHub Actions está habilitado en el clúster, también tendrá que incluir el par clave-valor mssql-server = true.
```
[cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...
```
Desde el shell administrativo del nodo donde has modificado cluster.conf, inicia una sesión de screen y ejecuta ghe-cluster-config-apply. Este comando vuelve a configurar el clúster, lo que promueve el nodo recién agregado al nodo mySQL principal y convierte el nodo mySQL principal original en una réplica.

Nota:

El fragmento de código anterior no supone que GitHub Actions esté habilitado en el clúster.
Si GitHub Actions está habilitado en el clúster, ejecute el siguiente comando desde el nuevo nodo MySQL y MSSQL.
Shell
```
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
```
```
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
```
Revisa el estado de la replicación de MySQL (o MySQL y MSSQL) desde cualquier nodo del clúster mediante la ejecución de ghe-cluster-status -v.
Cuando finalice la replicación de MySQL (o MySQL y MSSQL), deshabilita el modo de mantenimiento desde cualquier nodo del clúster. Consulta Habilitar y programar el modo de mantenimiento.

¿Quién puede utilizar esta característica?

En este artículo

Acerca del reemplazo de nodos de GitHub Enterprise Server clúster

Reemplazar un nodo funcional

Reemplazar un nodo en una emergencia

Reemplazo del nodo de la base de datos principal (MySQL o MySQL y MSSQL)