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

¡Buenos días, queridos khabrovitas! Permíteme presentarme, Alejandro. Administrador de sistemas de un pequeño pero orgulloso estudio WEB. Realmente queremos que todo funcione de forma rápida, segura y con un software nuevo. Para ello, incluso levantamos el paquete nagios + PhantomJS en la computadora interna de la oficina y cada 30 minutos verificamos la velocidad de carga de la página. De acuerdo con los términos del servicio, también supervisamos las actualizaciones de 1C-Bitrix y las instalamos periódicamente. Y luego, un día, después de la próxima actualización, vemos un mensaje en el panel de administración que indica que desde el verano de 2019, 1C-Bitrix deja de funcionar con MySQL 5.5 y necesita actualizarse. Los muchachos de ISPSystem son guapos y amplían regularmente la funcionalidad del panel, por lo que les agradecemos especialmente. Pero esta vez no fue posible hacer clic en todo con el mouse. Pero debajo del corte se puede encontrar lo que pasó y cuántas canas hay ahora en mi barba.

Solo había una opción para instalar un "servidor DBMS alternativo" que se instala en el contenedor Docker. Por supuesto, entiendo que Docker es muy frugal con los recursos, pero no importa cuán bien funcione, la sobrecarga seguirá siendo> 0. Y aquí estamos, por así decirlo, luchando en décimas de segundo y optimizando todos los sitios en la entrada antes de publicar y firmar un acuerdo. Así que no es mi elección.
Bien, ¿qué hay en la documentación? Haga una copia de seguridad de todo, agregue un archivo con un enlace al repositorio de MariaDB a yum.repos.d, luego

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

Yum jurará posteriormente por el hecho de que alguien retiró los paquetes sin su conocimiento. Pero primero, déjalo jurar, está bien. Y en segundo lugar, si realiza la eliminación a través de yum, intentará demoler, junto con MariaDB, todo lo relacionado con él por dependencias, y esto es PHP, ISPManager y PHPmyadmin. Así que nos ocuparemos de los errores más tarde.

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

En general, todo se montó y se puso en marcha. Lo bueno es que se recogieron las bases y no fue necesario restaurarlas de vertederos. Revisé los sitios: funcionan y son rápidos. Fui a un par de paneles de administración para asegurarme de que nada se cayó y cancelé la suscripción al director de que todo estaba bien. En menos de 30 minutos, resultó que ni siquiera estaba bien...

Cuando traté de ir al panel de administración y agregar editar cualquier cosa en el contenido, se cayó un mensaje

MySQL Query Error: 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] Duplicate entry '10555' for key 'PRIMARY']

Dado que el contenido en el sitio es agregado por nuestros empleados, los clientes aún no sabían nada y aún no habían comenzado a separarnos. Pero era cuestión de tiempo, porque la información de los sitios necesita ser actualizada, y muchos clientes lo siguen muy de cerca.

Del texto del error, podemos concluir que Bitrix está tratando de agregar un nuevo registro a la base de datos, mientras especifica la misma clave principal que tenía el artículo que se está editando. Entonces, hay motivos para sospechar que el problema ocurre del lado de Bitrix. Vaya a su sitio web y póngase en contacto con el soporte. Casi de inmediato recibimos la respuesta “problema difícil. Se lo dio a los ingenieros superiores, espere ... "

Tuve que esperar bastante tiempo (todo el diálogo tuvo lugar del 25.06.2019/9.07.2019/10.4.6 al XNUMX/XNUMX/XNUMX) y el resultado fue el mensaje "este problema no está relacionado con el funcionamiento de Bitrix CMS, pero está relacionado al funcionamiento de la propia base de datos en mariadb XNUMX y, lamentablemente, con el lado del sitio falta este problema para resolver la posibilidad, será necesario migrar a la versión anterior de MariaDB.”

Navegado... Pensé en bajar de categoría al principio de la historia, pero aquí en blanco y negroque no puede haber rebaja. Combinar volcados y volver a implementar en un servidor recién instalado. Aquellos. es bueno que no actualicé todos los servidores a la vez. Aquellos. "solo" cien sitios (risa nerviosa :-)). También dijeron en soporte: “Para resolver el problema al usar la base de datos MariaDB 10.4.6, deberá comunicarse con el soporte técnico de MariaDB para que la transacción no elimine un registro de la base de datos si se realiza una solicitud:

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

La esperanza brilló durante un par de horas desde el momento en que comenzamos a comunicarnos con el soporte de MariaDB, pero luego recibí una carta en la que se me informaba muy correctamente que no era un usuario comercial y, por lo tanto, nadie resolvería mi problema a propósito, pero hay un foro en su web y puedes intentar buscar opciones allí… No te aburriré con detalles. No hay opciones allí.
¡ACERCA DE! ¡Hemos comprado una licencia para ISP!
hola, apoyo? ¡Chicos, ayuda!
- Lo sentimos, no apoyamos a los matones que cambian las versiones nativas del DBMS. Si quieres, hay una opción con un servidor alternativo en docker.
- Pero, ¿cómo llegarán allí los usuarios y las bases de datos? ¿A la ventana acoplable?
- Bueno, los arrastras allí con las manos...
- ¡Sí! Y no olvide que el puerto para mysql cambiará y deberá revisar y reescribir todas las configuraciones.
Ok gracias, lo pensaré...
Pensé y decidí demoler el 10.4 con handles e instalar el 10.2 con el cual no hubo problemas en otros servidores.

El proceso no fue muy diferente del proceso de actualización. Solo era necesario cambiar 10.4 a 10.2 en el enlace al repositorio, resetear y volver a crear el caché para yum. Bueno, una “bagatela” más: después de eliminar la 10.4, vamos a /var/lib/mysql y borramos todo de ahí. Sin este paso, después de instalar 10.2, el servicio fallará constantemente y verá

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

O

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

Antes de importar las bases de datos, primero configuré la contraseña raíz de mysql que se especificó en las configuraciones del ISP e importé el volcado de la base de datos mysql. Bueno, entonces, como ya hay usuarios y derechos, simplemente importamos todas las bases de datos de usuarios en una fila con la cuenta raíz.

Texto del script para el volcado de la base de datos:

#!/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 bases de datos, debe descomprimirlas. Así que solo ejecuta el comando

gunzip /BACK/*.gz

Y lo último: por alguna razón, los guiones están permitidos en los nombres de las bases de datos (si los crea usando ISPmanager). Pero al crear o intentar cargar un volcado en una base de datos que tiene un guión en el nombre, recibe un mensaje que indica que la sintaxis de la consulta es incorrecta.

Lea hasta el final de todas las bendiciones. Pido disculpas por las comas probablemente no espaciadas: están en problemas. Si hay deseos para una propuesta esencialmente descrita, escriba en un personal porque en los comentarios tengo miedo de perderme algo. Y no jures demasiado: este es mi primer artículo 🙂

UPD1:

Casi me olvido de mencionar: mientras intentaba encontrar una solución al problema sin degradar MariaDB, tuve que actualizar la información de alguna manera. Se actualizó así: toda la base de datos se convierte de InnoDB a MyISAM, infa se actualiza y luego se vuelve a convertir a InooDB.
UPD2:

Acabo de recibir una carta de 1C-Bitrix con el siguiente contenido:

Solicitud de revisión completada
"Después de actualizar mariadb a 10.4.6, ocurrió un error al guardar el elemento infoblock"
Módulo: iblock, versión: desconocida
Solución: rechazado

Entonces, por ahora, aparentemente es imposible actualizar a 10.4 🙁

Fuente: habr.com