Bos días, queridos Khabrovitas! Permíteme que me presente, Alexander. Administrador do sistema dun pequeno pero orgulloso WEB-studio. Realmente queremos que todo funcione de forma rápida, segura e cun software novo. Para iso, mesmo levantamos o paquete nagios + PhantomJS no ordenador da oficina e cada 30 minutos comprobamos a velocidade de carga da páxina. Segundo os termos de servizo, tamén supervisamos as actualizacións de 1C-Bitrix e as instalamos regularmente. E entón un día, despois da seguinte actualización, vemos unha mensaxe no panel de administración que indica que desde o verán de 2019, 1C-Bitrix deixa de funcionar con MySQL 5.5 e necesita ser actualizado. Os mozos de ISPSystem son guapos e amplían regularmente a funcionalidade do panel, polo que lles agradecemos especialmente. Pero esta vez non foi posible facer clic en todo co rato. Pero o que pasou e cantas canas hai agora na miña barba pódese atopar baixo o corte.
Só había unha opción para instalar un "servidor DBMS alternativo" que está instalado no contedor Docker. Por suposto, entendo que Docker é moi frugal cos recursos, pero por moito que funcione, a sobrecarga aínda será > 0. E aquí estamos, por así dicir, loitando en décimas de segundo e optimizando todos os sitios da entrada antes de publicar e asinar un acordo. Entón non é a miña elección.
Ok, que hai na documentación? Fai unha copia de seguranza de todo, engade un ficheiro cunha ligazón ao repositorio de MariaDB a yum.repos.d e despois
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum, posteriormente, xurará o feito de que alguén quitou os paquetes sen o seu coñecemento. Pero en primeiro lugar - déixao xurar, está ben. E en segundo lugar, se fai a eliminación a través de yum, entón tenta demoler, xunto con MariaDB, todo o que está relacionado con el por dependencias, e isto é PHP e ISPManager e PHPmyadmin. Entón, trataremos os erros máis tarde.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonEn xeral, todo estaba configurado e comezou. O bonito é que se recolleron as bases e non foi necesario restauralas dos vertedoiros. Comprobei os sitios: funcionan e rapidamente. Fun a un par de paneis de administración para asegurarme de que non se caía nada e cancelei a subscrición ao director de que todo estaba ben. En menos de 30 minutos, resultou que nin sequera estaba ben...
Cando tentei ir ao panel de administración e engadir calquera cousa ao contido, saíu unha mensaxe
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 o contido do sitio é engadido polos nosos empregados, os clientes aínda non sabían nada e aínda non comezaran a separarnos. Pero era cuestión de tempo, porque a información dos sitios necesita ser actualizada, e moitos clientes seguen isto moi de preto.
Do texto do erro, podemos concluír que Bitrix está tentando engadir un novo rexistro á base de datos, mentres especifica a mesma clave principal que tiña o artigo que se está editando. Polo tanto, hai motivos para sospeitar que o problema ocorre no lado de Bitrix. Vaia ao seu sitio web e póñase en contacto co soporte. Case inmediatamente recibimos a resposta "problema difícil. Entreguello aos enxeñeiros seniores - agarde... "
Tiven que esperar bastante tempo (todo o diálogo tivo lugar do 25.06.2019/9.07.2019/10.4.6 ao XNUMX/XNUMX/XNUMX) e o resultado foi a mensaxe “este problema non está relacionado co funcionamento do CMS Bitrix, senón que está relacionado ao funcionamento da propia base de datos en mariadb XNUMX e, por desgraza, se falta o lado do sitio para resolver este problema, será necesario migrar a unha versión máis antiga de MariaDB.
Navegaba... Pensei en baixar de categoría ao comezo da historia, pero que non pode haber baixa. Combina volcados e volve implementar nun servidor recén instalado. Eses. é bo que non actualicei todos os servidores á vez. Eses. "só" cen sitios (risa nerviosa :-)). Tamén dixeron en apoio: "Para resolver o problema ao usar a base de datos MariaDB 10.4.6, terás que contactar co soporte técnico de MariaDB para que a transacción non eliminará un rexistro da base de datos se se fai unha solicitude:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
A esperanza brillou durante un par de horas desde o momento en que comezamos a comunicarnos co soporte de MariaDB, pero entón recibín unha carta na que se me informaba moi correctamente de que non era un usuario comercial e que, polo tanto, ninguén resolvería o meu problema a propósito, pero hai un foro na súa páxina web e podes tentar buscar opcións alí... Non te aburrirei con detalles. Non hai opcións alí.
SOBRE! Compramos unha licenza para ISP!
Ola, apoio? Rapaces, axuda!
- Sentímolo, non admitimos matóns que cambien as versións nativas do DBMS. Se queres, hai unha opción cun servidor alternativo en docker.
- Pero como chegarán os usuarios e as bases de datos? Para docker?
- Pois arrastrástes ata alí coas mans...
- Si! E non esquezas que o porto para mysql cambiará e terás que pasar e reescribir todas as configuracións.
Ok, grazas, pensarei niso...
Pensei e decidín demoler 10.4 con asas e instalar 10.2 co que non había problemas noutros servidores.
O proceso non foi moi diferente do proceso de actualización. Só era necesario cambiar 10.4 a 10.2 na ligazón ao repositorio, restablecer e volver crear a caché para yum. Ben, un "chicacho" máis: despois de eliminar a 10.4, imos a /var/lib/mysql e borramos todo de alí. Sen este paso, despois de instalar 10.2, o servizo fallará constantemente e verás
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Ou
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Antes de importar as bases de datos, primeiro configurei o contrasinal de root de mysql que se especificou nas configuracións do ISP e importei o volcado da base de datos mysql. Pois ben, pois xa hai usuarios e dereitos, simplemente importamos todas as bases de datos de usuarios seguidas coa conta root.
Texto do script para o volcado da 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, cómpre descomprimilas. Entón só executa o comando
gunzip /BACK/*.gzE o último: por algún motivo, os guións están permitidos nos nomes das bases de datos (se os creas usando ISPmanager). Pero ao crear ou tentar cargar un volcado nunha base de datos que ten un guión no nome, recibe unha mensaxe de que a sintaxe da consulta é incorrecta.
Le ata o final de todas as bendicións. Pido desculpas polas comas non espaciadas máis probables: están en problemas. Se hai desexos dunha proposta esencialmente descrita, escriba nun persoal porque nos comentarios teño medo de perder algo. E non xuredes demasiado: este é o meu primeiro artigo 🙂
UPD1:
Case esquecín mencionar: mentres intentaba atopar unha solución ao problema sen baixar a MariaDB, tiven que actualizar a información dalgún xeito. Actualizouse así: toda a base de datos convértese de InnoDB a MyISAM, infa actualízase e despois convértese de novo a InooDB.
UPD2:
Acaba de recibir unha carta de 1C-Bitrix co seguinte contido:
Solicitude de revisión completada
"Despois de actualizar mariadb a 10.4.6, produciuse un erro ao gardar o elemento infoblock"
Módulo: iblock, versión: descoñecida
Solución: rexeitada
Entón, polo momento, ao parecer é imposible actualizar a 10.4 🙁
Fonte: www.habr.com