Ons kan alle mysql-versoeke van 'n sekere gebruiker maklik met die elegante een doodmaak:

select concat('KILL ',id,';') from information_schema.processlist where user='user123';

Ons vervang user123 deur die gebruiker wat ons wil hê en hardloop in mysql en alles is in orde 🙂

Ons het verlede week die Fantastico Deluxe-installeerder gekoop, wat na my nederige opinie een van die fatsoenlikste is vir CPanel-bedieners. Ons het dit geïnstalleer, dit getoets en alles het verloop. Vandag het 'n kliënt 'n probleem met die kodering van 'n wordpress-installasie gerapporteer. Ek het dinge nagegaan en dadelik lig gewerp op die probleem, die databasisse is standaard gekodeer Latyn1 in plaas van UTF8 soos dit veronderstel was. Dit is nog lekkerder, dat daar in phpmyadmin geskryf word dat UTF8 standaard gebruik word, drama. Ek het besluit om na die Fantastico-lêers te kyk om te sien of daar êrens is waar ek die standaard-databasisinstellings met die eerste oogopslag kon voorsien; ek het niks gesien nie. Toe het iets my gehaas om te sien wat in my.conf is en wat om te sien daar was geen ooreenstemmende instellings in die konfigurasie nie, en alles werk soos dit standaard gestel is. Die Mysql-bediener is 'n harde kode om UTF8 te gebruik as dit nie met ander instellings gekonfigureer is nie en die Fantastico is natuurlik met Latin1 ( wat 'n mooi dom besluit is). Die oplossing soos altyd word triviaal bygevoeg 2 bestel c [mysqld] deel om UTF8 die standaardkodering te maak en alles raak aan die slaap 🙂

karakter-stel-bediener = utf8
kollasie-bediener = utf8_general_ci

Ek het geen idee waarom ek hierdie instellings mis het nie, aangesien ek 'n paar speel “fyn” mysql-instellings.

Versterk deur Zemanta

Преди няколко дни излезе XAMPP 1.8.0 вчера след надграждане от версия 1.7.7 имах доста интересен проблем. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403

Access forbidden!


New XAMPP security concept:

Access to the requested object is only available from the local network.

This setting can be configured in the filehttpd-xampp.conf”.

Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. WTF ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Require all granted. О да еврика. Това е новия контролен механизъм който влезе в apache 2.4.x. С него се дава достъп или се отказва такъв на всички изискани, в общи линии се имитира Allow/Deny функционалността :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. Na die veranderinge lyk dit vir my so

<Gids “/kies / lampp / phpmyadmin”>
Laat toe dat AuthConfig-limiet oorgedra word
Bestel laat toe,ontken
Laat alles toe
Require all granted
</Gids>

 

Viangi kan ander barbare probeer, byvoorbeeld om die phpmyadmin-gids te hernoem na iets anders en 'n alias na nr. Maar dit is leliker en nie baie sinvol nie 🙂

p.s Ek is gevra waarom ek XAMPP gebruik en nie 'n skoon installasie van alle komponente nie, aangesien my Debian geboorte daaraan gegee het – die antwoord is baie eenvoudig – luiheid. Ek is te lui om 'n paar opdragte te skryf, raak dan my conf ens. Dit is baie makliker om die hele pakket af te laai, uit te pak en te verbrand 😉

Versterk deur Zemanta

Image representing MySQL as depicted in CrunchBase

Ek het 'n geruime tyd gelede geskryf MySQL volledige teks soek 🙂 Vandag het ek 'n baie interessante ervaring met een versoek gehad. In die algemeen kyk die navraag na resultate wat in 'n ander tabel ontbreek. Een basiese seleksie en een subkeuse in die WAAR-deel van die navraag. Oor die algemeen is die skelet

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

Basies 'n eenvoudige navraag. Ek het dit geskryf 30 sec ek hardloop dit en die masjien loop. Na 'n lang en geduldige wag van my kant of meer presies ~ 43 sek . Ek spoeg die resultaat uit lol . Pffff madhouse. Ek gaan die masjien binne en kyk dat die SVE gewoonlik amper in 'n rustige toestand gelaai is. Skok en afgryse. Ek het die vraag weer dieselfde resultaat. Fok WTF. Ek het die navraag verduidelik en alles skyn – die tweede veld secondTextField is slegs volledige teks soek sonder indeks, en daar is die plaat beskeie van ongeveer 35k lyne. Wie om te lees – volteks soek is nie 'n indeks nie. Die probleem is vinnig duidelik

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

En dinge het op die plek geval wat Query aangeneem het 0.0005 sek 😀

Wees versigtig hoe u die indekse daaruit plaas, die spoed van die navraag hang effens van u af.

p.s Oor die algemeen is ek die skuld vir bogenoemde situasie, nie net omdat dit nie 'n indeks het nie, maar omdat dit nie die volledige teks-soekmetode gebruik nie 😀

Versterk deur Zemanta

Вчера след обновяване на версията на mysql, server-ът ми започна да ми крещи, че има табличка, която не е била затворена чисто и има нужда от поправка и прочие. Блах, коя ще е тая таблица, все пак са ми около 30-тина на тоя сървър. Единият вариант е да видите в log-овете какво пише по въпроса и да пуснете поправка на съответната таблица или другият вариантдалеч по-добрияте да пуснете поправка, проверка и оптимизиране на всички таблици. За тази цел ще използвам mysqlcheck инструмента. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъвароматична поправка, проверка и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.