İyi günler sevgili Habrovitler! Kendimi tanıtmama izin ver Alexander. Küçük ama gururlu bir WEB stüdyosunun sistem yöneticisi. Her şeyin hızlı, güvenli ve yeni yazılımlarla çalışmasını gerçekten istiyoruz. Bunu yapmak için ofis içi bilgisayarda nagios + PhantomJS paketini bile yükselttik ve sayfa yükleme hızını her 30 dakikada bir kontrol ettik. Hizmet şartları gereği 1C-Bitrix güncellemelerini de takip edip düzenli olarak kuruyoruz. Ve bir gün, bir sonraki güncellemeden sonra, yönetici panelinde 2019 yazından bu yana 1C-Bitrix'in MySQL 5.5 ile çalışmayı bıraktığını ve güncellenmesi gerektiğini belirten bir mesaj görüyoruz. ISPSystem'deki adamlar yakışıklı ve panelin işlevselliğini düzenli olarak genişletiyorlar, bunun için onlara özel teşekkürler. Ancak bu sefer fareyle her şeye tıklamak mümkün olmadı. Ama ne olduğu ve sakalımda şu anda kaç tane gri saç olduğu kesimin altında bulunabilir.
Yalnızca Docker konteynerine kurulu “alternatif bir DBMS sunucusu” kurma seçeneği vardı. Elbette Docker'ın kaynaklar konusunda çok tutumlu olduğunu anlıyorum, ancak ne kadar harika çalışırsa çalışsın, ek yük yine de > 0 olacaktır. Ve işte buradayız, bir anlaşmayı yayınlayıp imzalamadan önce onda bir saniye içinde savaşıyor ve girişteki tüm siteleri optimize ediyoruz. Yani benim seçimim değil.
Tamam, belgelerde ne var? Her şeyi yedekleyin, MariaDB deposuna bağlantı içeren bir dosyayı yum.repos.d'ye ekleyin, ardından
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum daha sonra birisinin paketleri onun bilgisi olmadan çıkardığına yemin edecek. Ama önce yemin etmesine izin verin, sorun değil. İkincisi, silme işlemini yum aracılığıyla yaparsanız, MariaDB ile birlikte bağımlılıklarla ilgili olan her şeyi yok etmeye çalışır ve bu PHP, ISPManager ve PHPmyadmin'dir. Bu yüzden hatalarla daha sonra ilgileneceğiz.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonGenel olarak her şey kuruldu ve başladı. İşin güzel yanı, üslerin toplanmış olması ve onları çöplüklerden geri yüklemeye gerek kalmaması. Siteleri kontrol ettim - çalışıyorlar ve hızlılar. Hiçbir şeyin düşmediğinden emin olmak için birkaç yönetici paneline gittim ve yönetmene her şeyin yolunda olduğuna dair aboneliğimi iptal ettim. 30 dakikadan kısa bir süre içinde durumun hiç de yolunda olmadığı ortaya çıktı...
Yönetici paneline gidip içeriğe düzenleme eklemeye çalıştığımda bir mesaj düştü
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']Sitedeki içerikler çalışanlarımız tarafından eklendiğinden, müşteriler henüz hiçbir şey bilmiyorlardı ve henüz bizi ayırmaya başlamamışlardı. Ancak bu an meselesiydi çünkü sitelerdeki bilgilerin güncellenmesi gerekiyor ve birçok müşteri bunu çok yakından takip ediyor.
Hata metninden Bitrix'in, düzenlenen makalenin sahip olduğu birincil anahtarın aynısını belirtirken veritabanına yeni bir kayıt eklemeye çalıştığı sonucuna varabiliriz. Dolayısıyla sorunun Bitrix tarafında meydana geldiğinden şüphelenmek için nedenler var. Web sitelerine gidin ve destek ekibiyle iletişime geçin. Hemen hemen “zor bir problem” cevabını alıyoruz. Kıdemli mühendislere verildi - bekleyin ... "
Oldukça uzun bir süre beklemek zorunda kaldım (tüm diyalog 25.06.2019'dan 9.07.2019'a kadar gerçekleşti) ve sonuç şu mesajdı: "Bu sorun Bitrix CMS'nin çalışmasıyla ilgili değil, bununla ilgili mariadb 10.4.6'daki veritabanının işleyişine ve maalesef sitenin bu sorunu çözecek tarafının eksik olması nedeniyle MariaDB'nin daha eski bir sürümüne geçmek gerekecek."
Yelken açtı... Hikayenin başında seviye düşürmeyi düşündüm ama yani herhangi bir düşüş olamaz. Dökümleri birleştirin ve yeni kurulan bir sunucuda yeniden konuşlandırın. Onlar. tüm sunucuları aynı anda güncellememiş olmam iyi oldu. Onlar. “sadece” yüz site (gergin bir kıkırdama :-)). Destek olarak şunları da söylediler: "MariaDB 10.4.6 veritabanını kullanırken sorunu çözmek için, MariaDB teknik desteğiyle iletişime geçerek, bir talepte bulunulması durumunda işlemin veritabanından bir kaydı silmeyeceğine dair bilgi almanız gerekir:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
MariaDB desteğiyle iletişim kurmaya başladığımız andan itibaren birkaç saat boyunca umut parladı, ancak daha sonra ticari bir kullanıcı olmadığım ve bu nedenle kimsenin sorunumu kasıtlı olarak çözmeyeceği konusunda son derece doğru bir şekilde bilgilendirildiğim bir mektup aldım, ancak ortada bir sorun var. Web sitelerinde bir forum var ve oradaki seçeneklere bakmayı deneyebilirsiniz… Sizi ayrıntılarla sıkmayacağım. Orada hiçbir seçenek yok.
HAKKINDA! ISP için bir lisans satın aldık!
Merhaba, destek? Çocuklar, yardım edin!
- Üzgünüz, DBMS'nin yerel sürümlerini değiştiren haydutları desteklemiyoruz. İsterseniz docker'da alternatif sunuculu bir seçenek var.
- Peki kullanıcılar ve veritabanları oraya nasıl ulaşacak? Docker'a mı?
- Onları ellerinle oraya sürüklersin ...
- Evet! Ve MySQL bağlantı noktasının değişeceğini ve tüm yapılandırmaları gözden geçirip yeniden yazmanız gerekeceğini unutmayın.
Tamam teşekkürler, düşüneceğim...
Düşündüm ve 10.4'ü tanıtıcılarla yıkıp diğer sunucularda sorun olmayan 10.2'yi kurmaya karar verdim.
Süreç yükseltme işleminden pek farklı değildi. Yalnızca depo bağlantısındaki 10.4'ü 10.2'ye değiştirmek, yum için önbelleği sıfırlamak ve yeniden oluşturmak gerekiyordu. Peki, bir "önemsiz şey" daha: 10.4'ü kaldırdıktan sonra /var/lib/mysql'e gidiyoruz ve oradan her şeyi siliyoruz. Bu adım olmadan, 10.2'yi yükledikten sonra hizmet sürekli olarak çökecek ve şunu göreceksiniz:
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Veya
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Veritabanlarını içe aktarmadan önce ilk olarak ISP yapılandırmalarında belirtilen mysql root şifresini ayarladım ve mysql veritabanı dökümünü içe aktardım. Öyleyse, zaten kullanıcılar ve haklar olduğundan, tüm kullanıcı veritabanlarını kök hesapla arka arkaya içe aktarıyoruz.
Veritabanı dökümü için komut dosyası metni:
#!/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'Veritabanlarını içe aktarmadan önce bunları açmanız gerekir. Yani sadece komutu çalıştırın
gunzip /BACK/*.gzVe son olarak: Bazı nedenlerden dolayı, veritabanı adlarında kısa çizgilere izin verilir (eğer bunları ISPmanager kullanarak oluşturursanız). Ancak adında kısa çizgi bulunan bir veritabanına döküm oluştururken veya yüklemeye çalışırken, sorgu sözdiziminin yanlış olduğunu belirten bir mesaj alırsınız.
Bütün nimetleri sonuna kadar okuyun. Büyük olasılıkla aralıksız virgüller için özür dilerim - başları dertte. Esas olarak açıklanan bir teklif için dilekleriniz varsa - kişisel olarak yazın çünkü yorumlarda bir şeyi kaçırmaktan korkuyorum. Ve çok fazla yemin etmeyin - bu benim ilk makalem 🙂
GÜNCELLEME1:
Neredeyse şunu söylemeyi unutuyordum: MariaDB'nin sürümünü düşürmeden soruna bir çözüm bulmaya çalışırken, bir şekilde bilgileri güncellemek zorunda kaldım. Bu şekilde güncellendi: tüm veritabanı InnoDB'den MyISAM'e dönüştürüldü, infa güncellendi ve ardından tekrar InooDB'ye dönüştürüldü.
GÜNCELLEME2:
Az önce 1C-Bitrix'ten aşağıdaki içeriğe sahip bir mektup aldım:
Revizyon talebi tamamlandı
"Mariadb 10.4.6'ya güncellendikten sonra bilgi bloğu öğesi kaydedilirken bir hata oluştu"
Modül: iblock, sürüm: bilinmiyor
Çözüm: reddedildi
Yani şimdilik 10.4'e güncellemek imkansız gibi görünüyor 🙁
Kaynak: habr.com