Boa tarde, queridos membros do Habr! Permitam-me apresentar, sou Alexander, administrador de sistemas de uma pequena, mas orgulhosa agência de WEB. Queremos muito que tudo funcione de forma rápida, segura e com software atualizado. Para isso, até configuramos uma combinação Nagios + PhantomJS no computador da empresa e verificamos a velocidade de carregamento das páginas a cada 30 minutos. Como parte do nosso serviço, também monitoramos as atualizações do 1C-Bitrix e as instalamos regularmente. E um dia, após a atualização, vimos uma mensagem na administração informando que a partir do verão de 2019, o 1C-Bitrix deixaria de funcionar com o MySQL 5.5 e que seria necessário atualizar. A galera da ISPSystem é fantástica e regularmente amplia as funcionalidades do painel, pelo que agradeço. Mas desta vez não consegui fazer tudo com o mouse. Sobre o que consegui fazer e quantos fios brancos agora estão na minha barba, podem descobrir a seguir.
Só havia a opção de instalar um "servidor de banco de dados alternativo" que é instalado em um contêiner Docker. Eu entendo que o Docker é bastante econômico em recursos, mas, por mais bem que funcione, sempre haverá uma sobrecarga >0. E aqui estamos lutando por frações de segundos e otimizamos todos os sites antes de publicá-los e assinar o contrato. Então, não é uma opção para mim.
Ok, o que está escrito na documentação? Backup de tudo, adicionar um arquivo em yum.repos.d com o link do repositório MariaDB, então
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonO Yum posteriormente reclamará que alguém removeu/instalou pacotes sem seu conhecimento. Mas, em primeiro lugar, que reclame, não há problema. E, em segundo lugar, se eu fizer a remoção pelo yum, ele tentará remover junto com o MariaDB tudo o que tiver dependências relacionadas, como PHP, ISPManager e PHPmyadmin. Portanto, resolveremos as queixas depois.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonNo geral, tudo foi instalado e funcionou. É agradável que os bancos tenham sido reconhecidos e não precisei restaurá-los a partir de dumps. Verifiquei os sites — estão funcionando e rápidos. Acesse algumas áreas administrativas para me certificar de que nada havia caído e informei o diretor que estava tudo OK. Não se passaram 30 minutos até que ficou claro que não estava nada OK...
Ao tentar acessar a área administrativa e adicionar/editar qualquer coisa no conteúdo, apareceu uma mensagem
Erro na consulta MySQL: INSERIR EM b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) SELECIONE 10555, 2201, P.ID, '3607', 3607.0000 DE b_iblock_property P ONDE ID = 184 [[1062] Entrada duplicada '10555' para a chave 'PRIMARY']Como o conteúdo do site é adicionado por nossas funcionárias, os clientes ainda não sabiam de nada e ainda não começaram a nos atacar. Mas isso era uma questão de tempo, pois as informações nos sites precisam ser atualizadas e muitos clientes monitoram isso de perto.
A partir do texto do erro, pode-se concluir que o Bitrix está tentando adicionar uma nova entrada ao banco de dados, ao mesmo tempo especificando a mesma chave primária que tinha o artigo sendo editado. Isso significa que há motivos para suspeitar que o problema surge do lado do Bitrix. Vamos ao site deles e entramos em contato com o suporte. Quase imediatamente recebemos a resposta: "problema complicado. Encaminhado para engenheiros seniores - aguarde..."
A espera foi bastante longa (todo o diálogo ocorreu de 25.06.2019 a 09.07.2019) e o resultado foi a mensagem: "este problema não está relacionado ao funcionamento do CMS Bitrix, mas sim ao funcionamento do próprio banco de dados no mariadb 10.4.6 e, infelizmente, do lado do site essa questão não pode ser resolvida; será necessário voltar para uma versão antiga do MariaDB."
Estamos em apuros... Eu pensei sobre o downgrade desde o início da história, mas , que não pode haver nenhum downgrade. Faça os dumps e reinstale tudo em uma instalação limpa. servidor. Ou seja, é bom que eu não atualizei todos os servidores de uma vez. Ou seja, "apenas" uma centena de sites (risada nervosa:-)). O suporte também disse: "Para resolver o problema ao usar o banco MariaDB 10.4.6, você precisará entrar em contato com o suporte técnico do MariaDB, pois na transação não será possível excluir a entrada do banco de dados, se for feita a consulta:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]); A esperança durou algumas horas desde o início do contato com o suporte do MariaDB, mas depois recebi um email que me informou educadamente que eu não sou um usuário comercial e, portanto, ninguém resolveria meu problema intencionalmente, mas há um fórum em seu site e lá posso tentar procurar opções... Não vou cansá-lo com detalhes. Não há opções lá.
Oh! Nós temos a licença comprada do ISP!
— Alô, suporte? Pessoal, ajudem-nos!
— Desculpe, não suportamos versões nativas de SGBD que são alteradas. Se quiser, há uma opção com um servidor alternativo em Docker.
— Mas como os usuários e bancos de dados vão acessar isso? Pelo Docker?
— Bem, você os levará para lá à mão...
— Sim! E não se esqueça de que a porta para MySQL será alterada e você precisará revisar e reescrever todos os arquivos de configuração.
— Ok, obrigado, vou pensar nisso...
Eu pensei e decidi manualmente remover o 10.4 e instalar o 10.2, que não teve problemas em outros servidores.
O processo não foi muito diferente do processo de atualização. Apenas precisava trocar 10.4 por 10.2 no link do repositório, limpar e recriar o cache para o yum. E mais uma 'pequena coisa': após remover o 10.4, vamos em /var/lib/mysql e removemos tudo de lá. Sem essa etapa, após a instalação do 10.2, o serviço ficará caindo constantemente e você verá
Não foi possível conectar ao banco de dados '' Lost connection to MySQL server at 'reading initial communication packet', erro do sistema: 104 "Connection reset by peer"Ou
Lost connection to MySQL server at 'handshake: reading initial communication packet', erro do sistema: 104Antes de importar os bancos, instalei a senha root para MySQL que estava configurada nos arquivos de configuração do ISP e importei o dump do banco MySQL. Assim, como os usuários e permissões já existem, simplesmente usamos a conta root para importar todos os bancos de usuários sequencialmente.
Texto do script para fazer dump dos bancos:
#!/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 os bancos, você precisa descompactá-los. Portanto, execute o comando
gunzip /BACK/*.gzE por último: por alguma razão, a presença de hífens no nome dos bancos (se você os cria através do ISPmanager) é permitida. Mas, ao criar ou tentar carregar um dump em um banco cujo nome tem hífen, você receberá uma mensagem indicando que a sintaxe da consulta está incorreta.
Para aqueles que leram até o fim, tudo de bom. Peço desculpas pela falta de vírgulas — estou com dificuldades nisso. Se houver sugestões ou pedidos sobre o que foi descrito — mande uma mensagem privada, pois temo perder algo nos comentários. E não sejam muito duros — este é meu primeiro artigo 🙂
UPD1:
Quase me esqueci de mencionar: enquanto tentava encontrar uma solução para o problema sem fazer downgrade do MariaDB, eu precisava de alguma forma atualizar as informações. A atualização foi feita assim: todo o banco foi convertido de InnoDB para MyISAM, as informações foram atualizadas e depois convertidas de volta para InnoDB.
UPD2:
Acabei de receber um e-mail da 1C-Bitrix com o seguinte conteúdo:
Solicitação de revisão foi implementada
«Após a atualização do mariadb para 10.4.6, erro ao salvar um item do bloco de informação»
Módulo: iblock, versão: desconhecida
Solução: rejeitada
Portanto, por enquanto, não é possível atualizar para 10.4 🙁
Fonte: habr.com
