Enterprise Server 3.20 actualmente está disponible como versión candidata para lanzamiento.

Diferir la carga inicial 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 más información, consulta 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

Nota:

La capacidad de aplazar la propagación de la base de datos está disponible como una versión preliminar 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 inicialización de la base de datos, permitiendo que el proceso de aplicación de la configuración se complete más rápido, lo que permite que su sistema esté disponible para el 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 inicializació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 nodo en el clúster, desde el shell administrativo del nodo con el cluster.conf modificado, ejecute ghe-cluster-config-init.

  5. Para validar el archivo de configuración y también copiar y configurar cada nodo de acuerdo con 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.