Bitrix և MariaDB-ի թարմացում վերջին կայուն տարբերակին

Բարի օր, սիրելի խաբրովիցիներ։ Թույլ տվեք ներկայանալ, Ալեքսանդր։ Մեկ փոքրիկ, բայց հպարտ WEB-ստուդիայի համակարգի ադմինիստրատոր: Մենք իսկապես ցանկանում ենք, որ ամեն ինչ աշխատի արագ, ապահով և թարմ ծրագրաշարով: Դա անելու համար մենք նույնիսկ բարձրացրեցինք nagios + PhantomJS փաթեթը ներգրասենյակային համակարգչում և ստուգեք էջի բեռնման արագությունը յուրաքանչյուր 30 րոպեն մեկ: Համաձայն ծառայության պայմանների՝ մենք նաև վերահսկում ենք 1C-Bitrix թարմացումները և պարբերաբար տեղադրում դրանք։ Եվ հետո մի օր, հաջորդ թարմացումից հետո, մենք տեսնում ենք հաղորդագրություն ադմինիստրատորի վահանակում այն ​​մասին, որ 2019 թվականի ամառվանից 1C-Bitrix-ը դադարում է աշխատել MySQL 5.5-ի հետ և պետք է թարմացվի: ISPSystem-ի տղաները գեղեցիկ են և պարբերաբար ընդլայնում են վահանակի ֆունկցիոնալությունը, ինչի համար հատուկ շնորհակալություն են հայտնում նրանց։ Բայց այս անգամ հնարավոր չեղավ մկնիկով սեղմել ամեն ինչ։ Բայց այն, ինչ եղավ, և քանի՞ մոխրագույն մազ կա մորուքիս մեջ, կարելի է գտնել կտրվածքի տակ։

Կար միայն «այլընտրանքային DBMS սերվեր» տեղադրելու տարբերակ, որը տեղադրված է Docker կոնտեյներով: Իհարկե, ես հասկանում եմ, որ Docker-ը շատ խնայող է ռեսուրսների հարցում, բայց որքան էլ այն լավ աշխատի, գերավճարը դեռ կլինի > 0: Եվ ահա մենք, իբրև թե, տասներորդական վայրկյանում պայքարում ենք և մուտքի մոտ բոլոր կայքերը օպտիմալացնում ենք նախքան համաձայնագիրը հրապարակելը և ստորագրելը։ Այնպես որ, ոչ իմ ընտրությունը:
Լավ, ինչ կա փաստաթղթերում: Կրկնօրինակեք ամեն ինչ, ավելացրեք ֆայլ՝ հղումով MariaDB պահեստին yum.repos.d-ին, այնուհետև

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common

Յամը հետագայում երդվելու է այն փաստի վրա, որ ինչ-որ մեկը հանել է փաթեթներն առանց իր իմացության: Բայց նախ՝ թող երդվի, ոչինչ։ Եվ երկրորդը, եթե ջնջումն անում ես yum-ի միջոցով, ապա այն փորձում է MariaDB-ի հետ միասին քանդել այն ամենը, ինչ կապված է իր հետ կախվածություններով, և սա PHP-ն ու ISPMmanager-ն ու PHPmyadmin-ն է։ Այսպիսով, մենք ավելի ուշ կզբաղվենք սխալներով:


yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-common

Ընդհանրապես, ամեն ինչ կարգավորվեց ու սկսվեց։ Հաճելին այն է, որ հենակետերը վերցվել են, և պետք չի եղել դրանք աղբավայրերից վերականգնել։ Ես ստուգեցի կայքերը, նրանք աշխատում են և արագ: Ես գնացի մի քանի ադմինիստրատորի վահանակ՝ համոզվելու, որ ոչինչ չի ընկել և բաժանորդագրվել եմ տնօրենին, որ ամեն ինչ կարգին է: 30 րոպեից էլ քիչ ժամանակում պարզվեց, որ ամենևին էլ լավ չէ…

Երբ ես փորձեցի գնալ ադմինիստրատորի վահանակ և բովանդակության մեջ որևէ բան խմբագրել, մի հաղորդագրություն դուրս եկավ

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']

Քանի որ կայքի բովանդակությունը ավելացվում է մեր աշխատակիցների կողմից, հաճախորդները դեռ ոչինչ չգիտեին և դեռ չէին սկսել մեզ բաժանել: Բայց դա ժամանակի հարց էր, քանի որ կայքերի տեղեկատվությունը թարմացման կարիք ունի, և շատ հաճախորդներ շատ ուշադիր հետևում են դրան:

Սխալի տեքստից կարող ենք եզրակացնել, որ Bitrix-ը փորձում է տվյալների բազայում նոր գրառում ավելացնել՝ միաժամանակ նշելով նույն հիմնական բանալին, որն ուներ խմբագրվող հոդվածը։ Այսպիսով, հիմքեր կան կասկածելու, որ խնդիրը տեղի է ունենում Bitrix-ի կողմից: Գնացեք նրանց կայք և կապվեք աջակցության հետ: Գրեթե անմիջապես մենք ստանում ենք «բարդ խնդիր» պատասխանը. Տրվում է ավագ ինժեներներին - սպասեք ... »:

Ես ստիպված էի բավականին երկար սպասել (ամբողջ երկխոսությունը տեղի ունեցավ 25.06.2019/9.07.2019/10.4.6-ից մինչև XNUMX/XNUMX/XNUMX) և արդյունքը եղավ «այս խնդիրը կապված չէ Bitrix CMS-ի շահագործման հետ, այլ կապված է բուն mariadb XNUMX-ում տվյալների բազայի աշխատանքին և, ցավոք, այս խնդրի լուծման համար կայքի կողմը բացակայում է, անհրաժեշտ կլինի տեղափոխել MariaDB-ի ավելի հին տարբերակ»:

Նավարկված ... Ես մտածեցի պատմության սկզբում իջեցնել վարկանիշը, բայց այստեղ սև ու սպիտակոր վարկանիշի իջեցում չի կարող լինել։ Միավորել աղբավայրերը և վերաբաշխել նոր տեղադրված սերվերի վրա: Նրանք. լավ է, որ միանգամից չթարմացրի բոլոր սերվերները։ Նրանք. «ընդամենը» հարյուր կայք (նյարդային քրքիջ :-)): «MariaDB 10.4.6 տվյալների բազան օգտագործելիս խնդիրը լուծելու համար դուք պետք է կապվեք MariaDB տեխնիկական աջակցության հետ, որ գործարքը չի ջնջի գրառումը տվյալների բազայից, եթե հարցում կատարվի.

$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”

Հույսը փայլեց մի քանի ժամվա ընթացքում այն ​​պահից, երբ մենք սկսեցինք շփվել MariaDB աջակցության հետ, բայց հետո ես նամակ ստացա, որում ես չափազանց ճիշտ տեղեկացված էի, որ ես առևտրային օգտատեր չեմ և, հետևաբար, ոչ ոք նպատակաուղղված չի լուծի իմ խնդիրը, բայց կա. ֆորում նրանց կայքում, և դուք կարող եք փորձել այնտեղ տարբերակներ փնտրել… Ես ձեզ չեմ ձանձրացնի մանրամասներով: Այնտեղ տարբերակներ չկան։
ՄԱՍԻՆ! Մենք լիցենզիա ենք գնել ISP-ի համար:
Բարև, աջակցություն: Տղե՛րք, օգնե՛ք։
- Ներեցեք, մենք չենք աջակցում ավազակներին, ովքեր փոխում են DBMS-ի բնօրինակ տարբերակները: Եթե ​​ցանկանում եք, այլընտրանքային սերվերով տարբերակ կա docker-ում:
- Բայց ինչպե՞ս են այնտեղ հասնելու օգտատերերն ու տվյալների բազաները: Նավահանգստի՞ն:
-Դե, դու նրանց ձեռքերով քաշում ես այնտեղ...
-Այո՜ Եվ մի մոռացեք, որ mysql-ի պորտը կփոխվի, և դուք պետք է անցնեք և վերագրեք բոլոր կոնֆիգուրները:
Լավ, շնորհակալություն, կմտածեմ...
Մտածեցի ու որոշեցի քանդել 10.4-ը բռնակներով ու տեղադրել 10.2, որի հետ այլ սերվերների վրա խնդիր չկար։

Գործընթացը շատ չէր տարբերվում արդիականացման գործընթացից: Միայն անհրաժեշտ էր պահեստի հղումում փոխել 10.4-ը 10.2-ի, զրոյացնել և վերստեղծել yum-ի քեշը։ Դե, ևս մեկ «մանրուք»՝ 10.4-ը հեռացնելուց հետո գնում ենք /var/lib/mysql և այնտեղից ջնջում ենք ամեն ինչ։ Առանց այս քայլի, 10.2-ը տեղադրելուց հետո ծառայությունը անընդհատ խափանում է, և դուք կտեսնեք

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Կամ

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

Նախքան տվյալների բազաները ներմուծելը, ես նախ դրեցի mysql արմատային գաղտնաբառը, որը նշված էր ISP-ի կոնֆիգուրացիաներում և ներմուծեցի mysql տվյալների բազայի աղբանոցը: Դե, ուրեմն, քանի որ արդեն կան օգտատերեր և իրավունքներ, մենք ուղղակի անընդմեջ ներմուծում ենք օգտատերերի բոլոր տվյալների բազաները՝ արմատային հաշվի հետ։

Տվյալների բազայի աղբանոցի սցենարի տեքստ.

#!/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'

Տվյալների շտեմարաններ ներմուծելուց առաջ դուք պետք է ապափափակեք դրանք: Այսպիսով, պարզապես գործարկեք հրամանը

gunzip /BACK/*.gz

Եվ վերջին բանը. չգիտես ինչու, տվյալների բազայի անուններում թույլատրվում են գծիկները (եթե դրանք ստեղծում եք ISPmanager-ի միջոցով): Բայց երբ ստեղծում կամ փորձում եք աղբավայր վերբեռնել տվյալների շտեմարան, որն անվանման մեջ ունի գծիկ, դուք հաղորդագրություն եք ստանում, որ հարցման շարահյուսությունը սխալ է:

Կարդացեք մինչև վերջ բոլոր օրհնությունները: Ներողություն եմ խնդրում, ամենայն հավանականությամբ, ոչ մի ստորակետերի համար. նրանք դժվարության մեջ են: Եթե ​​առաջարկի ցանկություններ կան, ըստ էության նկարագրված, գրեք անձնականում, քանի որ մեկնաբանություններում ես վախենում եմ ինչ-որ բան բաց թողնել: Եվ շատ մի հայհոյեք - սա իմ առաջին հոդվածն է 🙂

UPD1:

Ես գրեթե մոռացել էի նշել. մինչ ես փորձում էի խնդրի լուծում գտնել առանց MariaDB-ի վարկանիշը իջեցնելու, ես ստիպված էի ինչ-որ կերպ թարմացնել տեղեկատվությունը: Այն թարմացվել է այսպես. ամբողջ տվյալների բազան փոխարկվում է InnoDB-ից MyISAM, infa-ն թարմացվում է և այնուհետև նորից վերածվում InooDB-ի:
UPD2:

Հենց նոր նամակ ստացա 1C-Bitrix-ից հետևյալ բովանդակությամբ.

Վերանայման հարցումն ավարտված է
«Mariadb-ը 10.4.6-ին թարմացնելուց հետո ինֆոբլոկի տարրը պահելիս սխալ է տեղի ունեցել»
Մոդուլ՝ iblock, տարբերակը՝ անհայտ
Լուծում` մերժված

Այսպիսով, առայժմ, ըստ երևույթին, անհնար է թարմացնել մինչև 10.4 🙁

Source: www.habr.com

Добавить комментарий