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

Diferir la propagación de la base de datos

Puede acelerar el proceso de agregar un nuevo nodo de réplica de MySQL al clúster si opta por diferir la propagación de la base de datos.

¿Quién puede utilizar esta característica?

GitHub determina la idoneidad para la agrupación en clústeres y debe habilitar la configuración de la licencia de la instancia. La agrupación en clústeres conlleva una planeación cuidadosa y una sobrecarga administrativa adicional. Para obtener más información, vea «Acerca de las agrupaciones».

En este artículo

Acerca de diferir la propagación de la base de datos de un nodo de réplica de MySQL

Note

Se agregó la capacidad de diferir la propagación de la base de datos en la versión de revisión 3.9.13 y está disponible en versión beta pública.

Agregar un nuevo nodo de réplica de MySQL al clúster cuando el nodo principal tenga más de siete días de datos normalmente desencadenará la propagación de la base de datos que puede tardar varias horas en función de la cantidad de datos. Puede optar por diferir la propagación de la base de datos, lo que permite que la configuración se ejecute antes, con lo que el dispositivo puede abrir el dispositivo al tráfico antes.

Solo debe diferir la propagación de la base de datos si ya ha configurado al menos una réplica de MySQL y va a agregar una réplica de MySQL adicional. De lo contrario, no hay redundancia de MySQL hasta que se complete la propagación.

Al diferir la propagación de la base de datos, la nueva réplica de MySQL no se configurará para la replicación ni tendrá una copia de los datos en el nodo principal de MySQL hasta que la propagación se complete manualmente más adelante.

Configuración del aplazamiento de la propagación de MySQL al agregar un nuevo nodo mySQL

  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. Cree la entrada cluster.conf para el nuevo nodo MySQL e incluya el campo skip-data-setup = true. En el ejemplo siguiente se agrega un nuevo nodo con el nombre de host ghe-data-node-3 y el rol mysql-server.

     ...
 [cluster "ghe-data-node-3"]
   hostname = ghe-data-node-3
   ipv4 = 192.168.0.9
   # ipv6 = fd12:3456:789a:1::7
   mysql-server = true
   skip-data-setup = true
 ...

  4. Para inicializar el nuevo novo en el clúster, desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init.

  5. Para validar el archivo de configuración y copiar en cada nodo del clúster según el archivo cluster.conf modificado, ejecute ghe-cluster-config-apply.

Propagación manual de los datos

Una vez que haya ejecutado ghe-cluster-config-apply, el servicio MySQL se ejecutará en el nuevo nodo, pero no se configurará como una réplica ni se inicializará con datos del nodo principal de MySQL. Para inicializar los datos del nodo principal de MySQL, deberá configurar la replicación manualmente.

  1. Desde el nuevo nodo, para iniciar la replicación manual de los datos del nodo principal de MySQL, ejecute el siguiente comando y reemplace PRIMARY_IP por la dirección IP del nodo que ejecuta la base principal de MySQL.

    /usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP

El tiempo necesario para la propagación de la base de datos depende del tamaño de los datos. Para conjuntos de datos de gran tamaño, se recomienda ejecutar el comando anterior en una sesión screen para asegurarse de que sobrevive a las desconexiones SSH.