Salve, mi Khabrovsk habitant! Introducem me, Alexander. Ratio administrator unius parvi sed superbi VUL STUDIOSORUM. Re vera omnia volumus celeriter, tuto et cum programmate novissimo laborare. Ad hoc faciendum, etiam fasciculum phantasticum in nagios+PhantomJS in computatrum intra-officium constituimus et paginam onerantium celeritatem singulis 30 minutis reprehendo. Iuxta condicionem servitii nos etiam monitores 1C-Bitrix renovantes ac regulariter instituimus. Uno deinde die, post proximam renovationem, nuntium in tabula admin cernimus quod post aestatem 2019, 1C-Bitrix cum MySQL 5.5 laborat ac renovare oportet. Guys ex ISPSystem pulchri sunt et regulariter functionem tabellae expandunt, pro quibus speciales gratias eis agunt. Sed hoc tempus non erat omnia cum mure strepere. Sed scias quid acciderit, et quot canitie nunc in barba mea sub incisa sint.
Sola optio fuit ut instituendi "alterativus DBMS server" in Docker vase installatur. Nimirum intelligo Docker valde frugalem opibus, sed quantumvis magnas agit, caput adhuc erit >0. Et hic videmur pugnare in secundis decimis et optimizing omnibus locis in introitu ante editam et conventionem signando. Ne mea option.
Ok, what does the documentation say? Tergum omnia, fasciculum ad yum.repos.d cum nexu ad MariaDB repositorium adde, deinde
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum postea iurabit aliquem fasciculos inscio suo delevisse. Sed ante omnia iuret, bene est. Secundo, si deletionem per yum facias, tunc removere conatur, una cum MariaDB, omne quod ei per dependentiam annexum est, et hoc includit PHP et ISPManager et PHPmyadmin. Ideo de iureiurando postea agemus.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonFere omnia inaugurata sunt et inchoata. Grata res est quod databases lecta sunt nec opus erat ut eas e dumps restitueret. Sedatus situs - laborant et celeriter sunt. Ivi in ββduos areas admin ut caveret nihil decidisse et rescripsi ad rectorem omnia OK esse. Minus quam 30 minuta post accidit quod omnino non erat OK.
Cum in aream admin ire conatus sum et aliquid addere ac recensere in re contenta, nuntium papaver sursum
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']Cum argumenta in situ ab operariis nostris addantur, clientes nihil adhuc sciunt nec adhuc nos discerpere inceperunt. Sed res temporis erat, quod notitias in locis renovandas esse oportet, et multi clientes arcte monent hoc ipsi.
Ex textu erroris concludere possumus quod Bitrix conetur novum ingressum ad database addere, denotans eandem primariam clavem quae in edito articulo erat. Hoc significat causam suspicari quaestionem in Bitrix parte oriri. Ad eorum website et contactus adminicula imus. Fere statim responsum "complicatum" consequimur. Das id maioribus fabrum - opperiri...
Satis diu exspectandum erat (totus dialogus a die 25.06.2019 Iunii 9.07.2019 ad diem 10.4.6 iulii XNUMX factus est) et eventus fuit nuntius "hoc problema non operationi Bitrix CMS refertur, sed ad verbum refertur. operatio ipsius database in mariadb XNUMX et, proh dolor, cum In latere situs, hunc problema solvendum nullo modo est, necesse est ut ad veterem versionem MariaDB vertas".
Venerunt... Cogitavi de downgrad in principio fabulae, sed quod nulla turpitudo esse potest. Effundite dumps et re-explicare in servo perfecte inauguratus est. Illae. Bonum est quod omnes simul ministrantes non renovavi. Illae. "tantum" centum sites (risum nervorum :-)). Firmamentum etiam dixit: "Ad solvendam quaestionem cum MariaDB 10.4.6 database utens, technicam MariaDB auxilium contactum necesse erit quod gestum non delebit recordum e datorum, si petitio fiat:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);β
Spes per horas duas ab momento incepi communicare cum MariaDB auxilio, sed litteras accepi in quibus mihi rectissime dicebant me non esse commercialem usorem ideoque nemo de industria solvet quaestionem meam, sed est. forum in suo situ et ibi optiones tuas quaerere potes... Non te pertuli cum singulis. Nulla consequat tincidunt nulla.
FERE! ISP licentiam emimus!
- Salve, subsidium? Guys adiuva!
β Nos paenitet, scumbagibus non sustinemus qui vernaculas versiones DBMS mutant. Si vis, optio cum joco servientis in Docker datur.
- Sed quomodo illuc users et databases? Ad dock?
- Bene eos ibi manibus trahis.
- Ita! Et noli oblivisci quod portum pro mysql mutabit et per omnes ficos debes ire et eas rescribe.
- Bene, gratias, cogitabo...
Cogitavi de ea et manually 10.4 demoliri et instituere 10.2 constitui, cum quibus nullae quaestiones in aliis servientibus erant.
Processus non multum differt ab evolutione processus. EGO iustus had mutare 10.4 ad 10.2 in nexu repositorium, reset et re-creare cache pro yum. Bene, unum plusculum: dempto 10.4, vade ad /var/lib/mysql et inde omnia dele. Sine hoc passu, insertis 10.2, servitium constanter fragorem et videbis
ΠΠ΅ ΡΠ΄Π°Π»ΠΎΡΡ ΠΏΠΎΠ΄ΠΊΠ»ΡΡΠΈΡΡΡΡ ΠΊ Π±Π°Π·Π΅ Π΄Π°Π½Π½ΡΡ
'' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"uel
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Antequam databases invehendo, primum tesseram radicis pro mysql quae in ISP confis definita erat et in dump datorum mysql importabat. Bene ergo, cum iam utentes et iura habemus, simpliciter omnes databases utentes in ordine importamus in ratione utentis radicis.
Scriptor textus pro database TUBER:
#!/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'Priusquam databases inferentes, debes eas unzip. Sic nos iustus run imperium
gunzip /BACK/*.gzAc denique: aliqua de causa, hyphens permittitur in nomine datorum (si per ISPmanager eam creas). Cum autem creas vel conantur emittere TUBER ad database quod habet nomen hyphen, accipis nuntium quod syntaxin petitio falsa est.
Optima legentibus in finem. Ego paenitet maxime abhorrentes commatibus - quaestio sunt. Si quid habes suggestiones de essentia eorum quae describitur, scribe in nuntio personali quia timeo ne quid in commentis fallar. Nec nimium iuras - primus est articulus meus :)
UPD1:
Paene commemorare oblitus sum: dum conabar solutionem problematis sine gradu MariaDB invenire, notitias quodammodo renovare debebam. Renovatum est hoc modo: totum datorum ab InnoDB ad MyISAM convertitur, info renovatur et rursus ad InooDB convertitur.
UPD2:
Modo litteras accepi ab 1C-Bitrix cum sequenti contento:
Petitio recognitionis complebitur
"Post upgrading mariadb ad 10.4.6, error occurrit cum elementum infoblock servatum"
OMNIBUS: iblock, version: ignotus
Solutio: reprobatum
Ita non videtur posse pro nunc 10.4 renovare
Source: www.habr.com