Bitrix y actualización de MariaDB a la última versión estable

¡Buenas tardes, estimados Habreros! Permítanme presentarme, soy Alexander. Administrador de sistemas de un pequeño pero orgulloso estudio WEB. Queremos que todo funcione rápido, seguro y con software actualizado. Para ello, incluso hemos configurado un sistema con nagios+PhantomJS en nuestra computadora de oficina y cada 30 minutos comprobamos la velocidad de carga de las páginas. Según los términos de servicio, también monitoreamos las actualizaciones de 1C-Bitrix y las instalamos regularmente. Y un día, tras otra actualización, vemos un mensaje en el panel de administración sobre que desde el verano de 2019 1C-Bitrix dejará de funcionar con MySQL 5.5 y es necesario actualizar. Los chicos de ISPSystem son geniales y amplían regularmente las funciones del panel, por lo que les agradezco por eso. Pero esta vez no fue posible hacer todo con el mouse. Sobre lo que salió bien y cuántos cabellos grises hay ahora en mi barba se puede descubrir debajo del corte.

Solo había la opción de instalar un "servidor de bases de datos alternativo" que se instala en un contenedor Docker. Entiendo que Docker es bastante ahorrativo en recursos, pero por muy bien que funcione, siempre habrá un overhead >0. Y aquí estamos luchando por décimas de segundo y optimizando todos los sitios antes de publicarlos y firmar el contrato. Así que no es mi opción.
Bien, ¿qué dice la documentación? Hacer respaldo de todo, añadir en el archivo yum.repos.d un enlace al repositorio de MariaDB, luego

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common

Yum eventualmente se quejará de que alguien eliminó o instaló paquetes sin su conocimiento. Pero en primer lugar, que se queje, no es nada grave. Y en segundo lugar, si se hace la eliminación por yum, intentará eliminar junto con MariaDB todo lo que esté relacionado por dependencias, incluyendo PHP, ISPManager y PHPmyadmin. Así que luego resolveremos las quejas.

yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-common

En general, todo se instaló y funcionó. Lo bueno es que las bases de datos se detectaron y no fue necesario restaurarlas desde los volúmenes de respaldo. Verifiqué los sitios: funcionan y rápido. Entré a un par de paneles de administración para asegurarme de que nada se había caído y le informé al director que todo estaba OK. No pasaron ni 30 minutos antes de que resultara que no estaba en absoluto OK...

Al intentar entrar al panel de administración y agregar o editar cualquier cosa en el contenido, aparecía un mensaje

Error de consulta MySQL: INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) SELECT 10555, 2201, P.ID, '3607', 3607.0000 FR OM b_iblock_property P WHERE ID = 184 [[1062] Entrada duplicada '10555' para la clave 'PRIMARY']

Como el contenido del sitio es agregado por nuestras empleadas, los clientes aún no estaban al tanto y no habían comenzado a atacarnos. Pero era cuestión de tiempo ya que muchos clientes siguen de cerca la actualización de la información en los sitios.

A partir del texto del error, se puede concluir que Bitrix intenta agregar un nuevo registro en la base de datos especificando la misma clave primaria que tenía el artículo editado. Por lo tanto, hay motivos para sospechar que el problema surge del lado de Bitrix. Vamos a su sitio y nos dirigimos al soporte. Casi de inmediato recibimos la respuesta: “problema complicado. Lo hemos enviado a los ingenieros senior; por favor, espere…”

Tuvimos que esperar bastante tiempo (todo el diálogo ocurrió entre el 25.06.2019 y el 09.07.2019) y como resultado recibimos el mensaje: “este problema no está relacionado con el funcionamiento del CMS Bitrix, sino con el funcionamiento de la base de datos en mariadb 10.4.6 y, desafortunadamente, desde el lado del sitio no hay posibilidad de resolver este problema; será necesario volver a una versión anterior de MariaDB.”

Ya estamos… Pensé en el downgrade desde el comienzo de la historia, pero aquí está escrito negro sobre blanco, que no puede haber ningún downgrade. Hagan volcar los volúmenes y desplieguen nuevamente en una instalación limpia. servidor. Es bueno que no actualicé todos los servidores a la vez. Es decir, “solo” un centenar de sitios (risita nerviosa :-)). También en el soporte dijeron: “Para resolver el problema al usar la base de datos MariaDB 10.4.6, deberá ponerse en contacto con el soporte técnico de MariaDB, ya que en la transacción no se podrá eliminar el registro de la BDD si se realiza la consulta:

$DB->Query("DELETE FROM " . $strTable . " WHERE ID = " . $res["ID"]);
$results = $DB->Query("SELECT * FROM " . $strTable . " WHERE ID = " . $res["ID"]);”

La esperanza duró un par de horas desde el inicio de la comunicación con el soporte de MariaDB, pero luego llegó un correo en el que me informaron de manera muy correcta que no soy un usuario comercial y, por lo tanto, nadie resolverá específicamente mi problema, pero hay un foro en su sitio y allí se pueden buscar opciones... No los aburriré con detalles. No hay opciones allí.
¡Oh! ¡Tenemos una licencia comprada para ISP!
— ¿Aló, soporte? ¡Chicos, ayúdenme!
— Lo siento, no apoyamos a los individuos que cambian las versiones nativas de la base de datos. Si lo desea, hay una opción con un servidor alternativo en Docker.
— Pero, ¿cómo accederán los usuarios y las bases de datos? ¿En Docker?
— Bueno, ustedes los llevarán ahí manualmente...
— ¡Sí! Y no olviden que el puerto para MySQL cambiará y habrá que revisar y reescribir todos los archivos de configuración.
— Ok, gracias, lo pensaré...
Pensé y decidí eliminar manualmente 10.4 e instalar 10.2, con el que no había problemas en otros servidores.

El proceso no era muy diferente al de una actualización. Solo había que cambiar 10.4 a 10.2 en el enlace del repositorio, restablecer y volver a crear la caché para yum. Ah, y una 'pequeñez': después de eliminar 10.4, vamos a /var/lib/mysql y borramos todo de allí. Sin este paso, después de instalar 10.2, el servicio seguirá fallando y verán

No se pudo conectar a la base de datos '' Conexión perdida con el servidor MySQL en 'leyendo el paquete de comunicación inicial', error del sistema: 104 "Conexión reiniciada por el par"

O

Conexión perdida con el servidor MySQL en 'handshake: leyendo el paquete de comunicación inicial', error del sistema: 104

Antes de importar las bases, primero establecí la contraseña root para MySQL que estaba anotada en los archivos de configuración de ISP y luego importé el volcado de la base de datos MySQL. Ya que los usuarios y permisos ya existen, simplemente con la cuenta root importamos todas las bases de usuarios una tras otra.

Texto del script para volcar bases:

#!/bin/bash
echo 'show databases' | mysql -u root --password="ПаРоЛь_РУТА" --skip-column-names | grep -v information_schema | xargs -I {} -t bash -c 'mysqldump -u root --password="ПаРоЛь_РУТА" {} | gzip > /BACK/back-$(hostname)-{}-$(date +%Y-%m-%d-%H.%M.%S).sql.gz'

Antes de importar las bases, hay que descomprimirlas. Así que simplemente ejecutamos el comando

gunzip /BACK/*.gz

Y por último: por alguna razón, en el nombre de las bases (si se crean a través de ISPmanager) se permiten guiones. Sin embargo, al crear o intentar cargar un volcado en una base cuyo nombre tiene un guion, recibirás un mensaje indicando que la sintaxis de la consulta es incorrecta.

A quienes han llegado hasta aquí, les deseo todo lo bueno. Pido disculpas por la falta de comas — tengo problemas con ellas. Si tienen sugerencias sobre el contenido descrito, escriban en privado porque en los comentarios temo perder algo. Y no se enojen mucho — este es mi primer artículo 🙂

UPD1:

Casi olvido mencionar: mientras intentaba encontrar una solución al problema sin hacer un downgrade de MariaDB, había que actualizar la información de alguna manera. Se actualizaba así: toda la base se convertía de InnoDB a MyISAM, se actualizaba la información y luego se convertía de nuevo a InnoDB.
UPD2:

Acabo de recibir un correo de 1C-Bitrix con el siguiente contenido:

La solicitud de mejora ha sido implementada
«Después de actualizar mariadb a 10.4.6, error al guardar un elemento del infobloque»
Módulo: iblock, versión: desconocida
Solución: rechazada

Parece que no se puede actualizar a 10.4 por ahora 🙁

Fuente: habr.com