Problemas conocidos con las actualizaciones de la instancia

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.

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
• Actualización del almacenamiento de la instancia

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.

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):

[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

[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 "Restaurar desde una actualización fallida".