Buon pomeriggio, cari membri di Habr! Permettetemi di presentarmi, sono Alexander, amministratore di sistema di una piccola ma orgogliosa WEB studio. Vogliamo davvero che tutto funzioni velocemente, in sicurezza e con software aggiornato. A tal fine, abbiamo persino attivato una combinazione di nagios+PhantomJS su un computer interno e verifichiamo ogni 30 minuti la velocità di caricamento delle pagine. In base ai termini di servizio, monitoriamo anche gli aggiornamenti di 1C-Bitrix e li installiamo regolarmente. E un giorno, dopo un altro aggiornamento, abbiamo visto un messaggio nel pannello di amministrazione che dal'estate 2019 1C-Bitrix smetterà di funzionare con MySQL 5.5 e sarà necessario aggiornarsi. I ragazzi di ISPSystem sono davvero bravi e ampliano regolarmente le funzionalità del pannello, per questo un ringraziamento speciale a loro. Ma questa volta non siamo riusciti a fare tutto con il mouse. Quello che siamo riusciti a fare e quanti capelli grigi ci sono ora nella mia barba, si può scoprire sotto il tag.
C'era solo l'opzione di installare un "server DB alternativo" che si installa nel contenitore Docker. Capisco che Docker sia piuttosto parsimonioso con le risorse, ma per quanto possa funzionare bene, ci sarà comunque un overhead >0. Qui ci battiamo per frazioni di secondo e ottimizziamo tutti i siti prima di pubblicarli e firmare un contratto. Quindi non è la mia opzione.
Ok, cosa dice la documentazione? Backup di tutto, aggiungere nel file yum.repos.d il link al repository di MariaDB, quindi
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum successivamente si lamenterà che qualcuno ha rimosso/installato pacchetti senza il suo consenso. Ma prima di tutto, lasci che si lamenti, non è un grosso problema. E in secondo luogo, se si fa la rimozione tramite yum, cerca di rimuovere insieme a MariaDB anche tutto ciò che è legato alle sue dipendenze, comprese PHP, ISPManager e PHPmyadmin. Quindi ci occuperemo delle lamentele in seguito.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonIn generale, tutto è stato installato e avviato senza problemi. È piacevole notare che i database si sono caricati e non è stato necessario recuperarli dai backup. Ho controllato i siti: funzionano e sono veloci. Sono entrato in un paio di pannelli amministrativi per accertarmi che nulla fosse andato storto e ho informato il direttore che tutto era a posto. Non è passato neanche mezz'ora che si è scoperto che non era affatto così…
Quando tentavo di accedere al pannello amministrativo e aggiungere o modificare contenuti, si presentava il seguente messaggio
Errore di Query 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 DALLA b_iblock_property P DOVE ID = 184 [[1062] Duplicato della voce '10555' per la chiave 'PRIMARY']Poiché il contenuto del sito viene aggiunto dalle nostre stesse dipendenti, i clienti non sapevano ancora nulla e finora non hanno iniziato a lamentarsi. Ma era solo questione di tempo, poiché molte informazioni sui siti devono essere aggiornate e questo è qualcosa che molti clienti seguono personalmente e attentamente.
Dal messaggio di errore si può dedurre che Bitrix sta tentando di aggiungere una nuova registrazione nel database specificando lo stesso primary key di quello dell'articolo in fase di modifica. Ciò suggerisce che il problema potrebbe risiedere sul lato di Bitrix. Visitiamo il loro sito e contattiamo il supporto. Riceviamo quasi subito una risposta: “problema complesso. È stato passato agli ingegneri senior — attendete…”
Abbiamo dovuto aspettare piuttosto a lungo (l'intero dialogo è avvenuto tra il 25.06.2019 e il 9.07.2019) e il risultato è stato un messaggio: “questo problema non è correlato al funzionamento del CMS Bitrix, ma è legato al funzionamento del database stesso in mariadb 10.4.6 e, sfortunatamente, non è possibile risolvere questo problema dal lato del sito; sarà necessario tornare a una vecchia versione di MariaDB.”
Siamo nei guai… Pensavo al downgrade già all'inizio della storia, ma , che non è possibile alcun downgrade. Fate i dump e reinstallate da zero. server. Cioè, è una fortuna che non abbia aggiornato tutti i server contemporaneamente. Cioè, “giusto” un centinaio di siti (risata nervosa:-)). Inoltre, dal supporto hanno detto: “Per risolvere il problema utilizzando il database MariaDB 10.4.6 dovrai contattare il supporto tecnico di MariaDB, in quanto nella transazione non verrà eseguita la cancellazione della registrazione dal DB se si effettua la richiesta:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]); Una speranza è durata un paio d'ore dall'inizio della comunicazione con il supporto di MariaDB, ma poi è arrivata una lettera in cui mi hanno comunicato in modo estremamente cortese che non sono un utente commerciale e quindi nessuno si prenderà cura del mio problema, ma c'è un forum sul loro sito dove posso provare a cercare soluzioni… Non voglio annoiarvi con i dettagli. Non ci sono soluzioni lì.
Oh! Abbiamo una licenza acquistata per ISP!
— Pronto, supporto? Ragazzi, aiutateci!
— Scusate, non supportiamo i fessacchiotti che cambiano le versioni native del DBMS. Se volete, c'è un'opzione con un server alternativo in Docker.
— Ma come faranno ad accedere gli utenti e i database? In Docker?
— Beh, li porterete lì a mano…
— Sì! E non dimenticare che la porta per mysql cambierà, e dovrai rivedere e riscrivere tutti i file di configurazione.
— Ok, grazie, ci penserò…
Ho riflettuto e ho deciso di rimuovere manualmente 10.4 e installare 10.2, con cui non ho avuto problemi su altri server.
Il processo non era molto diverso dall'aggiornamento. Dovevi solo cambiare 10.4 in 10.2 nel link al repository, resettare e ricreare la cache per yum. E c'era anche un altro "piccolo dettaglio": dopo aver rimosso 10.4, vai in /var/lib/mysql e rimuovi tutto da lì. Senza questo passaggio, dopo l'installazione di 10.2, il servizio continuerà a cadere e vedrai.
Impossibile connettersi al database '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Oppure
Lost connection to MySQL server at 'handshake: reading initial communication packet', system error: 104Prima di importare i database, ho prima impostato la password root per mysql che era indicata nei file di configurazione ISP e ho importato il dump del database mysql. Poi, poiché gli utenti e i permessi esistono già, importiamo consecutivamente tutti i database degli utenti con l'account root.
Testo dello script per il dump dei database:
#!/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'Prima di importare i database, è necessario decomprimerli. Quindi esegui semplicemente il comando
gunzip /BACK/*.gzE per finire: per qualche motivo nei nomi dei database (se creati tramite ISPmanager) sono consentiti i trattini. Ma quando si crea o si tenta di caricare un dump in un database il cui nome contiene un trattino, si riceve un messaggio che indica che la sintassi della query non è corretta.
A tutti coloro che sono riusciti a leggere fino alla fine, vi auguro il meglio. Mi scuso per la probabile mancanza di virgole — ho qualche problema con esse. Se avete suggerimenti o proposte riguardo a quanto descritto, scrivetemi in privato perché nei commenti temo di perdere qualcosa. E non siate troppo severi — questo è il mio primo articolo 🙂
AGGIORNAMENTO1:
Quasi dimenticavo di menzionare: mentre cercavo di trovare una soluzione al problema senza fare il downgrade di MariaDB, dovevo in qualche modo aggiornare le informazioni. Ho aggiornato così: l'intero database viene convertito da InnoDB a MyISAM, si aggiornano le informazioni e poi si riconverte di nuovo in InnoDB.
AGGIORNAMENTO2:
Ho appena ricevuto una lettera da 1C-Bitrix con il seguente contenuto:
Richiesta di miglioramento realizzata
«Dopo l'aggiornamento di mariadb a 10.4.6 errore durante il salvataggio dell'elemento del catalogo»
Modulo: iblock, versione: sconosciuta
Soluzione: rifiutata
Quindi, per ora non è evidente che si possa aggiornare a 10.4 🙁
Fonte: habr.com
