Buen día, queridos Khabrovchianos! Déjame presentarme, Alexander. Administrador del sistema de un pequeño pero orgulloso estudio WEB. Realmente queremos que todo funcione de manera rápida, segura y con software nuevo. Para hacer esto, incluso levantaron un montón de nagios + PhantomJS en la computadora de la oficina y verificaron la velocidad de carga de la página cada 30 minutos. De acuerdo con los términos del servicio, también seguimos las actualizaciones de 1C-Bitrix y las instalamos regularmente. Y una vez, después de la próxima actualización, vemos un mensaje en el panel de administración que indica que en el verano de 2019 1C-Bitrix deja de funcionar con MySQL 5.5 y debe actualizarse. Los chicos de ISPSystem son guapos y regularmente amplían la funcionalidad del panel, por lo que les agradecemos especialmente. Pero esta vez no fue posible hacer clic en todo el mouse. Pero lo que sucedió y la cantidad de canas que hay ahora en mi barba se puede encontrar debajo del corte.
Solo había una opción para poner un "servidor DBMS alternativo" que se coloca en el contenedor Docker. Por supuesto, entiendo que Docker es muy eficiente en el uso de los recursos, pero no importa lo bueno que funcione, la sobrecarga seguirá siendo> 0. Y aquí estamos luchando, por así decirlo, en décimas de segundo, y en la entrada optimizamos todos los sitios antes de publicar y firmar un contrato. Entonces esta no es mi opción.
Ok, ¿qué está escrito en la documentación? Copia de seguridad total, agregue un archivo con un enlace al repositorio MariaDB en yum.repos.d, luego
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common
Yum maldecirá más tarde que alguien eliminó / instaló paquetes sin su conocimiento. Pero primero, déjalo jurar, está bien. Y en segundo lugar, si eliminas a través de yum, él intenta demoler, junto con MariaDB, todo lo que está relacionado con él, y esto es PHP e ISPManager y PHPmyadmin. Por lo tanto, trataremos con garabatos.
yum clean all yum update yum install MariaDB-server MariaDB-client MariaDB-common
En general, todo estaba configurado y terminado. Lo bueno es que las bases fueron recogidas y no hubo necesidad de restaurarlas de los vertederos. Revisé los sitios, funcionan y rápidamente. Entré en un par de páginas de administración para asegurarme de que nada se cayera y le escribí al director que todo estaba bien. En menos de 30 minutos resultó que no está del todo bien ...
Al intentar ir al panel de administración y agregar / editar cualquier cosa, se cayó un mensaje en el contenido
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']
Como nuestros empleados están agregando contenido al sitio, 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 en los sitios necesita ser actualizada y esto es lo que muchos clientes siguen y de cerca.
Del texto de error, podemos concluir que Bitrix está tratando de agregar un nuevo registro a la base de datos mientras indica la misma clave primaria que tenía el artículo editado. Por lo tanto, hay razones para sospechar que el problema surge del lado de Bitrix. Vamos a su sitio web y recurrimos a soporte. Casi de inmediato recibimos la respuesta "un problema difícil. Se lo di a ingenieros superiores: espera ... "
Tuvimos que esperar mucho tiempo (todo el diálogo tuvo lugar del 25/06/2019 al 09/07/2019) y el resultado fue el mensaje "este problema no está relacionado con el trabajo de Bitrix CMS, sino con la base de datos en sí en mariadb 10.4.6 y desafortunadamente con Al lado del sitio este problema para resolver la posibilidad falta, será necesario actualizar a la versión anterior de MariaDB.
Llegaron ... Pensé en la rebaja al comienzo de la historia, pero
aquí se dice en blanco y negro que no puede haber rebaja. Fusionar volcados e implementar nuevamente en un servidor limpio. Es decir Es bueno que no haya actualizado todos los servidores a la vez. Es decir "Solo" cien sitios (una risa nerviosa :-)). También dijeron en soporte: "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 para que la transacción no elimine el registro de la base de datos si se realiza la solicitud:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]); $results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Nadezhda se había estado calentando durante un par de horas desde el comienzo de la comunicación con el soporte de MariaDB, pero luego llegó una carta en la que me decían correctamente que no era un usuario comercial y, por lo tanto, nadie resolvería mi problema deliberadamente, pero había un foro en su sitio web y usted podía intentar buscar opciones allí. ... No voy a aburrir los detalles. No hay opciones allí.
Oh! ¡Tenemos una licencia comprada para ISP!
- Hola, apoyo? Chicos, ayuda!
- Lo sentimos, no admitimos las basura que cambian la versión nativa del DBMS. ¿Desea? Hay una opción con un servidor alternativo en la ventana acoplable.
- Pero, ¿cómo llegan los usuarios y las bases de datos? A la ventana acoplable?
- Bueno, los arrastras allí con tus manos ...
- si! Y no olvide que el puerto para mysql cambiará y deberá revisar todas las configuraciones y volver a escribirlo.
- Ok, gracias, pensaré ...
Pensé y decidí demoler 10.4 con bolígrafos y poner 10.2 con los que no hubo problemas en otros servidores.
El proceso no fue muy diferente del proceso de actualización. Solo era necesario en el enlace al repositorio cambiar 10.4 a 10.2, restablecer y volver a crear el caché para yum. Bueno, una "bagatela" más: después de eliminar 10.4, vaya a / var / lib / mysql y elimine todo desde allí. Sin este paso, después de instalar 10.2, el servicio caerá 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 de root para mysql que estaba registrada en las configuraciones del ISP e importé el volcado de la base de datos mysql. Bueno, entonces, dado que ya hay usuarios y derechos, simplemente importamos todas las bases de usuarios en una fila con la cuenta raíz.
Texto de script para el volcado de la base de datos:
Antes de importar bases de datos, debe descomprimirlas. Así que solo ejecuta el comando
gunzip /BACK/*.gz
Y el último: por alguna razón, se permiten guiones en el nombre de las bases de datos (si crea a través de ISPmanager). Pero cuando crea o intenta llenar el volcado en la base de datos con un guión en el nombre, recibe un mensaje de que la sintaxis de la consulta es incorrecta.
Lea hasta el final de todas las bendiciones. Pido disculpas por las comas probablemente no colocadas, problemas con ellas. Si hay deseos / sugerencias sobre la esencia de lo que se describe, escriba un mensaje personal porque me da miedo perder algo en los comentarios. Y no jures mucho, este es mi primer artículo :-)
UPD1:
Casi me olvido de mencionar: mientras trataba de encontrar una solución al problema sin degradar MariaDB, tuve que actualizar de alguna manera la información. Se actualizó de la siguiente manera: toda la base de datos se convierte de InnoDB a MyISAM, la información se actualiza y luego se vuelve a convertir a InooDB.
UPD2:
Acaba de llegar una carta de 1C-Bitrix con el siguiente contenido:
Solicitud de revisión implementada
"Después de actualizar mariadb a 10.4.6, se produjo un error al guardar el elemento de bloque de información"
Módulo: iblock, versión: desconocido
Solución: rechazada
Entonces, aunque aparentemente es imposible actualizar a 10.4 :-(