Skip to main content

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.

Problemas conocidos con las actualizaciones de la instancia

Consulta la información general de los problemas que afectan al proceso de actualización de GitHub Enterprise Server, o que afectan a tu instancia después de completar una actualización.

Acerca de los problemas conocidos con las actualizaciones de GitHub Enterprise Server

GitHub es consciente de los siguientes problemas que podrían afectar a las actualizaciones de las nuevas versiones de GitHub Enterprise Server. Para obtener más información, consulta las Notas de la versión de GitHub Enterprise Server.

GitHub recomienda encarecidamente realizar copias de seguridad periódicas de la configuración y los datos de tu instancia. Antes de continuar con cualquier actualización, realiza una copia de seguridad de la instancia y, a continuación, valida la copia de seguridad en un entorno de ensayo. Para obtener más información, vea «Configuración de copias de seguridad en la instancia» y «Configurar una instancia de preparación».

Mayor uso de E/S de la actualización de MySQL 8 en GitHub Enterprise Server 3.9 o versiones posteriores

Si actualizas de GitHub Enterprise Server 3.7 o 3.8 a 3.9 o posterior, una actualización del software de la base de datos en su instancia aumentará la utilización de E/S. En algunos casos, esto puede afectar al rendimiento de la instancia.

GitHub Enterprise Server incluye un servidor de bases de datos MySQL compatible con el motor de almacenamiento de InnoDB. GitHub Enterprise Server 3.8 y versiones anteriores usan MySQL 5.7. En octubre de 2023, Oracle finalizará la compatibilidad ampliada con MySQL 5.7. Para más información, consulta la directiva de soporte técnico de Oracle en el sitio web de soporte técnico de Oracle.

Para garantizar el futuro de GitHub Enterprise Server y proporcionar las últimas actualizaciones de seguridad, correcciones de errores y mejoras de rendimiento, GitHub Enterprise Server 3.9 y versiones posteriores utilizan MySQL 8.0. MySQL 8.0 logra un mayor número de consultas por segundo (QPS) debido a un registro REDO rediseñado. Para obtener más información, consulta Rendimiento de MySQL: registro REDO diseñado 8.0 y escalabilidad de cargas de trabajo de lectura y escritura en el weblog de DimitriK (dim).

Después de actualizar a GitHub Enterprise Server 3.9, si experimentas una degradación inaceptable en el rendimiento de la instancia, puedes recopilar datos del panel de supervisión de la instancia para confirmar el impacto. Puedes intentar mitigar el problema y puedes proporcionar los datos a Soporte de GitHub para ayudar a perfilar y comunicar el impacto real de este cambio.

Advertencia: Debido a la naturaleza de esta actualización, realiza una copia de seguridad de la configuración y los datos de la instancia antes de continuar. Valida la copia de seguridad en un entorno de ensayo. Para obtener más información, vea «Configuración de copias de seguridad en la instancia» y «Configurar una instancia de preparación».

Recopilación de datos de uso de E/S de línea de base antes de la actualización de MySQL

Recopila los datos de línea de base antes de actualizar a GitHub Enterprise Server 3.9 o posterior. Para recopilar datos de línea de base, GitHub recomienda configurar una instancia de ensayo de GitHub Enterprise Server que ejecute 3.7 o 3.8 y restaurar datos de la instancia de producción con GitHub Enterprise Server Backup Utilities. Para obtener más información, vea «Configurar una instancia de preparación» y «Configuración de copias de seguridad en la instancia».

Es posible que no puedas simular la carga que experimenta la instancia en un entorno de producción. Sin embargo, resulta útil si puedes recopilar datos de línea de base al simular patrones de uso del entorno de producción en la instancia de ensayo.

  1. Ve al panel de supervisión de la instancia. Para obtener más información, vea «Acceder al tablero del monitor».

  2. En el panel de supervisión, supervisa los gráficos pertinentes.

    • En "Procesos", supervisa los gráficos de "Operaciones de E/S (IOPS de lectura)" y "Operaciones de E/S (IOPS de escritura)", filtrando por mysqld. Estos gráficos muestran operaciones de E/S para todos los servicios del nodo.
    • En "Almacenamiento", supervisa el gráfico de "Utilización del disco (Dispositivo de datos DEVICE-ID)". Este gráfico muestra la cantidad de tiempo invertido en todas las operaciones de E/S del nodo.

Revisión de los datos de uso de E/S después de la actualización de MySQL

Después de actualizar a GitHub Enterprise Server 3,9, revisa el uso de E/S de la instancia. GitHub recomienda que actualices una instancia de ensayo de GitHub Enterprise Server que ejecute 3.7 o 3.8 que incluya datos restaurados de la instancia de producción, o que restaures los datos de la instancia de producción a una nueva instancia de ensayo que ejecute la versión 3.9. Para obtener más información, vea «Configurar una instancia de preparación» y «Configuración de copias de seguridad en la instancia».

  1. Ve al panel de supervisión de la instancia. Para obtener más información, vea «Acceder al tablero del monitor».

  2. En el panel de supervisión, supervisa los gráficos pertinentes.

    • En "Procesos", supervisa los gráficos de "Operaciones de E/S (IOPS de lectura)" y "Operaciones de E/S (IOPS de escritura)", filtrando por mysqld. Estos gráficos muestran operaciones de E/S para todos los servicios del nodo.
    • En "Almacenamiento", supervisa los gráficos de "Uso de disco (Dispositivo de datos DEVICE ID)" y "Latencia de disco (Dispositivo de datos DEVICE ID)". En este gráfico se muestra la cantidad de tiempo invertido en todas las operaciones de E/S del nodo, así como la latencia general del disco.
      • Los aumentos significativos de la latencia de disco podrían indicar que la instancia está obligando a la IOPS de disco a esperar para completarse.
      • Para confirmar una observación de una mayor latencia, revisa el gráfico de "Operaciones pendientes de disco (Dispositivo de datos DEVICE ID)", que podría indicar que el disco no puede abordar suficientemente todas las operaciones.

Mitigación del impacto de la actualización de MySQL

Para abordar la degradación inaceptable del rendimiento, GitHub recomienda las siguientes soluciones.

Antes de probar cualquier procedimiento de mitigación en un entorno de producción, realiza una copia de seguridad de la instancia, valida la copia de seguridad y prueba el procedimiento en un entorno de ensayo. Para obtener más información, vea «Configuración de copias de seguridad en la instancia» y «Configurar una instancia de preparación».

Ajuste del método de vaciado de InnoDB

Para intentar mitigar el impacto en el rendimiento, puedes ajustar el método de vaciado de InnoDB para omitir la llamada del sistema fsync() después de cada operación de escritura. Para obtener más información, consulta innodb_flush_method en el Manual de referencia de MySQL 8.0.

Las instrucciones siguientes solo están pensadas para GitHub Enterprise Server 3.9 y versiones posteriores.

Advertencia: El ajuste del método de vaciado requiere que el dispositivo de almacenamiento de la instancia tenga una memoria caché respaldada por baterías. Si la memoria caché del dispositivo no está respaldada por baterías, corres el riesgo de pérdida de datos.

  • Si hospedas la instancia mediante un hipervisor de virtualización dentro de un centro de datos local, revisa las especificaciones de almacenamiento para confirmar.
  • Si hospedas la instancia en un servicio de nube pública, consulta la documentación o al equipo de soporte técnico de su proveedor para confirmarlo.
  1. SSH en tu instancia de GitHub Enterprise Server Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. Para validar el método de vaciado actual para InnoDB, ejecuta el siguiente comando.

    Shell
    ghe-config mysql.innodb-flush-no-fsync
    

    De forma predeterminada, el comando devuelve false, que indica que la instancia realiza una llamada del sistema fsync() después de cada operación de escritura.

  3. Para configurar InnoDB para omitir la llamada del sistema fsync() después de cada operación de escritura, ejecuta el siguiente comando.

    Shell
    ghe-config mysql.innodb-flush-no-fsync true
    
  4. Para aplicar la configuración, ejecuta el siguiente comando.

    Nota: Durante la ejecución de una configuración, los servicios de tu instancia de GitHub Enterprise Server pueden reiniciarse, y esto puede provocar un breve tiempo de inactividad para los usuarios.

    Shell
    ghe-config-apply
    
  5. Espera que se complete la fase de configuración.

Actualización del almacenamiento de la instancia

Puedes reducir las operaciones pendientes, aumentar la IOPS y mejorar el rendimiento mediante el aprovisionamiento de almacenamiento más rápido para los nodos de la instancia. Para actualizar el almacenamiento de la instancia, realiza una copia de seguridad de la instancia y restaura la copia de seguridad en una nueva instancia de reemplazo. Para obtener más información, vea «Configuración de copias de seguridad en la instancia».

Uso compartido de datos con GitHub

Por último, si estás dispuesto a ayudar a GitHub a comprender el impacto real de la actualización a MySQL 8, puedes proporcionar los datos recopilados en Soporte de GitHub. Proporciona las observaciones de línea de base y posteriores a la actualización del panel de supervisión, junto con un lote de soporte técnico que cubra el período durante el que recopilaste los datos. Para obtener más información, vea «Acerca del Soporte de GitHub» y «Cómo proporcionar datos al servicio de soporte técnico de GitHub».

Los datos que envíes ayudan a GitHub a proporcionar un producto eficaz, pero GitHub no garantiza ningún paso de mitigación adicional ni cambios en el producto como resultado de los datos que proporciones.

MySQL no se inicia después de haber realizado la actualización a GitHub Enterprise Server 3.9 o 3.10

Al realizar una actualización a GitHub Enterprise Server 3.9 (desde 3.7 o 3.8) o 3.10 (solo desde 3.8),, si MySQL no se cerró correctamente durante el apagado de la instancia de GitHub Enterprise Server 3.7 o 3.8, MySQL intentará realizar la recuperación de bloqueos cuando se inicie la instancia de GitHub Enterprise Server 3.9 o 3.10. Como GitHub Enterprise Server 3.7 y 3.8 usan MySQL 5.7 y GitHub Enterprise Server 3.9 y 3.10 se han actualizado a MySQL 8.0, MySQL no podrá completar la recuperación de bloqueos.

Si vas a actualizar de GitHub Enterprise Server 3.9 a 3.10, no te verás afectado por este problema, ya que MySQL ya se ha actualizado de 5.7 a 8.0 en tu instancia.

Si tienes este problema, el siguiente error estará en el registro de errores de mysql (/var/log/mysql/mysql.err):

Shell
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported. This redo log was created with MySQL 5.7.40. Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/upgrading.html

Evitar este problema

Se recomienda encarecidamente actualizar la instancia de GitHub Enterprise Server a la versión de revisión más reciente (3.7.14 o posterior, o 3.8.7 o posterior) antes de actualizar a la versión 3.9 o 3.10. Estas versiones contienen una corrección para el problema de actualización.

Si no puedes actualizar tu instancia de GitHub Enterprise Server, puedes evitar el problema actualizando el tiempo de espera de nomad para MySQL antes de iniciar una actualización a GitHub Enterprise Server 3.9 (desde 3.7 o 3.8) o 3.10 (solo desde 3.8).

  1. Coloca la instancia en modo de mantenimiento:

    Shell
    ghe-maintenance -s
    
  2. Actualiza la plantilla consul para nomad:

    Shell
    sudo sed -i.bak '/kill_signal/i \      kill_timeout = "10m"' /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl
    
  3. Representa la plantilla consul para nomad:

    Shell
    sudo consul-template -once -template /etc/consul-templates/etc/nomad-jobs/mysql/mysql.hcl.ctmpl:/etc/nomad-jobs/mysql/mysql.hcl
    
  4. Verifica el valor kill_timeout actual:

    Shell
    nomad job inspect mysql | grep KillTimeout
    

    La respuesta esperada:

    Shell
    "KillTimeout": 5000000000
    
  5. Detén MySQL:

    Shell
    nomad job stop mysql
    
  6. Ejecuta un nuevo trabajo de MySQL:

    Shell
    nomad job run /etc/nomad-jobs/mysql/mysql.hcl
    
  7. Comprueba que kill_timeout se ha actualizado:

    Shell
    nomad job inspect mysql | grep KillTimeout
    

    La respuesta esperada:

    Shell
    "KillTimeout": 600000000000,
    
  8. Saca la instancia del modo de mantenimiento:

    Shell
    ghe-maintenance -u
    

Ahora que se ha actualizado el tiempo de espera de nomad para MySQL, puedes actualizar la instancia de GitHub Enterprise Server a la versión 3.9.

Mitigación de un reinicio erróneo de MySQL

Si este problema te afecta, restaura la instancia de GitHub Enterprise Server al estado en que estaba antes del intento de actualización y, después, sigue los pasos de la sección anterior.

Para más información sobre la restauración a partir de una actualización con errores, consulta "Actualizar el servidor de GitHub Enterprise".