Buon pomeriggio, cari Habriani! Permettetemi di presentarmi, Alessandro. Amministratore di sistema di uno piccolo ma orgoglioso studio WEB. Vogliamo davvero che tutto funzioni rapidamente, in modo sicuro e con software aggiornato. A tal fine, abbiamo persino configurato nel computer dell'ufficio una combinazione di nagios+PhantomJS e ogni 30 minuti verifichiamo la velocità di caricamento delle pagine. Secondo i termini di servizio, monitoriamo anche gli aggiornamenti di 1C-Bitrix e li installiamo regolarmente. E così, un giorno, dopo l'ennesimo aggiornamento, vediamo un messaggio nel pannello di amministrazione che informa che da estate 2019 1C-Bitrix smetterà di funzionare con MySQL 5.5 e occorre aggiornare. I ragazzi di ISPSystem sono fantastici e ampliano regolarmente le funzionalità del pannello, per cui un grazie a loro. Ma questa volta non è stato possibile cliccare tutto con il mouse. E riguardo a quanto siamo riusciti a fare e a quanti capelli bianchi ci sono adesso nella mia barba, potete scoprirlo di seguito.
C'era solo la possibilità di installare un 'server DBMS alternativo' che va installato in un contenitore Docker. Certo, capisco che Docker è molto 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 il contratto. Quindi non è la mia soluzione.
Ok, cosa c'è scritto nella documentazione? Backup completo, aggiungere un file in yum.repos.d con il link al repository MariaDB, poi
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum si lamenterà successivamente del fatto che qualcuno ha rimosso installato pacchetti senza il suo consenso. Ma in primo luogo - lasciamo che si lamenti, non è nulla di grave. E in secondo luogo, se si fa la rimozione tramite yum, lui cerca di rimuovere insieme a MariaDB anche tutto ciò che è legato a lui per dipendenze, e questo include PHP, ISPManager e PHPmyadmin. Quindi ci occupiamo delle lamentele in seguito.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonIn generale, tutto è stato installato e avviato. È piacevole che i database siano stati riconosciuti e non sia stato necessario ripristinarli dai dump. Ho controllato i siti: funzionano e velocemente. Sono entrato in un paio di pannelli di amministrazione per assicurarmi che nulla fosse andato storto e ho informato il direttore che tutto era OK. Non sono passati neanche 30 minuti quando è emerso che non era per niente OK…
Quando ho provato ad accedere al pannello di amministrazione e aggiungere/modificare qualsiasi cosa nel contenuto, appariva un 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 FR OM b_iblock_property P WHERE ID = 184 [[1062] Voce duplicata '10555' per chiave 'PRIMARY']Poiché il contenuto sul sito viene aggiunto dai nostri stessi collaboratori, i clienti non sapevano ancora nulla e non hanno iniziato a stracciarci. Ma era solo una questione di tempo, poiché le informazioni sui siti devono essere aggiornate e molti clienti lo controllano da soli e con attenzione.
Dal testo dell'errore si può dedurre che Bitrix sta cercando di aggiungere una nuova registrazione nel database, specificando lo stesso chiave primaria di quell'articolo in fase di modifica. Ci sono quindi motivi per sospettare che il problema si verifichi sul lato di Bitrix. Andiamo sul loro sito e contattiamo il supporto. Riceviamo quasi subito la risposta "problema complesso. Abbiamo passato la questione agli ingegneri senior - aspettate..."
Abbiamo dovuto aspettare piuttosto a lungo (l'intero dialogo è avvenuto dal 25.06.2019 al 09.07.2019) e il risultato è stato un messaggio "questo problema non è legato al funzionamento della CMS Bitrix, ma al funzionamento stesso del database in mariadb 10.4.6 e, sfortunatamente, dal lato del sito non è possibile risolvere questo problema; sarà necessario tornare a una versione precedente di MariaDB."
Siamo messi male... Avevo pensato al downgrade sin dall'inizio della storia, ma , che non è possibile alcun downgrade. Fate i dump e reinstallate tutto su un sistema pulito server. Cioè, è una fortuna che non ho aggiornato immediatamente tutti i server. Cioè, "solamente" un centinaio di siti (risata nervosa:-)). Inoltre, nel supporto hanno detto: "Per risolvere il problema utilizzando il database MariaDB 10.4.6 sarà necessario contattare il supporto tecnico di MariaDB, perché nella transazione non verrà eseguita la cancellazione del record dal DB, se viene effettuata la richiesta:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);" La speranza è durata un paio d'ore dall'inizio della comunicazione con il supporto di MariaDB, ma poi è arrivata una lettera in cui mi è stato comunicato molto gentilmente che non sono un utente commerciale e quindi nessuno si occuperà specificamente del mio problema, ma c'è un forum sul loro sito dove posso cercare delle soluzioni... Non voglio annoiarvi con i dettagli. Non ci sono soluzioni lì.
Oh! Abbiamo una licenza acquistata per l'ISP!
— Pronto, supporto? Ragazzi, aiutatemi!
— Mi scuso, non supportiamo i congelatori che cambiano le versioni native del DBMS. Volete — c'è un'opzione con un server alternativo in Docker.
— Ma come arriveranno gli utenti e i database là? In Docker?
— Beh, li porterete lì a mano...
— Sì! E non dimenticate che la porta per mysql cambierà e dovrete controllare e riscrivere tutti i file di configurazione.
— Ok, grazie, ci penserò...
Ho riflettuto e ho deciso di rimuovere manualmente la versione 10.4 e installare la 10.2 con cui non avevo avuto problemi su altri server.
Il processo non differiva molto da quello dell'aggiornamento. Dovevo semplicemente cambiare 10.4 in 10.2 nel link al repository, resettare e ricreare la cache per yum. E un'altra "piccola cosa": dopo aver rimosso 10.4, andiamo in /var/lib/mysql e cancella tutto da lì. Senza questo passaggio, dopo l'installazione di 10.2, il servizio si fermerà continuamente e vedrete
Impossibile connettersi al database '' Lost connection to MySQL server at 'reading initial communication packet', errore di sistema: 104 "Connection reset by peer"Oppure
Lost connection to MySQL server at 'handshake: reading inital communication packet', errore di sistema: 104Prima di importare i database, ho prima impostato la password root per mysql che era specificata nei file di configurazione di ISP e ho importato il dump del database mysql. E poi, poiché gli utenti e i permessi erano già presenti, importiamo semplicemente in sequenza tutti i database 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 estrarli. Pertanto, eseguiamo semplicemente il comando
gunzip /BACK/*.gzE per finire: per qualche motivo, nei nomi dei database (se creati tramite ISPmanager) sono consentiti i trattini. Tuttavia, durante la creazione o il tentativo 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 chi ha letto fino alla fine, auguri. Mi scuso per le virgole probabilmente mal posizionate — sono un problema. Se avete suggerimenti o richieste sui contenuti descritti — scrivetemi in privato perché nei commenti temo di perdere qualcosa. E non arrabbiatevi troppo — questo è il mio primo articolo 🙂
UPD1:
Quasi dimenticavo di menzionare: mentre cercavo di trovare una soluzione al problema senza downgrade di MariaDB, dovevo aggiornare le informazioni in qualche modo. Era aggiornata così: l'intero database è convertito da InnoDB a MyISAM, le informazioni vengono aggiornate e poi riconvertito di nuovo in InnoDB.
UPD2:
Ho appena ricevuto una lettera da 1C-Bitrix con il seguente contenuto:
La richiesta di modifica è stata realizzata
«Dopo l'aggiornamento di mariadb a 10.4.6 errore durante il salvataggio dell'elemento dell'infobase»
Modulo: iblock, versione: sconosciuta
Soluzione: rifiutata
Quindi, al momento sembra che non si possa aggiornare a 10.4 🙁
Fonte: habr.com
